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

[Alex Williamson]

On Thu, 19 Apr 2018 10:40:18 +0200
Gerd Hoffmann <kraxel at redhat.com> wrote:
> > 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?

It's used for some sort of page tracking backdoor.  Yes, I think vfio
devices, including mdev, should work with tcg.  Separating device
assignment to not be integrally tied to kvm is something I've strived
for with vfio.

> 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.

The intention was to tie it to 'device_api' which reports 'vfio-pci',
so the user would read the device_api, learn that it uses vfio-pci,
then look for attributes in a vfio-pci sub-directory.  If device_api
reported vfio-ccw, they'd look for a vfio-ccw directory.

> 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.

I'm afraid that as soon as we get away from a strict representation of
the vfio API, we're going to see feature creep with such a solution.
Ex. which hw encoders are supported, frame rate limiters, number of
heads, etc.

> > 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.

Minimally, I think anything we decide needs to be placed into the
instantiated device sysfs hierarchy rather than the template directory
for a given mdev type, otherwise we have no hope of supporting it with
physical devices.

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

I do not have them queued yet, I'll take a closer look at them shortly
and let you know if I find any issues.  Thanks for doing these!  I think
they'll be very helpful, especially for the task above to provide
reference implementations for whatever API exposure we design.  Thanks,

Alex