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

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

[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