Visible to Intel only — GUID: uog1487886246547
Ixiasoft
3.1. 843819: Memory Locations May be Accessed Speculatively Due to Instruction Fetches When HCR.VM is Set
3.2. 845719: A Load May Read Incorrect Data
3.3. 855871: ETM Does Not Report IDLE State When Disabled Using OSLOCK
3.4. 855872: A Store-Exclusive Instruction May Pass When it Should Fail
3.5. 711668: Configuration Extension Register Has Wrong Value Status
3.6. 720107: Periodic Synchronization Can Be Delayed and Cause Overflow
3.7. 855873: An Eviction Might Overtake a Cache Clean Operation
3.8. 853172: ETM May Assert AFREADY Before All Data Has Been Output
3.9. 836870: Non-Allocating Reads May Prevent a Store Exclusive From Passing
3.10. 836919: Write of the JMCR in EL0 Does Not Generate an UNDEFINED Exception
3.11. 845819: Instruction Sequences Containing AES Instructions May Produce Incorrect Results
3.12. 851672: ETM May Trace an Incorrect Exception Address
3.13. 851871: ETM May Lose Counter Events While Entering WFx Mode
3.14. 852071: Direct Branch Instructions Executed Before a Trace Flush May be Output in an Atom Packet After Flush Acknowledgment
3.15. 852521: A64 Unconditional Branch May Jump to Incorrect Address
3.16. 855827: PMU Counter Values May Be Inaccurate When Monitoring Certain Events
3.17. 855829: Reads of PMEVCNTR<n> are not Masked by HDCR.HPMN
3.18. 855830: Loads of Mismatched Size May not be Single-Copy Atomic
Visible to Intel only — GUID: uog1487886246547
Ixiasoft
3.18. 855830: Loads of Mismatched Size May not be Single-Copy Atomic
Description
The Cortex-A53 MPCore* processor supports single-copy atomic load and store accesses as described in the Arm* architecture documentation. However, in some unusual code sequences, this erratum can cause the CPU executing a store, and later a load, to the same address but with a different access size to load data that does not meet the requirements of a single-copy atomic load.
For this erratum to be present, a store instruction must execute on one CPU. This instruction can be any halfword, word, or double word store instruction that is not a store release and the address must be aligned to the access size. On a second CPU, the following sequence must occur:
- A store instruction executes. This store must be a smaller access size than the store on the first CPU, and must address bytes accessed by the first CPU. The address must also be aligned to the access size.
- The store instruction does not allocate into the cache because of any one of the following conditions:
- The memory address is marked as transient
- The write allocate hint in the translation table is not set or the memory is marked as non-cacheable
- The CPU recently executed a stream of stores and has subsequently dynamically switched into a no-write allocate mode
- A load instruction executes. The load must be a larger access size than the store from the same CPU, and at least some bytes of the load must be to the same address as the store. The address must also be aligned to the access size.
The Arm* architecture requires that the load is single-copy atomic. However, in the conditions described, the load may observe a combination of the two stores, indicating that the store on the initial CPU was serialized first. If the load is repeated, it might only see the data from the first CPU's store, indicating that the store on the first CPU was serialized second.
Impact
Concurrent, unordered stores are uncommon in multi-threaded code. In the ISO/IEC 9899:2011 (C11) standard, they are restricted to the family of relaxed atomics. Using different size load and store instructions to access the same data is also uncommon. For these reasons, the majority of multi-threaded software does not meet the conditions for this erratum.
Workaround
Most multi-threaded software does not satisfy the conditions of this erratum and therefore, does not require a workaround . If a workaround is required, then replace the store on the second CPU with a store-release instruction.