All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Matlack <dmatlack@google.com>
To: Narayana Murty N <nnmlinux@linux.ibm.com>
Cc: alex@shazbot.org, shuah@kernel.org, amastro@fb.com,
	rananta@google.com, kvm@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	vaibhav@linux.ibm.com, sbhat@linux.ibm.com,
	harshpb@linux.ibm.com
Subject: Re: [RFC PATCH 1/6] selftests/vfio: allow selecting IOMMU backend from environment
Date: Mon, 6 Jul 2026 21:49:03 +0000	[thread overview]
Message-ID: <akwiz5fpVRSWQEBC@google.com> (raw)
In-Reply-To: <20260703032806.40946-2-nnmlinux@linux.ibm.com>

On 2026-07-02 11:28 PM, Narayana Murty N wrote:
> Add support for selecting the IOMMU mode through the environment
> variable VFIO_SELFTESTS_IOMMU_MODE. This allows tests to be run
> with different IOMMU backends without modifying test code.
> 
> The environment variable is validated against the list of supported
> modes. On PowerPC, this includes the sPAPR TCE v2 mode which will
> be added in a subsequent patch.
> 
> If the environment variable is not set, tests use their default
> mode, preserving existing behavior.
> 
> Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>

> diff --git a/tools/testing/selftests/vfio/vfio_pci_device_test.c b/tools/testing/selftests/vfio/vfio_pci_device_test.c
> index 93c11fd5e081..45b8bf60527a 100644
> --- a/tools/testing/selftests/vfio/vfio_pci_device_test.c
> +++ b/tools/testing/selftests/vfio/vfio_pci_device_test.c
> @@ -29,7 +29,7 @@ FIXTURE(vfio_pci_device_test) {
>  
>  FIXTURE_SETUP(vfio_pci_device_test)
>  {
> -	self->iommu = iommu_init(default_iommu_mode);
> +	self->iommu = iommu_init(vfio_selftests_get_iommu_mode());
>  	self->device = vfio_pci_device_init(device_bdf, self->iommu);
>  }
>  
> @@ -121,7 +121,7 @@ FIXTURE_VARIANT_ADD(vfio_pci_irq_test, msix) {
>  
>  FIXTURE_SETUP(vfio_pci_irq_test)
>  {
> -	self->iommu = iommu_init(default_iommu_mode);
> +	self->iommu = iommu_init(vfio_selftests_get_iommu_mode());
>  	self->device = vfio_pci_device_init(device_bdf, self->iommu);
>  }

Rather than forcing the user to pass in the mode via environment
variable, can vfio_selftests_get_iommu_mode() pick a reasonable default
based on what the host supports? i.e. Is it possible for
vfio_selftests_get_iommu_mode() to now when to pick
MODE_VFIO_SPAPR_TCE_V2_IOMMU as the default mode?

The new KVM device-posted interrupt test that uses the VFIO selftests
library also wants this to pick between MODE_IOMMUFD and
MODE_VFIO_TYPE1_IOMMU.

  https://lore.kernel.org/kvm/aiIG2L_KdPwuxYA1@google.com/

And this would also fix VFIO selftests that get run on kernels where
IOMMUFD is not enabled.

  parent reply	other threads:[~2026-07-06 21:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03  3:28 [RFC PATCH 0/6] selftests/vfio: Add sPAPR TCE v2 coverage Narayana Murty N
2026-07-03  3:28 ` [RFC PATCH 1/6] selftests/vfio: allow selecting IOMMU backend from environment Narayana Murty N
2026-07-03  8:06   ` sashiko-bot
2026-07-06 21:49   ` David Matlack [this message]
2026-07-03  3:28 ` [RFC PATCH 2/6] selftests/vfio: add sPAPR TCE v2 IOMMU mode Narayana Murty N
2026-07-03  8:09   ` sashiko-bot
2026-07-03  3:28 ` [RFC PATCH 3/6] selftests/vfio: add sPAPR TCE v2 DMA window helpers Narayana Murty N
2026-07-03  8:05   ` sashiko-bot
2026-07-06 22:04   ` David Matlack
2026-07-06 22:17   ` David Matlack
2026-07-03  3:28 ` [RFC PATCH 4/6] selftests/vfio: Exercise sPAPR DDW path for hugepage DMA mappings Narayana Murty N
2026-07-03  8:11   ` sashiko-bot
2026-07-06 22:33   ` David Matlack
2026-07-06 22:41     ` David Matlack
2026-07-03  3:28 ` [RFC PATCH 5/6] selftests/vfio: Accept sPAPR errno for DMA range overflow Narayana Murty N
2026-07-03  8:08   ` sashiko-bot
2026-07-06 22:47   ` David Matlack
2026-07-03  3:28 ` [RFC PATCH 6/6] selftests/vfio: Enable VFIO selftests on ppc64 and ppc64le Narayana Murty N
2026-07-03  8:14   ` sashiko-bot
2026-07-03  8:28 ` [RFC PATCH 0/6] selftests/vfio: Add sPAPR TCE v2 coverage Harsh Prateek Bora
2026-07-06 22:55 ` David Matlack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akwiz5fpVRSWQEBC@google.com \
    --to=dmatlack@google.com \
    --cc=alex@shazbot.org \
    --cc=amastro@fb.com \
    --cc=harshpb@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=nnmlinux@linux.ibm.com \
    --cc=rananta@google.com \
    --cc=sbhat@linux.ibm.com \
    --cc=shuah@kernel.org \
    --cc=vaibhav@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.