1 ==============================
2 Memory Layout on AArch64 Linux
3 ==============================
4
5 Author: Catalin Marinas <catalin.marinas@arm.co
6
7 This document describes the virtual memory lay
8 Linux kernel. The architecture allows up to 4
9 tables with a 4KB page size and up to 3 levels
10
11 AArch64 Linux uses either 3 levels or 4 levels
12 with the 4KB page configuration, allowing 39-b
13 (256TB) virtual addresses, respectively, for b
14 64KB pages, only 2 levels of translation table
15 virtual address, are used but the memory layou
16
17 ARMv8.2 adds optional support for Large Virtua
18 only available when running with a 64KB page s
19 number of descriptors in the first level of tr
20
21 TTBRx selection is given by bit 55 of the virt
22 swapper_pg_dir contains only kernel (global) m
23 contains only user (non-global) mappings. The
24 written to TTBR1 and never written to TTBR0.
25
26
27 AArch64 Linux memory layout with 4KB pages + 4
28
29 Start End
30 --------------------------------------------
31 0000000000000000 0000ffffffffffff
32 ffff000000000000 ffff7fffffffffff
33 [ffff600000000000 ffff7fffffffffff]
34 ffff800000000000 ffff80007fffffff
35 ffff800080000000 fffffbffefffffff
36 fffffbfff0000000 fffffbfffdffffff
37 fffffbfffe000000 fffffbfffe7fffff
38 fffffbfffe800000 fffffbffff7fffff
39 fffffbffff800000 fffffbffffffffff
40 fffffc0000000000 fffffdffffffffff
41 fffffe0000000000 ffffffffffffffff
42
43
44 AArch64 Linux memory layout with 64KB pages +
45
46 Start End
47 --------------------------------------------
48 0000000000000000 000fffffffffffff
49 fff0000000000000 ffff7fffffffffff
50 [fffd800000000000 ffff7fffffffffff]
51 ffff800000000000 ffff80007fffffff
52 ffff800080000000 fffffbffefffffff
53 fffffbfff0000000 fffffbfffdffffff
54 fffffbfffe000000 fffffbfffe7fffff
55 fffffbfffe800000 fffffbffff7fffff
56 fffffbffff800000 fffffbffffffffff
57 fffffc0000000000 ffffffdfffffffff
58 ffffffe000000000 ffffffffffffffff
59
60
61 Translation table lookup with 4KB pages::
62
63 +--------+--------+--------+--------+-------
64 |63 56|55 48|47 40|39 32|31 2
65 +--------+--------+--------+--------+-------
66 | | | |
67 | | | |
68 | | | |
69 | | | |
70 | | | +----
71 | | +--------------
72 | +------------------------
73 +---------------------------------
74
75
76 Translation table lookup with 64KB pages::
77
78 +--------+--------+--------+--------+-------
79 |63 56|55 48|47 40|39 32|31 2
80 +--------+--------+--------+--------+-------
81 | | | |
82 | | | |
83 | | | |
84 | | | +---
85 | | +-------------------
86 | +------------------------
87 |
88 +---------------------------------
89
90
91 When using KVM without the Virtualization Host
92 hypervisor maps kernel pages in EL2 at a fixed
93 random) offset from the linear mapping. See th
94 kvm_update_va_mask function for more details.
95 GICv2 gets mapped next to the HYP idmap page,
96 ARM64_SPECTRE_V3A is enabled for particular CP
97
98 When using KVM with the Virtualization Host Ex
99 mappings are created, since the host kernel ru
100
101 52-bit VA support in the kernel
102 -------------------------------
103 If the ARMv8.2-LVA optional feature is present
104 with a 64KB page size; then it is possible to
105 space for both userspace and kernel addresses.
106 binary that supports 52-bit must also be able
107 at early boot time if the hardware feature is
108
109 This fallback mechanism necessitates the kerne
110 higher addresses such that they are invariant
111 to the kasan shadow being a fraction of the en
112 the end of the kasan shadow must also be in th
113 kernel VA space for both 48/52-bit. (Switching
114 the end of the kasan shadow is invariant and d
115 whilst the start address will "grow" towards t
116
117 In order to optimise phys_to_virt and virt_to_
118 is kept constant at 0xFFF0000000000000 (corres
119 this obviates the need for an extra variable r
120 offset and vmemmap offsets are computed at ear
121 this logic.
122
123 As a single binary will need to support both 4
124 spaces, the VMEMMAP must be sized large enough
125 also must be sized large enough to accommodate
126
127 Most code in the kernel should not need to con
128 code that does need to know the VA size the va
129 defined as follows:
130
131 VA_BITS constant the *maximum*
132
133 VA_BITS_MIN constant the *minimum*
134
135 vabits_actual variable the *actual* V
136
137
138 Maximum and minimum sizes can be useful to ens
139 sized large enough or that addresses are posit
140 the "worst" case.
141
142 52-bit userspace VAs
143 --------------------
144 To maintain compatibility with software that r
145 VA space maximum size of 48-bits, the kernel w
146 return virtual addresses to userspace from a 4
147
148 Software can "opt-in" to receiving VAs from a
149 specifying an mmap hint parameter that is larg
150
151 For example:
152
153 .. code-block:: c
154
155 maybe_high_address = mmap(~0UL, size, prot,
156
157 It is also possible to build a debug kernel th
158 from a 52-bit space by enabling the following
159
160 .. code-block:: sh
161
162 CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT
163
164 Note that this option is only intended for deb
165 and should not be used in production.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.