|
@@ -1,6 +1,4 @@
|
|
|
|
|
|
-<previous description obsolete, deleted>
|
|
|
-
|
|
|
Virtual memory map with 4 level page tables:
|
|
|
|
|
|
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
|
|
@@ -49,8 +47,9 @@ 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.
|
|
|
+through to the most-significant implemented bit are sign extended.
|
|
|
+This causes hole between user space and kernel addresses if you interpret them
|
|
|
+as unsigned.
|
|
|
|
|
|
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
|
|
@@ -60,9 +59,6 @@ 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
|
|
@@ -74,5 +70,3 @@ 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
|