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

Duan, Zhenzhong
2026-02-06T03:44:26Z

>-----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