[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