On Thu, 19 Apr 2018 10:40:18 +0200 Gerd Hoffmann <kraxel@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