Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum

[Ashish Mhetre]

On 6/3/2026 1:43 AM, Will Deacon wrote:
> External email: Use caution opening links or attachments
>
>
> On Mon, Jun 01, 2026 at 10:48:44AM +0000, Ashish Mhetre wrote:
> > Tegra264 SMMU is affected by erratum where a TLB entry can survive an
> > invalidation that races with concurrent traffic targeting the same
> > entry. The hardware-recommended software workaround is to issue every
> > CFGI/TLBI command (each followed by CMD_SYNC) twice. The second issue
> > is guaranteed to evict the entry. ATC_INV is not affected and must not
> > be doubled.
> >
> > The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
> > cannot be detected from hardware ID. Tegra264 boots from device tree
> > only and has no ACPI/IORT support, so detection is through device
> > tree only.
> That seems odd to me -- whether the hardware has the erratum is
> completely unrelated to whether it probes using DT or ACPI, so I find it
> really weird to have the workaround enabled when booting with DT and not
> when booting with ACPI. We should have consistent behaviour between the
> two.
>
> > Add the ARM_SMMU_OPT_TLBI_TWICE option and set it on instances matching
> > the existing "nvidia,tegra264-smmu" compatible. Also add a
> > static-inline arm_smmu_cmd_needs_tlbi_twice() classifier in
> > arm-smmu-v3.h so that subsequent changes wiring the workaround into the
> > CMDQ submission and iommufd batching paths can share a single
> > predicate.
> >
> > No callers consume the option yet; a subsequent change will wire the
> > workaround into the CMDQ issue paths.
> >
> > Signed-off-by: Ashish Mhetre <amhetre@xxxxxxxxxx>
> > Reviewed-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> > ---
> >   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  4 ++-
> >   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 40 +++++++++++++++++++++
> >   2 files changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index 4d29bd343460..08684bd40a6d 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -5243,8 +5243,10 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
> >        if (of_dma_is_coherent(dev->of_node))
> >                smmu->features |= ARM_SMMU_FEAT_COHERENCY;
> >
> > -     if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
> > +     if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu")) {
> >                tegra_cmdqv_dt_probe(dev->of_node, smmu);
> > +             smmu->options |= ARM_SMMU_OPT_TLBI_TWICE;
> > +     }
> >
> >        return ret;
> >   }
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> > index 16353596e08a..106034c348a1 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> > @@ -928,6 +928,14 @@ struct arm_smmu_device {
> >   #define ARM_SMMU_OPT_MSIPOLL         (1 << 2)
> >   #define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
> >   #define ARM_SMMU_OPT_TEGRA241_CMDQV  (1 << 4)
> > +/*
> > + * Tegra264 erratum: a TLB entry can survive an invalidation that races
> > + * with concurrent traffic targeting the same entry. The software
> > + * workaround is to issue every CFGI/TLBI command twice, each followed
> > + * by CMD_SYNC. The second issue is guaranteed to evict the entry.
> > + * ATC_INV commands are not affected and must not be doubled.
> > + */
> > +#define ARM_SMMU_OPT_TLBI_TWICE              (1 << 5)
> nit: I think this should be named slightly differently as it covers CFGI
> as well. Maybe ARM_SMMU_OPT_REPEAT_TLBI_CFGI ?
>
> The comment can be simpler too and avoid being specific to Tegra264. The
> main things to say are that it repeats {CFGI,TLBI}; SYNC sequences and
> does not apply to ATC_INV.

Ack, I will fix this in V4.

> > +/*
> > + * Returns true if @cmd is one of the CFGI_* or TLBI_* commands covered
> > + * by the Tegra264 erratum (see ARM_SMMU_OPT_TLBI_TWICE) on an affected
> > + * SMMU instance.
> > + */
> (remove the comment)

Ack.

> > +static inline bool arm_smmu_cmd_needs_tlbi_twice(struct arm_smmu_device *smmu,
> > +                                              struct arm_smmu_cmd *cmd)
> Rename the function to something like arm_smmu_erratum_cmd_needs_repeating()?

Ack.

> > +{
> > +     if (!(smmu->options & ARM_SMMU_OPT_TLBI_TWICE))
> > +             return false;
> Maybe we should make this a static key?

Okay. Shall I add just static key and remove option bit, or
have static key alongside existing option bit such that
static_branch_unlikely will precede the option bit check?

> > +     switch (FIELD_GET(CMDQ_0_OP, cmd->data[0])) {
> > +     case CMDQ_OP_CFGI_STE:
> > +     case CMDQ_OP_CFGI_ALL:
> > +     case CMDQ_OP_CFGI_CD:
> > +     case CMDQ_OP_CFGI_CD_ALL:
> > +     case CMDQ_OP_TLBI_NH_ALL:
> > +     case CMDQ_OP_TLBI_NH_ASID:
> > +     case CMDQ_OP_TLBI_NH_VA:
> > +     case CMDQ_OP_TLBI_NH_VAA:
> > +     case CMDQ_OP_TLBI_EL2_ALL:
> > +     case CMDQ_OP_TLBI_EL2_ASID:
> > +     case CMDQ_OP_TLBI_EL2_VA:
> > +     case CMDQ_OP_TLBI_S12_VMALL:
> > +     case CMDQ_OP_TLBI_S2_IPA:
> > +     case CMDQ_OP_TLBI_NSNH_ALL:
> > +             return true;
> Isn't this just everything < ATC_INV || >= CFGI_STE? Seems better than
> enumerating everything.

Ack.

> Will

Thanks,
Ashish Mhetre