[PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Zhenzhong Duan]

Hi,

When we add pasid support in QEMU for passthrough device, we found
PASID attachment to a nested parent domain with dirty tracking failed.

It's because PASID-level dirty tracking is not there yet, by adding it,
we can enable PASID attachment to such domain.

Thanks
Zhenzhong


Zhenzhong Duan (3):
  iommupt/vtd: Pass dmar_domain pointer to device_set_dirty_tracking()
  iommupt/vtd: Support dirty tracking on PASID
  iommufd/selftest: Test dirty tracking on PASID

 drivers/iommu/intel/iommu.c             | 33 ++++++++++++++-----------
 tools/testing/selftests/iommu/iommufd.c | 27 ++++++++++++++++++++
 2 files changed, 45 insertions(+), 15 deletions(-)

-- 
2.47.3

[PATCH 1/3] iommupt/vtd: Pass dmar_domain pointer to device_set_dirty_tracking()

[Zhenzhong Duan]

Pass dmar_domain pointer to device_set_dirty_tracking() instead of
device list in the domain.

This is a prerequisite patch to support dirty tracking on PASIDs.

No functional changes intended.

Suggested-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
---
 drivers/iommu/intel/iommu.c | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 134302fbcd92..acaa6eaf7e2f 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3687,16 +3687,15 @@ static void *intel_iommu_hw_info(struct device *dev, u32 *length,
 	return vtd;
 }
 
-/*
- * Set dirty tracking for the device list of a domain. The caller must
- * hold the domain->lock when calling it.
- */
-static int device_set_dirty_tracking(struct list_head *devices, bool enable)
+/* Set dirty tracking for the devices that the domain has been attached. */
+static int device_set_dirty_tracking(struct dmar_domain *domain, bool enable)
 {
 	struct device_domain_info *info;
 	int ret = 0;
 
-	list_for_each_entry(info, devices, link) {
+	lockdep_assert_held(&domain->lock);
+
+	list_for_each_entry(info, &domain->devices, link) {
 		ret = intel_pasid_setup_dirty_tracking(info->iommu, info->dev,
 						       IOMMU_NO_PASID, enable);
 		if (ret)
@@ -3716,7 +3715,7 @@ static int parent_domain_set_dirty_tracking(struct dmar_domain *domain,
 	spin_lock(&domain->s1_lock);
 	list_for_each_entry(s1_domain, &domain->s1_domains, s2_link) {
 		spin_lock_irqsave(&s1_domain->lock, flags);
-		ret = device_set_dirty_tracking(&s1_domain->devices, enable);
+		ret = device_set_dirty_tracking(s1_domain, enable);
 		spin_unlock_irqrestore(&s1_domain->lock, flags);
 		if (ret)
 			goto err_unwind;
@@ -3727,8 +3726,7 @@ static int parent_domain_set_dirty_tracking(struct dmar_domain *domain,
 err_unwind:
 	list_for_each_entry(s1_domain, &domain->s1_domains, s2_link) {
 		spin_lock_irqsave(&s1_domain->lock, flags);
-		device_set_dirty_tracking(&s1_domain->devices,
-					  domain->dirty_tracking);
+		device_set_dirty_tracking(s1_domain, domain->dirty_tracking);
 		spin_unlock_irqrestore(&s1_domain->lock, flags);
 	}
 	spin_unlock(&domain->s1_lock);
@@ -3745,7 +3743,7 @@ static int intel_iommu_set_dirty_tracking(struct iommu_domain *domain,
 	if (dmar_domain->dirty_tracking == enable)
 		goto out_unlock;
 
-	ret = device_set_dirty_tracking(&dmar_domain->devices, enable);
+	ret = device_set_dirty_tracking(dmar_domain, enable);
 	if (ret)
 		goto err_unwind;
 
@@ -3762,8 +3760,7 @@ static int intel_iommu_set_dirty_tracking(struct iommu_domain *domain,
 	return 0;
 
 err_unwind:
-	device_set_dirty_tracking(&dmar_domain->devices,
-				  dmar_domain->dirty_tracking);
+	device_set_dirty_tracking(dmar_domain, dmar_domain->dirty_tracking);
 	spin_unlock(&dmar_domain->lock);
 	return ret;
 }
-- 
2.47.3

[PATCH 2/3] iommupt/vtd: Support dirty tracking on PASID

[Zhenzhong Duan]

In order to support passthrough device with PASID capability in QEMU,
e.g., DSA device, kernel needs to support attaching PASID to a domain.

But attaching is not allowed if the domain is a second stage domain with
dirty tracking, this is the use case when guest configures 'iommu=pt'.

The reason is kernel lacking support for dirty tracking on such domain
attached to PASID. Same for nested domain even though there is no such
checking.

By adding dirty tracking on PASID, the check can be removed.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
---
 drivers/iommu/intel/iommu.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index acaa6eaf7e2f..5a9ed91109a2 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3621,9 +3621,6 @@ static int intel_iommu_set_dev_pasid(struct iommu_domain *domain,
 	if (!pasid_supported(iommu) || dev_is_real_dma_subdevice(dev))
 		return -EOPNOTSUPP;
 
-	if (domain->dirty_ops)
-		return -EINVAL;
-
 	if (context_copied(iommu, info->bus, info->devfn))
 		return -EBUSY;
 
@@ -3691,6 +3688,7 @@ static void *intel_iommu_hw_info(struct device *dev, u32 *length,
 static int device_set_dirty_tracking(struct dmar_domain *domain, bool enable)
 {
 	struct device_domain_info *info;
+	struct dev_pasid_info *dev_pasid;
 	int ret = 0;
 
 	lockdep_assert_held(&domain->lock);
@@ -3698,6 +3696,14 @@ static int device_set_dirty_tracking(struct dmar_domain *domain, bool enable)
 	list_for_each_entry(info, &domain->devices, link) {
 		ret = intel_pasid_setup_dirty_tracking(info->iommu, info->dev,
 						       IOMMU_NO_PASID, enable);
+		if (ret)
+			return ret;
+	}
+
+	list_for_each_entry(dev_pasid, &domain->dev_pasids, link_domain) {
+		info = dev_iommu_priv_get(dev_pasid->dev);
+		ret = intel_pasid_setup_dirty_tracking(info->iommu, info->dev,
+						       dev_pasid->pasid, enable);
 		if (ret)
 			break;
 	}
-- 
2.47.3

[PATCH 3/3] iommufd/selftest: Test dirty tracking on PASID

[Zhenzhong Duan]

Add test case for dirty tracking on a domain attached to PASID, also
confirm attachment to PASID fail if device doesn't support dirty tracking.

Suggested-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
---
 tools/testing/selftests/iommu/iommufd.c | 27 +++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/tools/testing/selftests/iommu/iommufd.c b/tools/testing/selftests/iommu/iommufd.c
index dadad277f4eb..d1fe5dbc2813 100644
--- a/tools/testing/selftests/iommu/iommufd.c
+++ b/tools/testing/selftests/iommu/iommufd.c
@@ -2275,6 +2275,33 @@ TEST_F(iommufd_dirty_tracking, set_dirty_tracking)
 	test_ioctl_destroy(hwpt_id);
 }
 
+TEST_F(iommufd_dirty_tracking, pasid_set_dirty_tracking)
+{
+	uint32_t stddev_id, ioas_id, hwpt_id, pasid = 100;
+	uint32_t dev_flags = MOCK_FLAGS_DEVICE_PASID;
+
+	/* Regular case */
+	test_cmd_hwpt_alloc(self->idev_id, self->ioas_id,
+			    IOMMU_HWPT_ALLOC_PASID | IOMMU_HWPT_ALLOC_DIRTY_TRACKING,
+			    &hwpt_id);
+	test_cmd_mock_domain_flags(hwpt_id, dev_flags, &stddev_id, NULL, NULL);
+	ASSERT_EQ(0, _test_cmd_pasid_attach(self->fd, stddev_id, pasid, hwpt_id));
+	test_cmd_set_dirty_tracking(hwpt_id, true);
+	test_cmd_set_dirty_tracking(hwpt_id, false);
+	ASSERT_EQ(0, _test_cmd_pasid_detach(self->fd, stddev_id, pasid));
+
+	test_ioctl_destroy(stddev_id);
+
+	/* IOMMU device does not support dirty tracking */
+	dev_flags |= MOCK_FLAGS_DEVICE_NO_DIRTY;
+	test_ioctl_ioas_alloc(&ioas_id);
+	test_cmd_mock_domain_flags(ioas_id, dev_flags, &stddev_id, NULL, NULL);
+	EXPECT_ERRNO(EINVAL, _test_cmd_pasid_attach(self->fd, stddev_id, pasid, hwpt_id));
+
+	test_ioctl_destroy(stddev_id);
+	test_ioctl_destroy(hwpt_id);
+}
+
 TEST_F(iommufd_dirty_tracking, device_dirty_capability)
 {
 	uint32_t caps = 0;
-- 
2.47.3

Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Jason Gunthorpe]

On Wed, Feb 04, 2026 at 09:34:01PM -0500, Zhenzhong Duan wrote:
> Hi,
> 
> When we add pasid support in QEMU for passthrough device, we found
> PASID attachment to a nested parent domain with dirty tracking failed.
> 
> It's because PASID-level dirty tracking is not there yet, by adding it,
> we can enable PASID attachment to such domain.
> 
> Thanks
> Zhenzhong
> 
> 
> Zhenzhong Duan (3):
>   iommupt/vtd: Pass dmar_domain pointer to device_set_dirty_tracking()
>   iommupt/vtd: Support dirty tracking on PASID
>   iommufd/selftest: Test dirty tracking on PASID

I'm not sure why you marked this s iommupt? It isn't right?

Also only the second stage table supports dirty tracking so I'm
confused what is the issue? Is it trying to say that if a second stage
is written to a pasid entry on a !=0 pasid path it doesn't work right?
But it does work on a 0 pasid?

Huh?

That sounds like a systemic problem, the two flows shouldn't actually
be any different.

Jason

RE: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Duan, Zhenzhong]

>-----Original Message-----
>From: Jason Gunthorpe <jgg@ziepe.ca>
>Subject: Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID
>
>On Wed, Feb 04, 2026 at 09:34:01PM -0500, Zhenzhong Duan wrote:
>> Hi,
>>
>> When we add pasid support in QEMU for passthrough device, we found
>> PASID attachment to a nested parent domain with dirty tracking failed.
>>
>> It's because PASID-level dirty tracking is not there yet, by adding it,
>> we can enable PASID attachment to such domain.
>>
>> Thanks
>> Zhenzhong
>>
>>
>> Zhenzhong Duan (3):
>>   iommupt/vtd: Pass dmar_domain pointer to device_set_dirty_tracking()
>>   iommupt/vtd: Support dirty tracking on PASID
>>   iommufd/selftest: Test dirty tracking on PASID
>
>I'm not sure why you marked this s iommupt? It isn't right?

Oops, should be iommu/vtd.

>
>Also only the second stage table supports dirty tracking so I'm
>confused what is the issue? Is it trying to say that if a second stage
>is written to a pasid entry on a !=0 pasid path it doesn't work right?

Yes, more strictly, if a second stage domain flagged with
IOMMU_HWPT_ALLOC_DIRTY_TRACKING is written to a pasid entry
on a !=0 pasid, it's not allowed currently, by below check:

static int intel_iommu_set_dev_pasid()
{
...
        if (domain->dirty_ops)
                return -EINVAL;


>But it does work on a 0 pasid?

More strictly, it works on IOMMU_NO_PASID.
For IOMMU_NO_PASID, we trigger attach_dev(), for other pasids,
We trigger set_dev_pasid().

>
>Huh?
>
>That sounds like a systemic problem, the two flows shouldn't actually
>be any different.

Yes, just because we have code to setup dirty tracking on 0 pasid entry
but lack the same code for !=0 pasid entry in VTD.

0 pasid is special that it can also be IOMMU_NO_PASID if PASID isn't supported.

Thanks
Zhenzhong

RE: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Duan, Zhenzhong]

Hi,

Kindly ping, any comments?

Thanks
Zhenzhong

On Wed, Feb 04, 2026 at 09:34:01PM -0500, Zhenzhong Duan wrote:
> Hi,
>
> When we add pasid support in QEMU for passthrough device, we found
> PASID attachment to a nested parent domain with dirty tracking failed.
>
> It's because PASID-level dirty tracking is not there yet, by adding it,
> we can enable PASID attachment to such domain.
>
> Thanks
> Zhenzhong
>
>
> Zhenzhong Duan (3):
>   iommupt/vtd: Pass dmar_domain pointer to device_set_dirty_tracking()
>   iommupt/vtd: Support dirty tracking on PASID
>   iommufd/selftest: Test dirty tracking on PASID

Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Baolu Lu]

On 3/23/26 09:51, Duan, Zhenzhong wrote:
> Hi,
> 
> Kindly ping, any comments?

This series looks fine to me. I will queue it (with the typo in the
subject fixed) for iommu/next if no further concerns. Thanks!

> Thanks
> Zhenzhong
> 
> On Wed, Feb 04, 2026 at 09:34:01PM -0500, Zhenzhong Duan wrote:
>> Hi,
>>
>> When we add pasid support in QEMU for passthrough device, we found
>> PASID attachment to a nested parent domain with dirty tracking failed.
>>
>> It's because PASID-level dirty tracking is not there yet, by adding it,
>> we can enable PASID attachment to such domain.
>>
>> Thanks
>> Zhenzhong
>>
>>
>> Zhenzhong Duan (3):
>>    iommupt/vtd: Pass dmar_domain pointer to device_set_dirty_tracking()
>>    iommupt/vtd: Support dirty tracking on PASID
>>    iommufd/selftest: Test dirty tracking on PASID
> 

Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Yi Liu]

Hi Baolu,

On 3/23/26 10:54, Baolu Lu wrote:
> On 3/23/26 09:51, Duan, Zhenzhong wrote:
>> Hi,
>>
>> Kindly ping, any comments?
> 
> This series looks fine to me. I will queue it (with the typo in the
> subject fixed) for iommu/next if no further concerns. Thanks!
The series also looks good to me with one more nit besides the typo in 
the subjects.

I think it's better to name device_set_dirty_tracking() to be 
domain_set_dirty_tracking() in patch 01.

Feel free to add:

Reviewed-by: Yi Liu <yi.l.liu@intel.com>

Regards,
Yi Liu

RE: [PATCH 2/3] iommupt/vtd: Support dirty tracking on PASID

[Tian, Kevin]

> From: Duan, Zhenzhong <zhenzhong.duan@intel.com>
> Sent: Thursday, February 5, 2026 10:34 AM
> 
> In order to support passthrough device with PASID capability in QEMU,
> e.g., DSA device, kernel needs to support attaching PASID to a domain.
> 
> But attaching is not allowed if the domain is a second stage domain with
> dirty tracking, this is the use case when guest configures 'iommu=pt'.
> 
> The reason is kernel lacking support for dirty tracking on such domain
> attached to PASID. Same for nested domain even though there is no such
> checking.

no check for nested domain is a bug. We should first add a check and
backport it to stable kernel. Then have this series to allow it in new
kernels.

RE: [PATCH 2/3] iommupt/vtd: Support dirty tracking on PASID

[Duan, Zhenzhong]

>-----Original Message-----
>From: Tian, Kevin <kevin.tian@intel.com>
>Subject: RE: [PATCH 2/3] iommupt/vtd: Support dirty tracking on PASID
>
>> From: Duan, Zhenzhong <zhenzhong.duan@intel.com>
>> Sent: Thursday, February 5, 2026 10:34 AM
>>
>> In order to support passthrough device with PASID capability in QEMU,
>> e.g., DSA device, kernel needs to support attaching PASID to a domain.
>>
>> But attaching is not allowed if the domain is a second stage domain with
>> dirty tracking, this is the use case when guest configures 'iommu=pt'.
>>
>> The reason is kernel lacking support for dirty tracking on such domain
>> attached to PASID. Same for nested domain even though there is no such
>> checking.
>
>no check for nested domain is a bug. We should first add a check and
>backport it to stable kernel. Then have this series to allow it in new
>kernels.

Make sense, will send v2 with the bug fix as first patch.

Thanks
Zhenzhong

RE: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Duan, Zhenzhong]

Hi Baolu,

>-----Original Message-----
>From: Liu, Yi L <yi.l.liu@intel.com>
>Subject: Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID
>
>Hi Baolu,
>
>On 3/23/26 10:54, Baolu Lu wrote:
>> On 3/23/26 09:51, Duan, Zhenzhong wrote:
>>> Hi,
>>>
>>> Kindly ping, any comments?
>>
>> This series looks fine to me. I will queue it (with the typo in the
>> subject fixed) for iommu/next if no further concerns. Thanks!
>The series also looks good to me with one more nit besides the typo in
>the subjects.
>
>I think it's better to name device_set_dirty_tracking() to be
>domain_set_dirty_tracking() in patch 01.

May I ask your preference so I could have it in next respin, device_set_dirty_tracking vs domain_set_dirty_tracking?

Thanks
Zhenzhong

>
>Feel free to add:
>
>Reviewed-by: Yi Liu <yi.l.liu@intel.com>
>
>Regards,
>Yi Liu

Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID

[Baolu Lu]

On 3/30/26 10:04, Duan, Zhenzhong wrote:
> Hi Baolu,
> 
>> -----Original Message-----
>> From: Liu, Yi L<yi.l.liu@intel.com>
>> Subject: Re: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID
>>
>> Hi Baolu,
>>
>> On 3/23/26 10:54, Baolu Lu wrote:
>>> On 3/23/26 09:51, Duan, Zhenzhong wrote:
>>>> Hi,
>>>>
>>>> Kindly ping, any comments?
>>> This series looks fine to me. I will queue it (with the typo in the
>>> subject fixed) for iommu/next if no further concerns. Thanks!
>> The series also looks good to me with one more nit besides the typo in
>> the subjects.
>>
>> I think it's better to name device_set_dirty_tracking() to be
>> domain_set_dirty_tracking() in patch 01.
> May I ask your preference so I could have it in next respin, device_set_dirty_tracking vs domain_set_dirty_tracking?

I prefer domain_set_dirty_tracking() according to what the helper does.

Thanks,
baolu