On Thu, 19 Apr 2018 10:40:18 +0200 Gerd Hoffmann <kraxel@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
