AArch64 TLB Maintenance: Break-Before-Make Requirements for Block Demotion

ARM Cortex-A53 TLB Coherency Issues During Block-to-Table Demotion

In ARMv8-A architectures, particularly when dealing with AArch64, the Translation Lookaside Buffer (TLB) plays a critical role in managing virtual-to-physical address translations. One of the more nuanced challenges arises when transitioning from a block mapping to a table mapping, especially in a multi-processing element (PE) environment. This scenario is commonly referred to as "block demotion," where a large block mapping (e.g., a 2MB block) is broken down into smaller page mappings (e.g., 4KB pages). The architectural requirements for TLB maintenance during this process are stringent, and failure to adhere to them can lead to coherency issues, multiple TLB entry conflicts, and undefined behavior.

The core issue revolves around the architectural requirement for a "break-before-make" (BBM) sequence when changing the size of the block used by the translation system. Specifically, when demoting a block mapping to a table mapping, the ARM architecture mandates that the old block entry must be invalidated before the new table entries are installed. This requirement is detailed in the ARM Architecture Reference Manual (ARM ARM), section D4.10.1, which discusses general TLB maintenance requirements. The manual explicitly states that BBM is necessary to avoid the creation of multiple TLB entries for the same address, which can occur if the old and new mappings coexist temporarily.

The confusion often arises from the interpretation of the term "size of block used by the translation system." This refers to the size of the memory region covered by a single TLB entry, which can vary depending on whether the mapping is a block or a table entry. For example, a 2MB block mapping covers a larger region than a 4KB page mapping, and changing from the former to the latter constitutes a change in block size. The architecture requires that such changes be handled with BBM to ensure TLB coherency across all PEs.

Memory Barrier Omission and TLB Invalidation Timing

One of the primary causes of TLB coherency issues during block demotion is the omission of memory barriers and improper timing of TLB invalidations. In a multi-PE system, each PE has its own TLB, and changes to the translation tables must be propagated correctly to ensure that all PEs have a consistent view of the memory mappings. If a PE accesses a memory region while the translation tables are being updated, it may load an outdated or incorrect TLB entry, leading to coherency issues.

The ARM architecture provides several mechanisms to manage TLB coherency, including the use of Data Synchronization Barriers (DSBs) and TLB maintenance instructions. However, these mechanisms must be used correctly to ensure that all PEs see the updated translation tables in the correct order. For example, when demoting a block mapping to a table mapping, the following sequence must be followed:

1. Invalidate the old block entry in the TLB using a TLB invalidate instruction (e.g., TLBI VAE1IS).
2. Issue a DSB to ensure that the TLB invalidation is complete before proceeding.
3. Install the new table entries in the translation tables.
4. Issue another DSB to ensure that the new entries are visible to all PEs.
5. Invalidate the TLB again to ensure that any stale entries are removed.

Failure to follow this sequence can result in a situation where a PE accesses a memory region using an outdated TLB entry, leading to incorrect translations and potential system crashes. Additionally, speculative accesses by other PEs can reload the old block mapping into the TLB, even after it has been invalidated, further complicating the coherency issue.

Another potential cause of TLB coherency issues is the use of hardware-managed Access and Dirty flags in the translation table entries. Starting with ARMv8.1, the architecture allows the hardware to update these flags automatically, which can lead to race conditions if the BBM sequence is not followed. For example, if a PE updates the Access or Dirty flag while another PE is in the process of demoting the block mapping, the resulting TLB entry may be inconsistent, leading to undefined behavior.

Implementing Break-Before-Make and Ensuring TLB Coherency

To address the TLB coherency issues during block demotion, it is essential to implement the BBM sequence correctly and ensure that all PEs see the updated translation tables in a consistent manner. The following steps outline the recommended approach for handling block demotion in an AArch64 system:

1. Prepare the New Table Entries: Before invalidating the old block mapping, prepare the new table entries in the translation tables. Ensure that these entries are equivalent in size, type, and attributes to the old block mapping. This step is crucial to ensure that the new mappings provide the same memory access permissions and attributes as the old block mapping.

2. Invalidate the Old Block Entry: Use a TLB invalidate instruction (e.g., TLBI VAE1IS) to invalidate the old block entry in the TLB. This step ensures that any existing TLB entries for the old block mapping are removed, preventing multiple TLB entries for the same address.

3. Issue a Data Synchronization Barrier (DSB): After invalidating the old block entry, issue a DSB to ensure that the TLB invalidation is complete before proceeding. This step is necessary to ensure that all PEs see the updated translation tables in the correct order.

4. Install the New Table Entries: Once the old block entry has been invalidated and the DSB has completed, install the new table entries in the translation tables. This step should be done atomically to ensure that no PE accesses the memory region while the translation tables are being updated.

5. Issue Another Data Synchronization Barrier (DSB): After installing the new table entries, issue another DSB to ensure that the new entries are visible to all PEs. This step is necessary to ensure that all PEs see the updated translation tables before accessing the memory region.

6. Invalidate the TLB Again: Finally, invalidate the TLB again to ensure that any stale entries are removed. This step is necessary to ensure that all PEs use the new table entries when accessing the memory region.

By following this sequence, you can ensure that the block demotion process is handled correctly and that all PEs see the updated translation tables in a consistent manner. This approach minimizes the risk of TLB coherency issues and ensures that the system remains stable during the demotion process.

In addition to the BBM sequence, it is also important to consider the impact of hardware-managed Access and Dirty flags on TLB coherency. If your system uses these features, you must ensure that the BBM sequence is followed to avoid race conditions and ensure that the flags are updated correctly. If your system does not use these features, you can safely ignore them, but it is still important to follow the BBM sequence to ensure TLB coherency.

Finally, it is worth noting that the BBM requirement applies not only to block demotion but also to block promotion (i.e., changing from a smaller block size to a larger block size). The same principles apply in both cases, and the BBM sequence must be followed to ensure TLB coherency. By adhering to these requirements, you can ensure that your system remains stable and performs correctly, even in complex multi-PE environments.

In conclusion, the ARM architecture’s requirement for a break-before-make sequence during block demotion is a critical aspect of TLB maintenance in AArch64 systems. By understanding the underlying causes of TLB coherency issues and implementing the correct sequence of operations, you can ensure that your system remains stable and performs correctly, even in complex multi-PE environments.