Re: [PATCH v6] vfio: selftests: Find devices that have VFIO selftest drivers

[Sean Christopherson]

On Fri, Jun 05, 2026, David Matlack wrote:
> On Thu, Jun 4, 2026 at 1:30 PM David Matlack <dmatlack@xxxxxxxxxx> wrote:
> >
> > On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Jun 02, 2026, Josh Hilke wrote:
> > > > Add a new script, list_supported_devices.sh, which prints out the
> > > > segment:bus:device.function (SBDF) numbers and names of devices on a
> > > > machine that have a VFIO selftest driver. This makes it easier to
> > > > determine if the system is capable of running VFIO selftests.
> > > >
> > > > Includes a -q (quiet) argument which prints just the SBDFs so that the
> > > > output can be passed to tools/testing/selftests/vfio/scripts/setup.sh
> > > > (e.g. via xargs) to bind the devices to VFIO to use in VFIO selftests.
> > > >
> > > > Examples:
> > > >
> > > > $ ./list_supported_devices.sh
> > > > 0000:6a:01.0 - Intel DSA SPR [8086:0b25]
> > > > 0000:6f:01.0 - Intel DSA SPR [8086:0b25]
> > > > 0000:74:01.0 - Intel DSA SPR [8086:0b25]
> > > >
> > > > $ ./list_supported_devices.sh -q
> > > > 0000:6a:01.0
> > > > 0000:6f:01.0
> > > > 0000:74:01.0
> > > >
> > > > Suggested-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > > > Signed-off-by: Josh Hilke <jrhilke@xxxxxxxxxx>
> > >
> > > NAK, until this stuff is fixed and properly documented.
> > >
> > > This script needs to (a) communicate that some of the devices may be on VFIO's
> > > denylist, (b) NOT report them by default, (c) let the user report denylisted
> > > devices, (d) make it *very* clear in the output that a device, and (e) ideally
> > > provide the user with a hint of how that might be able to test a denied device,
> > > e.g. by reloading vfio-pci with disable_denylist=1.
> > >
> > > Nothing in here so much as mentions that these "supported" devices may be
> > > disallowed by the kernel, including the devices that's USED AS THE EXAMPLE.
> > >
> > > The DSA SPR devices has been on the naughty list since commit 95feb3160eef ("VFIO:
> > > Add the SPR_DSA and SPR_IAX devices to the denylist") from 2024, so I have a
> > > very hard time believing y'all weren't aware of this.  And if you really truly
> > > weren't aware of this quirk, than what exactly are you even testing!?!?
> > >
> > > C'mon.
> >
> > Yeah vfio_pci.disable_denylist=Y is required to use the Intel DSA SPR
> > device. This script is a great place to capture that previously hidden
> > requirement.
> >
> > Your proposed (a)-(e) sound good to me.
> 
> Another direction we could go in here would be to set disable_denylist
> to Y in setup.sh (if it is currently N) and set it back to N in
> cleanup.sh (after the last device is cleaned up and only if it was
> previously N). I was already thinking about doing something similar
> for setting enable_srio to Y for Raghu's new SR-IOV uAPI test.
> 
> The only issue is that disable_denylist is not currently writable. I
> don't see any functional reason why it can't be writable though. It is
> just sampled during probe. And from a security perspective, privileged
> users can already reload vfio-pci with different parameters if it is
> built as a module. But for built-ins, this would enable the denylist
> to be disabled.

IMO, any changes to setup.h are completely orthogonal.  list_supported_devices.sh
can and will be run independently, e.g. by people like me, and so absolutely needs
to claim a device is supported when it's obviously not.

Actually, that's a good amendment to (b) above.  Instead of *never* reporting
denylisted devices by default, have the script check disable_denylist and act
accordingly.  And then it's "just" a matter of communicating these details to
the user, e.g. so that a user can find devices that are supported by selftests,
but not by their currently loaded kernel+modules.