linux-kernel - Re: x86_64 virtual memory map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1r5n7ln0l.fsf@fess.ebiederm.org>
Date:	Thu, 25 Mar 2010 21:34:02 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	hayfeng Lee <omycle@...il.com>
Cc:	linux-kernel@...r.kernel.org, ak@...ux.intel.com
Subject: Re: x86_64 virtual memory map

hayfeng Lee <omycle@...il.com> writes:

> Hi,folks.
> Recently I'm studying some things of x86_64 on Linux. And the virsion
> is 2.6.18.8. From the document of Documentation/x86_64/mm.txt,I found
> the mapping method for x86_64 virtual memory map. I want to know ,why
> use this method for virtual memory mapping?
>
> -----------------------------------------------------------------------------------------------
>   1
>   2 <previous description obsolete, deleted>
>   3
>   4 Virtual memory map with 4 level page tables:
>   5
>   6 0000000000000000 - 00007fffffffffff (=47bits) user space, different per mm
>   7 hole caused by [48:63] sign extension
>   8 ffff800000000000 - ffff80ffffffffff (=40bits) guard hole
>   9 ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of
> all phys. memory
>  10 ffffc10000000000 - ffffc1ffffffffff (=40bits) hole
>  11 ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space
>  12 ... unused hole ...
>  13 ffffffff80000000 - ffffffff82800000 (=40MB)   kernel text mapping,
> from phys 0
>  14 ... unused hole ...
>  15 ffffffff88000000 - fffffffffff00000 (=1919MB) module mapping space
>  16
>  17 The direct mapping covers all memory in the system upto the highest
>  18 memory address (this means in some cases it can also include PCI memory
>  19 holes)
>  20
>  21 vmalloc space is lazily synchronized into the different PML4 pages of
>  22 the processes using the page fault handler, with init_level4_pgt as
>  23 reference.
>  24
>  25 Current X86-64 implementations only support 40 bit of address space,
>  26 but we support upto 46bits. This expands into MBZ space in the page tables.
>  27
>  28 -Andi Kleen, Jul 2004
>
> I urgently want to know the answer.

We can't give you the answer unless you give us the question, and enough
context that the question makes sense.  I recommend looking up the AMD and
possibly the intel architecture documents on x86_64.  They very completely
cover what the processors can do and are freely available online.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/