From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: huang ying <huang.ying.caritas@gmail.com>,
Takao Indoh <indou.takao@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
tglx@linutronix.de, mingo@redhat.com, vgoyal@redhat.com,
nhorman@tuxdriver.com
Subject: Re: [PATCH][EFI] Run EFI in physical mode
Date: Mon, 16 Aug 2010 16:54:44 -0700 [thread overview]
Message-ID: <4C69CFC4.8020307@zytor.com> (raw)
In-Reply-To: <m1ocd2i0u0.fsf@fess.ebiederm.org>
On 08/16/2010 04:39 PM, Eric W. Biederman wrote:
>
> "H. Peter Anvin" <hpa@zytor.com> writes:
>> "huang ying" <huang.ying.caritas@gmail.com> wrote:
>>
>>> On Mon, Aug 16, 2010 at 11:27 AM, H. Peter Anvin <hpa@zytor.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.
>
Absolutely!
>>> 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.
Quite, which is yet another reason to have a common global page table
for all the 1:1 users... right now this is all ad hoc.
-hpa
prev parent reply other threads:[~2010-08-16 23:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-13 19:18 [PATCH][EFI] Run EFI in physical mode Takao Indoh
2010-08-13 22:19 ` Eric W. Biederman
2010-08-16 19:30 ` Takao Indoh
2010-08-13 22:24 ` H. Peter Anvin
2010-08-13 22:33 ` Luck, Tony
2010-08-13 23:11 ` Eric W. Biederman
2010-08-13 23:16 ` H. Peter Anvin
2010-08-13 23:36 ` Tony Luck
2010-08-16 1:31 ` Simon Horman
2010-08-13 22:28 ` H. Peter Anvin
2010-08-16 1:43 ` huang ying
2010-08-16 3:27 ` H. Peter Anvin
2010-08-16 4:58 ` huang ying
2010-08-16 5:08 ` H. Peter Anvin
2010-08-16 23:39 ` Eric W. Biederman
2010-08-16 23:54 ` H. Peter Anvin [this message]
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=4C69CFC4.8020307@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=huang.ying.caritas@gmail.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nhorman@tuxdriver.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox