[PATCH 0/3] sample: vfio mdev display devices.
Zhenyu Wang
zhenyuw at linux.intel.com
Thu Apr 19 10:03:47 UTC 2018
On 2018.04.19 10:40:18 +0200, Gerd Hoffmann wrote:
> 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.
>
yeah, that's true.
> > 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.
I also don't like that strict link and although now KVM is the only upstream
hypervisor GVT supports, we shouldn't require a must available instance for
some device info access.
>
> > 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.
Or a 'feature' file with defined string list for those capabilities?
Might be easier to extend in future.
>
> > 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"?
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20180419/dac0da0b/attachment.sig>
More information about the intel-gvt-dev
mailing list