[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1ocd2i0u0.fsf@fess.ebiederm.org>
Date: Mon, 16 Aug 2010 16:39:51 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@...or.com>
Cc: huang ying <huang.ying.caritas@...il.com>,
Takao Indoh <indou.takao@...fujitsu.com>,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
tglx@...utronix.de, mingo@...hat.com, vgoyal@...hat.com,
nhorman@...driver.com
Subject: Re: [PATCH][EFI] Run EFI in physical mode
"H. Peter Anvin" <hpa@...or.com> writes:
> "huang ying" <huang.ying.caritas@...il.com> wrote:
>
>>On Mon, Aug 16, 2010 at 11:27 AM, H. Peter Anvin <hpa@...or.com> wrote:
>>> No, it should not be dynamic; rather we should unify all the users
>>> who need a 1:1 map and just keep that page table set around.
We still want to restore cr3 from the local task structure as soon
as is reasonable, as an identity mapped page table will have page 0
mapped and thus hide null pointer dereferences.
>>Agree. One known issue of global 1:1 map is that we need to make at
>>least part of page table PAGE_KERNEL_EXEC for EFI runtime code, and
>>change_page_attr can not be used before page allocator is available.
> For the 1:1 map we probably should make all pages executable; other
> things need it too, but we shouldn't have it mapped in except when
> needed.
We need to be careful in the setup of the global page table so that
we are in sync with the pat structure for the attributes pages
are mapped so that we don't map a page as cached and uncached
at the same time. Otherwise we could accidentally get cache
corruption. To do that would seem to mean change_page_attr
is relevant at least after we switch from our default set of
page permissions.
Eric
--
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