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

[Robin Murphy <robin.murphy@arm.com>]

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.