lkml.org 
[lkml]   [2011]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Provisional Page Table] Why the linear address ranges starting both from 0 and PAGE_OFFSET are mapped to the same physical address range in the provisional page table?
From
On Fri, Dec 2, 2011 at 11:35 AM, zhihua che <zhihua.che@gmail.com> wrote:
> Hi, everyone
>        I know that the kernel constructs a provisional page table in
> head_32.S which maps the linear address ranges starting both from 0
> and PAGE_OFFSET to the same physical address range.  My question is
> why the linear address range starting from 0 needs to be mapped to the
> same physical address range as the leaner address range starting from
> PAGE_OFFSET does. I thought it's not necessary because the whole
> kernel (the protected mode part) is linked to the VMA PAGE_OFFSET.
>        But I found I was wrong. I'm writing a toy os which is also
> linked to VMA PAGE_OFFSET and constructs a provisional page table as
> the linux kernel does, and it works well with it. I mean it can enable
> paging successfully and continue to execute as I expect after that
> far-jump instruction. However, if I mapped only the linear address
> starting from 0xc0000000, the far-jump instructions would load random
> values to cs and eip respectfully and my os went crazy.

The identity mapping is required for the brief period between when
paging is enabled and the jump to the virtual address. Once paging is
enabled, eip still points to the low address for the next instruction,
and the instruction fetch will cause a page fault if the identity
mapping doesn't exist.

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

\
 
 \ /
  Last update: 2011-12-03 02:01    [W:0.518 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site