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

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

 



On Thu, Mar 07, 2013 at 01:34:16PM -0500, Laine Stump wrote:
> On 03/06/2013 10:23 AM, Daniel P. Berrange wrote:
> > On Wed, Mar 06, 2013 at 04:15:28PM +0100, Ján Tomko wrote:
> >> On 03/05/13 11:36, Daniel P. Berrange wrote:
> >>> On Mon, Mar 04, 2013 at 02:39:40PM -0500, Laine Stump wrote:
> >>>> On 03/04/2013 11:51 AM, Ján Tomko wrote:
> >>>>> 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)
> >> Maybe we could reserve the first bus as well?
> 
> I'm guessing that putting things behind a bridge might reduce
> performance somewhat? (or maybe it's a completely artificial concept
> within qemu that only exists for the sake of making things look right to
> the guest, I just don't know)
> 
> > I don't think we should artifically reserve anything that isn't
> > absolutely required by the underlying machine type.
> 
> Yeah, I don't think we should reserve an entire bus. However, when
> auto-assigning slots, I think we should make a "best effort" to always
> leave at least one slot open at the end. This will ensure that anyone
> hotplugging bunches of devices with no explicit pci address will succeed
> (although their final topology may be suboptimal).

I worry that trying to keep one slot open is going to break existing
users which may be filling up their slots 100%, but not have a new
enough QEMU for bridge support. We need to be very careful not to
regress for anyone when changing this address assignemnt.


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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]