[Ksummit-2012-discuss] PCI breakout session

James Bottomley James.Bottomley at HansenPartnership.com
Mon Jun 18 21:27:48 UTC 2012

On Mon, 2012-06-18 at 14:21 -0600, Bjorn Helgaas wrote:
> 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?

Well, I was actually wondering if something like a host bridge driver
(like they have/had in solaris) might help this case?  It would be able
to poke about with the bridge aperture internals (via the pci bios
callbacks or whatever replaces them).  All it needs is some way of
binding to the virtualisation bridge and we're there.

However, I'm still confused about whether the problem is actually just
doing a re-layout of the bridge or whether it's really the PCI resource
issue Peter referred to.


More information about the Ksummit-2012-discuss mailing list