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
