DC CVAC's Point of Coherency Scope in ARMv8.2: Stale Cache Uncertainty

Direct Answer

No. On ARMv8.2, DC CVAC alone does not guarantee that data written on one core is visible to all other cores. The Point of Coherency (PoC) is implementation-defined; if the PoC is restricted to an inner-shareable domain, a core in an outer-shareable domain may continue to observe stale data from its own local cache.

Confirmed Facts and Likely Explanation

Confirmed: The ARMv8-A architecture maintains a consistent definition of the PoC across versions 8.0 through 8.2. DC CVAC cleans the cache line to the PoC, but the scope of that PoC (whether it is inner-shareable or outer-shareable) depends entirely on the specific hardware implementation.

Likely Explanation: Stale data occurs when the writing core issues DC CVAC for a memory region where the PoC is inner-shareable, but the reading core is located in a different cluster or domain that only shares data at the outer-shareable level. Because the maintenance operation stops at the inner PoC, it does not invalidate or update the copies held in outer-level caches, leaving the reading core with outdated information.

Conditions for Propagation Failure

• The hardware implementation defines the PoC as inner-shareable for the target address.
• The reading core holds a cached copy of the line in a level outside the inner-shareable domain (e.g., a system-level cache).
• The software fails to issue a synchronization barrier or a wider-scope cache maintenance operation.

Recommended Synchronization Sequence

To ensure portable inter-core visibility across different ARMv8.2 implementations, avoid relying on DC CVAC in isolation. Use the following sequence:

1. Perform the data write.
2. Execute DC CIVAC (Clean and Invalidate by VA to PoC) to ensure the line is pushed to the PoC and invalidated locally.
3. Execute DSB SY (Data Synchronization Barrier, System scope) to ensure the maintenance operation is complete and visible before the next step.

Verification and Diagnostics

To verify the behavior on a specific target, you can read the ID_AA64MMFR_EL1 register or consult the Technical Reference Manual (TRM) for the specific SoC to determine the PoC scope. A practical test involves a two-core loop where Core A writes and cleans, and Core B polls for the update; if Core B hangs or reads old data without a DSB, the PoC is likely narrower than the shareability domain.

Missing Diagnostic: Which specific processor implementation (e.g., Cortex-A75, Neoverse N1) are you targeting? The recommendation only changes if the silicon documentation explicitly guarantees an outer-shareable PoC for your specific memory attributes.