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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
