mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-22 17:33:01 +00:00
12a8cc7fcf
We are going to support boot-time switching between 4- and 5-level paging. For KASAN it means we cannot have different KASAN_SHADOW_OFFSET for different paging modes: the constant is passed to gcc to generate code and cannot be changed at runtime. This patch changes KASAN code to use 0xdffffc0000000000 as shadow offset for both 4- and 5-level paging. For 5-level paging it means that shadow memory region is not aligned to PGD boundary anymore and we have to handle unaligned parts of the region properly. In addition, we have to exclude paravirt code from KASAN instrumentation as we now use set_pgd() before KASAN is fully ready. [kirill.shutemov@linux.intel.com: clenaup, changelog message] Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@suse.de> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-4-kirill.shutemov@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
77 lines
3.6 KiB
Plaintext
77 lines
3.6 KiB
Plaintext
|
|
<previous description obsolete, deleted>
|
|
|
|
Virtual memory map with 4 level page tables:
|
|
|
|
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
|
|
hole caused by [47:63] sign extension
|
|
ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor
|
|
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
|
|
ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
|
|
ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
|
|
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
|
|
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
|
|
... unused hole ...
|
|
ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
|
|
... unused hole ...
|
|
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
|
|
... unused hole ...
|
|
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
|
|
... unused hole ...
|
|
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
|
|
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
|
|
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
|
|
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
|
|
|
Virtual memory map with 5 level page tables:
|
|
|
|
0000000000000000 - 00ffffffffffffff (=56 bits) user space, different per mm
|
|
hole caused by [56:63] sign extension
|
|
ff00000000000000 - ff0fffffffffffff (=52 bits) guard hole, reserved for hypervisor
|
|
ff10000000000000 - ff8fffffffffffff (=55 bits) direct mapping of all phys. memory
|
|
ff90000000000000 - ff91ffffffffffff (=49 bits) hole
|
|
ff92000000000000 - ffd1ffffffffffff (=54 bits) vmalloc/ioremap space
|
|
ffd2000000000000 - ffd3ffffffffffff (=49 bits) hole
|
|
ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB)
|
|
... unused hole ...
|
|
ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB)
|
|
... unused hole ...
|
|
ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
|
|
... unused hole ...
|
|
ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
|
|
... unused hole ...
|
|
ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0
|
|
ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
|
|
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
|
|
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
|
|
|
|
Architecture defines a 64-bit virtual address. Implementations can support
|
|
less. Currently supported are 48- and 57-bit virtual addresses. Bits 63
|
|
through to the most-significant implemented bit are set to either all ones
|
|
or all zero. This causes hole between user space and kernel addresses.
|
|
|
|
The direct mapping covers all memory in the system up to the highest
|
|
memory address (this means in some cases it can also include PCI memory
|
|
holes).
|
|
|
|
vmalloc space is lazily synchronized into the different PML4/PML5 pages of
|
|
the processes using the page fault handler, with init_top_pgt as
|
|
reference.
|
|
|
|
Current X86-64 implementations support up to 46 bits of address space (64 TB),
|
|
which is our current limit. This expands into MBZ space in the page tables.
|
|
|
|
We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual
|
|
memory window (this size is arbitrary, it can be raised later if needed).
|
|
The mappings are not part of any other kernel PGD and are only available
|
|
during EFI runtime calls.
|
|
|
|
The module mapping space size changes based on the CONFIG requirements for the
|
|
following fixmap section.
|
|
|
|
Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
|
|
physical memory, vmalloc/ioremap space and virtual memory map are randomized.
|
|
Their order is preserved but their base will be offset early at boot time.
|
|
|
|
-Andi Kleen, Jul 2004
|