mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-22 20:23:57 +08:00
57d307720c
Fix typos. Lots of whitespace changes for readability and consistency. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andi Kleen <ak@suse.de>
29 lines
1.1 KiB
Plaintext
29 lines
1.1 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 [48:63] sign extension
|
|
ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole
|
|
ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory
|
|
ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole
|
|
ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space
|
|
... unused hole ...
|
|
ffffffff80000000 - ffffffff82800000 (=40 MB) kernel text mapping, from phys 0
|
|
... unused hole ...
|
|
ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space
|
|
|
|
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 pages of
|
|
the processes using the page fault handler, with init_level4_pgt as
|
|
reference.
|
|
|
|
Current X86-64 implementations only support 40 bits of address space,
|
|
but we support up to 46 bits. This expands into MBZ space in the page tables.
|
|
|
|
-Andi Kleen, Jul 2004
|