[libvirt] [PATCH v4 4/4] auto-create pci-bridge controller info

[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 at redhat.com>
> > >> Signed-off-by: liguang <lig.fnst at cn.fujitsu.com>
> > >> ---
> > > 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?

> 
> 
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list