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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.