From: Mark Rutland <mark.rutland@arm.com>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Fuad Tabba <fuad.tabba@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
"Ivan T. Ivanov" <iivanov@suse.de>,
Francesco Dolcini <francesco@dolcini.it>,
Frank Li <frank.li@nxp.com>,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
imx@lists.linux.dev, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 cache coherency issue
Date: Wed, 29 Jul 2026 10:50:56 +0100 [thread overview]
Message-ID: <amnNAJC4yHVsZaN8@J2N7QTR9R3.cambridge.arm.com> (raw)
In-Reply-To: <20260729-imx8qm-cache-coherency-v1-1-c9864e280437@nxp.com>
On Wed, Jul 29, 2026 at 11:28:52AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> According to NXP errata document IMX8_1N94W[1], the i.MX8QuadMax SoC
> suffers from a serious cache coherency issue (ERR050104). The upper
> bits, above bit 35, of the ARADDR and ACADDR buses within the Arm A53
> subsystem have been incorrectly connected. This causes some TLBI and IC
> maintenance operations exchanged between the A53 and A72 core clusters
> to be corrupted.
>
> The workaround requires:
>
> - Downgrading targeted TLBI operations to broadcast-all variants.
> Instead of patching the low-level __TLBI_1 macro (which interferes
> with the REPEAT_TLBI workaround and causes excessive over-
> invalidation), redirect high-level TLB flush functions
> (flush_tlb_mm, __do_flush_tlb_range, flush_tlb_kernel_range,
> __flush_tlb_kernel_pgtable) to use VMALLE1IS via static key checks.
>
> - Upgrading IC IVAU to IC IALLUIS for both kernel (via ALTERNATIVE in
> invalidate_icache_by_line) and EL0 userspace (via trap-and-upgrade
> in user_cache_maint_handler with SCTLR_EL1.UCI=0).
>
> - Disabling KVM since correct TLB maintenance cannot be guaranteed
> for guests without the proper devicetree.
>
> - No need to touch SMMU Broadcast TLB Maintenance (BTM) since i.MX8QM
> does not support broadcast TLB.
>
> SoC detection uses devicetree compatible string "fsl,imx8qm" since the
> boot CPU MIDR_EL1 (0x410fd034) and AIDR_EL1 (0) are not unique to this
> SoC.
>
> [1] https://www.nxp.com/docs/en/errata/IMX8_1N94W.pdf
[...]
> + if (alternative_has_cap_unlikely(ARM64_WORKAROUND_NXP_ERR050104)) {
> + __tlbi(vmalle1is);
> + } else {
> + switch (flags & (TLBF_NOWALKCACHE | TLBF_NOBROADCAST)) {
> + case TLBF_NONE:
> + __flush_s1_tlb_range_op(vae1is, start, pages, stride,
> + asid, tlb_level);
> + break;
> + case TLBF_NOWALKCACHE:
> + __flush_s1_tlb_range_op(vale1is, start, pages, stride,
> + asid, tlb_level);
> + break;
> + case TLBF_NOBROADCAST:
> + /* Combination unused */
> + BUG();
> + break;
> + case TLBF_NOWALKCACHE | TLBF_NOBROADCAST:
> + __flush_s1_tlb_range_op(vale1, start, pages, stride,
> + asid, tlb_level);
> + break;
> + }
> }
Are you sure the workaround needs to be applied for the TLBF_NOBROADCAST
cases? The NXP document lists non-broadcast TLBI instructions, but I
strongly suspect that's in error, as those shouldn't result in
transactions over the core's external interfaces.
[...]
> @@ -585,6 +585,12 @@ static void user_cache_maint_handler(unsigned long esr, struct pt_regs *regs)
> __user_cache_maint("dc civac", address, ret);
> break;
> case ESR_ELx_SYS64_ISS_CRM_IC_IVAU: /* IC IVAU */
> + if (cpus_have_final_cap(ARM64_WORKAROUND_NXP_ERR050104)) {
> + /* ERR050104: upgrade IC IVAU to IC IALLUIS */
> + asm volatile("ic ialluis");
> + ret = 0;
> + break;
> + }
> __user_cache_maint("ic ivau", address, ret);
> break;
This doesn't address my feedback on v1:
https://lore.kernel.org/all/ZIHisLL9FXlbuMLJ@FVFF77S0Q05N/
... which I see Sashiko has also spotted.
Please make this:
case ESR_ELx_SYS64_ISS_CRM_IC_IVAU: /* IC IVAU */
__user_cache_maint("ic ivau", address, ret)
if (cpus_have_final_cap(ARM64_WORKAROUND_NXP_ERR050104) && !ret)
asm volatile("ic ialluis");
break;
If there's a reason that doesn't work, please explain that reason.
Mark.
next prev parent reply other threads:[~2026-07-29 9:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 3:28 [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 cache coherency issue Peng Fan (OSS)
2026-07-29 9:50 ` Mark Rutland [this message]
2026-07-29 12:52 ` Peng Fan
-- strict thread matches above, loose matches on Subject: below --
2023-04-12 12:55 [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 Cache " Ivan T. Ivanov
2023-04-13 11:19 ` Mark Rutland
2023-04-14 11:36 ` Robin Murphy
2023-04-17 15:35 ` Mark Rutland
2023-04-18 16:54 ` Ivan T. Ivanov
2023-04-20 17:02 ` Robin Murphy
2023-04-18 13:25 ` Ivan T. Ivanov
2023-04-17 3:07 ` Peng Fan
2023-04-17 14:48 ` Frank Li
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=amnNAJC4yHVsZaN8@J2N7QTR9R3.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=francesco@dolcini.it \
--cc=frank.li@nxp.com \
--cc=fuad.tabba@linux.dev \
--cc=iivanov@suse.de \
--cc=imx@lists.linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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