在 2013-03-06三的 13:13 +0800，li guang写道： > 在 2013-03-05二的 10:36 +0000，Daniel P. Berrange写道： > > 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. > > Hmm, it's good point that haven't been considered by me, > so, do I have to hack into device hot-plug to know if > bus slot is almost exhausted and decide whether add pci-bridge or not? > or, just let user bear in mind that? > So ... , what should I do next? and what about other 3 patches? > > > > > > 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 > > > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list