From: Ingo Molnar <mingo@elte.hu>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] x86: fix some bugs about EFI runtime code mapping
Date: Fri, 25 Jan 2008 10:48:24 +0100 [thread overview]
Message-ID: <20080125094824.GH23708@elte.hu> (raw)
In-Reply-To: <1201253177.15972.57.camel@caritas-dev.intel.com>
* Huang, Ying <ying.huang@intel.com> wrote:
> On Fri, 2008-01-25 at 10:16 +0100, Ingo Molnar wrote:
> > * Huang, Ying <ying.huang@intel.com> wrote:
> >
> > > This patch fixes some bugs of making EFI runtime code executable.
> > >
> > > - Use change_page_attr in i386 too. Because the runtime code may be
> > > mapped not through ioremap.
> > >
> > > - If there is no _PAGE_NX in __supported_pte_mask, the change_page_attr
> > > is not called.
> > >
> > > - Make efi_ioremap map pages as PAGE_KERNEL_EXEC, because EFI runtime
> > > code may be mapped through efi_ioremap.
> >
> > thanks, applied.
> >
> > note that here:
> >
> > > - set_fixmap_nocache(FIX_EFI_IO_MAP_FIRST_PAGE - pages_mapped,
> > > - offset);
> > > + __set_fixmap(FIX_EFI_IO_MAP_FIRST_PAGE - pages_mapped,
> > > + offset, PAGE_KERNEL_EXEC);
> >
> > you've changed it from nocache-noexec to cached-exec. I suspect
> > that's what we want - except if an early EFI area can be
> > non-prefetchable device memory. Can that ever happen? Would you like
> > to have PAGE_KERNEL_NOCACHE_EXEC perhaps? I implemented that
> > yesterday but did not commit it yet. (see the patch below)
>
> Yes. EFI area can be non-prefetchable device memory. I should use
> PAGE_KERNEL_NOCACHE_EXEC.
ok, i fixed that in the patch and reordered the PAGE_KERNEL_NOCACHE_EXEC
patch to come before yours.
> A question about this:
>
> The MTRR on x86 should have set the memory area as un-cachable. Why do
> we bother to set it in page table?
you are right in that there is no immediate correctness reason for it.
The reason is to eventually get away from any MTRR dependencies. If some
other OS uses PATs and the BIOS sets up the wrong MTRR, then the other
OS might still having a working EFI, while Linux might crash and burn.
So we try to get both the MTRRs and the pagetable attributes match the
purpose of the area in question. If _both_ levels of attributes agree it
cannot hurt, but if one of them is wrong, the other one still saves the
day.
that's why we changed all ioremaps to default to cache-disabled (PCD) in
latest x86.git as well. For years the x86 architecture set the ioremap
pagetable entries to cacheable by default and only the MTRRs (and the
BIOS writers) saved us from trouble. Now we try to be a bit more
defensive and avoid "BIOS bug causes only Linux to crash and burn while
other OSs work fine" type of scenarios.
Ingo
prev parent reply other threads:[~2008-01-25 9:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-25 5:55 [PATCH 4/6] x86: fix some bugs about EFI runtime code mapping Huang, Ying
2008-01-25 7:35 ` Jeremy Fitzhardinge
2008-01-25 9:19 ` Ingo Molnar
2008-01-25 9:30 ` Huang, Ying
2008-01-25 9:16 ` Ingo Molnar
2008-01-25 9:26 ` Huang, Ying
2008-01-25 9:48 ` Ingo Molnar [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=20080125094824.GH23708@elte.hu \
--to=mingo@elte.hu \
--cc=ak@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=ying.huang@intel.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