[PATCH 0/3] sample: vfio mdev display devices.
Alex Williamson
alex.williamson at redhat.com
Thu Apr 19 14:20:03 UTC 2018
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
More information about the intel-gvt-dev
mailing list