From: Will Deacon <will@kernel•org>
To: Ashish Mhetre <amhetre@nvidia•com>
Cc: robin.murphy@arm•com, joro@8bytes•org, jgg@ziepe•ca,
nicolinc@nvidia•com, linux-arm-kernel@lists•infradead.org,
iommu@lists•linux.dev, linux-kernel@vger•kernel.org,
linux-tegra@vger•kernel.org
Subject: Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum
Date: Tue, 2 Jun 2026 21:13:39 +0100 [thread overview]
Message-ID: <ah85c4u011WNJQgE@willie-the-truck> (raw)
In-Reply-To: <20260601104845.995005-3-amhetre@nvidia.com>
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@nvidia•com>
> Reviewed-by: Nicolin Chen <nicolinc@nvidia•com>
> ---
> 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.
> +/*
> + * 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)
> +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()?
> +{
> + if (!(smmu->options & ARM_SMMU_OPT_TLBI_TWICE))
> + return false;
Maybe we should make this a static key?
> + 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.
Will
next prev parent reply other threads:[~2026-06-02 20:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 10:48 [PATCH v3 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround Ashish Mhetre
2026-06-01 10:48 ` [PATCH v3 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions Ashish Mhetre
2026-06-02 19:55 ` Will Deacon
2026-06-02 20:08 ` Nicolin Chen
2026-06-02 20:23 ` Will Deacon
2026-06-01 10:48 ` [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum Ashish Mhetre
2026-06-02 20:13 ` Will Deacon [this message]
2026-06-02 20:31 ` Nicolin Chen
2026-06-02 20:59 ` Will Deacon
2026-06-02 21:06 ` Nicolin Chen
2026-06-01 10:48 ` [PATCH v3 3/3] iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264 Ashish Mhetre
2026-06-01 18:37 ` Nicolin Chen
2026-06-02 20:22 ` Will Deacon
2026-06-02 20:35 ` Nicolin Chen
2026-06-03 0:59 ` Jason Gunthorpe
2026-06-03 1:01 ` Jason Gunthorpe
2026-06-03 11:33 ` Will Deacon
2026-06-02 16:31 ` [PATCH v3 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround Mostafa Saleh
2026-06-02 18:23 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ah85c4u011WNJQgE@willie-the-truck \
--to=will@kernel$(echo .)org \
--cc=amhetre@nvidia$(echo .)com \
--cc=iommu@lists$(echo .)linux.dev \
--cc=jgg@ziepe$(echo .)ca \
--cc=joro@8bytes$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-tegra@vger$(echo .)kernel.org \
--cc=nicolinc@nvidia$(echo .)com \
--cc=robin.murphy@arm$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox