Under certain conditions specific to the Cortex-A9 microarchitecture, a write operation that updates a cacheable translation table entry might cause both the old and the new translation entries to be temporarily invisible to translation table walks, thus erroneously causing a translation fault.
Here are the requirements for this problem to occur:
In practice, the problem can occur when an OS is changing the mapping of a physical page. The OS might have an existing mapping to a physical page (the old mapping), but wants to move the mapping to a new page (the new mapping). To do this, the OS might:
However, because of this issue, neither of the new or old mappings may be visible after the new entry is written, causing a Translation fault.
Minor. This issue causes a translation fault. There is a work-around for the issue.
Perform a clean and invalidate operation, refer to Workaround Details.
Systems that use the CPUs.
|Device Revision(s) Affected:||All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 SoC Silicon Revision Differences Answer Record.|
The recommended workaround is to perform a clean and invalidate operation on the cache line that contains the translation entry before updating the entry, to ensure that the write operation misses in the Data Cache.
This workaround prevents the micro-architectural conditions required for the issue from happening. Interrupts must be temporarily disabled so that no interrupt can be taken between the maintenance operation and the translation entry update.
This avoids the possibility of the interrupt service routine bringing the cache line back in the cache.
Another possible workaround is to place the translation table entries in Non-Cacheable memory areas, but this workaround is likely to have a noticeable performance penalty.
Note that inserting a DSB instruction immediately after writing the new translation table entry significantly reduces the probability of hitting the erratum, but is not a complete workaround.
March 2013 new.