Re: [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 cache coherency issue

[Peng Fan <peng.fan@oss.nxp.com>]

Hi Mark,

Thanks for your reviewing.

On Wed, Jul 29, 2026 at 10:50:56AM +0100, Mark Rutland wrote:
>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.

I think you are right, TLBF_NOBROADCAST should not be applied with the
workaround.

I will use below if this looks good to you.

 if (alternative_has_cap_unlikely(ARM64_WORKAROUND_NXP_ERR050104) &&
     !(flags & TLBF_NOBROADCAST)) {
         __tlbi(vmalle1is);
 } else {
 ...
 }

>
>[...]
>
>> @@ -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/

Sorry for missing this one.

>
>... 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.

It should be ok.  I will take your suggestion in next version.

Thanks,
Peng

>
>Mark.
>
>