From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BDE26478E36 for ; Wed, 17 Jun 2026 15:37:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781710674; cv=none; b=dtjYBT1lB839EKJuykDNvZPMghhhw7r9p1YKYmt1pBNVIxCQ4EkMvZecTY1zOp/PE8kJGOS9ednIZs+tgKx7gRcwxOtLFyryw8JjPgup6dlAnopUH2QTn/vNBMgsAMeDzcF/1JNFVNXajiv5WrssgFUEtq1PG/KfE9Y3u3Of9E0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781710674; c=relaxed/simple; bh=bc69wBq2NH6ty+sum9MiAmxf6DzoX6x3UszNK/XTWKM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nIKiQcgYveOH3YpXjju+TZ4fFlMHXTxtyNsyFPQSrEqIrWA1KY+rHK7o+lzqUYYvUiTizegXcSPGofL0NJ5Qk25J+t7scmeEKny2AxGt2KFCJrrkP2JaWv9617tPVsask5szN+wutpHElQtDgfrOnGsE7EMfBZDYIZbKhskVK8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ap2b3Btz; arc=none smtp.client-ip=209.85.216.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ap2b3Btz" Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-37cae11ba85so865770a91.1 for ; Wed, 17 Jun 2026 08:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781710660; x=1782315460; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=GKd6b+WufKYKVi+Itkm90GNjDyaZCJZDAg9Po0kQfu8=; b=ap2b3BtzVRRI4LctJJHwIyw2/FZY615ABdWsxogwNZEDeskSUWDxqfSsyx2YhkeITe BZtE4anWUYU2jLteqIyJr3jgrf85O3dD9lbMKuPlTvc1MkSY12mdtq4PPph+Yx0yMMST 5llQGdoUpSwIURNyw9+LMO7qnc6QXjOjy/PEJV3g7tl4Lp6X0BSk2sYGTGbXFAjDoe0N CCJejm+/WhZR8E1zzTFUA/Tz+T5QMmKLKRDy8tFox6TbXYCTDjeUFII+SYwrv187lHeg OxvJr4FNq0vtsxsmvqtO69vYPOmuqoTBstppoqy9ikGNIB2By7Ac8LhnbbZDENSaPb1x Nwqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781710660; x=1782315460; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GKd6b+WufKYKVi+Itkm90GNjDyaZCJZDAg9Po0kQfu8=; b=pXjiimyzjGoRaltcPoxE1xezxlLANkdun+tw0U+d8GqBkwNPEExFv+6Mfpj572P+J7 Rm5pUOsW3v5ZFNeEG7Y4sO3S/izlp2erjPyHfs90yOjNwlFw9hlpL4MZoU2DswJ/eNf5 FUz+eQdU8scGZeECW+0AX4t/nw5LwmgtFHp19+21j1dmUI7GxGWJJtOoYHD45J4iZtYn jbUmnGjwm6aW0CLqtGKjpjp+Cz7qgPDOVwkE1PKiksC0iARLdYILHxPUENIRVPhJhT1J FPTOWB4TeKdVa+xtxj2Bjr0FX+aKjVl52q3VuVQbU96FsC9buP2Hvomgkv3NEEZL041I ipEA== X-Forwarded-Encrypted: i=1; AFNElJ+FmLbfA6M1MiFIQjh/a2i2UASpgfBxm/nVnE/xz5124wf1F+ZYQEw2ix4w4FAD1jy3bA4AB3zdVWXO19c=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4f3s+e/F9Y1uCTY8zNxYySswmLJrUEt6xNyX6kZgJGySpFmNY PG06l40cpd7NoK1BRVaOvbSBlJxcQwD7lKI/54NfsKcsFH4YGYP4zyBNbs+OecGLXA== X-Gm-Gg: AfdE7ckRdoo7PFW5OlMOnoTkOAQYcaMSFljI0mx0qctefmLmkTcVNOk9GoeF6QIkitE +9LNJt/0EwrIMaUCYLcDB/IsWl4fnhg7nQJcApi4KvW4U3Q2+EVlBFbZuulxQ4kNeTeP8uhBPpv zlCs4DoFnz/qopDylCf4C3fIiAS6nq0bVDBYtcN7OvvjWNKSwgnGJjsPRXxP4RQMHuoLwq1FFzR a2gtCC5vVMRnsnRYhvDvdCnyB2Ue28sBO/UCcyrpPJK5SUEXr24Ry7a0NIY7WVFuQwPp4V9kFkG zUFPllfmtOESTLWRDbnU/GX7LQ5hQLNRlRpZZv8O5dVAktjZIeZDF8DQYxCH5mKx48z5TV83O+V +CbDDpkzNQe8M8s9WTPpDm/A4qJy40vpOCTnZjFS2NdaB5jWSKx9hAWbmQu+8LMH+B6rJsGRrvW lt6fpUxp0TCIFndOFU/7ZhDuBoY5IcrFEfTK0fcMBBAH+DgZ1nePg= X-Received: by 2002:a17:90b:568c:b0:36b:a0fa:ff96 with SMTP id 98e67ed59e1d1-37c9405031amr4063979a91.12.1781710659141; Wed, 17 Jun 2026 08:37:39 -0700 (PDT) Received: from google.com (56.149.168.34.bc.googleusercontent.com. [34.168.149.56]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-37c5222e07fsm6260474a91.17.2026.06.17.08.37.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 08:37:38 -0700 (PDT) Date: Wed, 17 Jun 2026 15:37:35 +0000 From: David Matlack To: Sean Christopherson Cc: Josh Hilke , Alex Williamson , Vipin Sharma , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Raghavendra Rao Ananta Subject: Re: [PATCH v6] vfio: selftests: Find devices that have VFIO selftest drivers Message-ID: References: <20260602222941.3133236-1-jrhilke@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 wrote: > > > > > > On Thu, Jun 4, 2026 at 12:50 PM Sean Christopherson 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 > > > > > Signed-off-by: Josh Hilke > > > > > > > > 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.