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

Daniel P. Berrangé berrange at redhat.com
Fri Aug 5 09:37:19 UTC 2022


On Thu, Aug 04, 2022 at 03:11:07PM -0400, Laine Stump wrote:
> On 8/4/22 2:36 PM, Jason Gunthorpe wrote:
> > On Thu, Aug 04, 2022 at 12:18:26PM -0600, Alex Williamson wrote:
> > > 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.
> > 
> > That is reasonable, but I'd say those three kernels only have two
> > drivers and they both have vfio as a substring in their name - so the
> > simple thing of just substring searching 'vfio' would get us over that
> > gap.
> 
> Looking at the aliases for exactly "vfio_pci" isn't that much more
> complicated, and "feels" a lot more reliable than just doing a substring
> search for "vfio" in the driver's name. (It would be, uh, .... "not smart"
> to name a driver "vfio<anything>" if it wasn't actually a vfio variant
> driver (or the opposite), but I could imagine it happening; :-/)

If it is just 2 drivers so far then we don't need to even do a
substring. We should do a precise full string match for just
those couple of drivers that exist. We don't need to care about
out of tree drivers IMHO.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


More information about the libvir-list mailing list