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

[Jason Gunthorpe]

On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote:

> > > 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; :-/)

This is still pretty hacky. I'm worried about what happens to the
kernel if this becames some crazy unintended uAPI that we never really
thought about carefully... This was not a use case when we designed
the modules.alias stuff at least.

BTW - why not do things the normal way?

1. readlink /sys/bus/pci/devices/XX/iommu_group
2. Compute basename of #1
3. Check if /dev/vfio/#2 exists (or /sys/class/vfio/#2)

It has a small edge case where a multi-device group might give a false
positive for an undrivered device, but for the purposes of libvirt
that seems pretty obscure.. (while the above has false negative
issues, obviously)

> > Since we already need to do something else as a stop-gap for the interim
> > (in order to avoid making driver developers wait any longer if for no 
> > other reason), my opinion would be to not spend extra time splitting up 
> > patches just to give us this functionality slightly sooner; we'll anyway 
> > have something at least workable in place.
> 
> We also need to be careful in adding things piecemeal that libvirt can
> determine when new functionality, such as vfio device chardevs, are
> actually available and not simply a placeholder to fill a gap
> elsewhere.

In sysfs the kernel standard is the directory means there is a "struct
device" and the "dev" file within the directory means there is a cdev,
so it is safely discoverable.

I would like to split the kernel patch anyhow because the cdev is
conceptually complicated so having just the struct device bits on its
own would be helpful..

Jason