Linux Documentation
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
	Fuad Tabba <fuad.tabba@linux.dev>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.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 v4] arm64: errata: Add NXP iMX8QM workaround for A53 cache coherency issue
Date: Thu, 8 Oct 2026 21:23:31 +0800	[thread overview]
Message-ID: <aseZUwi0CYTXuE/I@shlinux89> (raw)
In-Reply-To: <asTZEhzMDs869r_n@arm.com>

Hi Catalin,

On Tue, Oct 06, 2026 at 12:18:42PM +0100, Catalin Marinas wrote:
>Hi Peng,
>
>On Mon, Aug 24, 2026 at 12:02:04PM +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 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.
>
>Do you need virtualisation on such platform? An alternative would be for

We not have KVM support in our software release for i.MX8QM.

>the guests to be aware of the erratum as well and use the right TLBI/IC
>ops. But you'd also need to upgrade the VMID-aware ops in KVM (unless
>the hardware can't work around stage 2 TLBI at all).

We not have test cases for this since KVM is not in our release scope. 
Could we take this as a future enablement to avoid uneccessary churn

>
>>   - 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" or
>> "fsl,imx8qp" since the boot CPU MIDR_EL1 (0x410fd034) and AIDR_EL1 (0)
>> are not unique to this SoC.
>
>That's fine but I wonder whether your hardware implements the SoC ID
>SMCCC. That would come in handy if some future revision fixes the bug.
>The DT string doesn't tell you version/revision.

Sadly no, we not have ARM SMCCC to get SoC ID, we only have vendor SIP
for i.MX9 to get soc information.

>
>> @@ -580,23 +584,28 @@ static __always_inline void __do_flush_tlb_range(struct vm_area_struct *vma,
>>  
>>  	asid = ASID(mm);
>>  
>>  }
[...]
>>  
>> +#ifdef CONFIG_NXP_IMX8QM_ERRATUM_ERR050104
>> +static bool
>> +is_imx8qm_soc(const struct arm64_cpu_capabilities *entry, int scope)
>> +{
>> +	WARN_ON(preemptible());
>
>Not needed for a DT lookup.

Will fix in V5.

>
>> +
>> +	return of_machine_is_compatible("fsl,imx8qm") ||
>> +		of_machine_is_compatible("fsl,imx8qp");
>> +}
>> +
>> +static void
>> +cpu_enable_imx8qm_err050104(const struct arm64_cpu_capabilities *__unused)
>> +{
>> +	cpu_enable_cache_maint_trap(__unused);
>> +
>> +	/*
>> +	 * TLB maintenance cannot be guaranteed correct for guests, so
>> +	 * disable KVM as if kvm-arm.mode=none was passed on the command line.
>> +	 */
>> +	kvm_force_disabled();
>> +}
>> +#endif
>> +
>>  #define CAP_MIDR_RANGE(model, v_min, r_min, v_max, r_max)	\
>>  	.matches = is_affected_midr_range,			\
>>  	.midr_range = MIDR_RANGE(model, v_min, r_min, v_max, r_max)
>> @@ -1030,6 +1055,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>  		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>>  		.matches = has_broken_gic_v3_seis,
>>  	},
>> +#ifdef CONFIG_NXP_IMX8QM_ERRATUM_ERR050104
>> +	{
>> +		.desc = "NXP erratum ERR050104",
>> +		.capability = ARM64_WORKAROUND_NXP_ERR050104,
>> +		.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
>> +		.matches = is_imx8qm_soc,
>> +		.cpu_enable = cpu_enable_imx8qm_err050104,
>> +	},
>> +#endif
>
>There's a precedent with 4311569 to wire up a SoC erratum into the CPU
>errata framework. That one is a system wide feature, so only probed once
>for the CPUs coming up at boot (though still probed for each late CPUs).
>For iMX, you need this turned on early, hence the boot probing. But
>calling it a strict boot CPU feature is a bit of a stretch. It also gets
>probed on every CPU, unnecessarily.
>
>I think we could do with something like below (maybe as a preparatory
>patch). We could also add it to 4311569 even if it changes its scope
>from system to boot CPU (the early param is available).
>
>Only compile-tested and haven't tried wiring up your workaround:

With type set to ARM64_CPUCAP_SOC_ERRATUM for i.MX8QM and your patch
applied, I not see issues in my test.

Would you post it as a formal patch or need me to include your patch
with i.MX8QM errata patch in a patchset?

Thanks
Peng.

>
>-------------------8<-----------------------
>diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>index 4f04ad82ea34..669f808e379e 100644
>--- a/arch/arm64/include/asm/cpufeature.h
>+++ b/arch/arm64/include/asm/cpufeature.h
>@@ -266,6 +266,13 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
> #define SCOPE_BOOT_CPU				ARM64_CPUCAP_SCOPE_BOOT_CPU
> #define SCOPE_ALL				ARM64_CPUCAP_SCOPE_MASK
> 
>+/*
>+ * matches() is called only once, when the capability is detected, and the
>+ * result applies to all CPUs. Secondary and late CPUs are not checked for
>+ * conflicts but cpu_enable() is still called on each of them. It has no
>+ * effect on SCOPE_LOCAL_CPU capabilities.
>+ */
>+#define ARM64_CPUCAP_PROBE_ONCE			((u16)BIT(3))
> /*
>  * Is it permitted for a late CPU to have this capability when system
>  * hasn't already enabled it ?
>@@ -293,6 +300,13 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
>  */
> #define ARM64_CPUCAP_LOCAL_CPU_ERRATUM		\
> 	(ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU)
>+/*
>+ * SoC (not CPU) errata workarounds. The erratum is probed once on the boot
>+ * CPU, before the secondary CPUs are brought up, and no secondary or late CPU
>+ * can conflict with it.
>+ */
>+#define ARM64_CPUCAP_SOC_ERRATUM			\
>+	(ARM64_CPUCAP_SCOPE_BOOT_CPU | ARM64_CPUCAP_PROBE_ONCE)
> /*
>  * CPU feature detected at boot time based on system-wide value of a
>  * feature. It is safe for a late CPU to have this feature even though
>@@ -414,6 +428,12 @@ static inline bool cpucap_match_all_early_cpus(const struct arm64_cpu_capabiliti
> 	return cap->type & ARM64_CPUCAP_MATCH_ALL_EARLY_CPUS;
> }
> 
>+static inline bool cpucap_probe_once(const struct arm64_cpu_capabilities *cap)
>+{
>+	return (cap->type & ARM64_CPUCAP_PROBE_ONCE) &&
>+	       !(cap->type & ARM64_CPUCAP_SCOPE_LOCAL_CPU);
>+}
>+
> /*
>  * Generic helper for handling capabilities with multiple (match,enable) pairs
>  * of call backs, sharing the same capability bit.
>diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>index e0c09402540c..a418e240ccce 100644
>--- a/arch/arm64/kernel/cpu_errata.c
>+++ b/arch/arm64/kernel/cpu_errata.c
>@@ -986,7 +986,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> #ifdef CONFIG_ARM64_ERRATUM_4311569
> 	{
> 		.capability = ARM64_WORKAROUND_4311569,
>-		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
>+		.type = ARM64_CPUCAP_SOC_ERRATUM,
> 		.matches = need_arm_si_l1_workaround_4311569,
> 	},
> #endif
>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>index 84053f0a8e01..0e4c3de78c1d 100644
>--- a/arch/arm64/kernel/cpufeature.c
>+++ b/arch/arm64/kernel/cpufeature.c
>@@ -3695,8 +3695,11 @@ static void verify_local_cpu_caps(u16 scope_mask)
> 		if (!caps || !(caps->type & scope_mask))
> 			continue;
> 
>-		cpu_has_cap = caps->matches(caps, SCOPE_LOCAL_CPU);
> 		system_has_cap = cpus_have_cap(caps->capability);
>+		if (cpucap_probe_once(caps))
>+			cpu_has_cap = system_has_cap;
>+		else
>+			cpu_has_cap = caps->matches(caps, SCOPE_LOCAL_CPU);
> 
> 		if (system_has_cap) {
> 			/*
>
>

      reply	other threads:[~2026-10-08 13:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24  4:02 [PATCH v4] arm64: errata: Add NXP iMX8QM workaround for A53 cache coherency issue Peng Fan (OSS)
2026-08-25  7:06 ` Franz Schnyder
2026-09-15 15:04   ` Peng Fan
2026-09-15 15:02 ` Peng Fan
2026-10-05  8:08   ` Francesco Dolcini
2026-10-06 11:18 ` Catalin Marinas
2026-10-08 13:23   ` Peng Fan [this message]

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=aseZUwi0CYTXuE/I@shlinux89 \
    --to=peng.fan@oss.nxp.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=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=rdunlap@infradead.org \
    --cc=seiden@linux.ibm.com \
    --cc=skhan@linuxfoundation.org \
    --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