virtio: fix trivial build bug
[wrt350n-kernel.git] / Documentation / x86_64 / mm.txt
blobb89b6d2bebfa7b355aeffacc5c7e60e91eb54a86
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 - ffff80ffffffffff (=40 bits) guard hole
9 ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory
10 ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole
11 ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space
12 ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB)
13 ... unused hole ...
14 ffffffff80000000 - ffffffff82800000 (=40 MB)   kernel text mapping, from phys 0
15 ... unused hole ...
16 ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space
18 The direct mapping covers all memory in the system up to the highest
19 memory address (this means in some cases it can also include PCI memory
20 holes).
22 vmalloc space is lazily synchronized into the different PML4 pages of
23 the processes using the page fault handler, with init_level4_pgt as
24 reference.
26 Current X86-64 implementations only support 40 bits of address space,
27 but we support up to 46 bits. This expands into MBZ space in the page tables.
29 -Andi Kleen, Jul 2004