[libvirt] [PATCH 4/6] conf: new <hotplug require='yes|no'/> element for hotpluggable devices

Daniel P. Berrange berrange at redhat.com
Tue Aug 9 07:54:51 UTC 2016

On Mon, Aug 08, 2016 at 04:56:55AM -0400, Laine Stump wrote:
> When faced with a guest device that requires a PCI address but doesn't
> have one manually assigned in the config, libvirt has always insisted
> (well... *tried* to insist) on auto-assigning an address that is on a
> PCI controller that supports hotplug. One big problem with this is
> that it prevents automatic use of a Q35 (or aarch64/virt) machine's
> pcie-root (since the PCIe root complex doesn't support hotplug).

I'm not really seeing why lack of use of pcie-root is a real problem. It
makes total sense to always use the bridge instead of root if the latter
does not support hotplug. At the time you first create a guest, you may
not even realize that you'll need to be able to hot-unplug a particular
device later. So putting any device on pcie-root is tieing your hands for
the entire lifetime of the guest.

> In order to promote simpler domain configs (more devices on pcie-root
> rather than on a pci-bridge), this patch adds a new sub-element to all
> guest devices that have a PCI address and support hotplug:
>   <hotplug require='no'/>
> For devices that have hotplug require='no', we turn off the
> VIR_PCI_CONNECT_HOGPLUGGABLE bit in the devFlags when searching for an
> available PCI address. Since pcie-root now allows standard PCI
> devices, this results in those devices being placed on pcie-root
> rather than pci-bridge.

I still really hate the idea of adding elements to the XML config
that have nothing todo with the actual guest ABI config, but instead
are setting logic policy in libvirt. But more generally I don't see
why anyone would ever want to set require=no for this - it just ties
your hands for later.

> NB: According to the code in qemuDomainAssignDevicePCISlots()
> and qemuDomainAttachDeviceLive(), the following device types are the
> only ones that use a PCI address *and* support hotplug:
>   <interface>
>   <hostdev>
>   <rng>
>   <serial>
>   <disk> (only virtio)
>   <controller> (hotplug only for SCSI controllers)
> These devices use a PCI address, but don't support hotplug, so the RNG
> doesn't allow them to have a <hotplug> element:
>   <filesystem>
>   <sound>
>   <balloon>
>   <watchdog>
>   <video>
>   <shmem>
>   <input>

IMHO it is really bad practice to make any assumption about what
devices support hotplug & what don't. In fact if any device type
does not support hotplug I think it is fair to argue that is
simply a bug / missing feature in libvirt right now. I see no
reason why any of those devices should not be able to support
hotplug in general.

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

More information about the libvir-list mailing list