[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMzpN2haQjckBGkA1ujaCD0iehAsC2S-xO7eN89S+u+FQ65zXw@mail.gmail.com>
Date: Fri, 2 Dec 2011 19:58:12 -0500
From: Brian Gerst <brgerst@...il.com>
To: zhihua che <zhihua.che@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [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?
On Fri, Dec 2, 2011 at 11:35 AM, zhihua che <zhihua.che@...il.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists