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

[Robin Murphy]

On 18/04/2023 5:54 pm, Ivan T. Ivanov wrote:
> On 04-17 16:35, Mark Rutland wrote:
> 
>>>>> @@ -835,7 +835,8 @@ static inline bool system_supports_bti(void)
>>>>>    static inline bool system_supports_tlb_range(void)
>>>>>    {
>>>>>    	return IS_ENABLED(CONFIG_ARM64_TLB_RANGE) &&
>>>>> -		cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
>>>>> +		cpus_have_const_cap(ARM64_HAS_TLB_RANGE) &&
>>>>> +		!cpus_have_const_cap(ARM64_WORKAROUND_NXP_ERR050104);
>>>>>    }
>>>>
>>>> It'd be better to handle this in the detection of ARM64_HAS_TLB_RANGE, as we
>>>> have for CNP where has_useable_cnp() checks for ARM64_WORKAROUND_NVIDIA_CARMEL_CNP.
>>>
>>> It's not needed in either place, since neither Cortex-A53 or Cortex-A72
>>> support FEAT_TLBIRANGE, so this could never be true on affected platforms
>>> anyway.
>>
>> Ah, even better -- we can just drop it.
> 
> Ok.
> 
>>
>>> Tangentially, I understand this platform has an SMMU[1], so I'd say it would
>>> also be worth checking what SMMU_IDR0.BTM reports. With any luck it might be
>>> 0, but if it's 1 then strictly it would want to be overridden as part of a
>>> complete workaround as well. That wouldn't be a practical issue right now,
>>> not least since the current Linux driver doesn't even use BTM, but it's
>>> something which could need to be borne in mind in future.
>>
>> Absolutely.
> 
> I don't completely understand implication of this, but for SMMU inside
> iMX8QM report that "Broadcast TLB maintenance is supported"

Aha, in fact it seems we might be OK. I double-checked and it turns out 
that thanks to an MMU-500 erratum, we can't necessarily believe IDR0.BTM 
anyway. Thus anyone who adds DVM support to an SMMUv2 driver is going to 
need to implement some new firmware property or platform detection, at 
which point the chances of it getting silently enabled for i.MX8 (if 
indeed BTM isn't already a lie there) seem sufficiently remote that I'd 
feel fairly comfortable not doing anything explicit for now.

(The case of concern wouldn't be so much the expected use of DVM to 
share CPU pagetables with the SMMU, which in principle the regular CPU 
workaround should already cover, but more anyone trying to play clever 
tricks using DVM and CPU instructions to maintain private SMMU contexts 
rather than register-based commands.)

Thanks,
Robin.