[Ksummit-2012-discuss] PCI breakout session

Bjorn Helgaas bhelgaas at google.com
Mon Jun 18 20:21:45 UTC 2012


On Mon, Jun 18, 2012 at 5:25 AM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Mon, 2012-06-18 at 11:08 +0300, Michael S. Tsirkin wrote:

>> An interesting related problem is hot-plugging complex bridged hierarchies - esoteric
>> on real hardware but easy and sometimes useful in a VM.
>> It would seem that at least for that space, adding support
>> for moving resources around could be useful. For things like IO it
>> only seems possible to do with cooperation from the drivers - and at least for
>> VMs that's not such a big deal as we only emulate a handful of devices.
>> Or do we need to try and solve it generally straight away?
>
> What's missing?  Some of the parisc systems end up with crap (or no)
> window assignments when left to firmware, so we do a lot of re-layout of
> PCI device resources (see for example drivers/parisc/dino.c).
>
> This shouldn't be generic: you need a lot of platform internals
> knowledge to muck around with PCI bus resource assignments, so I'd need
> convincing there should be a more generic interface than the existing
> pci bios fixup callbacks.

I'm trying to eradicate pcibios_fixup_bus() and
pcibios_fixup_resources() by adding core support for host bridge
apertures and address offsets and resource claiming.

If you're talking about platform internals knowledge for mucking
around with host bridges, I fully agree.  But you already know host
bridge discovery and programming is not architected by PCI, so I
suspect you mean something else.

Once we get below the host bridge and start dealing with PCI endpoints
and P2P bridges, I don't think we should need platform knowledge
except maybe for alignment constraints and address ranges to avoid.
Can you elaborate on things I'm missing?

Bjorn


More information about the Ksummit-2012-discuss mailing list