Re: [PATCH v2 00/14] KVM: selftests: Link with VFIO selftests lib and test device interrupts

[Sean Christopherson <seanjc@google.com>]

On Wed, Apr 01, 2026, David Matlack wrote:
> On 2026-04-01 11:17 AM, Sean Christopherson wrote:
> > On Tue, Mar 31, 2026, Josh Hilke wrote:
> 
> > > This test only supports x86. Testing physical device interrupts (-d argument) is
> > > only supported for Intel because there are no VFIO selftest drivers for AMD
> > > devices.
> > 
> > This needs to be expressed in code and human readable error messages to the user.
> > I already knew the basic of what the VFIO selfests are doing, and it still took
> > me 5+ minutes to find the DSA driver and probing logic.
> > 
> > Concretely, this code needs to be part of the standard vfio selftests APIs:
> > 
> > 	device = vfio_pci_device_init(device_bdf, iommu);
> > 
> > 	has_driver = !!device->driver.ops;
> > 
> > E.g. have vfio_pci_device_init() explicitly return an error (or NULL) if it can't
> > init the device driver.
> 
> No. Not every VFIO selftest or user of libvfio needs a driver. A driver
> is only needed in tests that want to use the driver, i.e. want to call
> one of the very obviously named functions:
> 
>  - vfio_pci_driver_send_msi()
>  - vfio_pci_driver_memcpy()
>  - etc.
> 
> Requiring a driver for vfio_pci_device_init() to return non-NULL would
> significantly reduce our ability to test VFIO on different platforms and
> environments.

Ah, sorry.  I was speed reading and missed that some (most?) tests don't require
a driver.  Scratch the "make it unconditional", but there still needs to be an
API to up-level binding to a driver.  KVM selftests shouldn't have to manually
check for that.

> > The fixtures in vfio_pci_driver_test.c already blindly assume success, so you
> > might not need to do much beyond changing main() in that file.
> 
> I don't follow. What is the issue with vfio_pci_driver_test.?

What I was trying to say is that if vfio_pci_device_init() were to unconditionally
require a driver, then vfio_pci_driver_test() should Just Work.  But that doesn't
make a whole lot of sense given the above.  Though it could use the new API that
checks for a driver.

> > And then, also as a vfio_pci_device_xxx() API, add a helper to print out what
> > devices are supported, e.g. so that KVM selftests can do something like:
> 
> Agree this would be nice to have. Is this a blocker for this series?

Yes.  KVM selftests need to assert there's a driver before trying to proceed.

> > struct vfio_pci_device *kvm_vfio_device_init(const char *bdf)
> > {
> > 	struct vfio_pci_device *device;
> > 	struct iommu *iommu;
> > 
> > 	iommu = iommu_init(default_iommu_mode);
> > 
> > 	device = vfio_pci_device_init(bdf, iommu);
> > 	if (!device) {
> > 		vfio_pci_device_print_drivers(stderr);
> > 		TEST_FAIL("No driver found for BDF '%s'", bdf);
> > 	}
> > 	return device;
> > }
> > 
> > Because as is, this requires way too much a priori knowledge and magic for
> > upstream.  The user shouldn't have to dig through code just to understand what
> > devices are supported.
> >
> > Ideally, VFIO selftests would also provide a script, utility, and/or helper to
> > identify BDFs for devices it has drivers for.  In my experience, binding a device
> > to VFIO is trivial.  Finding the device in the first place is more annoying.
> 
> Agree this would be nice to have. Is this a blocker for this series?

Yes.  As I mentioned to Josh off-list, I'm not willing to accept a "we pinky-swear
we'll make this stuff user friendly".  It's not that I don't trust you and Josh
(and others), it's that for me, this level of user-friendly behavior isn't nice
to have, it's mandatory for these tests to be usable upstream.

Internally we can squeak by with barebones, unhelpful tests, because the run
commands are often hardcoded somewhere and there is piles of documentation elsewhere.
But for upstream, none of that holds true.

If it were weeks of effort, I would be more open to treating this as nice to have,
but AFAICT writing the code should be less than a days worth of work.