Commit 32b89760 authored by Ingo Molnar's avatar Ingo Molnar

x86/mm/doc: Enhance the x86-64 virtual memory layout descriptions

After the cleanups from Baoquan He, make it even more readable:

 - Remove the 'bits' area size column: it's pretty pointless and was even
   wrong for some of the entries. Given that MB, GB, TB, PT are 10, 20,
   30 and 40 bits, a "8 TB" size description makes it obvious that it's
   43 bits.

 - Introduce an "offset" column:

    --------------------------------------------------------------------------------
    start addr       | offset     | end addr         |  size   | VM area description
    -----------------|------------|------------------|---------|--------------------
    ...
    ffff880000000000 | -120    TB | ffffc7ffffffffff |   64 TB | direct mapping of all physical memory (page_offset_base),
                                                                 this is what limits max physical memory supported.

   The -120 TB notation makes it obvious where this particular virtual memory
   region starts: 120 TB down from the top of the 64-bit virtual memory space.
   Especially the layout of the kernel mappings is a *lot* more obvious when
   written this way, plus it's much easier to compare it with the size column
   and understand/check/validate and modify the kernel's layout in the future.

 - Mark the part from where the 47-bit and 56-bit kernel layouts are 100% identical,
   this starts at the -512 GB offset and the EFI region.

 - Re-shuffle the size desciptions to be continous blocks of sizes, instead of the
   often mixed size. I.e. write "0.5 TB" instead of "512 GB" if we are still in
   the TB-granular region of the map.

 - Make the 47-bit and 56-bit descriptions use the *exact* same layout and wording,
   and only differ where there's a material difference. This makes it easy to compare
   the two tables side by side by switching between two terminal tabs.

 - Plus enhance a lot of other stylistic/typographical details: make the tables
   explicitly tabular, add headers, enhance certain entries, etc. etc.

Note that there are some apparent errors in the tables as well, but I'll fix
them in a separate patch to make it easier to review/validate.

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: corbet@lwn.net
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: thgarnie@google.com
Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
parent 5b129040
====================================================
Complete virtual memory map with 4-level page tables
====================================================
Virtual memory map with 4 level page tables: Notes:
0000000000000000 - 00007fffffffffff (=47 bits, 128 TB) user space, different per mm - Negative addresses such as "-23 TB" are absolute addresses in bytes, counted down
hole caused by [47:63] sign extension from the top of the 64-bit address space. It's easier to understand the layout
ffff800000000000 - ffff87ffffffffff (=43 bits, 8 TB) guard hole, reserved for hypervisor when seen both in absolute addresses and in distance-from-top notation.
ffff880000000000 - ffffc7ffffffffff (=46 bits, 64 TB) direct mapping of all phys. memory (page_offset_base)
ffffc80000000000 - ffffc8ffffffffff (=40 bits, 1 TB) unused hole For example 0xffffe90000000000 == -23 TB, it's 23 TB lower than the top of the
ffffc90000000000 - ffffe8ffffffffff (=45 bits, 32 TB) vmalloc/ioremap space (vmalloc_base) 64-bit address space (ffffffffffffffff).
ffffe90000000000 - ffffe9ffffffffff (=40 bits, 1 TB) unused hole
ffffea0000000000 - ffffeaffffffffff (=40 bits, 1 TB) virtual memory map (vmemmap_base) Note that as we get closer to the top of the address space, the notation changes
ffffeb0000000000 - ffffebffffffffff (=40 bits, 1 TB) unused hole from TB to GB and then MB/KB.
ffffec0000000000 - fffffbffffffffff (=44 bits, 16 TB) kasan shadow memory
fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole - "16M TB" might look weird at first sight, but it's an easier to visualize size
vaddr_end for KASLR notation than "16 EB", which few will recognize at first sight as 16 exabytes.
fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping It also shows it nicely how incredibly large 64-bit address space is.
fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) LDT remap for PTI
ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks ========================================================================================================================
ffffff8000000000 - fffffffeefffffff (~39 bits, ~507 GB) unused hole Start addr | Offset | End addr | Size | VM area description
ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space ========================================================================================================================
ffffffff00000000 - ffffffff7fffffff (=31 bits, 2 GB) unused hole | | | |
ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB) kernel text mapping, from phys 0 0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm
ffffffffa0000000 - fffffffffeffffff (~31 bits, 1520 MB) module mapping space __________________|____________|__________________|_________|___________________________________________________________
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range | | | |
ffffffffff600000 - ffffffffff600fff ( =4 kB) legacy vsyscall ABI 0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
ffffffffffe00000 - ffffffffffffffff ( =2 MB) unused hole | | | | virtual memory addresses up to the -128 TB
| | | | starting offset of kernel mappings.
Virtual memory map with 5 level page tables: __________________|____________|__________________|_________|___________________________________________________________
|
0000000000000000 - 00ffffffffffffff (=56 bits, 64 PB) user space, different per mm | Kernel-space virtual memory, shared between all processes:
hole caused by [56:63] sign extension ____________________________________________________________|___________________________________________________________
ff00000000000000 - ff0fffffffffffff (=52 bits, 4 PB) guard hole, reserved for hypervisor | | | |
ff10000000000000 - ff8fffffffffffff (=55 bits, 32 PB) direct mapping of all phys. memory (page_offset_base) ffff800000000000 | -128 TB | ffff87ffffffffff | 8 TB | ... guard hole, also reserved for hypervisor
ff90000000000000 - ff9fffffffffffff (=52 bits, 4 PB) LDT remap for PTI ffff880000000000 | -120 TB | ffffc7ffffffffff | 64 TB | direct mapping of all physical memory (page_offset_base)
ffa0000000000000 - ffd1ffffffffffff (=53 bits, 12800 TB) vmalloc/ioremap space (vmalloc_base) ffffc80000000000 | -56 TB | ffffc8ffffffffff | 1 TB | ... unused hole
ffd2000000000000 - ffd3ffffffffffff (=49 bits, 512 TB) unused hole ffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base)
ffd4000000000000 - ffd5ffffffffffff (=49 bits, 512 TB) virtual memory map (vmemmap_base) ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
ffd6000000000000 - ffdeffffffffffff (~51 bits, 2304 TB) unused hole ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
ffdf000000000000 - fffffdffffffffff (~53 bits, ~8 PB) kasan shadow memory ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
fffffc0000000000 - fffffdffffffffff (=41 bits, 2 TB) unused hole ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
vaddr_end for KASLR fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
fffffe0000000000 - fffffe7fffffffff (=39 bits, 512 GB) cpu_entry_area mapping | | | | vaddr_end for KASLR
fffffe8000000000 - fffffeffffffffff (=39 bits, 512 GB) unused hole fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
ffffff0000000000 - ffffff7fffffffff (=39 bits, 512 GB) %esp fixup stacks fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | LDT remap for PTI
ffffff8000000000 - ffffffeeffffffff (~39 bits, 444 GB) unused hole ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
ffffffef00000000 - fffffffeffffffff (=36 bits, 64 GB) EFI region mapping space __________________|____________|__________________|_________|____________________________________________________________
ffffffff00000000 - ffffffff7fffffff (31 bits, 2 GB) unused hole |
ffffffff80000000 - ffffffff9fffffff (=29 bits, 512 MB) kernel text mapping, from phys 0 | Identical layout to the 47-bit one from here on:
ffffffffa0000000 - fffffffffeffffff (~31 bits, 1520 MB) module mapping space ____________________________________________________________|____________________________________________________________
[fixmap start] - ffffffffff5fffff kernel-internal fixmap range | | | |
ffffffffff600000 - ffffffffff600fff ( =4 kB) legacy vsyscall ABI ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
ffffffffffe00000 - ffffffffffffffff ( =2 MB) unused hole ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
ffffffff80000000 |-2048 MB | | |
ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
ffffffffff000000 | -16 MB | | |
FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
__________________|____________|__________________|_________|___________________________________________________________
====================================================
Complete virtual memory map with 5-level page tables
====================================================
Notes:
- With 56-bit addresses, user-space memory gets expanded by a factor of 512x,
from 0.125 PB to 64 PB. All kernel mappings shift down to the -64 PT starting
offset and many of the regions expand to support the much larger physical
memory supported.
========================================================================================================================
Start addr | Offset | End addr | Size | VM area description
========================================================================================================================
| | | |
0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm
__________________|____________|__________________|_________|___________________________________________________________
| | | |
0000800000000000 | +64 PB | ffff7fffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical
| | | | virtual memory addresses up to the -128 TB
| | | | starting offset of kernel mappings.
__________________|____________|__________________|_________|___________________________________________________________
|
| Kernel-space virtual memory, shared between all processes:
____________________________________________________________|___________________________________________________________
| | | |
ff00000000000000 | -64 PB | ff0fffffffffffff | 4 PB | ... guard hole, also reserved for hypervisor
ff10000000000000 | -60 PB | ff8fffffffffffff | 32 PB | direct mapping of all physical memory (page_offset_base)
ff90000000000000 | -28 PB | ff9fffffffffffff | 4 PB | LDT remap for PTI
ffa0000000000000 | -24 PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base)
ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
ffdf000000000000 | -8.25 PB | fffffdffffffffff | ~8 PB | KASAN shadow memory
fffffc0000000000 | -4 TB | fffffdffffffffff | 2 TB | ... unused hole
| | | | vaddr_end for KASLR
fffffe0000000000 | -2 TB | fffffe7fffffffff | 0.5 TB | cpu_entry_area mapping
fffffe8000000000 | -1.5 TB | fffffeffffffffff | 0.5 TB | ... unused hole
ffffff0000000000 | -1 TB | ffffff7fffffffff | 0.5 TB | %esp fixup stacks
__________________|____________|__________________|_________|____________________________________________________________
|
| Identical layout to the 47-bit one from here on:
____________________________________________________________|____________________________________________________________
| | | |
ffffff8000000000 | -512 GB | ffffffeeffffffff | 444 GB | ... unused hole
ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | ... unused hole
ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physical address 0
ffffffff80000000 |-2048 MB | | |
ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
ffffffffff000000 | -16 MB | | |
FIXADDR_START | ~-11 MB | ffffffffff5fffff | ~0.5 MB | kernel-internal fixmap range, variable size and offset
ffffffffff600000 | -10 MB | ffffffffff600fff | 4 kB | legacy vsyscall ABI
ffffffffffe00000 | -2 MB | ffffffffffffffff | 2 MB | ... unused hole
__________________|____________|__________________|_________|___________________________________________________________
Architecture defines a 64-bit virtual address. Implementations can support Architecture defines a 64-bit virtual address. Implementations can support
less. Currently supported are 48- and 57-bit virtual addresses. Bits 63 less. Currently supported are 48- and 57-bit virtual addresses. Bits 63
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment