[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



在 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 redhat com>
> > > >> Signed-off-by: liguang <lig fnst 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?
> 

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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]