1 ==============================
2 Memory Layout on AArch64 Linux
3 ==============================
5 Author: Catalin Marinas <catalin.marinas@arm.com>
7 This document describes the virtual memory layout used by the AArch64
8 Linux kernel. The architecture allows up to 4 levels of translation
9 tables with a 4KB page size and up to 3 levels with a 64KB page size.
11 AArch64 Linux uses either 3 levels or 4 levels of translation tables
12 with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
13 (256TB) virtual addresses, respectively, for both user and kernel. With
14 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
15 virtual address, are used but the memory layout is the same.
17 User addresses have bits 63:48 set to 0 while the kernel addresses have
18 the same bits set to 1. TTBRx selection is given by bit 63 of the
19 virtual address. The swapper_pg_dir contains only kernel (global)
20 mappings while the user pgd contains only user (non-global) mappings.
21 The swapper_pg_dir address is written to TTBR1 and never written to
25 AArch64 Linux memory layout with 4KB pages + 3 levels::
28 -----------------------------------------------------------------------
29 0000000000000000 0000007fffffffff 512GB user
30 ffffff8000000000 ffffffffffffffff 512GB kernel
33 AArch64 Linux memory layout with 4KB pages + 4 levels::
36 -----------------------------------------------------------------------
37 0000000000000000 0000ffffffffffff 256TB user
38 ffff000000000000 ffffffffffffffff 256TB kernel
41 AArch64 Linux memory layout with 64KB pages + 2 levels::
44 -----------------------------------------------------------------------
45 0000000000000000 000003ffffffffff 4TB user
46 fffffc0000000000 ffffffffffffffff 4TB kernel
49 AArch64 Linux memory layout with 64KB pages + 3 levels::
52 -----------------------------------------------------------------------
53 0000000000000000 0000ffffffffffff 256TB user
54 ffff000000000000 ffffffffffffffff 256TB kernel
57 For details of the virtual kernel memory layout please see the kernel
61 Translation table lookup with 4KB pages::
63 +--------+--------+--------+--------+--------+--------+--------+--------+
64 |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
65 +--------+--------+--------+--------+--------+--------+--------+--------+
68 | | | | | [11:0] in-page offset
69 | | | | +-> [20:12] L3 index
70 | | | +-----------> [29:21] L2 index
71 | | +---------------------> [38:30] L1 index
72 | +-------------------------------> [47:39] L0 index
73 +-------------------------------------------------> [63] TTBR0/1
76 Translation table lookup with 64KB pages::
78 +--------+--------+--------+--------+--------+--------+--------+--------+
79 |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
80 +--------+--------+--------+--------+--------+--------+--------+--------+
83 | | | | [15:0] in-page offset
84 | | | +----------> [28:16] L3 index
85 | | +--------------------------> [41:29] L2 index
86 | +-------------------------------> [47:42] L1 index
87 +-------------------------------------------------> [63] TTBR0/1
90 When using KVM without the Virtualization Host Extensions, the
91 hypervisor maps kernel pages in EL2 at a fixed (and potentially
92 random) offset from the linear mapping. See the kern_hyp_va macro and
93 kvm_update_va_mask function for more details. MMIO devices such as
94 GICv2 gets mapped next to the HYP idmap page, as do vectors when
95 ARM64_HARDEN_EL2_VECTORS is selected for particular CPUs.
97 When using KVM with the Virtualization Host Extensions, no additional
98 mappings are created, since the host kernel runs directly in EL2.