2 <previous description obsolete, deleted>
4 Virtual memory map with 4 level page tables:
6 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
7 hole caused by [48:63] sign extension
8 ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
9 ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
10 ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
11 ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
12 ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
13 ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
15 ffffec0000000000 - fffffc0000000000 (=44 bits) kasan shadow memory (16TB)
17 ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
19 ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0
20 ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
21 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
22 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
24 The direct mapping covers all memory in the system up to the highest
25 memory address (this means in some cases it can also include PCI memory
28 vmalloc space is lazily synchronized into the different PML4 pages of
29 the processes using the page fault handler, with init_level4_pgt as
32 Current X86-64 implementations only support 40 bits of address space,
33 but we support up to 46 bits. This expands into MBZ space in the page tables.
37 We map EFI runtime services in the aforementioned PGD in the virtual
38 range of 64Gb (arbitrarily set, can be raised if needed)
40 0xffffffef00000000 - 0xffffffff00000000