When a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor. Therefore, if a program executes a LDREX/STREX loop, with the DSB instruction within, and it keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds.
The issue happens in systems that might generate external aborts in answer to cacheable memory requests. There are two work-arounds: turn on the branch prediction or remove the DSB in the middle of the LDREX/STREX sequence.
Impact: | Minor |
Work-around: | Turn on the branch prediction or remove the DSB in the middle of the LDREX/STREX sequence. |
Configurations Affected: | Systems that use one or both processors. |
Device Revision(s) Affected: | All, no plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 SoC Silicon Revision Differences |
On Cortex-A9, when a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor. Therefore, if a program executes a LDREX/STREX loop which keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds, leading to a possible processor livelock.
As an example, the following code sequence may exhibit the issue:
loop LDREX ... DSB STREX CMP BNE loop ...LDR (into aborting region)
The LDREX/STREX does not succeed on the first pass of the loop, and the BNE is predicted, so the LDR afterwards is speculatively executed and the processor keeps on executing:
LDR to aborting region (this speculative LDR now appears "before" the LDREX & DSB) LDREX DSB STREX
The LDR misses in the L1 cache, and never gets allocated as valid because it is aborting.
The LDREX is executed, and sets the exclusive monitor.
The DSB is executed. It waits for the LDR to complete, which aborts, causing an allocation (as invalid) in the Data Cache, which clears the exclusive monitor The STREX is executed, but the exclusive monitor is now cleared, so the STREX fails.
The BNE may be predicted again, so the LDR is speculatively executed again, and the code loops back on the same failing LDREX/STREX sequence.
Impact Details
The issue happens in systems which may generate external aborts in answer to cacheable memory requests. If the program reaches a stable state where the internal exclusive monitor keeps on being cleared in the middle of the LDREX/STREX sequence, then the processor may encounter livelock.
In practice, this scenario seems very unlikely to happen because several conditions may prevent the erratum to happen:
Work-around Details
There are two work-arounds for this issue:
Answer Number | Answer Title | Version Found | Version Resolved |
---|---|---|---|
47916 | Zynq-7000 AP SoC Devices - Silicon Revision Differences | N/A | N/A |
AR# 47586 | |
---|---|
Date | 05/25/2018 |
Status | Active |
Type | Design Advisory |
Devices |