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

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

[Josh Hilke]

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@google.com>
Signed-off-by: Josh Hilke <jrhilke@google.com>
---
Changelog

v5 -> v6
- Fix typos in commit message (Sashiko)
- Remove unused variable (Sashiko)

v5: https://lore.kernel.org/kvm/20260602185615.3025904-1-jrhilke@google.com/

 tools/testing/selftests/vfio/Makefile         |  1 +
 .../vfio/scripts/list_supported_devices.sh    | 43 +++++++++++++++++++
 2 files changed, 44 insertions(+)
 create mode 100755 tools/testing/selftests/vfio/scripts/list_supported_devices.sh

diff --git a/tools/testing/selftests/vfio/Makefile b/tools/testing/selftests/vfio/Makefile
index 0684932d91bf..127e70b996a9 100644
--- a/tools/testing/selftests/vfio/Makefile
+++ b/tools/testing/selftests/vfio/Makefile
@@ -15,6 +15,7 @@ TEST_GEN_PROGS += vfio_pci_driver_test
 
 TEST_FILES += scripts/cleanup.sh
 TEST_FILES += scripts/lib.sh
+TEST_FILES += scripts/list_supported_devices.sh
 TEST_FILES += scripts/run.sh
 TEST_FILES += scripts/setup.sh
 
diff --git a/tools/testing/selftests/vfio/scripts/list_supported_devices.sh b/tools/testing/selftests/vfio/scripts/list_supported_devices.sh
new file mode 100755
index 000000000000..4a4a2bc41901
--- /dev/null
+++ b/tools/testing/selftests/vfio/scripts/list_supported_devices.sh
@@ -0,0 +1,43 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+# List of devices which have a VFIO selftest driver. Device IDs are found in the
+# drivers in selftests/vfio/lib/drivers.
+readonly DEVICES=(
+	"8086:0b25,Intel DSA SPR"
+	"8086:11fb,Intel DSA GNR-D"
+	"8086:1212,Intel DSA DMR"
+	"8086:2021,Intel IOAT SKX"
+)
+
+# Print the segment:bus:device.function numbers of PCI devices that can be used
+# to run VFIO selftests.
+function main() {
+	local id_name
+	local quiet=""
+	local name
+	local bdfs
+	local id
+
+	while getopts "q" opt; do
+		case $opt in
+			q) quiet="true" ;;
+			\?) echo "Usage: $0 [-q]" >&2; exit 1 ;;
+		esac
+	done
+
+	for id_name in "${DEVICES[@]}"; do
+		IFS=',' read -r id name <<< "$id_name"
+		bdfs=$(lspci -D -d "${id}" | awk '{print $1}')
+
+		[[ -z $bdfs ]] && continue
+
+		if [ "$quiet" ]; then
+			echo "${bdfs}"
+		else
+			echo "${bdfs}" | sed "s|$| - ${name} [${id}]|"
+		fi
+	done
+}
+
+main "$@"
-- 
2.54.0.1013.g208068f2d8-goog

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

[Sean Christopherson]

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@google.com>
> Signed-off-by: Josh Hilke <jrhilke@google.com>

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.

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

[David Matlack]

On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@google.com> 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@google.com>
> > Signed-off-by: Josh Hilke <jrhilke@google.com>
>
> 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.

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

[David Matlack]

On Thu, Jun 4, 2026 at 1:30 PM David Matlack <dmatlack@google.com> wrote:
>
> On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@google.com> 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@google.com>
> > > Signed-off-by: Josh Hilke <jrhilke@google.com>
> >
> > 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.

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@google.com> wrote:
> >
> > On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@google.com> 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@google.com>
> > > > Signed-off-by: Josh Hilke <jrhilke@google.com>
> > >
> > > 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.

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

[David Matlack]

On 2026-06-05 11:19 AM, Sean Christopherson wrote:
> On Fri, Jun 05, 2026, David Matlack wrote:
> > On Thu, Jun 4, 2026 at 1:30 PM David Matlack <dmatlack@google.com> wrote:
> > >
> > > On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@google.com> 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@google.com>
> > > > > Signed-off-by: Josh Hilke <jrhilke@google.com>
> > > >
> > > > 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.

SGTM

Josh can you do this in v7? We'll probably need a flag to control
whether the script lists devices not currently supported due to
denylist, and how to convey all that to the user. I lean towards
list_supported_devices.sh printing as much information as possible when
run without arguments. So maybe a flag to hide denylisted devices.

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

[Vipin Sharma]

On Wed, Jun 17, 2026 at 03:37:35PM +0000, David Matlack wrote:
> On 2026-06-05 11:19 AM, Sean Christopherson wrote:
> > On Fri, Jun 05, 2026, David Matlack wrote:
> > > On Thu, Jun 4, 2026 at 1:30 PM David Matlack <dmatlack@google.com> wrote:
> > > >
> > > > On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@google.com> 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@google.com>
> > > > > > Signed-off-by: Josh Hilke <jrhilke@google.com>
> > > > >
> > > > > 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.
> 
> SGTM
> 
> Josh can you do this in v7? We'll probably need a flag to control
> whether the script lists devices not currently supported due to
> denylist, and how to convey all that to the user. I lean towards
> list_supported_devices.sh printing as much information as possible when
> run without arguments. So maybe a flag to hide denylisted devices.

Do we need then flag to hide denylisted devices? Instead, I think it should be
opposite (I think that what Sean is suggesting as amendment). If
the script finds vfio_pci.disable_denylist param value is:
 - Y, then just show those DSA devices if they are available on the
   host. Don't differenciate.
 - N, then don't show these denylist devices.

A flag can be added to show all of the VFIO selftests supported devices
present on the host with the warning next to denylisted devices or group
them in the output.

Flag case is for human consumption only.

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

[David Matlack]

On Wed, Jun 17, 2026 at 9:28 AM Vipin Sharma <vipinsh@google.com> wrote:
>
> On Wed, Jun 17, 2026 at 03:37:35PM +0000, David Matlack wrote:
> > On 2026-06-05 11:19 AM, Sean Christopherson wrote:
> > > On Fri, Jun 05, 2026, David Matlack wrote:
> > > > On Thu, Jun 4, 2026 at 1:30 PM David Matlack <dmatlack@google.com> wrote:
> > > > >
> > > > > On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson <seanjc@google.com> 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@google.com>
> > > > > > > Signed-off-by: Josh Hilke <jrhilke@google.com>
> > > > > >
> > > > > > 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.
> >
> > SGTM
> >
> > Josh can you do this in v7? We'll probably need a flag to control
> > whether the script lists devices not currently supported due to
> > denylist, and how to convey all that to the user. I lean towards
> > list_supported_devices.sh printing as much information as possible when
> > run without arguments. So maybe a flag to hide denylisted devices.
>
> Do we need then flag to hide denylisted devices? Instead, I think it should be
> opposite (I think that what Sean is suggesting as amendment). If
> the script finds vfio_pci.disable_denylist param value is:
>  - Y, then just show those DSA devices if they are available on the
>    host. Don't differenciate.
>  - N, then don't show these denylist devices.
>
> A flag can be added to show all of the VFIO selftests supported devices
> present on the host with the warning next to denylisted devices or group
> them in the output.
>
> Flag case is for human consumption only.

Can you explain why it should be that way?

IMO running list_supported_devices.sh without any arguments should
display as much information as possible. I think that will maximimize
the probability that people running VFIO selftests for the first time
will be able to figure things out for themselves.