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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <IA3PR11MB9136AFF8794A8A2018E008179266A@IA3PR11MB9136.namprd11.prod.outlook.com>
Date: Fri, 6 Feb 2026 03:44:22 +0000
From: "Duan, Zhenzhong" <zhenzhong.duan@...el.com>
To: Jason Gunthorpe <jgg@...pe.ca>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "dwmw2@...radead.org"
	<dwmw2@...radead.org>, "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
	"joro@...tes.org" <joro@...tes.org>, "will@...nel.org" <will@...nel.org>,
	"robin.murphy@....com" <robin.murphy@....com>, "Tian, Kevin"
	<kevin.tian@...el.com>
Subject: RE: [PATCH 0/3] iommupt/vtd: Support dirty tracking on PASID



>-----Original Message-----
>From: Jason Gunthorpe <jgg@...pe.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