Armv8-R AEM FVP Exclusive Monitor Failure with cache_state_modelled=0

Armv8-R AEM FVP Exclusive Monitor Behavior Under cache_state_modelled=0

The Armv8-R AEM FVP (Fixed Virtual Platform) exhibits unexpected behavior when the cache_state_modelled parameter is set to 0. Specifically, the exclusive load/store (LDREX/STREX) instructions, which are critical for implementing atomic operations such as spinlocks, cease to function correctly. This issue is particularly perplexing because the same binary and configuration work flawlessly when cache_state_modelled=1. Additionally, the Armv8-A architecture’s FVP does not exhibit this problem under the same conditions, suggesting a divergence in how the exclusive monitor is implemented or managed between the two architectures.

The exclusive monitor is a hardware mechanism that tracks exclusive access to memory locations, ensuring atomicity for operations like spinlocks. When cache_state_modelled=0, the cache state is not simulated, which reduces simulation overhead and speeds up execution. However, the Fast Models Reference Guide (Version 11.20) implies that a backup implementation of the exclusive monitor should exist that does not rely on cache state modeling. This backup mechanism appears to function correctly in the Armv8-A FVP but fails in the Armv8-R FVP, leading to the observed issue.

The problem manifests when running a bare-metal application that relies on spinlocks implemented using LDREX/STREX instructions. The application stalls indefinitely when attempting to acquire a lock, indicating that the exclusive monitor is not functioning as expected. This behavior is consistent with the exclusive monitor failing to track the state of the memory location, causing the STREX instruction to always fail.

Cache State Modeling and Exclusive Monitor Implementation Divergence

The root cause of this issue lies in the divergence between how the exclusive monitor is implemented in the Armv8-R and Armv8-A FVPs when cache_state_modelled=0. In the Armv8-A FVP, the exclusive monitor appears to have a fallback mechanism that operates independently of cache state modeling. This fallback ensures that exclusive LD/ST instructions continue to function even when cache state modeling is disabled. However, the Armv8-R FVP lacks this fallback mechanism, leading to the exclusive monitor’s failure when cache_state_modelled=0.

The exclusive monitor in Arm architectures is tightly coupled with the cache coherence protocol. When cache_state_modelled=1, the monitor relies on the cache state to track exclusive access. Disabling cache state modeling removes this dependency, necessitating an alternative implementation. The absence of such an alternative in the Armv8-R FVP suggests either an oversight in the model’s implementation or a deliberate design choice that was not adequately documented.

Another possible cause is the difference in memory protection schemes between Armv8-A and Armv8-R. While Armv8-A uses a Memory Management Unit (MMU) for virtual memory management, Armv8-R employs a Memory Protection Unit (MPU) for fixed memory regions. This difference could affect how the exclusive monitor interacts with memory access mechanisms, particularly when cache state modeling is disabled. However, this explanation is less likely, as the exclusive monitor’s functionality should be independent of the memory protection scheme.

The issue is further compounded by the fact that the same binary, with minor modifications for MMU/MPU setup, works correctly on the Armv8-A FVP but fails on the Armv8-R FVP. This suggests that the problem is not related to the software but rather to the FVP’s implementation of the exclusive monitor under specific conditions.

Resolving Exclusive Monitor Issues in Armv8-R FVP with cache_state_modelled=0

To address the exclusive monitor failure in the Armv8-R FVP when cache_state_modelled=0, several steps can be taken. First, it is essential to verify whether the issue is indeed caused by the lack of a fallback mechanism for the exclusive monitor. This can be done by examining the FVP’s internal implementation or consulting Arm’s documentation for any updates or patches related to this behavior.

If no fallback mechanism exists, a workaround can be implemented at the software level. One approach is to replace the LDREX/STREX-based spinlock implementation with an alternative synchronization mechanism that does not rely on the exclusive monitor. For example, a simple test-and-set loop using regular load/store instructions can be used, although this may result in higher contention and reduced performance.

Another potential solution is to modify the FVP configuration to ensure that the exclusive monitor remains functional even when cache_state_modelled=0. This may involve enabling specific parameters or flags that force the FVP to use a backup implementation of the exclusive monitor. If such parameters do not exist, it may be necessary to raise a support case with Arm to request a fix or enhancement to the FVP.

In the long term, it is crucial to ensure that the exclusive monitor’s behavior is consistent across all Arm architectures and FVP configurations. This can be achieved by advocating for better documentation and more robust fallback mechanisms in future FVP releases. Additionally, developers should be made aware of this issue and provided with guidelines on how to handle similar scenarios in their designs.

Below is a summary of the key points and recommended actions:

By following these steps, developers can mitigate the impact of the exclusive monitor failure in the Armv8-R FVP and ensure that their applications continue to function correctly even when cache_state_modelled=0.