Each time an application accesses a memory location, that access is made to a virtual address that is automatically translated to a physical address by the CPU’s memory management unit (MMU) using tables programmed by the kernel; these tables are also used to specify properties and attributes such as access permissions and whether the processor can execute from the region.
Programming the MMU and its translation tables is a very important step during the boot process; without this the processor defaults to having most of its built-in memory access optimizations switched off, including the caches, write merging, access reordering, and more. With this in mind, the processor is running much slower up until the MMU is enabled as it will often be stalled waiting for the results of memory reads and writes.
Each exception level above EL0 has control over the configuration of the MMU when executing in their respective levels. For page table managment, ARM banks page table base registers (called translation table base registers, TTBRs) across each exception level.
EL1 and EL0 share an address space accross two TTBRs, TTBR0_EL1 and TTBR1_EL1, that are under EL1 control. This shared address space is split in half with TTBR1_EL1 for the upper addresses and TTBR0_EL1 for the lower addresses. This split provides a convenient mechanism for splitting a kernel and user address space.
A virtual machine running in EL1 will first translate virtual addresses into intermediate physical addresses (IPA) using its own page table. Next, the second stage translates IPAs into physical addresses using a page table provided by the hyper- visor in EL2.
The registers:
- VTTBR** (Virtualization Translation Table Base Register)**
- Holds the base address of the translation table for the stage 2 translation of memory accesses from Non-secure modes other than Hyp mode.
- VSTTBR** (Virtualization Secure Translation Table Base Register)**
- Holds the base address of the translation table for the initial lookup for stage 2 of an address translation in the Secure EL1&0 translation regime, and other information for this translation stage.
- **TTBRn (Translation Table Base Register) - TTBR0 or **TTBR1
- Holds the base address of the translation table for the initial lookup for stage 1 of the translation of an address from the lower VA range in the PL1&0 translation regime, and other information for this translation regime.
Registers that control address translation
Address translation is controlled by a combination of system registers:
- SCTLR_ELxM - Enable Memory Management Unit (MMU).C - Enable for data and unified caches.EE - Endianness of translation table walks.
- TTBR0_ELx and TTBR1_ELxBADDR - Physical address (PA) (or intermediate physical address, IPA, for EL0/EL1) of start of translation table.ASID - The Address Space Identifier for Non-Global translations.
- TCR_ELxPS/IPS - Size of PA or IPA space, the maximum output address size.TnSZ - Size of address space covered by table.TGn - Granule size.SH/IRGN/ORGN - Cacheability and shareability to be used by MMU table walks.TBIn - Disabling of table walks to a specific table.
- MAIR_ELxAttr - Controls the Type and cacheability in Stage 1 tables.
https://developer.arm.com/documentation/101811/0102/Translation-granule
TLB
The ARM virtual memory model provides features for operating system developers to mitigate unnecesary TLB flushes. For example, ARM TLB’s can match entries based on the current exception level, removing the need to flush the TLB when taking an exception.
ARM defines a unique application specific identifier (ASID) that an OS assigns to each user process. ASID’s are commu- nicated to the hardware through the top sixteen bits of TTBR0_EL1. During an address translation, the hard- ware matches TLB entries using the ASID, removing the need to flush the TLB during a context switch.
VMIDs
Each VM is assigned a virtual machine identifier (VMID). The VMID is used to tag translation lookaside buffer (TLB) entries, to identify which VM each entry belongs to. This tagging allows translations for multiple different VMs to be present in the TLBs at the same time.
The VMID is stored in VTTBR_EL2 can either be 8 or 16 bits. The VMID is controlled by the VTCR_EL2.VS bit. Support for 16-bit VMIDs is optional, and was added in Armv8.1-A.
- Note: Translations for the EL2 and EL3 translation regimes are not tagged with a VMID, because they are not subject to stage 2 translation.
VMID interaction with ASIDs
TLB entries can also be tagged with an Address Space Identifier (ASID). An application is assigned an ASID by the OS, and all the TLB entries in that application are tagged with that ASID. This means that TLB entries for different applications are able to coexist in the TLB, without the possibility that one application uses the TLB entries that belong to a different application.
Each VM has its own ASID namespace. For example, two VMs might both use ASID 5, but they use them for different things. The combination of ASID and VMID is the thing that is important.
https://www.starlab.io/blog/deep-dive-mmu-virtualization-with-xen-on-arm
https://developer.arm.com/documentation/101811/0102/The-Memory-Management-Unit-MMU
https://www.ashw.io/blog-pgtable-tool