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. Regards, 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