Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
Hi,
Erik Skultety brought up a good question today regarding how libvirt
is
meant to handle these different flavors of display interfaces and
knowing whether a given mdev device has display support at all. It
seems that we cannot simply use the default display=auto because
libvirt needs to specifically configure gl support for a dmabuf type
interface versus not having such a requirement for a region interface,
perhaps even removing the emulated graphics in some cases (though I
don't think we have boot graphics through either solution yet).
Correct, no boot graphics yet. The option to disable emulated graphics
should be added nevertheless. It's an option after all, you don't have
to use it.
But after install things usually work just fine, it just takes a little
longer for the guest display to show up.. There is also the option to
add a serial console to the guest for boot loader access.
Additionally, GVT-g seems to need the x-igd-opregion support
enabled(?), which is a non-starter for libvirt as it's an experimental
option!
Windows guests need it, yes. And it seems we have still have to add igd
opregion support to ovmf as only bios guests are working. Or hack up a
efi rom doing that. But patching ovmf is probably alot easier because
it already has support code for fw_cfg access.
Linux i915.ko is happy without opregion.
So I was ready to return and suggest that maybe libvirt should probe
the device to know about these ancillary configuration details, but
then I remembered that both mdev vGPU vendors had external dependencies
to even allow probing the device. KVMGT will fail to open the device
if it's not associated with an instance of KVM and NVIDIA vGPU, I
believe, will fail if the vGPU manager process cannot find the QEMU
instance to extract the VM UUID. (Both of these were bad ideas)
Oops. I've trapped into the kvm issue too. Wondering what the reason
is, shouldn't this work with tcg too?
But, yes, that indeed pretty much kills the "just let libvirt use the
probe ioctl" idea.
The existing device_api file reports "vfio-pci", so we base
the device
API info in a directory named vfio-pci. We're specifically exposing
device information, so we have a device directory. We have a GFX_PLANE
query ioctl, so we have a gfx_plane sub-directory. I imagine the
dmabuf and region files here expose either Y/N or 1/0.
Do we want tie this to vfio-pci? All existing devices are actually pci,
and the qemu code only works for vfio-pci devices too. But at vfio api
level there is no vfio-pci dependency I'm aware of, and I think we
shouldn't add one without a good reason.
Should we just add a gfx_plane_api file maybe? Which would be a
comma-separated list of interfaces, listed in order of preference in
case multiple are supported.
anything other than mdev. This inconsistency with physically
assigned
devices has been one of my arguments against enhancing mdev sysfs.
Thanks to anyone still reading this. Ideas how we might help libvirt
fill this information void so that they can actually configure a VM
with a display device? Thanks,
Well, no good idea for the physical assigned device case.
cheers,
Gerd
PS: Any comment on the sample driver patches? Or should I take the lack
of comments as "no news is good news, they are queued up already"?