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> 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.
Libvirt needs backwards compatibility, so we'll need it to look for the
vfio-pci driver through some long deprecation period. In the interim,
it can look at module aliases, support for which will be necessary and
might be leveraged for managed='yes' with variant drivers. Once vfio
devices expose a chardev themselves, libvirt might order the tests as:
a) vfio device chardev present
b) driver is a vfio-pci modalias
c) driver is vfio-pci
The current state of the world though is that variant driver exist and
libvirt can't make use of them. Thanks,
Alex