Re: [Qemu-devel] Help: Does Qemu support virtio-pci for net-device and disk device?

[Laine Stump]

On 08/18/2016 08:10 AM, Marcel Apfelbaum wrote:
> On 08/17/2016 08:00 PM, Laine Stump wrote:

>  What I'm not sure about is whether we should always auto-add an extra
> pcie-*-root to be sure a device can be hotplugged, or if we should admit
> that 1
> > available slot isn't good enough for all situations, so we should
> > instead just leave it up to the user/management to manually add extra
> > ports if they think they'll want to hotplug something later.
>
> Why not? Leaving 1 or 2 PCIe ports should be enough. On each port you
> can hotplug a switch with several downstream ports. You can continue
> nesting the switches up to depth of 6-7 I think.

When did qemu start supporting hotplug of pcie switch ports? My 
understanding is that in real hardware the only way this is supported is 
to plug in the entire "upstream+downstream+downstream+..." set as a 
single unit, since there is no mechanism for guest kernel to notify the 
upstream port that a new downstream port has been attached to it (or 
something like that; I'm vague on the details). From the other end, qemu 
can only hotplug a single PCI device at a time, so by the time we get to 
the point of plugging in the downstream ports, the upstream port is 
already cemented in place by the guest kernel.

I think that would be a really desirable feature though. Maybe qemu 
could queue up any downstream-ports which are pointing to an 
as-yet-nonexistent upstream-port id, then when the upstream-port with 
the proper id is finally attached, it could send the right magic to the 
guest (similar to the way it allows hotplugging all non-0 functions 
first, then takes action when function 0 is hotplugged).

If that was available, then yes, it would make perfect sense for libvirt 
to simply always make sure at least one empty pcie-*-port was available. 
If you have plans of doing something to support hotplugging a 
pcie-switch-* collection, then that's what I'll do.