From: joe Shmoe <jsmoe3@yahoo.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE
Date: Fri, 28 Aug 2009 13:23:23 -0700 (PDT) [thread overview]
Message-ID: <205.26101.qm@web45216.mail.sp1.yahoo.com> (raw)
In-Reply-To: <20090828205337.3677cf04@lxorguk.ukuu.org.uk>
>That however means reloading %cr3 (page table base) which is very
>expensive, and some very hard to implement locking on user space access
I understand the implications of reloading CR3. But once the page tables are setup to map all the available physical RAM to virtual (linear) address it could be for eg. 1, 2, 3 or 4 GB how does it matter.
Now If a process wants to access a memory location which is above 1GB , since kernel already setup the page tables CPU MMU will do the translation since it consults this page table setup by kernel. Of course it also makes sure the page table has appropriate privilege level for access.
Am I missing something here?
--- On Fri, 8/28/09, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE
> To: "joe Shmoe" <jsmoe3@yahoo.com>
> Cc: Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org
> Date: Friday, August 28, 2009, 3:53 PM
> On Fri, 28 Aug 2009 12:44:25 -0700
> (PDT)
> joe Shmoe <jsmoe3@yahoo.com>
> wrote:
>
> > No I am not talking about embedded systems. It is just
> an example.
> > My question is what is preventing the kernel from
> setting up the page tables so that entire RAM can be mapped
> upto 4 GB.
>
> The design of the x86 processor
>
> You only have 4GB of virtual address space at any one time
> so you have to
> fit the following within your 4GB virtual space
>
> - Virtual addresses of the user space
> - Mappings for physical memory
> - Kernel virtual spaces (vmalloc etc)
> - Various miscellaneous kernel mappings
> - I/O MMIO space
>
> Now you could in theory switch the page tables on kernel
> entry to get a
> very big user space mapping and then instead of relying on
> the user space
> being mapped you could map specific user pages or access
> them via their
> physical address lookup.
>
> That however means reloading %cr3 (page table base) which
> is very
> expensive, and some very hard to implement locking on user
> space access.
>
> Some other processor families have the notion of "spaces"
> or MMU
> bypassing. The Sparc64 for example can access MMIO space
> without an MMU
> mapping or virtual address being needed for it. x86 does
> not - it has
> segments but the segments map into the 4GB space so they
> don't help here
> hence the current implementation and 3G/1G split.
>
next prev parent reply other threads:[~2009-08-28 20:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-28 18:08 kernel page table mapping for >1GB <3 GB for x86 arch without PAE joe Shmoe
2009-08-28 18:12 ` Roland Dreier
2009-08-28 18:40 ` joe Shmoe
2009-08-28 19:13 ` Valdis.Kletnieks
2009-08-28 19:44 ` joe Shmoe
2009-08-28 19:53 ` Alan Cox
2009-08-28 20:23 ` joe Shmoe [this message]
2009-08-28 22:16 ` Alan Cox
2009-08-29 0:20 ` joe Shmoe
2009-08-29 13:05 ` Alan Cox
2009-08-29 14:40 ` joe Shmoe
2009-08-28 21:07 ` joe Shmoe
2009-08-28 22:11 ` Alan Cox
2009-08-28 19:49 ` Roland Dreier
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=205.26101.qm@web45216.mail.sp1.yahoo.com \
--to=jsmoe3@yahoo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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