Hi,
> type_register_static(&vfio_pci_dev_info);
> + type_register_static(&vfio_pci_ramfb_dev_info);
My concern here is still all of the extra tooling that needs to be
added to management layers above QEMU for this device that exists only
because we can't hotplug the primary display in QEMU. What happens when
we can hotplug the primary display?
Ramfb uses fw_cfg, and fw_cfg files can't be added or removed at
runtime, the interface simply isn't designed for that.
Aren't disabling hotplug of a
vfio-pci device and supporting ramfb two separate things? I think
we're leaking current implementation issues out to the device options
when really we'd rather have a "ramfb" (or perhaps "console")
option on
the vfio-pci device and the hotplug capability determined automatically
and available through introspection of the device.
Well, I don't think libvirt will have too much trouble handling this.
We have two variants (with and without vga compatibility) of other
devices: qxl-vga and qxl, virtio-vga and virtio-gpu-pci. libvirt copes
just fine and picks the right one (I think depending on video model
'primary' property).
Also libvirt manages hotpluggability per device *class*, not per device
*instance*. So a device being hotpluggable or not depending on some
device property is a problem for libvirt ...
I'm open to suggestions how to handle this better, as long as the
libvirt people are on board with the approach.
cheers,
Gerd