[PATCH v2 2/2] iommu/arm-smmu-v3: Add HAFT support for SVA

[Will Deacon]

On Sat, Jul 25, 2026 at 11:27:59AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 23, 2026 at 03:19:44PM +0100, Robin Murphy wrote:
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -102,6 +102,8 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
> >  			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);
> > +		if (master->smmu->features & ARM_SMMU_FEAT_HAFT && system_supports_haft())
> > +			target->data[1] |= cpu_to_le64(CTXDESC_CD_1_HAFT);
> >  	} else {
> >  		target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_EPD0);
> 
> Based on the Sashiko remark and your note you should lift all the
> HA/HD/HAFT bits outside this if (mm) block.
> 
> AFAICT it is fine for HA/HD/HAFT to be set with EPD0, the HW won't
> process any PTEs so they won't have any effect.

I'm not sure about that. The spec says this about CD.HAFT:

| If CD.HA is 0 and not IGNORED, it is ILLEGAL to set this field to 1
| and this results in C_BAD_CD.

so the question is whether or not CD.HA is IGNORED when EPD0 is set, and
I couldn't find anything to suggest that is the case (which kinda makes
sense, given that there are two TTBs).

As a last resort, I tried to parse the pseudocode for C_BAD_CD (based on
CdIllegal() in "5.4.2 Validity of CD")...

It looks like EPD0 gets wrapped up in 'n_transl_cfg0', but that's not
used at all in the relevant check (you need to skip past the first few
bits, but I've included them for completeness):


// Check CD.HA, CD.HD, CD.HAFT
if !using_vmsa32 &&
    // The following conditions are ILLEGAL when VMSAv8-64 or
    // when VMSAv9-128 are used.
    // No flag updates supported, but CD wants to update flag
    (((CD.HA == '1' || CD.HD == '1') && (SMMU_IDR0.HTTU == '00')) ||

    // Only access flag update suppported, but CD updates dirty flag
    (CD.HD == '1' && SMMU_IDR0.HTTU == '01') ||

    ** LOOK HERE! This is the relevant part: **

    // Hardware update of AF in Table descriptors is supported and enabled,
    // but update of AF in leaf descriptors is not enabled
    (SMMU_IDR0.HTTU == '11' && CD.HAFT == '1' && CD.HA == '0')) then

  return TRUE; // Invalid


so I think your options are either:

1. Use the cmdline option that Robin is adding so that you can disable
   HAFT altogether.

- or -

2. We could disable HAFT first, and then do the hitless transition.

(2) means we can miss table AF updates during that window, but I think
that should be fine?

Will