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