[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BFC5650.7090104@sgi.com>
Date: Tue, 25 May 2010 15:59:28 -0700
From: Mike Travis <travis@....com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: Yinghai <yinghai.lu@...cle.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
Suresh Siddha <suresh.b.siddha@...el.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Jens Axboe <jens.axboe@...cle.com>,
Jack Steiner <steiner@....com>,
LKML <linux-kernel@...r.kernel.org>, jkosina@...ell.com
Subject: Re: [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi_memmap
specified v2
Currently, the e820_reserve_resources() function does not add entries
obtained via the "add_efi_memmap" kernel cmdline option. This causes
/sys/firmware/memmap/... to be incomplete (stops after 128 entries).
Utilities that examine these entries then do not get the complete
picture of system memory.
This patch causes the add_efi_memmap function to add the memmap entries
to both the e820 map and the e820_saved map.
Signed-off-by: Mike Travis <travis@....com>
Signed-off-by: Jack Steiner <steiner@....com>
---
v2: drop call to sanitize e820_saved map after adding efi_memmap
entries. (Note: it may still be "sanitized" via setup_arch->
early_reserve_e820_mpc_new-> early_reserve_e820->update_e820_saved->
sanitize_e820_map)
---
arch/x86/include/asm/e820.h | 1 +
arch/x86/kernel/e820-xen.c | 5 +++++
arch/x86/kernel/e820.c | 11 ++++++++---
arch/x86/kernel/efi.c | 1 +
4 files changed, 15 insertions(+), 3 deletions(-)
--- linux-2.6.32.orig/arch/x86/include/asm/e820.h
+++ linux-2.6.32/arch/x86/include/asm/e820.h
@@ -70,6 +70,7 @@ extern unsigned long pci_mem_start;
extern int e820_any_mapped(u64 start, u64 end, unsigned type);
extern int e820_all_mapped(u64 start, u64 end, unsigned type);
extern void e820_add_region(u64 start, u64 size, int type);
+extern void e820_saved_add_region(u64 start, u64 size, int type);
extern void e820_print_map(char *who);
extern int
sanitize_e820_map(struct e820entry *biosmap, int max_nr_map, u32 *pnr_map);
--- linux-2.6.32.orig/arch/x86/kernel/e820-xen.c
+++ linux-2.6.32/arch/x86/kernel/e820-xen.c
@@ -150,6 +150,11 @@ void __init e820_add_region(u64 start, u
__e820_add_region(&e820, start, size, type);
}
+void __init e820_saved_add_region(u64 start, u64 size, int type)
+{
+ __e820_add_region(&e820_saved, start, size, type);
+}
+
static void __init e820_print_type(u32 type)
{
switch (type) {
--- linux-2.6.32.orig/arch/x86/kernel/e820.c
+++ linux-2.6.32/arch/x86/kernel/e820.c
@@ -33,9 +33,9 @@
* and that is also registered with modifications in the kernel resource tree
* with the iomem_resource as parent.
*
- * The e820_saved is directly saved after the BIOS-provided memory map is
- * copied. It doesn't get modified afterwards. It's registered for the
- * /sys/firmware/memmap interface.
+ * The e820_saved is saved after the BIOS-provided memory map is copied as
+ * well as the optional add_efi_memmap entries are processed. It doesn't get
+ * modified afterwards. It's registered for the /sys/firmware/memmap interface.
*
* That memory map is not modified and is used as base for kexec. The kexec'd
* kernel should get the same memory map as the firmware provides. Then the
@@ -132,6 +132,11 @@ void __init e820_add_region(u64 start, u
__e820_add_region(&e820, start, size, type);
}
+void __init e820_saved_add_region(u64 start, u64 size, int type)
+{
+ __e820_add_region(&e820_saved, start, size, type);
+}
+
static void __init e820_print_type(u32 type)
{
switch (type) {
--- linux-2.6.32.orig/arch/x86/kernel/efi.c
+++ linux-2.6.32/arch/x86/kernel/efi.c
@@ -271,6 +271,7 @@ static void __init do_add_efi_memmap(voi
break;
}
e820_add_region(start, size, e820_type);
+ e820_saved_add_region(start, size, e820_type);
}
sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists