From: "H. Peter Anvin" <hpa@zytor.com>
To: Bill Richardson <wfrichar@chromium.org>
Cc: tglx@linutronix.de, mingo@redhat.com, x86@kernel.org,
akpm@linux-foundation.org, fweisbec@gmail.com,
yinghai@kernel.org, pavel@ucw.cz, shane.wang@intel.com,
linux-kernel@vger.kernel.org, olofj@chromium.org,
msb@chromium.org, drewry@chromium.org
Subject: Re: [RFC] [PATCH] Allow empty e820 map if EFI map will be provided later.
Date: Wed, 02 Jun 2010 18:14:13 +0200 [thread overview]
Message-ID: <4C068355.9070000@zytor.com> (raw)
In-Reply-To: <20100602151602.GA3656@google.com>
No! Bloody **** hell no!
This is yet another attempt at doing more of the wrong thing, which not
only will make it harder to push things that should be earlier in the
kernel there.
This was settled in 2007 -- it is the boot loaders duty to provide a
memory map. The fact that we allowed a hack in to let the kernel itself
add additional ranges from EFI has proven to be an utter mistake, and
this is yet another example of it.
Vetoed in the extreme.
-hpa
On 06/02/2010 05:16 PM, Bill Richardson wrote:
> If you are booting an x86-based system from an EFI BIOS that does not
> provide any e820-style memory maps, setup_arch() calls functions that expect
> to find the e820 maps long before it calls functions to find the EFI maps.
> The default behavior in arch/x86/kernel/e820.c is that if no e820 map
> exists, default_machine_specific_memory_setup() adds two default regions
> just in case. Later, when you get around to using the EFI maps, these
> default regions interfere with the real memory map.
>
> This patch provides a config option that allows the lack of e820 maps to be
> ignored, under the assumption that you know what you're doing and will
> provide a valid EFI memory map to use.
>
> The reason this problem has not arisen before now is that under most
> circumstances either the EFI BIOS' Compatibility Support Module provides an
> e820-style memory map in the first place, or the EFI-aware bootloader
> (grub2, elilo) translates the EFI map to the e280 format before booting the
> kernel.
>
> I'm trying to reduce the boot time and BIOS footprint, so I'm booting
> without either of those pre-boot map translations. This patch allows that to
> happen.
>
> Signed-off-by: Bill Richardson<wfrichar@chromium.org>
next prev parent reply other threads:[~2010-06-02 16:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 15:16 [RFC] [PATCH] Allow empty e820 map if EFI map will be provided later Bill Richardson
2010-06-02 16:14 ` H. Peter Anvin [this message]
2010-06-02 16:24 ` Bill Richardson
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=4C068355.9070000@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=drewry@chromium.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=msb@chromium.org \
--cc=olofj@chromium.org \
--cc=pavel@ucw.cz \
--cc=shane.wang@intel.com \
--cc=tglx@linutronix.de \
--cc=wfrichar@chromium.org \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/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