Hi Manish,
Before I agree or disagree with the suggested fix, the following would be interesting to know/discuss. Please feel free to correct me if i've misunderstood something.
1) Are "speculative" AT instructions subject to TCR_ELx control bits for all the listed CPU's? I imagine the answer is yes but would be good to get confirmation. I could not find any evidence in the instruction description or psuedocode in the ARMv8 ARM. It is possible to play many tricks on speculative execution of instructions such as skipping checks and doing them only when the CPU knows the instruction will be committed. If this is the case, changing TCR_ELx bits may not work. The errata document is vague about how to fix it.
2) Assuming the answer to question 1 is yes, your proposal may not work as is. In the worst case, as soon as you enter EL3, the very first thing that may happen, before you ever operate/write to TCR_ELx, is a speculative AT instruction that caches a bad translation in the TLB's. The same thing can happen on the exit path. As soon as you restore the TCR_ELx register, the first thing that can happen is a speculative AT that caches a bad translation. However, the el3_exit path does have DSB before ERET, so we will not speculate to an AT instruction if there are no branches between the instruction that sets TCR_ELx and the ERET. Somewhere in between, it looks like we will need a TLBI NSH to be certain there are no bad translation cached. This obviously has a potential performance cost on the lower EL's. Every entry into EL3 flushes the TLB for lower EL's.
Thanks
Raghu
On 4/24/20 2:56 AM, Manish Badarkhe via TF-A wrote:
Hi All
We are trying to implement errata which is applicable for below CPUs:
<CPUs> : <Errata No.>
Cortex-A53: 1530924
Cortex-A76: 1165522 Cortex-A72: 1319367 Cortex-A57: 1319537 Cortex-A55: 1530923
*Errata Description:*
A speculative Address Translation (AT) instruction translates using registers that are associated with an out-of-context translation regime and caches the resulting translation in the TLB. A subsequent translation request that is generated when the out-of-context translation regime is current uses the previous cached TLB entry producing an incorrect virtual to physical mapping.
*Probable solution is to implement below fix in context.S file:*
*During ELx (1 or 2) context save:*
·Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits
oThis will avoid any page table walk for S-EL1 or S-EL2. This will help in avoiding caching of translations in TLB
for S-EL1/S-EL2 in EL3.
·Save all system registers (which is already available) except TCR
·Clear EPD bits of TCR and then save. (Just to enable PTW during restore context).
*During ELx (1 or 2) context restore:*
- Operate TCR_ELx(1/2) to disable page table walk by operating EPD bits
- Restore all system registers (which are saved during context save) except TCR register.
- Restore TCR_ELx(1/2) register (which enable back PTW).
With above we ensured that there will be no page table walk for S-EL1 and S-EL2 in EL3.
is this proper other way to fix this problem? Need some suggestion/use cases where and all we need this workaround in TF-A code.
Thanks
Manish Badarkhe
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.