From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Matt Fleming <matt@console-pimps.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>, Zhang Rui <rui.zhang@intel.com>,
Huang Ying <huang.ying.caritas@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] x86, efi: Calling __pa() with an ioremap'd address is invalid
Date: Mon, 7 Nov 2011 20:23:24 +0000 [thread overview]
Message-ID: <20111107202324.GA27515@srcf.ucam.org> (raw)
In-Reply-To: <1320680088-2584-1-git-send-email-matt@console-pimps.org>
On Mon, Nov 07, 2011 at 03:34:48PM +0000, Matt Fleming wrote:
> After the feedback from v1 I tried to unify the efi_ioremap()
> implementations but ran into the issue detailed in the RH bug report
> in the changelog. Unless we teach the x86 setup code that
> EFI_RUNTIME_SERVICES_DATA regions should be part of the direct kernel
> mapping table (even though they're marked as E820_RESERVED) I think
> this patch makes the most sense.
Honestly it seems like there may well be an argument for that. We're
talking about executable code that the kernel will be calling - it seems
theoretically neater for it to be added to the direct mapping. We're
just heavily constrained by our collapsing of the EFI memory map onto
the rather less fine-grained E820 one and the lack of any obvious way to
extend that in an OS-specific manner. I guess we could expect the
bootloader to conform to the standard and then re-walk the EFI memory
map ourselves to fix things up, but eww...
--
Matthew Garrett | mjg59@srcf.ucam.org
next parent reply other threads:[~2011-11-07 20:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1320680088-2584-1-git-send-email-matt@console-pimps.org>
2011-11-07 20:23 ` Matthew Garrett [this message]
2011-11-07 20:36 ` [PATCH v3] x86, efi: Calling __pa() with an ioremap'd address is invalid H. Peter Anvin
2011-11-07 20:37 ` Matthew Garrett
2011-11-07 20:45 ` H. Peter Anvin
2011-11-07 20:48 ` Matthew Garrett
2011-11-07 20:57 ` H. Peter Anvin
2011-11-07 20:58 ` Matthew Garrett
2011-11-07 21:01 ` H. Peter Anvin
2011-11-07 21:07 ` Matthew Garrett
2011-11-07 21:20 ` H. Peter Anvin
2011-11-07 21:23 ` Matthew Garrett
2011-11-07 21:34 ` H. Peter Anvin
2011-11-07 21:36 ` Matthew Garrett
2011-11-07 22:43 ` Alan Cox
2011-11-11 1:02 ` huang ying
2011-11-11 13:12 ` Matt Fleming
2011-11-11 13:49 ` Matt Fleming
2011-11-07 15:46 Matt Fleming
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=20111107202324.GA27515@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=hpa@zytor.com \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=mingo@elte.hu \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.