On Mon, Mar 04, 2013 at 02:39:40PM -0500, Laine Stump wrote: > On 03/04/2013 11:51 AM, Ján Tomko wrote: > > On 02/19/13 03:25, liguang wrote: > >> if some devices specify a pci bus number that > >> haven't been defined by a pci-bridge controller > >> then fill the required correct controller info > >> silently. > >> > >> Acked-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > >> Signed-off-by: liguang <lig.fnst@xxxxxxxxxxxxxx> > >> --- > > This will only add bridges for the explictly mentioned buses, which > > would mean we could have buses 0 and 6 with no buses between them. > > Maybe we should add them the way we add disk controllers - find the > > highest index and add all bridges with indexes from 1 to max. > > But each pci bridge device takes up another slot, which we may not want > to give up. (Although arguably, once we have pci-bridge devices, we can > create as many slots as we like :-) > > > Is there some advantage to having all the buses filled in (other than > similarity to what's done for other types of controllers)? > > > It would be nice if we could add pci bridges even when there weren't any > > specified in the XML, but there are too many PCI devices. I don't know > > what would be the nicest way to do that. > > If we auto-assign addresses for un-addressed devices first (your recent > patches did that, right? I forget the status of those), *then* > auto-create the required bridges (which themselves will need an > auto-assigned address), that should just happen. > > Of course, if we do that, then we won't have reserved any slots on bus 0 > for even a single pci-bridge device, so we'll fail. Is the proper way > out of this to always reserve one (or maybe two, for good measure) slots > on any given bus to be used only for bridges? That way no matter how out > of hand things get, we'll always have a place we can add another bus. > (In the case of *lots* of devices, I assume that a device on a nested > PCI bridge would be less efficient, and may have some other limitations, > but it would be better than nothing. And if the admin was really > concerned about that, they could modify their config to explicitly place > several bridges directly on bus 0) You'd have todo a 2 pass assignment. First count the number of devices that need to have PCI addresses assigned. Then create the required number of bridges, then assign the addresses. All this time though, bear in mind that auto-address assignment is just a convenience. At some point we are well within our right to stop and say this is as good as its going to get, you must do address assignment if the app if you want something more clever. > This also brings up the fact that we need to deal with the possibility > of all buses being full during hotplug - when that happens I suppose we > will also want to auto-add a pci bridge. Well if buses are all full, there's no where to hook in the bridge :-) So you need to do that before filling up, or just say this is out of scope and the app must explicitly plug a bridge if they want more space. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list