> > Well, it's simliar to qxl vs. qxl-vga. It's not qxl,vga={on,off} and
> > libvirt has no problems to deal with that ...
> >
> > Another more technical reason is (again) hotplug. ramfb needs an fw_cfg
> > entry for configuration, and fw_cfg entries can't be hotplugged. So
> > hotplugging vfio-pci with ramfb=on isn't going to fly. So we need a
> > separate device with hotplug turned off.
>
> Well if that's not supposed to work ever, libvirt's hotplug code could format
> the following FWIW:
> "-device vfio-pci [opts],ramfb=off"
>
> As such, new device wouldn't be that of an issue for libvirt if vfio-pci and
> vfio-pci-ramfb are back to back compatible with all the device options that are
> available for vfio-pci (I mean in terms of using an mdev). Because in that
> case, what libvirt could do is to look whether we're supposed to turn on the
> display, if so, then we need support for this in capabilities to query and then
> we could prefer this new device over the "legacy" vfio-pci one. However, if we
> expect a case where QEMU would succeed to start with an mdev mapped to this
> new ramfb device but not with vfio-pci, then that's an issue.
vfio-pci and vfio-pci-ramfb are identical, except for the later having a
boot display (with display=on), and vfio-pci-ramfb not being
hotplugable. So, yes, all pcu/mdev devices should work with both
vfio-pci variants.
> But I'm still curious about the ramfb=off possibility I asked above
> for hotplug nonetheless.
Well, the problem is introspection. qemu can report via qmp whenever a
specific device supports hotplug. A device which can both be
hot-pluggable or not hot-pluggable depending on some condition is a
problem here ...
cheers,
Gerd
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
