Re: Analysis of the effect of adding PCIe root ports

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

 



On Fri, 2016-10-07 at 12:11 -0400, Laine Stump wrote:
> > So instead of guaranteeing that there will always be an empty
> > slot available for hotplug during a single start/destroy
> > cycle of the guest, we would be guaranteeing that there will
> > be 3/4 empty slots available for either hotplug or coldplug
> > throughout the entire life of the guest.
> 
> A better way to put it is that we guarantee there will be "N" (3 or 4 or 
> whatever) slots available when the domain is originally defined. Once 
> any change has been made, all bets are off.

Okay, your alternative reading matches with my understanding
of your proposal :)

> > Sounds like a pretty good compromise to me.
> > 
> > The only problem I can think of is that there might be
> > management applications that add eg. a pcie-root in the XML
> > when first defining a guest, and after the change such guests
> > would get zero hotpluggable ports. Then again it's probably
> > okay to expect such management applications to add the
> > necessary number of pcie-root-ports themselves.
> 
> Yeah, if they know enough to be adding a root-port, then they know 
> enough to add extras.

Note that I wrote pcie-root, not pcie-root-port.

> > Maybe we could relax the wording on A) and ignore any
> > pci{,e}-root? Even though there is really no reason for
> > either a user or a management application to add them
> > explicitly when defining a guest, I feel like they might be
> > special enough to deserve an exception.
> 
> I thought about that; I'm not sure. In the case of libguestfs, even if 
> Rich added a pcie-root, I guess he would still be manually addressing 
> his pci devices, so that would be clue enough that he knew what he was 
> doing and didn't want any extra.

Yeah, I'm not sure about that either, I just felt like it
would be good to think about it. I don't really see problems
going one way or the other, and I guess your initial
proposal is slightly more strict, so we might as well go for
it and relax it later if a compelling use case is found.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
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]