Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
On Thu, 19 Apr 2018 10:40:18 +0200
Gerd Hoffmann <kraxel(a)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