From: ebiederm@xmission.com (Eric W. Biederman)
To: hayfeng Lee <omycle@gmail.com>
Cc: linux-kernel@vger.kernel.org, ak@linux.intel.com
Subject: Re: x86_64 virtual memory map
Date: Thu, 25 Mar 2010 21:34:02 -0700 [thread overview]
Message-ID: <m1r5n7ln0l.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <5f6c52c61003241920i6b3eaaf7k946f67d1a6f9e384@mail.gmail.com> (hayfeng Lee's message of "Thu\, 25 Mar 2010 10\:20\:27 +0800")
hayfeng Lee <omycle@gmail.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
next prev parent reply other threads:[~2010-03-26 4:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-25 2:20 x86_64 virtual memory map hayfeng Lee
2010-03-26 4:34 ` Eric W. Biederman [this message]
2011-07-25 10:13 ` Bob Zhang
2011-07-25 10:17 ` Bob Zhang
2011-07-25 10:33 ` Eric W. Biederman
2011-07-26 8:43 ` Bob Zhang
2011-07-26 19:26 ` Valdis.Kletnieks
2011-07-26 19:49 ` Andi Kleen
2011-07-27 7:13 ` Bob Zhang
2011-07-27 15:38 ` Andi Kleen
2011-08-19 15:13 ` Bob Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1r5n7ln0l.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=ak@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=omycle@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox