Re: [PATCH] util: basic support for vendor-specific vfio drivers

On Thu, 4 Aug 2022 13:51:20 -0300 Jason Gunthorpe <jgg(a)nvidia.com&gt; wrote: > On Mon, Aug 01, 2022 at 09:49:28AM -0600, Alex Williamson wrote: > > > > > > > Fortunately these new vendor/device-specific drivers can be easily > > > > > > identified as being "vfio-pci + extra stuff" - all that's needed is to > > > > > > look at the output of the "modinfo $driver_name" command to see if > > > > > > "vfio_pci" is in the alias list for the driver. > > We are moving in a direction on the kernel side to expose a sysfs > under the PCI device that definitively says it is VFIO enabled, eg > something like > > /sys/devices/pci0000:00/0000:00:1f.6/vfio/<N> > > Which is how every other subsystem in the kernel works. When this > lands libvirt can simply stat the vfio directory and confirm that the > device handle it is looking at is vfio enabled, for all things that > vfio support. > > My thinking had been to do the above work a bit later, but if libvirt > needs it right now then lets do it right away so we don't have to > worry about this hacky modprobe stuff down the road? That seems like a pretty long gap, there are vfio-pci variant drivers since v5.18 and this hasn't even been proposed for v6.0 (aka v5.20) midway through the merge window. We therefore have at least 3 kernels exposing devices in a way that libvirt can't make use of simply due to a driver matching test.

might be leveraged for managed='yes' with variant drivers. Once vfio devices expose a chardev themselves, libvirt might order the tests as: