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 <[email protected]>
---
arch/x86/Kconfig | 10 ++++++++++
arch/x86/include/asm/e820.h | 5 +++++
arch/x86/kernel/e820.c | 2 +-
3 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dcb0593..5af1da6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1468,6 +1468,16 @@ config EFI
resultant kernel should continue to boot on existing non-EFI
platforms.
+config ALLOW_EMPTY_E820
+ bool "Allow empty e820 memory maps"
+ default y
+ depends on EFI && (X86_64 || X86_32)
+ ---help---
+ Enable this if you are using EFI memory maps instead of e820.
+ The EFI memory maps are scanned much later than the e820 maps, and
+ without this option the e280 setup code will automatically add
+ some default mappings that may conflict with the real EFI maps.
+
config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h
index ec8a52d..cbe22f9 100644
--- a/arch/x86/include/asm/e820.h
+++ b/arch/x86/include/asm/e820.h
@@ -134,6 +134,11 @@ extern void e820_reserve_resources(void);
extern void e820_reserve_resources_late(void);
extern void setup_memory_map(void);
extern char *default_machine_specific_memory_setup(void);
+#ifdef CONFIG_ALLOW_EMPTY_E820
+static inline int no_e820_map_return(void) { return 0; }
+#else
+static inline int no_e820_map_return(void) { return -1; }
+#endif
/*
* Returns true iff the specified range [s,e) is completely contained inside
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7bca3c6..b7db15c 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -416,7 +416,7 @@ static int __init append_e820_map(struct e820entry *biosmap, int nr_map)
{
/* Only one memory region (or negative)? Ignore it */
if (nr_map < 2)
- return -1;
+ return no_e820_map_return();
return __append_e820_map(biosmap, nr_map);
}
--
1.7.0.1
--
Art for Art's Sake
Engineering for Money
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<[email protected]>
On Wed, Jun 2, 2010 at 9:14 AM, H. Peter Anvin <[email protected]> wrote:
>
> No! ?Bloody **** hell no!
Heh. Well, that answers that.
> 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.
Ah. With that hint, I've now found some of the original discussion.
Sorry I missed it before. Having dealt with EFI for some weeks now, I
can't say I find your reaction overstated.
Thanks for the quick response.
Bill