ARM Cortex-A Series VMSAv8-64 Stage 2 Translation Regime: PA Size Implications
The VMSAv8-64 architecture, used in ARM Cortex-A series processors, implements a two-stage address translation mechanism for virtualization. Stage 2 translation, managed by the hypervisor, maps Intermediate Physical Addresses (IPAs) to Physical Addresses (PAs). The Physical Address (PA) size supported by the system plays a critical role in determining the structure and behavior of the Stage 2 translation tables. Specifically, the PA size can constrain the IPA size and the starting level of translation, sometimes necessitating the use of concatenated translation tables.
In the VMSAv8-64 architecture, the VTCR_EL2 (Virtualization Translation Control Register at Exception Level 2) and VSTCR_EL2 (Virtualization System Translation Control Register at Exception Level 2) control the Stage 2 translation regime. The T0SZ field in these registers defines the size of the IPA space. However, the supported PA size imposes restrictions on the IPA size and the translation starting level. For example, when the PA size is 40 bits and the translation granule is 4 KiB, the IPA size can be set to 40 bits (VTCR_EL2.T0SZ = 24), but the translation must start at level 1 or higher. This is because level 0 translation tables cannot resolve 40-bit IPAs without concatenation.
Concatenated translation tables are a mechanism to extend the addressing capability of a single translation level by combining multiple tables. In the case of a 40-bit PA size and 4 KiB granule, two concatenated translation tables are required at level 1 to resolve the additional bit [39] in the IPA. This is a direct consequence of the PA size constraint and the architecture’s design choices.
The ARM Architecture Reference Manual (ARM ARM) provides tables (e.g., D5-6 and D5-14) that outline the relationship between PA size, IPA size, and translation starting level. These tables highlight scenarios where concatenated translation tables are not optional but mandatory due to PA size limitations. This behavior is not immediately intuitive and warrants a deeper exploration of the underlying architectural decisions and their implications.
Memory Hierarchy Constraints and Concatenated Translation Table Necessity
The necessity of concatenated translation tables in certain scenarios stems from the interplay between the PA size, IPA size, and the translation granule size. The VMSAv8-64 architecture supports multiple translation granules (4 KiB, 16 KiB, and 64 KiB), each with its own addressing limitations and table structures. The choice of granule size affects the number of translation levels and the size of the address space that can be resolved at each level.
When the PA size is constrained (e.g., 40 bits), the architecture must ensure that the IPA size does not exceed the PA size. This constraint is enforced by the VTCR_EL2.T0SZ field, which defines the IPA size. However, the translation starting level is also influenced by the PA size. For example, with a 4 KiB granule and a 40-bit PA size, the translation must start at level 1 or higher because level 0 cannot resolve 40-bit IPAs without concatenation.
The use of concatenated translation tables at level 1 allows the architecture to extend the addressing capability of a single translation level. By combining two tables, the architecture can resolve an additional bit in the IPA, enabling the translation of 40-bit IPAs. This approach avoids the overhead of an additional translation level, which would increase latency and complexity.
The ARM ARM’s tables (D5-6 and D5-14) provide detailed mappings of PA size, IPA size, and translation starting level for different granule sizes. These tables reveal that concatenated translation tables are not merely an optional optimization but a necessary feature in certain configurations. The architecture’s design prioritizes efficiency and simplicity, favoring concatenation over additional translation levels in scenarios where the PA size imposes strict constraints.
Implementing Concatenated Translation Tables for 40-Bit PA Systems
To implement concatenated translation tables in a system with a 40-bit PA size and 4 KiB granule, the hypervisor must configure the VTCR_EL2 register appropriately and ensure that the translation tables are correctly concatenated. The following steps outline the process:
-
Configure VTCR_EL2.T0SZ: Set the T0SZ field to 24 to define a 40-bit IPA space. This ensures that the IPA size matches the PA size constraint.
-
Determine Translation Starting Level: Based on the PA size and granule size, determine that the translation must start at level 1. This is because level 0 cannot resolve 40-bit IPAs without concatenation.
-
Allocate Concatenated Translation Tables: Allocate two level 1 translation tables and configure them as concatenated tables. This involves setting the appropriate bits in the translation table descriptors to indicate concatenation.
-
Populate Translation Tables: Populate the concatenated translation tables with valid descriptors that map IPAs to PAs. Ensure that the descriptors correctly reflect the memory layout and access permissions.
-
Enable Stage 2 Translation: Set the VTCR_EL2.SL0 field to indicate the starting level (level 1) and enable Stage 2 translation by setting the VTCR_EL2.ENABLE bit.
-
Verify Translation Behavior: Test the translation behavior to ensure that IPAs are correctly mapped to PAs and that the concatenated tables function as expected. Use debugging tools and performance counters to verify the correctness and efficiency of the translation process.
By following these steps, the hypervisor can effectively manage Stage 2 address translation in systems with constrained PA sizes, leveraging concatenated translation tables to extend the addressing capability of a single translation level. This approach balances performance and complexity, ensuring efficient and reliable address translation in virtualized environments.
The use of concatenated translation tables in VMSAv8-64 Stage 2 address translation is a powerful mechanism to address the constraints imposed by PA size. While it may seem counterintuitive at first, this design choice reflects the architecture’s emphasis on efficiency and simplicity. By understanding the underlying principles and implementing the necessary configurations, developers can ensure robust and performant address translation in ARM Cortex-A series processors.
