[SeaBIOS] [Qemu-devel] [PATCH V2] pci: fixes to allow booting from extra root pci buses.

[Benjamin Herrenschmidt]

On Sun, 2015-06-14 at 20:06 +0200, Michael S. Tsirkin wrote:

> > As I understand it, the use case for multiple PCI roots is large
> > servers that process a lot of IO.
> 
> For better or worse, guest OS-es assume that numa locality
> can only be specified for PCI roots.
> 
> So the use case is to specify numa locality for virtual
> devices.

In addition, I'd add that on ppc "pseries", the standard way of
hotplugging devices is to hotplug PCI roots (ie, a virtual host bridge
with the new device(s) below it).  

> > I'm not aware of real world hardware with hot-plugable root buses.
> > Should it come about then some kind of OS visible spec would be needed
> > for the OS to identify and enumerate newly added buses, and I suppose
> > we could figure out how to handle it once that type of thing happens.

On IBM ppc systems, both exist. IE, real HW hot pluggable roots (on
older systems mostly, GX based drawers with PCI host bridges in them
nowadays, we tend to use PCIe cable card based drawers), and in
virtualized systems, hot plugging root bridges is the standard way
PowerVM (aka pHyp) uses for hotplug which we need to support in
qemu/pseries at some point.

> > > But more importantly, if the sort is by the bus number,
> > > then how is it better than just using the bus number directly?

PCI Bus number makes no sense. Any root can have the whole range of bus
numbers 0...255 and the bus number assignment is under control of the
guest anyway. Or are you talking about a different bus number (somewhat
picked up the conversation half way...)
 
> To summarise, you feel that modifying bus id without reordering
> bus ids between roots is likely, modifications that would
> cause reordering are unlikely, thus counting bus ids
> in order gives a stable index. Is that right?
> 
> To be on the safe side, it would be nice to have bios skip some
> fields/properties when parsing paths, so that if we want to use another
> id in the future, we can supply both id types.  I haven't looked at the
> parsing code - maybe it does this already?

Ben.