[libvirt] [PATCH 0/3] sample: vfio mdev display devices.

[Zhenyu Wang]

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: <http://listman.redhat.com/archives/libvir-list/attachments/20180419/dac0da0b/attachment-0001.sig>