From: Ashish Mhetre <amhetre@nvidia.com>
Cc: <linux-tegra@vger.kernel.org>, Ashish Mhetre <amhetre@nvidia.com>
Subject: [PATCH v5 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround
Date: Thu, 9 Jul 2026 09:56:10 +0000 [thread overview]
Message-ID: <20260709095613.831769-4-amhetre@nvidia.com> (raw)
In-Reply-To: <20260709095613.831769-1-amhetre@nvidia.com>
Nvidia Tegra264 SMMUs are affected by an 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 must execute only after the first issue's CMD_SYNC
has completed, giving the sequence:
TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
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 is device-tree-only
(no ACPI/IORT support), so detection is purely by compatible string.
This series is structured as a small refactor + infrastructure + enable
sequence so that each step is reviewable in isolation:
1/3 Pure refactor (no functional change): lift the existing
force-sync conditions out of arm_smmu_cmdq_batch_add_cmd_p()
into a new arm_smmu_cmdq_batch_force_sync() helper, so that
adding another condition (in patch 2) is a one-line addition.
Authored by Nicolin Chen.
2/3 Add the workaround infrastructure without enabling it. Defines
the arm_smmu_erratum_repeat_tlbi_cfgi_key static key, the shared
arm_smmu_erratum_cmd_needs_repeating() predicate, the
arm_smmu_cmdq_issue_cmdlist() wrapper that can re-issue matching
cmdlists, the batch-helper force-sync condition, and the iommufd
batching split for mixed command classes.
3/3 Enable the workaround for the existing "nvidia,tegra264-smmu"
compatible and document the erratum in silicon-errata.rst.
The series applies cleanly on linux-next/master (base-commit below).
Changes since v4:
- Drop ARM_SMMU_OPT_REPEAT_TLBI_CFGI entirely: the option bit was
set and read on the exact same "nvidia,tegra264-smmu" compatible
as the static key, so it added no per-instance signal that the
static key did not already carry. The predicate now gates purely
on arm_smmu_erratum_repeat_tlbi_cfgi_key. (Nicolin: "Are they
redundant? / Drop the deadcode then.")
- Reorder the series so the compatible-string detection lands
last, once all the infrastructure exists (Nicolin):
1/3 factor out force_sync helper (unchanged)
2/3 add static key + WAR functions (no functional change)
3/3 enable the key on nvidia,tegra264-smmu + silicon-errata
Split the old v4 "Detect" and "Issue twice" patches accordingly.
- Update the /* See ARM_SMMU_OPT_REPEAT_TLBI_CFGI */ comment inside
arm_smmu_cmdq_batch_force_sync() to reference
arm_smmu_erratum_cmd_needs_repeating() instead.
Changes since v3:
- Drop the cmds->num == 0 early-return so the refactor is
truly "no functional change".
- Rename ARM_SMMU_OPT_TLBI_TWICE -> ARM_SMMU_OPT_REPEAT_TLBI_CFGI
and rephrase its kdoc to be hardware-agnostic.
- Rename arm_smmu_cmd_needs_tlbi_twice() ->
arm_smmu_erratum_cmd_needs_repeating() and drop the kdoc
above it.
- Replace the explicit opcode switch with a single range check
opcode >= CMDQ_OP_CFGI_STE && opcode < CMDQ_OP_ATC_INV.
- Introduce arm_smmu_erratum_repeat_tlbi_cfgi_key static key:
the predicate gates on it first so unaffected kernels pay
only a single static_branch_unlikely() check.
- Drop the verbose Tegra264-specific comments above
arm_vsmmu_can_batch_cmd() and inside the batch helper.
- Document the erratum in
Documentation/arch/arm64/silicon-errata.rst.
- Guard the repeat path in arm_smmu_cmdq_issue_cmdlist() with
an n > 0 check so we never inspect cmds[0] on the bare-SYNC
flush emitted by arm_smmu_cmdq_batch_add_cmd_p() when the
next command is unsupported by the batch's pre-selected
cmdq.
- Drop the carried Reviewed-by tags now that the patch
shape has changed; re-review appreciated.
Changes since v2:
- Split into a 3-patch series (refactor / detect / apply) to keep
each step small and bisectable.
- Move the classifier to arm-smmu-v3.h as static inline so the
iommufd file can share it.
- Add arm_vsmmu_can_batch_cmd() to split iommufd batches at
"needs repeating" transitions so the per-batch decision based
on the first command stays correct under mixed user input.
- Spell out in the commit message why detection is via DT and
not via IIDR/ACPI.
Changes since v1:
- Detect the erratum from the existing "nvidia,tegra264-smmu"
compatible instead of adding a new property.
- Centralise the doubling at the CMDQ submission layer and only
apply it to CFGI/TLBI (not ATC_INV).
- Drop the binding/dtsi patches accordingly.
Ashish Mhetre (2):
iommu/arm-smmu-v3: Introduce CFGI/TLBI-repeat workaround
infrastructure
iommu/arm-smmu-v3: Enable CFGI/TLBI-repeat workaround on Tegra264
Nicolin Chen (1):
iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
Documentation/arch/arm64/silicon-errata.rst | 2 +
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 15 ++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 63 +++++++++++++++----
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 15 +++++
4 files changed, 83 insertions(+), 12 deletions(-)
base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474
--
2.50.1
next prev parent reply other threads:[~2026-07-09 9:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 9:56 [PATCH v5 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions Ashish Mhetre
2026-07-09 9:56 ` [PATCH v5 2/3] iommu/arm-smmu-v3: Introduce CFGI/TLBI-repeat workaround infrastructure Ashish Mhetre
2026-07-10 4:20 ` Nicolin Chen
2026-07-10 6:35 ` Ashish Mhetre
2026-07-09 9:56 ` [PATCH v5 3/3] iommu/arm-smmu-v3: Enable CFGI/TLBI-repeat workaround on Tegra264 Ashish Mhetre
2026-07-10 4:25 ` Nicolin Chen
2026-07-10 6:36 ` Ashish Mhetre
2026-07-09 9:56 ` Ashish Mhetre [this message]
2026-07-10 4:28 ` [PATCH v5 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions Nicolin Chen
2026-07-10 6:39 ` Ashish Mhetre
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=20260709095613.831769-4-amhetre@nvidia.com \
--to=amhetre@nvidia.com \
--cc=linux-tegra@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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