From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 DC1FF31F9AE for ; Wed, 17 Jun 2026 19:07:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781723239; cv=none; b=UyC9B7lezrPAdteKKibYdD3EvJSz3nv21uLKe/inZtVWrA/tGbnO48belcwmffp1WAisjoRyR9sqdRXQ2lv3K0wQwoHFTaEsLpyNsQEozdmPy1HXzkqwbaqkH6lpOaMywWb35ZpJBZnS4HfuHVz9rcolg1q7mJhzd/MapZO5pyE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781723239; c=relaxed/simple; bh=xCtJPcNLWyoPjpPhu2YChOz+3yORpxz1XHDMMWMaME8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fIlRz90m9VYYZLvfN07ktHRPH/rGjyCu1OJeDj20qF/hoJAvpB1d5wVpxBvXG6amVAGloq0oJSGxtD7BKpL+R6UthJtYGSp2F54d00nmGvvgeX20gdv6SIk0WMDsW0TnSQeQkcY3c8NSzt1a8cFtcxM6jKD2ely+O4DrrFEjFhI= 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=vDuRB2at; arc=none smtp.client-ip=209.85.214.177 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="vDuRB2at" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2c69fa0b1f8so10725ad.0 for ; Wed, 17 Jun 2026 12:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781723237; x=1782328037; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=81mXXCCpcttBKrAxsKwbl4tlltYVTnNUOOayD4OTdWM=; b=vDuRB2atV0Y5P2mgJqmOX+Sbkk9DrtfGe1fTWDZOa7crA8mQQTDXRgaJAG4eMGmOCK dYcng0KXbkr22v7b8bmwjW3IaA83WrBILQLQNRZ5z1ws/0Qlae507oHmCM2sQWWt67pi F9CKGdWdey/Pq1NsBIiI6FNYP+Dt9LmDdWLTjlKnp77V7U1K1Izs8z8zj0f4Zi/Mzho9 3z7K6iiw9VX9FrjJURorhrIJVZRtQDycX7aZplE2CwANncvvEurDgjX3sUjgUHMrDjJm vAHUWtIXS1XYWeiG8DNeE2iRS/GtRBtCVPfCHiYFFa44N8V1kujhC3fPOf6S2XjMwusu Ih2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781723237; x=1782328037; h=in-reply-to:content-transfer-encoding:content-disposition :content-type: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:content-type; bh=81mXXCCpcttBKrAxsKwbl4tlltYVTnNUOOayD4OTdWM=; b=T2D8VkZL4ytu6vaHR10CG5VoGYFNfYc34wexg+Dpiu9rmxS8/9S49g19Ch9DkEgcyT MirPEo34MjUW7x8HC/CjHwc1c7pxU0nXmPJFPFloLC0mYRFzDoVWWrsJNJGMAq0R3jYb DsH5bZNG+r1CCuaC8owM6E7VI/vdKswYLlNXizB7Kpda4Z6IO6zRvpmVzxr3NVPLXFSj 9xXPvHAyDMxHN1H6wQUFJteqNmHiMnHoBlo+/9FaSMy6D/Ri95VbTPOP2mHRT8JfdDNM QwKBByYshZi4I+ZO6Y+5pqti8KsyrmBFCRkue+dOZMog3pHKLuuRQ+wOb85lYSfPWHpx s5Dg== X-Forwarded-Encrypted: i=1; AFNElJ9658xedY/zPOM7zgm8Mm/KJAd9avJ0NBdKx3ZuxvMypB4AV87TlKvRJn4M5woBc1fe6VJrGwYxsYHx4q0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy8K+zO84RebUITJW8gYB+FXF5fLUY408CvwDP9GSB1g2D7q9GO U5xAnUGS7UQq+8AzOjNrTXpDQiLC79vtEHfT66qLLjfugPcU8W9iqkWH+2Fz4rxWqQ== X-Gm-Gg: AfdE7cnyNCm4OSbgYcsZCTfotUEGphXB+P0vL0DaPJbjNICQGoDYFjt2CpCscV9a7oj 99NuynFvVae0yUwYKUPbch23Hx3e5PyhkzTNqb67gZSbsaDffw5Gf0j8YFbX8BJ+puhPcp3AQE0 s18AjLK1r4KeMaV1DdQphOvsW9e9zUCDVw0/oZexVeCWysDja0TRcujIiBOv7Q1ibkbbCENrPN2 Wyhj9tNs+upJKuwgtR8/tpHThqZRVTdMguu4RRHD9HnaqdOpZsPQRMwArjp8TzjBZecpk4TJePK 3jq4tY+D5MJW5JPS9NkeKAF9XgAJyKMPc3NfSgRoZdG9yZ5a3T8zn9j03Muqo4yCTCrP9rwHAsX WZAvjcwaAGAi08pGnHTgDG5BUMC2/UFjsxvMUETTEG/qeN6cPzZOoo3lSvH4OEtWrjkUvP0i0Dq mi+koNIeq6Euh8e8tfSCghfA39KNUVfg2P2R+qQLhf3ScsovHBVQ== X-Received: by 2002:a17:902:ec91:b0:2bd:a61:8536 with SMTP id d9443c01a7336-2c6e20e58c8mr471575ad.6.1781723236749; Wed, 17 Jun 2026 12:07:16 -0700 (PDT) Received: from google.com (176.13.105.34.bc.googleusercontent.com. [34.105.13.176]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c866518677dsm15074194a12.19.2026.06.17.12.07.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 12:07:15 -0700 (PDT) Date: Wed, 17 Jun 2026 12:07:11 -0700 From: Vipin Sharma To: David Matlack Cc: Sean Christopherson , Josh Hilke , Alex Williamson , 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: <20260617180507.GB2704872.vipinsh@google.com> References: <20260602222941.3133236-1-jrhilke@google.com> <20260617161412.GA2704872.vipinsh@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 Wed, Jun 17, 2026 at 09:34:18AM -0700, David Matlack wrote: > On Wed, Jun 17, 2026 at 9:28 AM Vipin Sharma 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 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. > > > > 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. My view is that setup.sh should get supported device list by default using the list_supported_devices.sh which should correctly tell what is supported based on the kernel one has booted and wanted to test. We also have in-progress series for IGB and MLX devices selftest driver support, these devices are not in the denylist. People running VFIO selftests will be intentionally running them on supported hardware. They will also first need to check/read scripts on how to use the setup.sh, run.sh, and cleanup.sh, or manually pass device BDF value (via args or environment variable). These things are not default and one will not have a successful run in the first try without knowing these internal details. vfio-pci module default is to disable use of these denylist devices. To use these devices one has to set Y to the vfio_pci.disable_denytlist module param and reboot the kernel. So, a pre-requisite for running VFIO selftest is to be an advance user and I don't think they will have any trouble in figuring out these things.If they see no run has happened or they want to explore more, list_supported_devices.sh will be an easy read to discover flags. I think my suggested approach is advocating for keeping things in sync with what kernel default is or booted with. It looks cleaner to me and respect safeguards provided by the kernel.