On Tue, 11 Sep 2018 06:38:43 +0200 Gerd Hoffmann <kra...@redhat.com> wrote:
> 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. Ok, so we need a new class to handle making a device non-hotpluggable, but I'm still not sure whether we should make: -device vfio-pci-ramfb or -device vfio-pci-nohotplug,ramfb=on Where ramfb would be a property only available on the nohotplug class variant. The latter seems to provide a lot more flexibility, but which is more practical for libvirt? Thanks, Alex
