[PATCH 1/10] x86 boot: include missing smp.h header

[PATCH 1/10] x86 boot: include missing smp.h header

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

The patch:
    x86: convert cpu_to_apicid to be a per cpu variable
introduced a dependency of ipi.h on smp.h in x86
builds with an allnoconfig.  Including smp.h in ipi.h
fixes the build error:
    In file included from arch/x86/kernel/traps_64.c:48:
    include/asm/ipi.h: In function 'send_IPI_mask_sequence':
    include/asm/ipi.h:114: error: 'per_cpu__x86_cpu_to_apicid' undeclared (first use in this function)

Signed-off-by: Paul Jackson <pj@sgi.com>
Cc: Mike Travis <travis@sgi.com>

---
 include/asm-x86/ipi.h |    1 +
 1 file changed, 1 insertion(+)

--- linux.orig/include/asm-x86/ipi.h	2008-05-13 10:44:39.000000000 -0700
+++ linux/include/asm-x86/ipi.h	2008-05-13 10:56:37.431506774 -0700
@@ -20,6 +20,7 @@
 
 #include <asm/hw_irq.h>
 #include <asm/apic.h>
+#include <asm/smp.h>
 
 /*
  * the following functions deal with sending IPIs between CPUs.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 2/10] x86 boot: remove some unused extern function declarations

[Paul Jackson]

From: Paul Jackson <pj@sgi.com

Remove three extern declarations for routines
that don't exist.  Fix a typo in a comment.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/mm/numa_64.c |    2 +-
 include/linux/efi.h   |    4 ----
 2 files changed, 1 insertion(+), 5 deletions(-)

--- 2.6.26-rc2-mm1.orig/include/linux/efi.h	2008-05-14 03:07:03.231239814 -0700
+++ 2.6.26-rc2-mm1/include/linux/efi.h	2008-05-14 03:07:07.039302049 -0700
@@ -287,7 +287,6 @@ efi_guid_unparse(efi_guid_t *guid, char 
 extern void efi_init (void);
 extern void *efi_get_pal_addr (void);
 extern void efi_map_pal_code (void);
-extern void efi_map_memmap(void);
 extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
 extern void efi_gettimeofday (struct timespec *ts);
 extern void efi_enter_virtual_mode (void);	/* switch EFI to virtual mode, if possible */
@@ -295,14 +294,11 @@ extern u64 efi_get_iobase (void);
 extern u32 efi_mem_type (unsigned long phys_addr);
 extern u64 efi_mem_attributes (unsigned long phys_addr);
 extern u64 efi_mem_attribute (unsigned long phys_addr, unsigned long size);
-extern int efi_mem_attribute_range (unsigned long phys_addr, unsigned long size,
-				    u64 attr);
 extern int __init efi_uart_console_only (void);
 extern void efi_initialize_iomem_resources(struct resource *code_resource,
 		struct resource *data_resource, struct resource *bss_resource);
 extern unsigned long efi_get_time(void);
 extern int efi_set_rtc_mmss(unsigned long nowtime);
-extern int is_available_memory(efi_memory_desc_t * md);
 extern struct efi_memory_map memmap;
 
 /**
--- 2.6.26-rc2-mm1.orig/arch/x86/mm/numa_64.c	2008-05-14 03:07:03.231239814 -0700
+++ 2.6.26-rc2-mm1/arch/x86/mm/numa_64.c	2008-05-14 03:07:07.047302180 -0700
@@ -231,7 +231,7 @@ void __init setup_node_bootmem(int nodei
 	else
 		bootmap_start = round_up(start, PAGE_SIZE);
 	/*
-	 * SMP_CAHCE_BYTES could be enough, but init_bootmem_node like
+	 * SMP_CACHE_BYTES could be enough, but init_bootmem_node like
 	 * to use that to align to PAGE_SIZE
 	 */
 	bootmap = early_node_mem(nodeid, bootmap_start, end,

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 3/10] x86 boot: add header comment to dmi.h stating what it is

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

The "dmi.h" file did not state anywhere in the file what "DMI" was.
For those who know, it's obvious.  For the rest of us, I added a
brief opening comment.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 drivers/firmware/dmi_scan.c |    5 +++++
 1 file changed, 5 insertions(+)

--- linux.orig/drivers/firmware/dmi_scan.c	2008-04-16 19:49:44.000000000 -0700
+++ linux/drivers/firmware/dmi_scan.c	2008-05-05 03:41:45.921911888 -0700
@@ -8,6 +8,11 @@
 #include <linux/slab.h>
 #include <asm/dmi.h>
 
+/*
+ * DMI stands for "Desktop Management Interface".  It is part
+ * of and an antecedent to, SMBIOS, which stands for System
+ * Management BIOS.  See further: http://www.dmtf.org/standards
+ */
 static char dmi_empty_string[] = "        ";
 
 static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 4/10] x86 boot: simplify pageblock_bits enum declaration

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

The use of #defines with '##' pre-processor concatenation is a useful
way to form several symbol names with a common pattern.  But when there
is just a single name obtained from that #define, it's just obfuscation.
Better to just write the plain symbol name, as is.

The following patch is a result of my wasting ten minutes looking through
the kernel to figure out what 'PB_migrate_end' meant, and forgetting what
I came to do, by the time I figured out that the #define PB_range macro
defined it.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 include/linux/pageblock-flags.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

--- linux.orig/include/linux/pageblock-flags.h	2008-05-13 05:42:39.869811856 -0700
+++ linux/include/linux/pageblock-flags.h	2008-05-13 05:51:47.994829315 -0700
@@ -25,13 +25,11 @@
 
 #include <linux/types.h>
 
-/* Macro to aid the definition of ranges of bits */
-#define PB_range(name, required_bits) \
-	name, name ## _end = (name + required_bits) - 1
-
 /* Bit indices that affect a whole block of pages */
 enum pageblock_bits {
-	PB_range(PB_migrate, 3), /* 3 bits required for migrate types */
+	PB_migrate,
+	PB_migrate_end = PB_migrate + 3 - 1,
+			/* 3 bits required for migrate types */
 	NR_PAGEBLOCK_BITS
 };
 

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 5/10] x86 boot: minor code format fixes in e820 and efi routines

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Standardize a few pointer declarations to not have the
extra space after the '*' character.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820_32.c |    2 +-
 arch/x86/kernel/e820_64.c |    2 +-
 arch/x86/kernel/efi_64.c  |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_32.c	2008-05-14 02:27:19.659222093 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_32.c	2008-05-14 02:50:11.450652182 -0700
@@ -280,7 +280,7 @@ void __init add_memory_region(unsigned l
  * replaces the original e820 map with a new one, removing overlaps.
  *
  */
-int __init sanitize_e820_map(struct e820entry * biosmap, char * pnr_map)
+int __init sanitize_e820_map(struct e820entry *biosmap, char *pnr_map)
 {
 	struct change_member *change_tmp;
 	unsigned long current_type, last_type;
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_64.c	2008-05-14 02:27:19.687222570 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_64.c	2008-05-14 03:04:29.540729012 -0700
@@ -740,7 +740,7 @@ static void early_panic(char *msg)
 }
 
 /* We're not void only for x86 32-bit compat */
-char * __init machine_specific_memory_setup(void)
+char *__init machine_specific_memory_setup(void)
 {
 	char *who = "BIOS-e820";
 	/*
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/efi_64.c	2008-05-14 02:27:19.783224204 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/efi_64.c	2008-05-14 02:50:11.474652591 -0700
@@ -103,7 +103,7 @@ void __init efi_reserve_bootmem(void)
 				memmap.nr_map * memmap.desc_size);
 }
 
-void __iomem * __init efi_ioremap(unsigned long phys_addr, unsigned long size)
+void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size)
 {
 	static unsigned pages_mapped __initdata;
 	unsigned i, pages;

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 6/10] x86 boot: proper use of ARRAY_SIZE instead of repeated E820MAX constant

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

This patch is motivated by a subsequent patch which will allow for more
memory map entries on EFI supported systems than can be passed via the x86
legacy BIOS E820 interface.  The legacy interface is limited to E820MAX ==
128 memory entries, and that "E820MAX" manifest constant was used as the
size for several arrays and loops over those arrays.

The primary change in this patch is to change code loop sizes over those
arrays from using the constant E820MAX, to using the ARRAY_SIZE() macro
evaluated for the array being looped.  That way, a subsequent patch can
change the size of some of these arrays, without breaking this code.

This patch also adds a parameter to the sanitize_e820_map() routine,
which had an implicit size for the array passed it of E820MAX entries.
This new parameter explicitly passes the size of said array.  Once again,
this will allow a subsequent patch to change that array size for some
calls to sanitize_e820_map() without breaking the code.

As part of enhancing the sanitize_e820_map() interface this way, I further
combined the unnecessarily distinct x86_32 and x86_64 declarations for
this routine into a single, commonly used, declaration.

This patch in itself should make no difference to the resulting kernel
binary.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/boot/memory.c        |    3 ++-
 arch/x86/kernel/e820_32.c     |    9 +++++----
 arch/x86/kernel/e820_64.c     |   15 +++++++++------
 arch/x86/mach-default/setup.c |    4 +++-
 arch/x86/mach-voyager/setup.c |    4 +++-
 include/asm-x86/setup.h       |    4 +++-
 6 files changed, 25 insertions(+), 14 deletions(-)

--- 2.6.26-rc2-mm1.orig/arch/x86/boot/memory.c	2008-05-14 03:07:02.923234780 -0700
+++ 2.6.26-rc2-mm1/arch/x86/boot/memory.c	2008-05-14 03:07:20.607523804 -0700
@@ -13,6 +13,7 @@
  */
 
 #include "boot.h"
+#include <linux/kernel.h>
 
 #define SMAP	0x534d4150	/* ASCII "SMAP" */
 
@@ -53,7 +54,7 @@ static int detect_memory_e820(void)
 
 		count++;
 		desc++;
-	} while (next && count < E820MAX);
+	} while (next && count < ARRAY_SIZE(boot_params.e820_map));
 
 	return boot_params.e820_entries = count;
 }
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_32.c	2008-05-14 03:07:19.459505040 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_32.c	2008-05-14 03:07:20.627524130 -0700
@@ -262,7 +262,7 @@ void __init add_memory_region(unsigned l
 
 	x = e820.nr_map;
 
-	if (x == E820MAX) {
+	if (x == ARRAY_SIZE(e820.map)) {
 		printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
 		return;
 	}
@@ -280,7 +280,8 @@ void __init add_memory_region(unsigned l
  * replaces the original e820 map with a new one, removing overlaps.
  *
  */
-int __init sanitize_e820_map(struct e820entry *biosmap, char *pnr_map)
+int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
+				char *pnr_map)
 {
 	struct change_member *change_tmp;
 	unsigned long current_type, last_type;
@@ -414,7 +415,7 @@ int __init sanitize_e820_map(struct e820
 					change_point[chgidx]->addr - last_addr;
 				/* move forward only if the new size was non-zero */
 				if (new_bios[new_bios_entry].size != 0)
-					if (++new_bios_entry >= E820MAX)
+					if (++new_bios_entry >= max_nr_map)
 						break; 	/* no more space left for new bios entries */
 			}
 			if (current_type != 0)	{
@@ -767,7 +768,7 @@ void __init update_e820(void)
 	u8 nr_map;
 
 	nr_map = e820.nr_map;
-	if (sanitize_e820_map(e820.map, &nr_map))
+	if (sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &nr_map))
 		return;
 	e820.nr_map = nr_map;
 	printk(KERN_INFO "modified physical RAM map:\n");
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_64.c	2008-05-14 03:07:19.467505171 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_64.c	2008-05-14 03:07:20.643524392 -0700
@@ -441,7 +441,7 @@ void __init add_memory_region(unsigned l
 {
 	int x = e820.nr_map;
 
-	if (x == E820MAX) {
+	if (x == ARRAY_SIZE(e820.map)) {
 		printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
 		return;
 	}
@@ -509,7 +509,8 @@ static void __init e820_print_map(char *
  * replaces the original e820 map with a new one, removing overlaps.
  *
  */
-static int __init sanitize_e820_map(struct e820entry *biosmap, char *pnr_map)
+int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
+				    char *pnr_map)
 {
 	struct change_member {
 		struct e820entry *pbios; /* pointer to original bios entry */
@@ -681,7 +682,7 @@ static int __init sanitize_e820_map(stru
 					 * no more space left for new
 					 * bios entries ?
 					 */
-					if (++new_bios_entry >= E820MAX)
+					if (++new_bios_entry >= max_nr_map)
 						break;
 			}
 			if (current_type != 0)	{
@@ -749,7 +750,9 @@ char *__init machine_specific_memory_set
 	 * Otherwise fake a memory map; one section from 0k->640k,
 	 * the next section from 1mb->appropriate_mem_k
 	 */
-	sanitize_e820_map(boot_params.e820_map, &boot_params.e820_entries);
+	sanitize_e820_map(boot_params.e820_map,
+			ARRAY_SIZE(boot_params.e820_map),
+			&boot_params.e820_entries);
 	if (copy_e820_map(boot_params.e820_map, boot_params.e820_entries) < 0)
 		early_panic("Cannot find a valid memory map");
 	printk(KERN_INFO "BIOS-provided physical RAM map:\n");
@@ -820,7 +823,7 @@ void __init finish_e820_parsing(void)
 	if (userdef) {
 		char nr = e820.nr_map;
 
-		if (sanitize_e820_map(e820.map, &nr) < 0)
+		if (sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &nr) < 0)
 			early_panic("Invalid user supplied memory map");
 		e820.nr_map = nr;
 
@@ -861,7 +864,7 @@ void __init update_e820(void)
 	u8 nr_map;
 
 	nr_map = e820.nr_map;
-	if (sanitize_e820_map(e820.map, &nr_map))
+	if (sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &nr_map))
 		return;
 	e820.nr_map = nr_map;
 	printk(KERN_INFO "modified physical RAM map:\n");
--- 2.6.26-rc2-mm1.orig/arch/x86/mach-default/setup.c	2008-05-14 03:07:02.923234780 -0700
+++ 2.6.26-rc2-mm1/arch/x86/mach-default/setup.c	2008-05-14 03:07:20.659524653 -0700
@@ -163,7 +163,9 @@ char * __init machine_specific_memory_se
 	 * Otherwise fake a memory map; one section from 0k->640k,
 	 * the next section from 1mb->appropriate_mem_k
 	 */
-	sanitize_e820_map(boot_params.e820_map, &boot_params.e820_entries);
+	sanitize_e820_map(boot_params.e820_map,
+			ARRAY_SIZE(boot_params.e820_map),
+			&boot_params.e820_entries);
 	if (copy_e820_map(boot_params.e820_map, boot_params.e820_entries)
 	    < 0) {
 		unsigned long mem_size;
--- 2.6.26-rc2-mm1.orig/arch/x86/mach-voyager/setup.c	2008-05-14 03:07:02.927234845 -0700
+++ 2.6.26-rc2-mm1/arch/x86/mach-voyager/setup.c	2008-05-14 03:07:20.675524915 -0700
@@ -111,7 +111,9 @@ char *__init machine_specific_memory_set
 	 * Otherwise fake a memory map; one section from 0k->640k,
 	 * the next section from 1mb->appropriate_mem_k
 	 */
-	sanitize_e820_map(boot_params.e820_map, &boot_params.e820_entries);
+	sanitize_e820_map(boot_params.e820_map,
+			ARRAY_SIZE(boot_params.e820_map),
+			&boot_params.e820_entries);
 	if (copy_e820_map(boot_params.e820_map, boot_params.e820_entries)
 	    < 0) {
 		unsigned long mem_size;
--- 2.6.26-rc2-mm1.orig/include/asm-x86/setup.h	2008-05-14 03:07:02.927234845 -0700
+++ 2.6.26-rc2-mm1/include/asm-x86/setup.h	2008-05-14 03:07:20.691525176 -0700
@@ -43,6 +43,9 @@ char *machine_specific_memory_setup(void
  */
 extern struct boot_params boot_params;
 
+int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
+			     char *pnr_map);
+
 #ifdef __i386__
 /*
  * Do NOT EVER look at the BIOS memory size location.
@@ -56,7 +59,6 @@ char * __init machine_specific_memory_se
 char *memory_setup(void);
 
 int __init copy_e820_map(struct e820entry *biosmap, int nr_map);
-int __init sanitize_e820_map(struct e820entry *biosmap, char *pnr_map);
 void __init add_memory_region(unsigned long long start,
 			      unsigned long long size, int type);
 

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 7/10] x86 boot: extend some internal memory map arrays to handle larger EFI input

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Extend internal boot time memory tables to allow for up to
three entries per node, which may be larger than the 128 E820MAX
entries handled by the legacy BIOS E820 interface.  The EFI
interface, if present, is capable of passing memory map
entries for these larger node counts.

This patch requires an earlier patch that rewrote code depending
on these array sizes from using E820MAX explicitly to size loops,
to instead using ARRAY_SIZE() of the applicable array.

Another patch following this one will provide the code to pick
up additional memory entries passed via the EFI interface from
the BIOS and insert them in the following, now enlarged, arrays.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820_32.c |    8 ++++----
 arch/x86/kernel/e820_64.c |    8 ++++----
 include/asm-x86/e820.h    |   37 ++++++++++++++++++++++++++++++++++++-
 3 files changed, 44 insertions(+), 9 deletions(-)

--- 2.6.26-rc2-mm1.orig/include/asm-x86/e820.h	2008-05-14 03:07:02.719231446 -0700
+++ 2.6.26-rc2-mm1/include/asm-x86/e820.h	2008-05-14 08:03:45.138599021 -0700
@@ -2,6 +2,41 @@
 #define __ASM_E820_H
 #define E820MAP	0x2d0		/* our map */
 #define E820MAX	128		/* number of entries in E820MAP */
+
+/*
+ * Legacy E820 BIOS limits us to 128 (E820MAX) nodes due to the
+ * constrained space in the zeropage.  If we have more nodes than
+ * that, and if we've booted off EFI firmware, then the EFI tables
+ * passed us from the EFI firmware can list more nodes.  Size our
+ * internal memory map tables to have room for these additional
+ * nodes, based on up to three entries per node for which the
+ * kernel was built: MAX_NUMNODES == (1 << CONFIG_NODES_SHIFT),
+ * plus E820MAX, allowing space for the possible duplicate E820
+ * entries that might need room in the same arrays, prior to the
+ * call to sanitize_e820_map() to remove duplicates.  The allowance
+ * of three memory map entries per node is "enough" entries for
+ * the initial hardware platform motivating this mechanism to make
+ * use of additional EFI map entries.  Future platforms may want
+ * to allow more than three entries per node or otherwise refine
+ * this size.
+ */
+
+/*
+ * Odd: 'make headers_check' complains about numa.h if I try
+ * to collapse the next two #ifdef lines to a single line:
+ *	#if defined(__KERNEL__) && defined(CONFIG_EFI)
+ */
+#ifdef __KERNEL__
+#ifdef CONFIG_EFI
+#include <linux/numa.h>
+#define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES)
+#else	/* ! CONFIG_EFI */
+#define E820_X_MAX E820MAX
+#endif
+#else	/* ! __KERNEL__ */
+#define E820_X_MAX E820MAX
+#endif
+
 #define E820NR	0x1e8		/* # entries in E820MAP */
 
 #define E820_RAM	1
@@ -18,7 +53,7 @@ struct e820entry {
 
 struct e820map {
 	__u32 nr_map;
-	struct e820entry map[E820MAX];
+	struct e820entry map[E820_X_MAX];
 };
 #endif /* __ASSEMBLY__ */
 
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_32.c	2008-05-14 03:07:20.627524130 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_32.c	2008-05-14 07:56:55.307867050 -0700
@@ -21,10 +21,10 @@ struct change_member {
 	struct e820entry *pbios; /* pointer to original bios entry */
 	unsigned long long addr; /* address for this change point */
 };
-static struct change_member change_point_list[2*E820MAX] __initdata;
-static struct change_member *change_point[2*E820MAX] __initdata;
-static struct e820entry *overlap_list[E820MAX] __initdata;
-static struct e820entry new_bios[E820MAX] __initdata;
+static struct change_member change_point_list[2*E820_X_MAX] __initdata;
+static struct change_member *change_point[2*E820_X_MAX] __initdata;
+static struct e820entry *overlap_list[E820_X_MAX] __initdata;
+static struct e820entry new_bios[E820_X_MAX] __initdata;
 /* For PCI or other memory-mapped resources */
 unsigned long pci_mem_start = 0x10000000;
 #ifdef CONFIG_PCI
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_64.c	2008-05-14 03:07:20.643524392 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_64.c	2008-05-14 07:56:55.307867050 -0700
@@ -516,10 +516,10 @@ int __init sanitize_e820_map(struct e820
 		struct e820entry *pbios; /* pointer to original bios entry */
 		unsigned long long addr; /* address for this change point */
 	};
-	static struct change_member change_point_list[2*E820MAX] __initdata;
-	static struct change_member *change_point[2*E820MAX] __initdata;
-	static struct e820entry *overlap_list[E820MAX] __initdata;
-	static struct e820entry new_bios[E820MAX] __initdata;
+	static struct change_member change_point_list[2*E820_X_MAX] __initdata;
+	static struct change_member *change_point[2*E820_X_MAX] __initdata;
+	static struct e820entry *overlap_list[E820_X_MAX] __initdata;
+	static struct e820entry new_bios[E820_X_MAX] __initdata;
 	struct change_member *change_tmp;
 	unsigned long current_type, last_type;
 	unsigned long long last_addr;

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 8/10] x86 boot: change sanitize_e820_map parameter from byte to int to allow bigger memory maps

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

The map size counter passed into, and back out of, sanitize_e820_map(),
was an eight bit type (char or u8), as derived from its origins in
legacy BIOS E820 structures.  This patch changes that type to an 'int',
to allow this sanitize routine to also be used on larger maps (larger
than the 256 count that fits in a char).  The legacy BIOS E820 interface
of course does not change; that remains at 8 bits for this count, holding
up to E820MAX == 128 entries.  But the kernel internals can handle more
when those additional memory map entries are passed from the BIOS via
EFI interfaces.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820_32.c     |    4 ++--
 arch/x86/kernel/e820_64.c     |   12 ++++++++----
 arch/x86/mach-default/setup.c |    5 ++++-
 arch/x86/mach-voyager/setup.c |    5 ++++-
 include/asm-x86/setup.h       |    2 +-
 5 files changed, 19 insertions(+), 9 deletions(-)

--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_32.c	2008-05-14 03:07:25.795608600 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_32.c	2008-05-14 03:07:30.395683787 -0700
@@ -281,7 +281,7 @@ void __init add_memory_region(unsigned l
  *
  */
 int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
-				char *pnr_map)
+				int *pnr_map)
 {
 	struct change_member *change_tmp;
 	unsigned long current_type, last_type;
@@ -765,7 +765,7 @@ void __init update_memory_range(u64 star
 }
 void __init update_e820(void)
 {
-	u8 nr_map;
+	int nr_map;
 
 	nr_map = e820.nr_map;
 	if (sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &nr_map))
--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_64.c	2008-05-14 03:07:25.811608861 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_64.c	2008-05-14 03:07:30.399683852 -0700
@@ -510,7 +510,7 @@ static void __init e820_print_map(char *
  *
  */
 int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
-				    char *pnr_map)
+				    int *pnr_map)
 {
 	struct change_member {
 		struct e820entry *pbios; /* pointer to original bios entry */
@@ -571,6 +571,7 @@ int __init sanitize_e820_map(struct e820
 		return -1;
 
 	old_nr = *pnr_map;
+	BUG_ON(old_nr > max_nr_map);
 
 	/* bail out if we find any unreasonable addresses in bios map */
 	for (i = 0; i < old_nr; i++)
@@ -744,15 +745,18 @@ static void early_panic(char *msg)
 char *__init machine_specific_memory_setup(void)
 {
 	char *who = "BIOS-e820";
+	int new_nr;
 	/*
 	 * Try to copy the BIOS-supplied E820-map.
 	 *
 	 * Otherwise fake a memory map; one section from 0k->640k,
 	 * the next section from 1mb->appropriate_mem_k
 	 */
+	new_nr = boot_params.e820_entries;
 	sanitize_e820_map(boot_params.e820_map,
 			ARRAY_SIZE(boot_params.e820_map),
-			&boot_params.e820_entries);
+			&new_nr);
+	boot_params.e820_entries = new_nr;
 	if (copy_e820_map(boot_params.e820_map, boot_params.e820_entries) < 0)
 		early_panic("Cannot find a valid memory map");
 	printk(KERN_INFO "BIOS-provided physical RAM map:\n");
@@ -821,7 +825,7 @@ early_param("memmap", parse_memmap_opt);
 void __init finish_e820_parsing(void)
 {
 	if (userdef) {
-		char nr = e820.nr_map;
+		int nr = e820.nr_map;
 
 		if (sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &nr) < 0)
 			early_panic("Invalid user supplied memory map");
@@ -861,7 +865,7 @@ void __init update_memory_range(u64 star
 
 void __init update_e820(void)
 {
-	u8 nr_map;
+	int nr_map;
 
 	nr_map = e820.nr_map;
 	if (sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &nr_map))
--- 2.6.26-rc2-mm1.orig/arch/x86/mach-default/setup.c	2008-05-14 03:07:20.659524653 -0700
+++ 2.6.26-rc2-mm1/arch/x86/mach-default/setup.c	2008-05-14 03:07:30.419684179 -0700
@@ -153,6 +153,7 @@ late_initcall(print_ipi_mode);
 char * __init machine_specific_memory_setup(void)
 {
 	char *who;
+	int new_nr;
 
 
 	who = "BIOS-e820";
@@ -163,9 +164,11 @@ char * __init machine_specific_memory_se
 	 * Otherwise fake a memory map; one section from 0k->640k,
 	 * the next section from 1mb->appropriate_mem_k
 	 */
+	new_nr = boot_params.e820_entries;
 	sanitize_e820_map(boot_params.e820_map,
 			ARRAY_SIZE(boot_params.e820_map),
-			&boot_params.e820_entries);
+			&new_nr);
+	boot_params.e820_entries = new_nr;
 	if (copy_e820_map(boot_params.e820_map, boot_params.e820_entries)
 	    < 0) {
 		unsigned long mem_size;
--- 2.6.26-rc2-mm1.orig/arch/x86/mach-voyager/setup.c	2008-05-14 03:07:20.675524915 -0700
+++ 2.6.26-rc2-mm1/arch/x86/mach-voyager/setup.c	2008-05-14 03:07:30.439684506 -0700
@@ -62,6 +62,7 @@ void __init time_init_hook(void)
 char *__init machine_specific_memory_setup(void)
 {
 	char *who;
+	int new_nr;
 
 	who = "NOT VOYAGER";
 
@@ -111,9 +112,11 @@ char *__init machine_specific_memory_set
 	 * Otherwise fake a memory map; one section from 0k->640k,
 	 * the next section from 1mb->appropriate_mem_k
 	 */
+	new_nr = boot_params.e820_entries;
 	sanitize_e820_map(boot_params.e820_map,
 			ARRAY_SIZE(boot_params.e820_map),
-			&boot_params.e820_entries);
+			&new_nr);
+	boot_params.e820_entries = new_nr;
 	if (copy_e820_map(boot_params.e820_map, boot_params.e820_entries)
 	    < 0) {
 		unsigned long mem_size;
--- 2.6.26-rc2-mm1.orig/include/asm-x86/setup.h	2008-05-14 03:07:20.691525176 -0700
+++ 2.6.26-rc2-mm1/include/asm-x86/setup.h	2008-05-14 03:07:30.459684833 -0700
@@ -44,7 +44,7 @@ char *machine_specific_memory_setup(void
 extern struct boot_params boot_params;
 
 int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
-			     char *pnr_map);
+			     int *pnr_map);
 
 #ifdef __i386__
 /*

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 9/10] x86 boot: longer comment explaining sanitize_e820_map routine

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Elaborate on the comment for sanitize_e820_map(), epxlaining more what
it does, what it inputs, and what it returns.  Rearrange the placement of
this comment to fit kernel conventions, before the routine's code rather
than buried inside it.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820_64.c |   94 +++++++++++++++++++++++++++-------------------
 1 file changed, 56 insertions(+), 38 deletions(-)

--- 2.6.26-rc2-mm1.orig/arch/x86/kernel/e820_64.c	2008-05-14 03:07:30.399683852 -0700
+++ 2.6.26-rc2-mm1/arch/x86/kernel/e820_64.c	2008-05-14 03:07:34.755755053 -0700
@@ -506,9 +506,64 @@ static void __init e820_print_map(char *
  * Sanitize the BIOS e820 map.
  *
  * Some e820 responses include overlapping entries. The following
- * replaces the original e820 map with a new one, removing overlaps.
+ * replaces the original e820 map with a new one, removing overlaps,
+ * and resolving conflicting memory types in favor of highest
+ * numbered type.
  *
+ * The input parameter biosmap points to an array of 'struct
+ * e820entry' which on entry has elements in the range [0, *pnr_map)
+ * valid, and which has space for up to max_nr_map entries.
+ * On return, the resulting sanitized e820 map entries will be in
+ * overwritten in the same location, starting at biosmap.
+ *
+ * The integer pointed to by pnr_map must be valid on entry (the
+ * current number of valid entries located at biosmap) and will
+ * be updated on return, with the new number of valid entries
+ * (something no more than max_nr_map.)
+ *
+ * The return value from sanitize_e820_map() is zero if it
+ * successfully 'sanitized' the map entries passed in, and is -1
+ * if it did nothing, which can happen if either of (1) it was
+ * only passed one map entry, or (2) any of the input map entries
+ * were invalid (start + size < start, meaning that the size was
+ * so big the described memory range wrapped around through zero.)
+ *
+ *	Visually we're performing the following
+ *	(1,2,3,4 = memory types)...
+ *
+ *	Sample memory map (w/overlaps):
+ *	   ____22__________________
+ *	   ______________________4_
+ *	   ____1111________________
+ *	   _44_____________________
+ *	   11111111________________
+ *	   ____________________33__
+ *	   ___________44___________
+ *	   __________33333_________
+ *	   ______________22________
+ *	   ___________________2222_
+ *	   _________111111111______
+ *	   _____________________11_
+ *	   _________________4______
+ *
+ *	Sanitized equivalent (no overlap):
+ *	   1_______________________
+ *	   _44_____________________
+ *	   ___1____________________
+ *	   ____22__________________
+ *	   ______11________________
+ *	   _________1______________
+ *	   __________3_____________
+ *	   ___________44___________
+ *	   _____________33_________
+ *	   _______________2________
+ *	   ________________1_______
+ *	   _________________4______
+ *	   ___________________2____
+ *	   ____________________33__
+ *	   ______________________4_
  */
+
 int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
 				    int *pnr_map)
 {
@@ -529,43 +584,6 @@ int __init sanitize_e820_map(struct e820
 	int old_nr, new_nr, chg_nr;
 	int i;
 
-	/*
-		Visually we're performing the following
-		(1,2,3,4 = memory types)...
-
-		Sample memory map (w/overlaps):
-		   ____22__________________
-		   ______________________4_
-		   ____1111________________
-		   _44_____________________
-		   11111111________________
-		   ____________________33__
-		   ___________44___________
-		   __________33333_________
-		   ______________22________
-		   ___________________2222_
-		   _________111111111______
-		   _____________________11_
-		   _________________4______
-
-		Sanitized equivalent (no overlap):
-		   1_______________________
-		   _44_____________________
-		   ___1____________________
-		   ____22__________________
-		   ______11________________
-		   _________1______________
-		   __________3_____________
-		   ___________44___________
-		   _____________33_________
-		   _______________2________
-		   ________________1_______
-		   _________________4______
-		   ___________________2____
-		   ____________________33__
-		   ______________________4_
-	*/
-
 	/* if there's only one memory region, don't bother */
 	if (*pnr_map < 2)
 		return -1;

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Add to the kernels boot memory map 'memmap' entries found in
the EFI memory descriptors passed in from the BIOS.

On EFI systems, up to E820MAX == 128 memory map entries can
be passed via the legacy E820 interface (limited by the size
of the 'zeropage').  These entries can be duplicated in the
EFI descriptors also passed from the BIOS, and possibly more
entries passed by the EFI interface, which does not have the
E820MAX limit on number of memory map entries.

This code doesn't worry about the likely duplicate, overlapping
or (unlikely) conflicting entries between the EFI map and the
E820 map.  It just dumps all the EFI entries into the memmap[]
array (which already has the E820 entries) and lets the existing
routine sanitize_e820_map() sort the mess out.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/efi.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

--- linux.orig/arch/x86/kernel/efi.c	2008-05-06 06:44:32.332774433 -0700
+++ linux/arch/x86/kernel/efi.c	2008-05-06 06:55:20.767816417 -0700
@@ -213,6 +213,31 @@ unsigned long efi_get_time(void)
 		      eft.minute, eft.second);
 }
 
+/*
+ * Tell the kernel about the EFI memory map.  This might include
+ * more than the max 128 entries that can fit in the e820 legacy
+ * (zeropage) memory map.
+ */
+
+static void __init add_efi_memmap(void)
+{
+	void *p;
+
+	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+		efi_memory_desc_t *md = p;
+		unsigned long long start = md->phys_addr;
+		unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
+		int e820_type;
+
+		if (md->attribute & EFI_MEMORY_WB)
+			e820_type = E820_RAM;
+		else
+			e820_type = E820_RESERVED;
+		add_memory_region(start, size, e820_type);
+	}
+	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
+}
+
 #if EFI_DEBUG
 static void __init print_efi_memmap(void)
 {
@@ -370,6 +395,7 @@ void __init efi_init(void)
 	if (memmap.desc_size != sizeof(efi_memory_desc_t))
 		printk(KERN_WARNING "Kernel-defined memdesc"
 		       "doesn't match the one from EFI!\n");
+	add_efi_memmap();
 
 	/* Setup for EFI runtime service */
 	reboot_type = BOOT_EFI;

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Paul Jackson]

Ying Huang, H. Peter Anvin, Andi Kleen, Ingo Molnar (and anyone else
interested):

I invite your review of these patches, especially 7, 9 and 10 of the
set of 10, that I posted yesterday.

In combination, I believe that they allow passing more than E820MAX
(128) memory map entries from EFI firmware to a booting kernel, beyond
the E820 constraints of non-EFI legacy BIOS's, without changing the
EFI interface interface.  My understanding of the EFI interface is
that it already allows for this, and that we just needed to add the
ability, as done in these patches, for the kernel to make use of this.

The separate work of Ying Huang, to leverage Andi's reserve_early()
and to revise the EFI interface, to pass multiple pages of information
from the EFI firmware to the kernel at boot is, I presume, still needed
for other extensions, such as for passing more hard disk drive entries.

But the particular extension of interest to me, passing more memory map
entries (for future x86_64 systems with more than 128 memory nodes)
can I believe be done fairly easily, with these patches, with no need
of revising the EFI interface or reserving early memory, and with code
that is compatible across both x86_32 and x86_64 arch's.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Ingo Molnar]

* Paul Jackson <pj@sgi.com> wrote:

> I invite your review of these patches, especially 7, 9 and 10 of the 
> set of 10, that I posted yesterday.

thanks Paul, i've queued up your changes to the -tip tree - they look 
nice and finegrained.

I merged them ontop of Yinghai's e820 unification work. The merge was 
far from trivial (functions you were patching moved to other files, 
interface definitions changed, etc.) so double-checking it would be 
nice. This will all show up in the x86/mtrr branch in -tip, probably 
later today.

	Ingo

Re: [PATCH 1/10] x86 boot: include missing smp.h header

[Mike Travis]

Acked-By: Mike Travis <travis@sgi.com>

Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> The patch:
>     x86: convert cpu_to_apicid to be a per cpu variable
> introduced a dependency of ipi.h on smp.h in x86
> builds with an allnoconfig.  Including smp.h in ipi.h
> fixes the build error:
>     In file included from arch/x86/kernel/traps_64.c:48:
>     include/asm/ipi.h: In function 'send_IPI_mask_sequence':
>     include/asm/ipi.h:114: error: 'per_cpu__x86_cpu_to_apicid' undeclared (first use in this function)
> 
> Signed-off-by: Paul Jackson <pj@sgi.com>
> Cc: Mike Travis <travis@sgi.com>
> 
> ---
>  include/asm-x86/ipi.h |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux.orig/include/asm-x86/ipi.h	2008-05-13 10:44:39.000000000 -0700
> +++ linux/include/asm-x86/ipi.h	2008-05-13 10:56:37.431506774 -0700
> @@ -20,6 +20,7 @@
>  
>  #include <asm/hw_irq.h>
>  #include <asm/apic.h>
> +#include <asm/smp.h>
>  
>  /*
>   * the following functions deal with sending IPIs between CPUs.
> 

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Paul Jackson]

Ingo wrote:
> i've queued up your changes to the -tip tree 

Thanks.

> so double-checking it [the merge ontop of Yinghai's e820 work] would be nice.

Ok - will do.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Paul Jackson]

Ingo wrote:
> so double-checking [the merge of my x86 boot patches] would be nice.

I only see one detail worth mentioning on reading the resulting merge
in ingo.tip.

Shouldn't the static array declarations in arch/x86/kernel/e820.c
be indented?  It looks like the -file- static declarations
from arch/x86/kernel/e820_32.c (which were not indented) took
precedence in the merge over the -function- static declarations
from arch/x86/kernel/e820_64.c.  The code, from the perspective
of what ends up in the compiled kernel, seems fine -- just the
indentation off.

int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
				int *pnr_map)
{
	struct change_member {
		struct e820entry *pbios; /* pointer to original bios entry */
		unsigned long long addr; /* address for this change point */
	};
static struct change_member change_point_list[2*E820_X_MAX] __initdata;
static struct change_member *change_point[2*E820_X_MAX] __initdata;
static struct e820entry *overlap_list[E820_X_MAX] __initdata;
static struct e820entry new_bios[E820_X_MAX] __initdata;
	struct change_member *change_tmp;
	unsigned long current_type, last_type;
	unsigned long long last_addr;


-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Ingo Molnar]

* Paul Jackson <pj@sgi.com> wrote:

> Ingo wrote:
> > so double-checking [the merge of my x86 boot patches] would be nice.
> 
> I only see one detail worth mentioning on reading the resulting merge 
> in ingo.tip.
> 
> Shouldn't the static array declarations in arch/x86/kernel/e820.c be 
> indented?  It looks like the -file- static declarations from 
> arch/x86/kernel/e820_32.c (which were not indented) took precedence in 
> the merge over the -function- static declarations from 
> arch/x86/kernel/e820_64.c.  The code, from the perspective of what 
> ends up in the compiled kernel, seems fine -- just the indentation 
> off.
> 
> int __init sanitize_e820_map(struct e820entry *biosmap, int max_nr_map,
> 				int *pnr_map)
> {
> 	struct change_member {
> 		struct e820entry *pbios; /* pointer to original bios entry */
> 		unsigned long long addr; /* address for this change point */
> 	};
> static struct change_member change_point_list[2*E820_X_MAX] __initdata;
> static struct change_member *change_point[2*E820_X_MAX] __initdata;
> static struct e820entry *overlap_list[E820_X_MAX] __initdata;
> static struct e820entry new_bios[E820_X_MAX] __initdata;
> 	struct change_member *change_tmp;
> 	unsigned long current_type, last_type;
> 	unsigned long long last_addr;

indeed that's quite off.

	Ingo

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Huang, Ying]

Hi, Paul,

Sorry for my late. I am busy on something other these days.

Because EFI memory map are converted to E820 memory map in boot loader
if the converted E820 entry number is below 128 now, I think it is
better to do all the conversion in boot loader. The limitation lies in
the size of struct boot_params (zero page), which is 4k. But there is an
extension to struct boot_params named linked list of struct setup_data
in a previous patch:

http://lkml.org/lkml/2008/3/27/26

With the help of linked list of struct setup_data, the E820 memory map
with more than 128 entries in EFI system can be passed to kernel as
follow.

1. In boot loader, EFI memory map is converted to E820 memory map A
2. The low 128 map entries of map A is copied to e820_map of struct
boot_params.
3. A setup_data struct is constructed to hold the other E820 entries.

4. In Linux kernel, the E820 map entries from both struct boot_params
and setup_data are used.

Best Regards,
Huang Ying

On Wed, 2008-05-14 at 08:15 -0700, Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> Add to the kernels boot memory map 'memmap' entries found in
> the EFI memory descriptors passed in from the BIOS.
> 
> On EFI systems, up to E820MAX == 128 memory map entries can
> be passed via the legacy E820 interface (limited by the size
> of the 'zeropage').  These entries can be duplicated in the
> EFI descriptors also passed from the BIOS, and possibly more
> entries passed by the EFI interface, which does not have the
> E820MAX limit on number of memory map entries.
> 
> This code doesn't worry about the likely duplicate, overlapping
> or (unlikely) conflicting entries between the EFI map and the
> E820 map.  It just dumps all the EFI entries into the memmap[]
> array (which already has the E820 entries) and lets the existing
> routine sanitize_e820_map() sort the mess out.
> 
> Signed-off-by: Paul Jackson <pj@sgi.com>
> 
> ---
>  arch/x86/kernel/efi.c |   26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> --- linux.orig/arch/x86/kernel/efi.c	2008-05-06 06:44:32.332774433 -0700
> +++ linux/arch/x86/kernel/efi.c	2008-05-06 06:55:20.767816417 -0700
> @@ -213,6 +213,31 @@ unsigned long efi_get_time(void)
>  		      eft.minute, eft.second);
>  }
>  
> +/*
> + * Tell the kernel about the EFI memory map.  This might include
> + * more than the max 128 entries that can fit in the e820 legacy
> + * (zeropage) memory map.
> + */
> +
> +static void __init add_efi_memmap(void)
> +{
> +	void *p;
> +
> +	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> +		efi_memory_desc_t *md = p;
> +		unsigned long long start = md->phys_addr;
> +		unsigned long long size = md->num_pages << EFI_PAGE_SHIFT;
> +		int e820_type;
> +
> +		if (md->attribute & EFI_MEMORY_WB)
> +			e820_type = E820_RAM;
> +		else
> +			e820_type = E820_RESERVED;
> +		add_memory_region(start, size, e820_type);
> +	}
> +	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
> +}
> +
>  #if EFI_DEBUG
>  static void __init print_efi_memmap(void)
>  {
> @@ -370,6 +395,7 @@ void __init efi_init(void)
>  	if (memmap.desc_size != sizeof(efi_memory_desc_t))
>  		printk(KERN_WARNING "Kernel-defined memdesc"
>  		       "doesn't match the one from EFI!\n");
> +	add_efi_memmap();
>  
>  	/* Setup for EFI runtime service */
>  	reboot_type = BOOT_EFI;
> 

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Paul Jackson]

Huang Ying wrote:
> Because EFI memory map are converted to E820 memory map in boot loader
> if the converted E820 entry number is below 128 now, I think it is
> better to do all the conversion in boot loader. The limitation lies in
> the size of struct boot_params (zero page), which is 4k. But there is an
> extension to struct boot_params named linked list of struct setup_data
> in a previous patch:
> 
> http://lkml.org/lkml/2008/3/27/26

That previous patch of yours that you reference required modifying
the long standing E820 interface to the kernel, including bumping the
boot_params.hdr.version from 0x0208 to0x0209, and required reserving
additional early boot memory, in order to manage new linked list
data structures to be passed to the kernel and to allocate space for
these structures in early boot.

Why do you think that patch is better?  You say "because entries below
128 are already converted to the E820 map."

But I reply mine is better, because we can already provide, with the
current EFI interfaces, all the entries from the boot loader to the
kernel, so we do not need to provide them twice, a second time via an
E820 map mechanism that must be revised and extended to handle the
additional memory map entries past the first 128 of them.

Why should we do the extra work of passing something in a more difficult
manner, revising a key interface, when we can already pass it with
existing interface?

As Andi Kleen wrote on Feb 20, 2008:
> Just getting it directly from EFI is certainly easier in Linux
> than to do any complicated boot protocol extensions.

Resolving this need to pass more than 128 memory map entries has been
in development now for over six months.  I see related developments in
this area dating back to early October 2007.  I have been quite
explicit since January of 2008 that we (SGI) needed a solution to this
fairly soon.  I am running out of time, and need to have a solution to
this accepted.

If at some point you have other reasons to revision the EFI and E820
interfaces, for example to pass the EDD BIOS Enhanced Disk Drive
Services past what the classic E820 interface handles, that would be
fine my me.

I am not opposed to your patch mentioned above.  It's just that I don't
think it is needed for this particular purpose, of extending the number
of memory map entries past 128.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[H. Peter Anvin]

Paul Jackson wrote:
> 
> But I reply mine is better, because we can already provide, with the
> current EFI interfaces, all the entries from the boot loader to the
> kernel, so we do not need to provide them twice, a second time via an
> E820 map mechanism that must be revised and extended to handle the
> additional memory map entries past the first 128 of them.
> 

This was discussed over a year ago, and it was declared the boot 
loaders' responsibility.  Please go back and look at the archives for 
the discussion rather than rehashing it at this time.

	-hpa

Re: [PATCH 10/10] x86 boot: add code to add BIOS provided EFI memory entries to kernel

[Paul Jackson]

H. Peter Anvin wrote:
> This was discussed over a year ago, and it was declared the boot
> loaders' responsibility.  Please go back and look at the archives for
> the discussion rather than rehashing it at this time.


Good grief - you're right.  I had only looked back nine months in my
archives, as you can tell, from my last message, in which I recite
some of that history.  This saga has dragged on for two years now.

Summary of what's transpired in the last two years:

  A] In the summer of 2006, Edgar Hucek submitted a patch that
     after some back and forth ended up doing pretty much what my
     latest patch does -- enabling the kernel to extract any EFI
     memory map entries and add them to the E820 map.
     
     At the time, there seemed to be agreement from both Linus and
     yourself (hpa) that this was a good approach.
     
     However, Edgar Hucek, perhaps not used to the various details
     and difficulties needed to gain acceptance of a kernel patch,
     gave up and went away before the patch gained final acceptance.

  B] Beginning in May of 2007, with the work of Chandramouli
     "Mouli" Narayanan, and continuing in July 2007 with the
     work of Ying Huang, when Mouli went on sabbatical, an
     extended series of patches has added EFI support to x86_32
     and x86_64.

  C] Beginning in August 2007, H. Peter Anvin has been advocating
     that instead of the approach of [A] above, rather we extend the
     e820 interface between the bootloader and the kernel to pass
     more than a single 4K page (the legacy 'zeropage'), using a
     linked of setup_data structs.
     
     Ying Huang has been fully supportive of this direction,  and,
     along with the reserve_memory() apparatus by Andi Kleen,
     providing the bulk of the code implementing it.
     
     The essential motivation for this extension of the e820 interface
     seems to be allowing for more than six drives in the EDD BIOS
     Enhanced Disk Drive Services interface.

  D] Beginning in January 2008, I have been repeatedly urging
     the portion of this work along that would enable more
     memory nodes than the 128 (E820MAX) allowed by the legacy
     e820 bios interface.  It is essential for my current
     project.  We really wanted this in 2.6.26, but no later
     than 2.6.27.

  E] Now, in May 2008, I present a patch set, the key part of
     which is a rather simple code loop, to copy any EFI memory
     map entries over to the E820 memory map.
     
     Earlier patches in this set generalize some data types (such
     as a u8 array index) and some array sizes (from the hard coded
     E820MAX) in order to accomodate E820 memory map structures
     internal to the kernel that are larger than what might be passed
     by the legacy interface.  I suspect that these patches growing
     the kernels internal e820 memory map will be needed by the
     extended setup_data linked list e820 interface that Peter
     and Ying have been working toward, for nine months now.

I have detailed this history further below, as a by-product of my
reviewing it myself, to be sure I fully went "back and looked at the
archives", as Peter requested.


Conclusions:
------------

  As I stated in my reply to Ying to which you are responding, Peter,
  my patch does not preclude you and Ying from continuing toward your
  goal of nine months now to extend the e820 interface to handle a
  linked list of setup_data structs.
  
  Indeed, much of my patch set is stuff you'll need anyway, to enable
  growing the internal kernel e820 map structures to more than 128
  entries.
  
  There is just a single patch, containing one new routine of less
  than 20 straight forward lines of code, that is at issue here.
  That routine copies efi memory entries into the e820 map.

  As Linus, and yourself, noted some two years ago, such copying of the
  efi map entries to the e820 map is a simple and sensible approach.
  
  I've waited, patiently proddding now for five months, and it has
  been nine months since you proposed the linked list of setup_data,
  and still it is not entirely coded or in the tree.  It missed
  2.6.26, and looks not to make 2.6.27 either.
  
  I can wait no longer; I do not stand in your way; and I only ask for
  this one small, sensible, alternative to handling larger memory maps.
  
  The two of you, Ying and Peter, are welcome to continue work with
  your planned extension to the e820 interface.  I appreciate that
  you need it for additional EDD entries, and that some, even most,
  BIOS's may prefer to use it for additional memory map entries.

  That's fine.  But, as has been long understood, it is not the only
  possible solution for additional memory map entries on EFI systems.

  Meanwhile, and in any case, my special thanks to Ying Huang for
  his substantial and extended work in adding EFI support to
  x86_64.  His work is much appreciated and vital to the project
  on which I'm focused.  Thanks, Ying!


===

Ok ... rolling back the hands of time (those who are not
terminally masochistic can stop reading now ;).


==================== June - August 2006 ====================

1) On June 20 to 28, 2006, Edgar Hucek posted a series of patches:
   	[PATCH 1/1] Fix boot on efi 32 bit Machines
   This patch set bypassed the failing e820 code memory map
   loading code on systems, such as Intel Mac's, that had no
   E820 memory map.

2) On June 27, 2006, Linus wrote in the discussion of Edgar's patches:

      I'd really suggest just filling in the e820 table from the
      EFI information early at boot.

      (Even better would be for the EFI bootloader on x86 to just
      fill things in _as_if_ it was filling in e820 data, but that's
      outside of the kernel, so if you want the _kernel_ to be able
      to handle native EFI data, do it by just translating it once
      into e820 mode, and you're done).

      The translation from EFI to e820 format should be very
      straightforward indeed. I think it's pretty much the same
      thing with different naming.

3) On June 28, 2006, hpa (you might know him ;) replied to Linus:

      You probably don't want to put it in the bootloader.  The kernel
      is easier to upgrade than the bootloader, which is easier to
      upgrade than the firmware, so it makes more sense for the kernel
      to be as self-sufficient as is possible, or at least practical.

4) On July 2, 2006, Eric W. Biederman replied to the above discussion
   of Hucek's above patches with a request to remove or disable the
   efi implementation hacks, because they break kexec, at least if
   EFI callbacks are used.  (Sorry, Eric, if I misstated that one.)

5) July 2-14, 2006, the discussion of the above patch continued,
   with increasing evidence of problems with the kernels EFI code.

6) On July 16, 2006, Edgar Hucek posted the patch:
       [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
   This patch added efi memory entries to the e820 map if efi was
   enabled at boot.  I should study this patch more closely; it might
   have details that I should pick up for my current patch proposal.

7) On July 24, 2006, Eric W. Biederman justified this latest patch
   of Edgar Hucek by stating:

      The x86 architecture needs a way to represent the firmware
      supplied memory map in a way that later code can query what is
      in the map.  The easiest way to do this is simply to convert
      the efi memory map into an e820 memory map.

8) On July 24, 2006, Linus stated that "Edgars patch looks fine per se",
   though Linus wished for more testers.  Linus also took the occassion
   to criticize EFI and ACPI.  H. Peter Anvin reminded Linus that
   PXE was also worthy of criticism.  Linus said he wasn't forgetting
   PXE; rather he was just repressing it.

10) On July 26, 2006, Andrew Morton accepted Edgars patch into
    2.6.18-rc4-mm1.  Various fixes and minor confusions followed.

11) Edgar Hucek's last post, ever, to lkml made on August 19, 2006.

12) On August 21, 2006, Andrew dropped Edgars patch, because:
       "it got rejects, and I don't think we'll be proceeding with it anwyay?"
    I cannot find the discussion that led to Andrew thinking that
    we were not proceeding with this patch.


==================== May - Dec 2007 ====================

13) On May 1, 2007,  Chandramouli "Mouli" Narayanan submitted a patch set
   "x86_64: EFI64 support" to add EFI support to x86_64.

14) Various comments to these patches, including Andi Kleen's comment:
        "Please convert the memory map from EFI into the e820 map in one place."

15) On July 2, 2007, Mouli submitted second version of this patch set,
    with numerous improvements, including:

       - Implemented EFI to E820 memory map conversion. This is based on
         bootloader support. The ELILO bootloader x86_64 support has been
         updated to pass E820 map to kernel.

16) On July 4, 2007, Ying Huang picked up this task from Mouli, who
    left for sabbatical.

17) On July 31, 2007, Ying Huang submitted another update of the patches
    to add EFI support to x86_64.  Various comments, especially from
    Andi Kleen and Eric W. Biederman.

18) On August 9, 2007, Ying Huang submitted another update.  The EFI
    memory map is converted to E820 in the bootloader, so kernel
    support is not needed to parse an EFI memory map.

19) On August 9, 2007, H. Peter Anvin proposes a "linked list of tagged
    data items" to extend the boot protocol past the compromises imposed
    by a 4K boot page (zeropage):

	I mentioned in private email to a few people that I think
	a linked list of tagged data items (similar to the way PCI
	capabilities work) would probably make sense; we want a piece
	of code to know the structure without needing to know the
	contents, in order to rescue data.
    
20) August 13-22, 2007 has a lengthy discussion between Ying, Peter,
    and Andi, in a thread with the Subject of:
        "[PATCH 0/3] x86_64 EFI runtime service support"
    This discussion is likely part of what Peter refers to as "over a
    year ago" (only nine months, actually.)

21) Another patchset from Ying on August 13, 2007.

22) This version of the patch set had a "major trainwreck" (to quote
    Andrew) with Peter's git-newsetup.patch, and so got dropped on
    August 15, 2007.

23) On Sept 17, 2007, Ying Huang presents a patchset with a new 32 bit
    boot protocol for use on non-legacy i386 and for x86_64, with an
    extensible linked list of boot parameters.  A recognized issue was
    finding a safe place for this linked list of setup_data.

24) On Sept 18, 2007, Ying Huang updated this patchset (setup_data
    linked list 32 bit boot protocol) (patch version v2)

25) On Sept 19, 2007, patch version v3 from Ying Huang.

26) On Sept 22, 2007, in response to a question of "why?" from Jeremy
    Fitzhardinge, H. Peter Anvin explained that the linked list was
    needed because:

	We have already run into at least one case where the existing
	structure is insufficient (EDD overhaul), and so we need to
	do something extensible.

27) On October 9, 2007, patch version v4 from Ying Huang.

28) On October 12, 2007, patch version v5 from Ying Huang.

29) On October 16, 2007, patch from H. Peter Anvin replaces the
    "magic macros" with a boot_params structure.
    
30) On October 22, 2007, patch version v6 from Ying Huang.

31) On October 23, 2007, Ying Huang submitted the documentation of
    the 32 bit x86 boot protocol as a separate patch, documenting
    current behaviour.

32) On October 24, 2007, Ying Huang resent his x86_64 EFI boot support
    patches, asking Andrew Morton to accept them into *-mm, which
    Andrew did.

33) On October 25, 2007, Ying Huang submitted a 4 patch set for
    x86_64 EFI runtime service support (version v4).  Continued
    discussion of whether EFI runtime services were needed, with
    Ying Huang concluding that at least the BIOS variable service
    was useful, and that it didn't break anything, but that it
    should be via virtual mode (to improve reliability of OOPS
    information writing) and that some code duplication between
    efi_32.c and efi_64.c needed to be eliminated.
    
34) On October 30, 2007, Ying Huang released version v5 of his
    x86_64 EFI runtime service support patches.

35) On Nov 2, 2007, Ying Huang submitted version v3 of his x86_64 boot
    support patches.

36) On Nov 5, 2007, Andrew Morton added v3 of the x86_64 EFI boot
    support for EFI frame buffer to *-mm, and it was included in
    2.6.24.  However the linked list setup_data patches were not
    included, due to ongoing discussions over how to reserve early
    memory for them.

37) On Nov 26 to Dec 14, Ying Huang updated his x86_64 EFI runtime
    service patches.  Sometime thereafter they seem to have made
    their way into the mainline kernel.

38) On Dec 11, 2007, Ying Huang removed some code that had been
    handling the EFI memory map, because it is "converted to e820
    memory map in bootloader."

39) On Dec 29, 2007, Ying Huang submitted patch to split EFI
    table parsing from EFI runtime support.


==================== Jan - May 2008 ====================

40) January, 2008, various refinements and fixes from Ying Huang.

41) January 18 and 23, 2008 - I (pj) begin asking when and how
    the 128 memory map limit (E820MAX) will be overcome.
    
42) February 12 and 14, 2008, various EFI cache mapping bug fixes
    from Andi Kleen.

43) February 20, 2008, I (pj) renewed my inquiry as to when x86_64
    EFI extensions for high node counts would be available.  I was
    looking for them to be merged by 2.6.26.

44) Andi Kleen, in one reply to my inquiry, wrote:

      Anyways if it's really a problem I guess the easiest fix would be
      to just call EFI again and get the true map directly and convert
      it to e820. As long as it's only in a single place somewhere
      in the EFI code and not spread all over that should be fine.

   [P.S. - it is a real problem, we missed 2.6.26, and still don't
   have a firm release date, and my latest patch set of last week
   does as Andi suggests, which looks to be what Linus and (in an
   earlier life, Peter) thought sensible, in response to Edgar Hucek's
   patches of 2006. -pj]

   H. Peter Anvin replied to Andi with:
   
       We need the expanded boot protocol *anyway*, for other reasons.
     
   In reply to Andi asking what these other reasons were, Peter wrote:
   
       So far, we have at least EDD, which is currently truncated to the
       point of uselessness (see posts by Alan Cox for the gory details),
       and non-EFI systems.

45) In a discussion on March 3 and 4 of these early memory needs
    for both 32 and 64 bit systems, Ingo Molnar noted:
    
	i'd strongly support the moving of this from the realm
	of talk into the realm of code! :-)

46) The above February discussion died out, so on March 23, 2008,
    I asked again "how goes this work?"
    
    The answer turned out to be that it was awaiting a x86_32 version
    of the reserve_early() memory allocation handler of Andi Kleen.

47) On May 14, 2008, I (pj) submitted a patchset that extracted
    any EFI memory map and added it to the e820 map.

    Ingo added this to his x86 tree.

48) On May 27, 2008, Ying Huang responded to my patchset, stating he
    preferred the planned extensions to the E820 boot protocol
    (the linked list of setup_data allowing more than one page
    of boot information to be passed.)

49) On May 27, 2008, I replied to Ying Huang, explaining advantages
    of my patches, and noting that they do -not- conflict with
    his planned  extensions to the E820 boot protocol.

50) On May 27, 2008, H. Peter Anvin replied to me, asking me not to
    rehash a discussion of "over a year ago."

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214