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

[Jason Gunthorpe]

On Fri, Aug 05, 2022 at 08:21:50PM -0400, Laine Stump wrote:

> Without looking/trying, I would have said that libvirt would check for (2),
> but I guess nobody ever tried it :-/

There is nothing you can do about this in userspace today. The kernel
has internal data about what devices are or are not compatible with
vfio, and that data should stay internal to the kernel. Hardwiring ABI
assumptions to fix this in vfio is pretty bad.

> > The initial step is to then enlighten libvirt that other drivers can be
> > compatible for the 'no' case and later we can make smarter choices
> > about which driver to use or allow the user to specify (ie. a user
> > should be able to use vfio-pci rather than a variant driver if they
> > choose) in the 'yes' case.
> 
> Yes, that's the next step. I just wanted to first add a simple (i.e.
> difficult to botch up) patch to allow trying out the new variant drivers
> without bypassing libvirt (which is bad PR for libvirt every time it
> happens).

I still think "search for vfio in the driver name" is sufficient for
now, and we can do much better, including solving (2) with kernel
support.

> Yep. Currently we miss case (2) above. With this suggested method of
> detecting vfio variant drivers, we would also start missing (1).

No, (1) should be detected by scanning /sys/class/vfio/XX and looking
for devices in the same group and running your "different QEMU
process" algorithm on those grouping. (1) should have nothing to do
with driver name matching.

Jason