[PATCH] util: basic support for vendor-specific vfio drivers
Alex Williamson
alex.williamson at redhat.com
Thu Aug 4 18:18:26 UTC 2022
On Thu, 4 Aug 2022 13:51:20 -0300
Jason Gunthorpe <jgg at 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
More information about the libvir-list
mailing list