Hi, > > The connection between QemuConsole and User Interface (i.e. gtk, spice, > > ...) is a bit more flexible. But also not really designed for hotplug > > as QemuConsole is not hotpluggable in the first place ... > > > > We could drop the display property and use two devices instead. > > > > new vfio-pci would behave like display=off with this series. > > added vfio-pci-display has display=on behavior. > > display=auto is not possible. > > I expect libvirt and above would balk at creating a separate QEMU > device for this purpose, easy for QEMU, hard for anything that manages > QEMU.
Now as you've mentioned libvirt I remember we had the same discussion before, with usb host adapters. The uhci and ehci controllers have a simliar issue: If they are configured as companion setup (ehci for usb2 and uhci for usb1) they can't be hotplugged, as standalone controller hotplugging works fine. We ended up with splitting the controllers into two groups: The ones which can be used in a companion setup (basically all ich9-* devices) which are not hotpluggable. And the other ones which don't support companion setups but can be hotplugged. Commits: ec56214f6f usb: tag standalone ehci as hotpluggable 638ca939d8 usb: tag standalone uhci as hotpluggable The argument from the libvirt side was that it is actually easier for them to handle if hotplugging is a fixed property of a device and doesn't change magically depending on device configuration. First because they can query qemu then whenever a given device can be hotplugged or not, and second because it'll work for both plug-in and plug-out. So this patch isn't going to fly, and unless someone can come up with a better idea I'll go use the two-devices approach. cheers, Gerd
