Skip to content
Continuing from the previous article, Introduction to MMU in ARMV8-A – Part 4.
ARMV8-A supports three types of page table formats:
-
ARMV8-A AArch64 Long Descriptor Format
-
ARMV7-A Long Descriptor Format, such as the Large Physical Address Extension (LPAE) in the ARM Cortex-A15 processor
-
ARMV7-A Short Descriptor Format
Although ARMV8-A uses the AArch64 instruction set, it still retains the ARMV7 compatible instruction set, referred to as AArch32 state, which requires switching to exception mode. In AArch32 state, the existing ARMV7-A long and short descriptor formats can be used to run existing client operating systems and application code without modification. The ARMV7-A Short Descriptor can only be used for EL0 and EL1 stage 1 translation. They cannot be used by hypervisor or secure monitor code.
The ARMV8-A Long Descriptor Format is always used in AArch64 execution state. This is similar to the ARMV7-A Long Descriptor Format with Large Physical Address Extension. It uses the same 64-bit long descriptor format but with some variations. It introduces a level 0 table index that uses the same descriptor format as level 1 tables. It adds support for up to 48-bit input and output addresses. The input virtual address is now 64 bits. However, since the architecture does not support full 64-bit addressing, bits [63:48] of the address must all be the same, either all zero or all one, or the upper 8 bits can be used for VA tagging to select different page table base address registers. This has been mentioned earlier.
AArch64 supports three different page translation granularities. These define the size of the memory blocks (physical pages) at the lowest (end) level of the translation table and control the size of the translation tables being used. Larger granularities reduce the number of translation table levels required, which can be an important consideration in systems using hypervisors for virtualization. The granularities supported by AArch64 are 4KB, 16KB, and 64KB. Which of these block size granularities is supported is determined by IMPLEMENTATION DEFINED. The system software creating the translation tables (generally the kernel) can read the memory model feature system registers (ID_AA64MMFR0_EL1, see Figure 8) to find out the supported sizes. The size of each translation table within the Translation Control Register (TCR_EL1) is configurable.
Page Table Descriptor Format
The AArch64 descriptor format is used for page tables at all levels from level 0 to level 3. Level 0 descriptors can only output the address of the level 1 table. Level 3 descriptors cannot point to another table and can only output the address of a block (physical page). Therefore, the table format at level 3 is slightly different.
The red box in Figure 9 shows that the page table descriptor type is identified by the bits [1:0] of the entry. Its functions are: 1. The address of the next level table, in which case memory can be further subdivided into smaller blocks. 2. The address of the memory block. 3. The page table entry can be marked as “fault” or “invalid”.
Impact of Page Table Granularity Size
In ARMV8-A, the three different granularities of page table sizes affect the required number and size of page tables. If the input range of the virtual address (VA) is limited to 39 bits, the first-level table is omitted. Depending on the size of the possible VA range, there may be fewer levels of page tables. For example, for 4KB granularity, if the TTBCR is set to low addresses spanning only 1GB, levels 0 and 1 of the page tables are not needed, and the translation table starts from level 2, with translations dropping to level 3 for 4KB pages.
For 4KB granularity, the hardware can use a 4-level page table lookup process. Each conversion level has 9 address bits for a 48-bit address (i.e., each has 512 entries), and the last 12 bits select one byte within the 4KB, directly from the original virtual address.
The bits [47:39] of the virtual address index into a 512-entry L0 table. Each of these table entries can address a range of 512GB and point to the next level L1 page table. The L1 table also has 512 entries, where bits [38:30] are used as an index to select an entry, each entry pointing to a 1GB block or the next level L2 table.
If there is an L2 table, then bits [29:21] will index one entry in the 512 entries of the L2 table, each entry pointing to a 2MB block or the next level L3 table. In the L3 page table, bits [20:12] will index one entry in the 512 entries of the L3 table, with each entry pointing to a 4KB block.
For a detailed explanation of the page table levels, see Figure 10:
We welcome everyone to continue reading the next article, “Introduction to MMU in ARMV8-A – Part 6”.
