[PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Nicolin Chen]

HTTU is introduced by utilizing the Dirty Bit Modifier (DBM) in the PTE.
When kernel maps a clean but writable page, it will set PTE_READONLY and
PTE_DBM (aka PTE_WRITE) at the same time. When a write occurs, an HTTU-
capable MMU will automatically clear the PTE_RDONLY bit without software
intervention.

On the other hand, SMMU has the same HTTU feature, yet it is not enabled
in the SVA CD. As a result, SMMU will not clear the PTE_RDONLY bit while
sharing the CPU page table, resulting in unnecessary stalls.

Thus, enable CTXDESC_CD_0_TCR_HA and CTXDESC_CD_0_TCR_HD in the SVA CD.

Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index f1f8e01a7e914..1ed8a6f29dc44 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
 
 		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
 					      CTXDESC_CD_1_TTB0_MASK);
+
+		/*
+		 * Enable Hardware Access and Dirty updates (DBM) if supported.
+		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
+		 * share the same bit.
+		 */
+		if (master->smmu->features & ARM_SMMU_FEAT_HA)
+			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
+		if (master->smmu->features & ARM_SMMU_FEAT_HD)
+			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
 	} else {
 		target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_EPD0);
 
-- 
2.43.0

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Sun, May 03, 2026 at 06:54:12AM -0700, Nicolin Chen wrote:
> HTTU is introduced by utilizing the Dirty Bit Modifier (DBM) in the PTE.
> When kernel maps a clean but writable page, it will set PTE_READONLY and
> PTE_DBM (aka PTE_WRITE) at the same time. When a write occurs, an HTTU-
> capable MMU will automatically clear the PTE_RDONLY bit without software
> intervention.
> 
> On the other hand, SMMU has the same HTTU feature, yet it is not enabled
> in the SVA CD. As a result, SMMU will not clear the PTE_RDONLY bit while
> sharing the CPU page table, resulting in unnecessary stalls.
> 
> Thus, enable CTXDESC_CD_0_TCR_HA and CTXDESC_CD_0_TCR_HD in the SVA CD.
> 
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index f1f8e01a7e914..1ed8a6f29dc44 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
>  
>  		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
>  					      CTXDESC_CD_1_TTB0_MASK);
> +
> +		/*
> +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
> +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
> +		 * share the same bit.
> +		 */
> +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
> +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
> +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);

IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?

I think the driver maintains a clear distinction between HW capability 
(FEAT_HA/HD) and feature enablement (IO_PGTABLE_QUIRK_ARM_HD). 

We set IO_PGTABLE_QUIRK_ARM_HD during S1 domain finalize if 
IOMMU_HWPT_ALLOC_DIRTY_TRACKING flag is passed. Hence, we should check
for that flag OR IO_PGTABLE_QUIRK_ARM_HD before enabling these in CD..

Thanks,
Praan

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Jason Gunthorpe]

On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
> > @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
> >  
> >  		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
> >  					      CTXDESC_CD_1_TTB0_MASK);
> > +
> > +		/*
> > +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
> > +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
> > +		 * share the same bit.
> > +		 */
> > +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
> > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> > +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
> > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> 
> IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?

SVA does not use IO_PGTABLE at all, and it directly constructs its own
CD.

No relation between those two flows.

Jason

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Fri, May 08, 2026 at 09:35:50AM -0300, Jason Gunthorpe wrote:
> On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
> > > @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
> > >  
> > >  		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
> > >  					      CTXDESC_CD_1_TTB0_MASK);
> > > +
> > > +		/*
> > > +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
> > > +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
> > > +		 * share the same bit.
> > > +		 */
> > > +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
> > > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> > > +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
> > > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> > 
> > IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?
> 
> SVA does not use IO_PGTABLE at all, and it directly constructs its own
> CD.
> 
> No relation between those two flows.

I understand that but I mean we need to know if the system supports
HTTU ? Like for SMMU we use the IO_PGTABLE_QUIRK, shouldn't we be
checking if the CPU's tables support HTTU?

Are we assuming that if the SMMU IDR presents HTTU capability the MMU
would also have it? I think an unconditional enablement is risky as we
may not have system-wide HTTU support.

If we look at arm_smmu_master_sva_supported, the driver already 
maintains a strict agreement between the CPU and SMMU for SVA.
It checks sanitized CPU ID registers for things like PARANGE & ASIDBITS,
and it uses system_supports_bbml2_noabort() to decide whether to enable 
FEAT_BBML2.

Shouldn't we follow this exact same pattern for HTTU ?
We should probably be checking cpu_has_hw_af() (from asm/cpufeature.h) 
in the SVA support check or here if we wanna enable HTTU.

Thanks,
Praan

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Jason Gunthorpe]

On Fri, May 08, 2026 at 01:12:56PM +0000, Pranjal Shrivastava wrote:

> Are we assuming that if the SMMU IDR presents HTTU capability the MMU
> would also have it? I think an unconditional enablement is risky as we
> may not have system-wide HTTU support.

Oh, yes! That is missing here it should not be turned on unless the
CPU side is also using it.

Jason

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Robin Murphy]

On 2026-05-08 2:12 pm, Pranjal Shrivastava wrote:
> On Fri, May 08, 2026 at 09:35:50AM -0300, Jason Gunthorpe wrote:
>> On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
>>>> @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
>>>>   
>>>>   		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
>>>>   					      CTXDESC_CD_1_TTB0_MASK);
>>>> +
>>>> +		/*
>>>> +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
>>>> +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
>>>> +		 * share the same bit.
>>>> +		 */
>>>> +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
>>>> +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
>>>> +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
>>>> +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
>>>
>>> IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?
>>
>> SVA does not use IO_PGTABLE at all, and it directly constructs its own
>> CD.
>>
>> No relation between those two flows.
> 
> I understand that but I mean we need to know if the system supports
> HTTU ? Like for SMMU we use the IO_PGTABLE_QUIRK, shouldn't we be
> checking if the CPU's tables support HTTU?
> 
> Are we assuming that if the SMMU IDR presents HTTU capability the MMU
> would also have it? I think an unconditional enablement is risky as we
> may not have system-wide HTTU support.
> 
> If we look at arm_smmu_master_sva_supported, the driver already
> maintains a strict agreement between the CPU and SMMU for SVA.
> It checks sanitized CPU ID registers for things like PARANGE & ASIDBITS,
> and it uses system_supports_bbml2_noabort() to decide whether to enable
> FEAT_BBML2.
> 
> Shouldn't we follow this exact same pattern for HTTU ?
> We should probably be checking cpu_has_hw_af() (from asm/cpufeature.h)
> in the SVA support check or here if we wanna enable HTTU.

It might make sense to depend on CONFIG_ARM64_HW_AFDBM - when that is 
enabled, then IIRC we already expect to cope with some CPUs not 
supporting hardware updates, so it should still be fine for an SMMU to 
make them even if no CPU does. However, if it's disabled then I'm not 
sure if missing access flag faults (if SMMU HA silently sets them) might 
be an issue - for dirty, we'd just never put down the Writeable-Clean 
permission so enabling SMMU HD wouldn't do anything anyway.

Thanks,
Robin.

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Fri, May 08, 2026 at 02:31:11PM +0100, Robin Murphy wrote:
> On 2026-05-08 2:12 pm, Pranjal Shrivastava wrote:
> > On Fri, May 08, 2026 at 09:35:50AM -0300, Jason Gunthorpe wrote:
> > > On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
> > > > > @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
> > > > >   		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
> > > > >   					      CTXDESC_CD_1_TTB0_MASK);
> > > > > +
> > > > > +		/*
> > > > > +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
> > > > > +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
> > > > > +		 * share the same bit.
> > > > > +		 */
> > > > > +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
> > > > > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> > > > > +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
> > > > > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> > > > 
> > > > IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?
> > > 
> > > SVA does not use IO_PGTABLE at all, and it directly constructs its own
> > > CD.
> > > 
> > > No relation between those two flows.
> > 
> > I understand that but I mean we need to know if the system supports
> > HTTU ? Like for SMMU we use the IO_PGTABLE_QUIRK, shouldn't we be
> > checking if the CPU's tables support HTTU?
> > 
> > Are we assuming that if the SMMU IDR presents HTTU capability the MMU
> > would also have it? I think an unconditional enablement is risky as we
> > may not have system-wide HTTU support.
> > 
> > If we look at arm_smmu_master_sva_supported, the driver already
> > maintains a strict agreement between the CPU and SMMU for SVA.
> > It checks sanitized CPU ID registers for things like PARANGE & ASIDBITS,
> > and it uses system_supports_bbml2_noabort() to decide whether to enable
> > FEAT_BBML2.
> > 
> > Shouldn't we follow this exact same pattern for HTTU ?
> > We should probably be checking cpu_has_hw_af() (from asm/cpufeature.h)
> > in the SVA support check or here if we wanna enable HTTU.
> 
> It might make sense to depend on CONFIG_ARM64_HW_AFDBM - when that is
> enabled, then IIRC we already expect to cope with some CPUs not supporting
> hardware updates, so it should still be fine for an SMMU to make them even
> if no CPU does. However, if it's disabled then I'm not sure if missing
> access flag faults (if SMMU HA silently sets them) might be an issue - for
> dirty, we'd just never put down the Writeable-Clean permission so enabling
> SMMU HD wouldn't do anything anyway.

I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
Since the fault handlers are already expecting HW-triggered updates?

Which means our check would be something like:

   if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
   	if (smmu->features & FEAT_HA)
	 ...
   }

instead of cpu_has_hw_af()?

Thanks,
Praan

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Robin Murphy]

On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> On Fri, May 08, 2026 at 02:31:11PM +0100, Robin Murphy wrote:
>> On 2026-05-08 2:12 pm, Pranjal Shrivastava wrote:
>>> On Fri, May 08, 2026 at 09:35:50AM -0300, Jason Gunthorpe wrote:
>>>> On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
>>>>>> @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
>>>>>>    		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
>>>>>>    					      CTXDESC_CD_1_TTB0_MASK);
>>>>>> +
>>>>>> +		/*
>>>>>> +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
>>>>>> +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
>>>>>> +		 * share the same bit.
>>>>>> +		 */
>>>>>> +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
>>>>>> +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
>>>>>> +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
>>>>>> +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
>>>>>
>>>>> IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?
>>>>
>>>> SVA does not use IO_PGTABLE at all, and it directly constructs its own
>>>> CD.
>>>>
>>>> No relation between those two flows.
>>>
>>> I understand that but I mean we need to know if the system supports
>>> HTTU ? Like for SMMU we use the IO_PGTABLE_QUIRK, shouldn't we be
>>> checking if the CPU's tables support HTTU?
>>>
>>> Are we assuming that if the SMMU IDR presents HTTU capability the MMU
>>> would also have it? I think an unconditional enablement is risky as we
>>> may not have system-wide HTTU support.
>>>
>>> If we look at arm_smmu_master_sva_supported, the driver already
>>> maintains a strict agreement between the CPU and SMMU for SVA.
>>> It checks sanitized CPU ID registers for things like PARANGE & ASIDBITS,
>>> and it uses system_supports_bbml2_noabort() to decide whether to enable
>>> FEAT_BBML2.
>>>
>>> Shouldn't we follow this exact same pattern for HTTU ?
>>> We should probably be checking cpu_has_hw_af() (from asm/cpufeature.h)
>>> in the SVA support check or here if we wanna enable HTTU.
>>
>> It might make sense to depend on CONFIG_ARM64_HW_AFDBM - when that is
>> enabled, then IIRC we already expect to cope with some CPUs not supporting
>> hardware updates, so it should still be fine for an SMMU to make them even
>> if no CPU does. However, if it's disabled then I'm not sure if missing
>> access flag faults (if SMMU HA silently sets them) might be an issue - for
>> dirty, we'd just never put down the Writeable-Clean permission so enabling
>> SMMU HD wouldn't do anything anyway.
> 
> I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> Since the fault handlers are already expecting HW-triggered updates?
> 
> Which means our check would be something like:
> 
>     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
>     	if (smmu->features & FEAT_HA)
> 	 ...
>     }
> 
> instead of cpu_has_hw_af()?

Hmm, looking closer, cpu_has_hw_af() is the thing which actually 
influences mm behaviour (via arch_has_hw_pte_young and 
arch_wants_old_prefaulted_pte), and that can still be false at runtime 
if ARM64_HW_AFDBM is enabled but any CPU doesn't support HAFDBS, so 
perhaps you were right the first time :)

Although AFAICS from __cpu_setup(), ARM64_HW_AFDBM will still 
unconditionally enable TCR_EL1.HA on CPUs which do support it, so maybe 
it is OK anyway?

Cheers,
Robin.

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Nicolin Chen]

On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > Since the fault handlers are already expecting HW-triggered updates?
> > 
> > Which means our check would be something like:
> > 
> >     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> >     	if (smmu->features & FEAT_HA)
> > 	 ...
> >     }
> > 
> > instead of cpu_has_hw_af()?
> 
> Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> CPU doesn't support HAFDBS, so perhaps you were right the first time :)

IIUIC, v2 should be:

+		/*
+		 * Enable Hardware Access and Dirty updates (DBM) if supported by
+		 * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU,
+		 * if the CPU does not support it as it bypasses mm page aging.
+		 */
+		if (cpu_has_hw_af()) {
+			if (master->smmu->features & ARM_SMMU_FEAT_HA)
+				target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
+			if (master->smmu->features & ARM_SMMU_FEAT_HD)
+				target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
+		}

Thanks
Nicolin

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > On Fri, May 08, 2026 at 02:31:11PM +0100, Robin Murphy wrote:
> > > On 2026-05-08 2:12 pm, Pranjal Shrivastava wrote:
> > > > On Fri, May 08, 2026 at 09:35:50AM -0300, Jason Gunthorpe wrote:
> > > > > On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
> > > > > > > @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
> > > > > > >    		target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
> > > > > > >    					      CTXDESC_CD_1_TTB0_MASK);
> > > > > > > +
> > > > > > > +		/*
> > > > > > > +		 * Enable Hardware Access and Dirty updates (DBM) if supported.
> > > > > > > +		 * This is safe to enable by default, as PTE_WRITE and PTE_DBM
> > > > > > > +		 * share the same bit.
> > > > > > > +		 */
> > > > > > > +		if (master->smmu->features & ARM_SMMU_FEAT_HA)
> > > > > > > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> > > > > > > +		if (master->smmu->features & ARM_SMMU_FEAT_HD)
> > > > > > > +			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> > > > > > 
> > > > > > IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?
> > > > > 
> > > > > SVA does not use IO_PGTABLE at all, and it directly constructs its own
> > > > > CD.
> > > > > 
> > > > > No relation between those two flows.
> > > > 
> > > > I understand that but I mean we need to know if the system supports
> > > > HTTU ? Like for SMMU we use the IO_PGTABLE_QUIRK, shouldn't we be
> > > > checking if the CPU's tables support HTTU?
> > > > 
> > > > Are we assuming that if the SMMU IDR presents HTTU capability the MMU
> > > > would also have it? I think an unconditional enablement is risky as we
> > > > may not have system-wide HTTU support.
> > > > 
> > > > If we look at arm_smmu_master_sva_supported, the driver already
> > > > maintains a strict agreement between the CPU and SMMU for SVA.
> > > > It checks sanitized CPU ID registers for things like PARANGE & ASIDBITS,
> > > > and it uses system_supports_bbml2_noabort() to decide whether to enable
> > > > FEAT_BBML2.
> > > > 
> > > > Shouldn't we follow this exact same pattern for HTTU ?
> > > > We should probably be checking cpu_has_hw_af() (from asm/cpufeature.h)
> > > > in the SVA support check or here if we wanna enable HTTU.
> > > 
> > > It might make sense to depend on CONFIG_ARM64_HW_AFDBM - when that is
> > > enabled, then IIRC we already expect to cope with some CPUs not supporting
> > > hardware updates, so it should still be fine for an SMMU to make them even
> > > if no CPU does. However, if it's disabled then I'm not sure if missing
> > > access flag faults (if SMMU HA silently sets them) might be an issue - for
> > > dirty, we'd just never put down the Writeable-Clean permission so enabling
> > > SMMU HD wouldn't do anything anyway.
> > 
> > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > Since the fault handlers are already expecting HW-triggered updates?
> > 
> > Which means our check would be something like:
> > 
> >     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> >     	if (smmu->features & FEAT_HA)
> > 	 ...
> >     }
> > 
> > instead of cpu_has_hw_af()?
> 
> Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> CPU doesn't support HAFDBS, so perhaps you were right the first time :)
> 

Yea, I believe the cpu_has_hw_af() is the right gate.

> Although AFAICS from __cpu_setup(), ARM64_HW_AFDBM will still
> unconditionally enable TCR_EL1.HA on CPUs which do support it, so maybe it
> is OK anyway?
> 

I believe cpu_has_hw_af() is still the safer gate for SVA. While 
individual cores might turn on their local HA support, cpu_has_hw_af()
represents the sanitized system view.

In mismatched systems (where some cores support HAFDBS and others don't),
cpu_has_hw_af() will be false & mm shall default to software-managed AF/
Dirty for consistency across all threads. Enabling HTTU in the SMMU while
the kernel mm is in 'SW-Managed' mode could cause the SMMU to silently 
flip bits that the kernel is expecting to handle via faults, leading to a
mismatch.

Thanks,
Praan

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Sat, May 09, 2026 at 12:56:57AM -0700, Nicolin Chen wrote:
> On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> > On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > > Since the fault handlers are already expecting HW-triggered updates?
> > > 
> > > Which means our check would be something like:
> > > 
> > >     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> > >     	if (smmu->features & FEAT_HA)
> > > 	 ...
> > >     }
> > > 
> > > instead of cpu_has_hw_af()?
> > 
> > Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> > mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> > and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> > CPU doesn't support HAFDBS, so perhaps you were right the first time :)
> 
> IIUIC, v2 should be:
> 
> +		/*
> +		 * Enable Hardware Access and Dirty updates (DBM) if supported by
> +		 * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU,
> +		 * if the CPU does not support it as it bypasses mm page aging.
> +		 */
> +		if (cpu_has_hw_af()) {

Ack, yes. IMO, this is the correct system-wide gate.

> +			if (master->smmu->features & ARM_SMMU_FEAT_HA)
> +				target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> +			if (master->smmu->features & ARM_SMMU_FEAT_HD)
> +				target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> +		}
> 

Thanks,
Praan

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Will Deacon]

On Mon, May 11, 2026 at 01:22:23PM +0000, Pranjal Shrivastava wrote:
> On Sat, May 09, 2026 at 12:56:57AM -0700, Nicolin Chen wrote:
> > On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> > > On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > > > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > > > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > > > Since the fault handlers are already expecting HW-triggered updates?
> > > > 
> > > > Which means our check would be something like:
> > > > 
> > > >     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> > > >     	if (smmu->features & FEAT_HA)
> > > > 	 ...
> > > >     }
> > > > 
> > > > instead of cpu_has_hw_af()?
> > > 
> > > Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> > > mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> > > and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> > > CPU doesn't support HAFDBS, so perhaps you were right the first time :)
> > 
> > IIUIC, v2 should be:
> > 
> > +		/*
> > +		 * Enable Hardware Access and Dirty updates (DBM) if supported by
> > +		 * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU,
> > +		 * if the CPU does not support it as it bypasses mm page aging.
> > +		 */
> > +		if (cpu_has_hw_af()) {
> 
> Ack, yes. IMO, this is the correct system-wide gate.

Hmm, I'm not so sure :/

cpu_has_hw_af() doesn't take into account CPUs with broken DBM and, in
fact, ID_AA64MMFR1_EL1.HAFDBS allows support for AF to be advertised
without support for DBM.

Having said that, I don't understand why we need to care about the CPU
support. The comment above states:

  "It is unsafe to enable SMMU's HTTU, if the CPU does not support it as
   it bypasses mm page aging."

but I don't understand what that "bypassing" means. vmscan should still
pick up the correct state from the page-table, so what's the problem?

Will

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Wed, May 13, 2026 at 12:42:47PM +0100, Will Deacon wrote:
> On Mon, May 11, 2026 at 01:22:23PM +0000, Pranjal Shrivastava wrote:
> > On Sat, May 09, 2026 at 12:56:57AM -0700, Nicolin Chen wrote:
> > > On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> > > > On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > > > > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > > > > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > > > > Since the fault handlers are already expecting HW-triggered updates?
> > > > > 
> > > > > Which means our check would be something like:
> > > > > 
> > > > >     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> > > > >     	if (smmu->features & FEAT_HA)
> > > > > 	 ...
> > > > >     }
> > > > > 
> > > > > instead of cpu_has_hw_af()?
> > > > 
> > > > Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> > > > mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> > > > and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> > > > CPU doesn't support HAFDBS, so perhaps you were right the first time :)
> > > 
> > > IIUIC, v2 should be:
> > > 
> > > +		/*
> > > +		 * Enable Hardware Access and Dirty updates (DBM) if supported by
> > > +		 * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU,
> > > +		 * if the CPU does not support it as it bypasses mm page aging.
> > > +		 */
> > > +		if (cpu_has_hw_af()) {
> > 
> > Ack, yes. IMO, this is the correct system-wide gate.
> 
> Hmm, I'm not so sure :/
> 
> cpu_has_hw_af() doesn't take into account CPUs with broken DBM and, in
> fact, ID_AA64MMFR1_EL1.HAFDBS allows support for AF to be advertised
> without support for DBM.
> 
> Having said that, I don't understand why we need to care about the CPU
> support. The comment above states:
> 
>   "It is unsafe to enable SMMU's HTTU, if the CPU does not support it as
>    it bypasses mm page aging."
> 
> but I don't understand what that "bypassing" means. vmscan should still
> pick up the correct state from the page-table, so what's the problem?

I agree that for the Access Flag (AF), vmscan would eventually see the 
bit in the table. However, I’m concerned about Hardware Dirty (HD/DBM).
I know the vmscan might eventually get to it.. but here's my worry:

IIUC, in arm64 the dirty state of a page is tracked through a specific 
protocol using the PTE_RDONLY and PTE_WRITE (DBM) bits. A shared writable
page is initially mapped with both bits set (_PAGE_SHARED [1])

It also seems to be documented in arch/arm64/include/asm/pgtable.h [2]:

/*
 * PTE bits configuration in the presence of hardware Dirty Bit Management
 * (PTE_WRITE == PTE_DBM):
 *
 * Dirty  Writable | PTE_RDONLY  PTE_WRITE  PTE_DIRTY (sw)
 *   0      0      |   1           0          0
 *   0      1      |   1           1          0
 *   1      0      |   1           0          1
 *   1      1      |   0           1          x
 *
 * When hardware DBM is not present, the software PTE_DIRTY bit is updated via
 * the page fault mechanism. Checking the dirty status of a pte becomes:
 *
 *   PTE_DIRTY || (PTE_WRITE && !PTE_RDONLY)
 */

Thus, if the CPU does not support/enable Hardware Dirty management
(TCR_EL1.HD == 0), it is forced to trigger a Permission Fault on the 1st
write because PTE_RDONLY is 1. The fault allows the kernel to call 
folio_mark_dirty() [3]

If we enable SMMU HD independently in the Context Descriptor, the SMMU
will see a write and silently clear PTE_RDONLY in the hardware table.
When the CPU later accesses the page, it sees PTE_RDONLY == 0 and 
proceeds without ever faulting.

Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA
writes to the page and the process (CPU) calls fsync(). IIUC, it performs
a lookup in the Page Cache specifically for folios tagged as DIRTY.
Since, vmscan didn't run yet, this could potentally drop the writes..

Thanks,
Praan

[1] https://elixir.bootlin.com/linux/v7.1-rc3/source/arch/arm64/include/asm/pgtable-prot.h#L61
[2] https://elixir.bootlin.com/linux/v7.1-rc3/source/arch/arm64/include/asm/pgtable.h#L390
[3] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/memory.c#L3698

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Jason Gunthorpe]

On Wed, May 13, 2026 at 02:27:48PM +0000, Pranjal Shrivastava wrote:

> Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA
> writes to the page and the process (CPU) calls fsync(). IIUC, it performs
> a lookup in the Page Cache specifically for folios tagged as DIRTY.
> Since, vmscan didn't run yet, this could potentally drop the writes..

How does it work differently in the MM when the CPU has BBM support?

Jason

Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava]

On Wed, May 13, 2026 at 11:32:13AM -0300, Jason Gunthorpe wrote:
> On Wed, May 13, 2026 at 02:27:48PM +0000, Pranjal Shrivastava wrote:
> 
> > Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA
> > writes to the page and the process (CPU) calls fsync(). IIUC, it performs
> > a lookup in the Page Cache specifically for folios tagged as DIRTY.
> > Since, vmscan didn't run yet, this could potentally drop the writes..
> 
> How does it work differently in the MM when the CPU has BBM support?

Hmm... I looked at fsync and I see that it eventually calls 
folio_mkclean() (via writeback [1]), which performs an rmap_walk() [2]
to harvest dirty bits from PTEs into the respective struct folios.
Similarly, the vm_scan path does the same thing via try_to_unmap [3].

Since the MM subsystem actively scans the tables during writeback, it
doesn't matter if the dirty bits were flipped asynchronously by HW (w/o
kernel traps).

I guess that settles it, we don't need to gate this behind cpu_has_hw_af()
and we need not care about the CONFIG_ARM64_HW_AFDBM either.

Reviewed by: Pranjal Shrivastava <praan@google.com>

Thanks,
Praan

[1] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/page-writeback.c#L2905
[2] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/rmap.c#L1103
[3] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/rmap.c#L2164