Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Samiullah Khawaja <skhawaja@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Aex Williamson <alex@shazbot.org>, Shuah Khan <shuah@kernel.org>,
	 Alex Mastro <amastro@fb.com>,
	Raghavendra Rao Ananta <rananta@google.com>,
	kvm@vger.kernel.org,  linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] vfio: selftests: Add support of creating multiple iommus from iommufd
Date: Mon, 11 May 2026 20:21:22 +0000	[thread overview]
Message-ID: <agI2EFvBwKUHaHVi@google.com> (raw)
In-Reply-To: <af4or28EA6PGEd12@google.com>

On Fri, May 08, 2026 at 06:17:19PM +0000, David Matlack wrote:
>On 2026-05-05 10:14 PM, Samiullah Khawaja wrote:
>> IOMMUFD allows creating multiple IOAS and HWPTs under one iommufd, Add
>> API to init a struct iommu using an already opened iommufd. The API
>> internally creates a new IOAS and also a new HWPT as an option based on
>> the flags passed to the function.
>>
>> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
>> ---
>>  .../vfio/lib/include/libvfio/iommu.h          |  5 ++
>>  .../lib/include/libvfio/vfio_pci_device.h     |  2 +
>>  tools/testing/selftests/vfio/lib/iommu.c      | 62 +++++++++++++++++--
>>  .../selftests/vfio/lib/vfio_pci_device.c      | 22 ++++++-
>>  4 files changed, 84 insertions(+), 7 deletions(-)
>>

[snip]
>>  int __iommu_map(struct iommu *iommu, struct dma_region *region);
>> diff --git a/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h b/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h
>> index 2858885a89bb..1143ceb6a9b8 100644
>> --- a/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h
>> +++ b/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_device.h
>> @@ -19,6 +19,7 @@ struct vfio_pci_device {
>>  	const char *bdf;
>>  	int fd;
>>  	int group_fd;
>> +	u32 dev_id;
>
>Please introduce an initialize this field in its own patch and, in the
>commit message, explain why it is being added and  how it will be used.

Agreed. Will do in next revision.
>
>>
>>  	struct iommu *iommu;
>>
>> @@ -65,6 +66,7 @@ void vfio_pci_config_access(struct vfio_pci_device *device, bool write,
>>  #define vfio_pci_config_writew(_d, _o, _v) vfio_pci_config_write(_d, _o, _v, u16)
>>  #define vfio_pci_config_writel(_d, _o, _v) vfio_pci_config_write(_d, _o, _v, u32)
>>
>> +void vfio_pci_device_attach_iommu(struct vfio_pci_device *device, struct iommu *iommu);
>>  void vfio_pci_irq_enable(struct vfio_pci_device *device, u32 index,
>>  			 u32 vector, int count);
>>  void vfio_pci_irq_disable(struct vfio_pci_device *device, u32 index);
>> diff --git a/tools/testing/selftests/vfio/lib/iommu.c b/tools/testing/selftests/vfio/lib/iommu.c
>> index 035dac069d60..644c049cf9f0 100644
>> --- a/tools/testing/selftests/vfio/lib/iommu.c
>> +++ b/tools/testing/selftests/vfio/lib/iommu.c
>> @@ -408,6 +408,18 @@ struct iommu_iova_range *iommu_iova_ranges(struct iommu *iommu, u32 *nranges)
>>  	return ranges;
>>  }
>>

[snip]
>> +struct iommu *iommufd_iommu_init(int iommufd, u32 dev_id, u32 flags)
>> +{
>> +	struct iommu *iommu;
>> +
>> +	iommu = iommu_alloc("iommufd");
>
>Use MODE_IOMMUFD instead of string literal.

Agreed. Will update this.
>
>> +
>> +	iommu->iommufd = dup(iommufd);
>> +	VFIO_ASSERT_GT(iommu->iommufd, 0);
>> +
>> +	iommu->ioas_id = iommufd_ioas_alloc(iommu->iommufd);
>
>Please avoid duplicating this code. e.g. Something like this:

Agreed. Will update this.
>
>diff --git a/tools/testing/selftests/vfio/lib/iommu.c b/tools/testing/selftests/vfio/lib/iommu.c
>index 644c049cf9f0..4909cda5c840 100644
>--- a/tools/testing/selftests/vfio/lib/iommu.c
>+++ b/tools/testing/selftests/vfio/lib/iommu.c
>@@ -443,6 +443,19 @@ static struct iommu *iommu_alloc(const char *iommu_mode)
>        return iommu;
> }
>
>+static void iommufd_init(struct iommu *iommu, int iommufd)
>+{
>+       /*
>+        * Require device->iommufd to be >0 so that a simple non-0 check can be
>+        * used to check if iommufd is enabled. In practice open() will never
>+        * return 0 unless stdin is closed.
>+        */
>+       VFIO_ASSERT_GT(iommufd, 0);
>+
>+       iommu->iommufd = iommufd;
>+       iommu->ioas_id = iommufd_ioas_alloc(iommu->iommufd);
>+}
>+
> struct iommu *iommu_init(const char *iommu_mode)
> {
>        const char *container_path;
>@@ -459,15 +472,7 @@ struct iommu *iommu_init(const char *iommu_mode)
>                version = ioctl(iommu->container_fd, VFIO_GET_API_VERSION);
>                VFIO_ASSERT_EQ(version, VFIO_API_VERSION, "Unsupported version: %d\n", version);
>        } else {
>-               /*
>-                * Require device->iommufd to be >0 so that a simple non-0 check can be
>-                * used to check if iommufd is enabled. In practice open() will never
>-                * return 0 unless stdin is closed.
>-                */
>-               iommu->iommufd = open("/dev/iommu", O_RDWR);
>-               VFIO_ASSERT_GT(iommu->iommufd, 0);
>-
>-               iommu->ioas_id = iommufd_ioas_alloc(iommu->iommufd);
>+               iommufd_init(iommu, open("/dev/iommu", O_RDWR));
>        }
>
>        return iommu;
>@@ -478,11 +483,7 @@ struct iommu *iommufd_iommu_init(int iommufd, u32 dev_id, u32 flags)
>        struct iommu *iommu;
>
>        iommu = iommu_alloc("iommufd");
>-
>-       iommu->iommufd = dup(iommufd);
>-       VFIO_ASSERT_GT(iommu->iommufd, 0);
>-
>-       iommu->ioas_id = iommufd_ioas_alloc(iommu->iommufd);
>+       iommufd_init(iommu, dup(iommufd));
>
>        if (flags & IOMMUFD_IOMMU_INIT_CREATE_PT)
>                iommu->hwpt_id = iommufd_hwpt_alloc(iommu, dev_id);
>
>> +
>> +	if (flags & IOMMUFD_IOMMU_INIT_CREATE_PT)
>> +		iommu->hwpt_id = iommufd_hwpt_alloc(iommu, dev_id);
>
>Does this need to be part of iommufd_iommu_init()? Maybe it would be
>better to expose a separate helper to allocate a HWPT for a given struct
>iommu *.

Hmm.. that is interesting.. I think we can have following immediate
possibilities when creating a struct iommu (there will be more down the
road, but can be handled in similar way):

- create using struct iommu with a new IOAS.
- create using struct iommu with existing IOAS but new HWPT.
- create using struct iommu with new IOAS and new HWPT.

I think I should probably add following flags:

IOMMUFD_IOMMU_INIT_CREATE_IOPT (IO Page Table) or _PT
IOMMUFD_IOMMU_INIT_CREATE_IOAS (IO address Space) or _AS

At least one of those should be required when creating new struct iommu
from an existing one. WDYT?
>
>This would enable use of HWPTs in iommus constructed by iommu_init() as
>well, which someone may want to do in the future.
>
>If you go this route, please introduce this in its own commit.

Both flags can be introduced in same commit or should be separate?
>
>> +
>> +	return iommu;
>> +}
>> +
>> +static void iommufd_cleanup(struct iommu *iommu)
>> +{
>> +	struct iommu_destroy args = {
>> +		.size = sizeof(args),
>> +	};
>> +
>> +	if (iommu->hwpt_id) {
>> +		args.id = iommu->hwpt_id;
>> +		ioctl_assert(iommu->iommufd, IOMMU_DESTROY, &args);
>> +	}
>> +
>> +	args.id = iommu->ioas_id;
>> +	ioctl_assert(iommu->iommufd, IOMMU_DESTROY, &args);
>
>
>Please create a helper function to do IOMMU_DESTROY ioctl. Then here you
>can just do:
>
>  if (iommu->hwpt_id)
>          iommufd_iommu_destroy(iommu, iommu->hwpt_id);
>
>  iommfd_iommu_destroy(iommu, iommu->ioas_id);

Looks great. Will do.
>
>> +
>> +	VFIO_ASSERT_EQ(close(iommu->iommufd), 0);
>> +}
>> +
>>  void iommu_cleanup(struct iommu *iommu)
>>  {
>>  	if (iommu->iommufd)
>> -		VFIO_ASSERT_EQ(close(iommu->iommufd), 0);
>> +		iommufd_cleanup(iommu);
>>  	else
>>  		VFIO_ASSERT_EQ(close(iommu->container_fd), 0);
>>

[snip]
>> +void vfio_pci_device_attach_iommu(struct vfio_pci_device *device, struct iommu *iommu)
>> +{
>> +	u32 pt_id = iommu->ioas_id;
>> +
>> +	/* Only iommufd supports changing struct iommu attachments */
>> +	VFIO_ASSERT_TRUE(iommu->iommufd);
>> +
>> +	if (iommu->hwpt_id)
>> +		pt_id = iommu->hwpt_id;
>
>nit: This can be folded into the variable declaration.
>
>  const u32 pt_id = iommu->hwpt_id ?: iommu->ioas_id;

Agreed
>
>> +
>> +	VFIO_ASSERT_NE(pt_id, 0);
>
>Why is this check needed?

I think it is redundant. I will remove it.
>
>> +	vfio_device_attach_iommufd_pt(device->fd, pt_id);
>> +	device->iommu = iommu;
>> +}
>
>Please introduce vfio_pci_device_attach_iommu() in its own patch.

Agreed. Will do.
>
>> +
>>  static void vfio_pci_iommufd_setup(struct vfio_pci_device *device, const char *bdf)
>>  {
>>  	const char *cdev_path = vfio_pci_get_cdev_path(bdf);
>> @@ -350,8 +366,8 @@ static void vfio_pci_iommufd_setup(struct vfio_pci_device *device, const char *b
>>  	VFIO_ASSERT_GE(device->fd, 0);
>>  	free((void *)cdev_path);
>>
>> -	vfio_device_bind_iommufd(device->fd, device->iommu->iommufd);
>> -	vfio_device_attach_iommufd_pt(device->fd, device->iommu->ioas_id);
>> +	device->dev_id = vfio_device_bind_iommufd(device->fd, device->iommu->iommufd);
>> +	vfio_pci_device_attach_iommu(device, device->iommu);
>>  }
>>
>>  struct vfio_pci_device *vfio_pci_device_init(const char *bdf, struct iommu *iommu)
>> --
>> 2.54.0.545.g6539524ca2-goog
>>

Thanks,
Sami

  reply	other threads:[~2026-05-11 20:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260505221518.619123-1-skhawaja@google.com>
2026-05-05 22:14 ` [PATCH 1/2] vfio: selftests: Add support of creating multiple iommus from iommufd Samiullah Khawaja
2026-05-08 18:17   ` David Matlack
2026-05-11 20:21     ` Samiullah Khawaja [this message]
2026-05-11 20:59       ` David Matlack
2026-05-11 21:41         ` Samiullah Khawaja
2026-05-05 22:14 ` [PATCH 2/2] vfio: selftests: Add iommufd multi iommu test Samiullah Khawaja
2026-05-08 20:14   ` David Matlack
2026-05-11 20:53     ` Samiullah Khawaja
2026-05-11 21:10       ` David Matlack
2026-05-11 21:27         ` Samiullah Khawaja

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=agI2EFvBwKUHaHVi@google.com \
    --to=skhawaja@google.com \
    --cc=alex@shazbot.org \
    --cc=amastro@fb.com \
    --cc=dmatlack@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=rananta@google.com \
    --cc=shuah@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox