[libvirt PATCH v3 4/8] util: permit existing binding to VFIO variant driver

[Michal Prívozník]

On 8/21/23 21:32, Laine Stump wrote:
> Before a PCI device can be assigned to a guest with VFIO, that device
> must be bound to the vfio-pci driver rather than to the device's
> normal host driver. The vfio-pci driver provides APIs that permit QEMU
> to perform all the necessary operations to make the device accessible
> to the guest.
> 
> In the past vfio-pci was the only driver that supplied these APIs, but
> there are now vendor/device-specific "VFIO variant" drivers that
> provide the basic vfio-pci driver functionality/API while adding
> support for device-specific operations (for example these
> device-specific drivers may support live migration of certain
> devices).  All that is needed to make this functionality available is
> to bind the vendor-specific "VFIO variant" driver to the device
> (rather than the generic vfio-pci driver, which will continue to work,
> just without the extra functionality).
> 
> But until now libvirt has required that all PCI devices being assigned
> to a guest with VFIO specifically have the "vfio-pci" driver bound to
> the device. So even if the user manually binds a shiny new
> vendor-specific VFIO variant driver to the device (and puts
> "managed='no'" in the config to prevent libvirt from changing the
> binding), libvirt will just fail during startup of the guest (or
> during hotplug) because the driver bound to the device isn't exactly
> "vfio-pci".
> 
> Beginning with kernel 6.1, it's possible to determine from the sysfs
> directory for a device whether the currently-bound driver is the
> vfio-pci driver or a VFIO variant - the device directory will have a
> subdirectory called "vfio-dev". We can use that to appropriately widen
> the list of drivers that libvirt will allow for VFIO device
> assignment.
> 
> This patch doesn't remove the explicit check for the exact "vfio-pci"
> driver (since that would cause systems with pre-6.1 kernels to behave
> incorrectly), but adds an additional check for the vfio-dev directory,
> so that any VFIO variant driver is acceptable for libvirt to continue
> setting up for VFIO device assignment.
> 
> Signed-off-by: Laine Stump <laine at redhat.com>
> ---
>  src/hypervisor/virhostdev.c | 28 +++++--------
>  src/libvirt_private.syms    |  1 +
>  src/util/virpci.c           | 78 ++++++++++++++++++++++++++++++++++---
>  src/util/virpci.h           |  3 ++
>  4 files changed, 87 insertions(+), 23 deletions(-)


Splendid! We can now turn virPCIDeviceGetCurrentDriverPathAndName() into
a static function is it's only real use is inside of virpci.c. The only
other use outside is in virpcitest.c and it only cares about
${driverName} anyway (so it's okay with calling this new
virPCIDeviceGetCurrentDriverNameAndType()). Feel free to save that work
for a follow up patch.

Michal