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"?
