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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.