Re: [PATCH v3] efi: Request desired alignment via the PE/COFF headers

2015-06-16 Thread Linn Crosetto 
On Tue, Jun 16, 2015 at 05:19:29PM +0100, Michael Brown wrote:
 On 15/06/15 22:43, Linn Crosetto wrote:
 Michael Brown mbrown@... writes:
 The kernel will align itself to the nearest boundary specified by the
 kernel_alignment field in the bzImage header.  If the kernel is loaded
 to an address which is not sufficiently aligned, it will therefore use
 memory beyond that indicated solely by the init_size field.
 
 The PE/COFF headers now include a .bss section to describe the
 requirements of the init_size field, but do not currently expose the
 alignment requirement.  Consequently, a kernel loaded via the PE entry
 point may still end up overwriting unexpected areas of memory.
 
 Fix by exposing the desired alignment via the SectionAlignment field
 in the PE/COFF headers.  Despite its name, this field provides an
 overall alignment requirement for the loaded file.  (Naturally, the
 FileAlignment field describes the alignment for individual sections.)
 
 There is no way in the PE/COFF headers to express the concept of
 min_alignment; we therefore do not expose the minimum (as opposed to
 preferred) alignment.
 
 snip
 
 There may be a problem with this change. The specification says that the
 SizeOfImage field must be a multiple of SectionAlignment. That was the case
 when SectionAlignment was 0x20, but now that it is so large it would
 require quite an increase in the last section to comply. A kernel I am
 looking at now has:
 
 Alignment of sections:   0x100
 Size of image:   0x105a000
 
 Any suggested solution?

I have been reverting this patch as a workaround. The fields need to be changed,
but I am not that familiar with the code. Maybe there is a way to use a
heuristic to calculate the best values based on init_sz?
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] efi: Request desired alignment via the PE/COFF headers

2015-06-15 Thread Linn Crosetto 
Michael Brown mbrown@... writes:

 
 The kernel will align itself to the nearest boundary specified by the
 kernel_alignment field in the bzImage header.  If the kernel is loaded
 to an address which is not sufficiently aligned, it will therefore use
 memory beyond that indicated solely by the init_size field.
 
 The PE/COFF headers now include a .bss section to describe the
 requirements of the init_size field, but do not currently expose the
 alignment requirement.  Consequently, a kernel loaded via the PE entry
 point may still end up overwriting unexpected areas of memory.
 
 Fix by exposing the desired alignment via the SectionAlignment field
 in the PE/COFF headers.  Despite its name, this field provides an
 overall alignment requirement for the loaded file.  (Naturally, the
 FileAlignment field describes the alignment for individual sections.)
 
 There is no way in the PE/COFF headers to express the concept of
 min_alignment; we therefore do not expose the minimum (as opposed to
 preferred) alignment.
 
 Signed-off-by: Michael Brown mbrown@...
 ---
  arch/x86/boot/header.S | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
 index 7a6d43a..16ef025 100644
 --- a/arch/x86/boot/header.S
 +++ b/arch/x86/boot/header.S
  at  at  -154,7 +154,7  at  at  extra_header_fields:
  #else
   .quad   0   # ImageBase
  #endif
 - .long   0x20# SectionAlignment
 + .long   CONFIG_PHYSICAL_ALIGN   # SectionAlignment
   .long   0x20# FileAlignment
   .word   0   # 
MajorOperatingSystemVersion
   .word   0   # 
MinorOperatingSystemVersion

There may be a problem with this change. The specification says that the 
SizeOfImage field must be a multiple of SectionAlignment. That was the case 
when SectionAlignment was 0x20, but now that it is so large it would 
require quite an increase in the last section to comply. A kernel I am 
looking at now has:

Alignment of sections:  0x100
Size of image:  0x105a000



--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] x86: EFI stub support for large memory maps

2013-09-27 Thread Linn Crosetto 
On Thu, Sep 26, 2013 at 12:34:00PM +0100, Matt Fleming wrote:
  I might add the following to your merge for semantic reasons:
  
  diff --git a/arch/x86/boot/compressed/eboot.c 
  b/arch/x86/boot/compressed/eboot.c
  index 04b228d..a7677ba 100644
  --- a/arch/x86/boot/compressed/eboot.c
  +++ b/arch/x86/boot/compressed/eboot.c
  @@ -730,6 +730,8 @@ get_map:
  boot_params-alt_mem_k = 32 * 1024;
   
  status = setup_e820(boot_params, e820ext, e820ext_size);
  +   if (status != EFI_SUCCESS)
  +   return status;
   
  return EFI_SUCCESS;
 
 Aha, nice catch! Though if setup_e820() fails we should be jumping to
 the 'free_mem_map' label so we don't leak the memory map, like so,
 
 diff --git a/arch/x86/boot/compressed/eboot.c 
 b/arch/x86/boot/compressed/eboot.c
 index 04b228d..602950b 100644
 --- a/arch/x86/boot/compressed/eboot.c
 +++ b/arch/x86/boot/compressed/eboot.c
 @@ -730,8 +730,8 @@ get_map:
   boot_params-alt_mem_k = 32 * 1024;
  
   status = setup_e820(boot_params, e820ext, e820ext_size);
 -
 - return EFI_SUCCESS;
 + if (status == EFI_SUCCESS)
 + return status;
  
  free_mem_map:
   efi_call_phys1(sys_table-boottime-free_pool, mem_map);

Given that we have already successfully called exit_boot_services, can we still
make this call to free_pool?
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] x86: EFI stub support for large memory maps

2013-09-25 Thread Linn Crosetto 
On Wed, Sep 25, 2013 at 01:58:40PM +0100, Matt Fleming wrote:
 On Sun, 22 Sep, at 07:59:08PM, Linn Crosetto wrote:
  This patch fixes a problem with EFI memory maps larger than 128 entries
  when booting using the EFI stub, which results in overflowing e820_map
  in boot_params and an eventual halt when checking the map size in
  sanitize_e820_map().
  
  If the number of map entries is greater than what can fit in e820_map,
  add the extra entries to the setup_data list using type SETUP_E820_EXT.
  These extra entries are then picked up when the setup_data list is
  parsed in parse_e820_ext().
  
  Signed-off-by: Linn Crosetto l...@hp.com
  ---
  Changes from v2:
   * Removed unnecessary optimization in alloc_e820ext() (Matt Fleming)
   * Fixed a bug where an incorrect buffer size may be passed to
 get_memory_map when jumping to get_map
  
   arch/x86/boot/compressed/eboot.c | 239 
  +++
   1 file changed, 167 insertions(+), 72 deletions(-)
 
 Thanks Linn. I applied this to the 'next' branch at,
 
   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
 
 but it required a bit of massaging to apply on top of the changes
 already there. Could you confirm that my changes are OK? I've included
 the modified commit below.

I have tested the 'next' branch on a system with a large number of entries in
the memory map and the merge appears to be functionally correct. 

With the change in commit ae8e9060, I noticed the memory map is no longer placed
in memory allocated with low_alloc(). I have not looked into what effect it
could have, if any.

 + /* Historic? */
 + boot_params-alt_mem_k = 32 * 1024;
 +
 + status = setup_e820(boot_params, e820ext, e820ext_size);
  
   return EFI_SUCCESS;

I might add the following to your merge for semantic reasons:

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 04b228d..a7677ba 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -730,6 +730,8 @@ get_map:
boot_params-alt_mem_k = 32 * 1024;
 
status = setup_e820(boot_params, e820ext, e820ext_size);
+   if (status != EFI_SUCCESS)
+   return status;
 
return EFI_SUCCESS;


--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] x86: EFI stub support for large memory maps

2013-09-22 Thread Linn Crosetto 
On Tue, Sep 17, 2013 at 09:14:52PM +0100, Matt Fleming wrote:
  +static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
  + u32 *e820ext_size)
  +{
  +   efi_status_t status;
  +   unsigned long size;
  +
  +   size = sizeof(struct setup_data) +
  +   sizeof(struct e820entry) * nr_desc;
  +
  +   if (*e820ext  size = *e820ext_size)
  +   return EFI_SUCCESS; /* Already allocated */
 
 Do we actually need this check? I thought the 'prev_nr_desc' below
 ensures we only allocate 'e820ext' if we need more memory.

I am okay with removing the check. There is another bug in exit_boot, when
jumping to get_map the call to get the memory map is passed the previous map
size instead of the size of the allocated buffer. I'll make the changes and
resend.

 
 [...]
 
  @@ -1016,6 +1157,19 @@ get_map:
  if (status != EFI_SUCCESS)
  goto free_mem_map;
   
  +   prev_nr_desc = nr_desc;
  +   nr_desc = size / desc_size;
  +   if (nr_desc  prev_nr_desc 
  +   nr_desc  ARRAY_SIZE(boot_params-e820_map)) {
  +   u32 nr_e820ext = nr_desc - ARRAY_SIZE(boot_params-e820_map);
  +
  +   status = alloc_e820ext(nr_e820ext, e820ext, e820ext_size);
  +   if (status != EFI_SUCCESS)
  +   goto free_mem_map;
  +
  +   goto get_map; /* Allocated memory, get map again */
  +   }
  +
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3] x86: EFI stub support for large memory maps

2013-09-22 Thread Linn Crosetto 
This patch fixes a problem with EFI memory maps larger than 128 entries
when booting using the EFI stub, which results in overflowing e820_map
in boot_params and an eventual halt when checking the map size in
sanitize_e820_map().

If the number of map entries is greater than what can fit in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().

Signed-off-by: Linn Crosetto l...@hp.com
---
Changes from v2:
 * Removed unnecessary optimization in alloc_e820ext() (Matt Fleming)
 * Fixed a bug where an incorrect buffer size may be passed to
   get_memory_map when jumping to get_map

 arch/x86/boot/compressed/eboot.c | 239 +++
 1 file changed, 167 insertions(+), 72 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b7388a4..bfa177a 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -982,46 +982,198 @@ fail:
return NULL;
 }
 
+static void add_e820ext(struct boot_params *params,
+   struct setup_data *e820ext, u32 nr_entries)
+{
+   struct setup_data *data;
+   efi_status_t status;
+   unsigned long size;
+
+   e820ext-type = SETUP_E820_EXT;
+   e820ext-len = nr_entries * sizeof(struct e820entry);
+   e820ext-next = 0;
+
+   data = (struct setup_data *)(unsigned long)params-hdr.setup_data;
+
+   while (data  data-next)
+   data = (struct setup_data *)(unsigned long)data-next;
+
+   if (data)
+   data-next = (unsigned long)e820ext;
+   else
+   params-hdr.setup_data = (unsigned long)e820ext;
+}
+
+static efi_status_t setup_e820(struct boot_params *params,
+  struct setup_data *e820ext, u32 e820ext_size)
+{
+   struct e820entry *e820_map = params-e820_map[0];
+   struct efi_info *efi = params-efi_info;
+   struct e820entry *prev = NULL;
+   u32 nr_entries;
+   u32 nr_desc;
+   int i;
+
+   nr_entries = 0;
+   nr_desc = efi-efi_memmap_size / efi-efi_memdesc_size;
+
+   for (i = 0; i  nr_desc; i++) {
+   efi_memory_desc_t *d;
+   unsigned int e820_type = 0;
+   unsigned long m = efi-efi_memmap;
+
+   d = (efi_memory_desc_t *)(m + (i * efi-efi_memdesc_size));
+   switch (d-type) {
+   case EFI_RESERVED_TYPE:
+   case EFI_RUNTIME_SERVICES_CODE:
+   case EFI_RUNTIME_SERVICES_DATA:
+   case EFI_MEMORY_MAPPED_IO:
+   case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
+   case EFI_PAL_CODE:
+   e820_type = E820_RESERVED;
+   break;
+
+   case EFI_UNUSABLE_MEMORY:
+   e820_type = E820_UNUSABLE;
+   break;
+
+   case EFI_ACPI_RECLAIM_MEMORY:
+   e820_type = E820_ACPI;
+   break;
+
+   case EFI_LOADER_CODE:
+   case EFI_LOADER_DATA:
+   case EFI_BOOT_SERVICES_CODE:
+   case EFI_BOOT_SERVICES_DATA:
+   case EFI_CONVENTIONAL_MEMORY:
+   e820_type = E820_RAM;
+   break;
+
+   case EFI_ACPI_MEMORY_NVS:
+   e820_type = E820_NVS;
+   break;
+
+   default:
+   continue;
+   }
+
+   /* Merge adjacent mappings */
+   if (prev  prev-type == e820_type 
+   (prev-addr + prev-size) == d-phys_addr) {
+   prev-size += d-num_pages  12;
+   continue;
+   }
+
+   if (nr_entries == ARRAY_SIZE(params-e820_map)) {
+   u32 need = (nr_desc - i) * sizeof(struct e820entry) +
+  sizeof(struct setup_data);
+
+   if (!e820ext || e820ext_size  need)
+   return EFI_BUFFER_TOO_SMALL;
+
+   /* boot_params map full, switch to e820 extended */
+   e820_map = (struct e820entry *)e820ext-data;
+   }
+
+   e820_map-addr = d-phys_addr;
+   e820_map-size = d-num_pages  PAGE_SHIFT;
+   e820_map-type = e820_type;
+   prev = e820_map++;
+   nr_entries++;
+   }
+
+   if (nr_entries  ARRAY_SIZE(params-e820_map)) {
+   u32 nr_e820ext = nr_entries - ARRAY_SIZE(params-e820_map);
+
+   add_e820ext(params, e820ext, nr_e820ext);
+   nr_entries -= nr_e820ext;
+   }
+
+   params-e820_entries = (u8)nr_entries;
+
+   return EFI_SUCCESS;
+}
+
+static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
+ u32

[PATCH] x86: EFI stub support for large memory maps

2013-08-23 Thread Linn Crosetto 
This patch fixes a problem with EFI memory maps larger than 128 entries
when booting using the EFI stub, which results in overflowing e820_map
in boot_params and an eventual halt when checking the map size in
sanitize_e820_map().

If the number of map entries is greater than what can fit in e820_map,
add the extra entries to the setup_data list using type SETUP_E820_EXT.
These extra entries are then picked up when the setup_data list is
parsed in parse_e820_ext().

Signed-off-by: Linn Crosetto l...@hp.com
---
 arch/x86/boot/compressed/eboot.c | 220 ---
 1 file changed, 157 insertions(+), 63 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b7388a4..89fcfe6 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -982,20 +982,158 @@ fail:
return NULL;
 }
 
+static void add_e820ext(struct boot_params *params,
+   struct setup_data *e820ext, u32 nr_entries)
+{
+   struct setup_data *data;
+   efi_status_t status;
+   unsigned long size;
+
+   e820ext-type = SETUP_E820_EXT;
+   e820ext-len = nr_entries * sizeof(struct e820entry);
+   e820ext-next = 0;
+
+   data = (struct setup_data *)(unsigned long)params-hdr.setup_data;
+
+   while (data  data-next)
+   data = (struct setup_data *)(unsigned long)data-next;
+
+   if (data)
+   data-next = (unsigned long)e820ext;
+   else
+   params-hdr.setup_data = (unsigned long)e820ext;
+}
+
+static efi_status_t setup_e820(struct boot_params *params,
+  struct setup_data *e820ext, u32 e820ext_size)
+{
+   struct e820entry *e820_map = params-e820_map[0];
+   struct efi_info *efi = params-efi_info;
+   struct e820entry *prev = NULL;
+   u32 nr_entries;
+   u32 nr_desc;
+   int i;
+
+   nr_entries = 0;
+   nr_desc = efi-efi_memmap_size / efi-efi_memdesc_size;
+
+   for (i = 0; i  nr_desc; i++) {
+   efi_memory_desc_t *d;
+   unsigned int e820_type = 0;
+   unsigned long m = efi-efi_memmap;
+
+   d = (efi_memory_desc_t *)(m + (i * efi-efi_memdesc_size));
+   switch (d-type) {
+   case EFI_RESERVED_TYPE:
+   case EFI_RUNTIME_SERVICES_CODE:
+   case EFI_RUNTIME_SERVICES_DATA:
+   case EFI_MEMORY_MAPPED_IO:
+   case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
+   case EFI_PAL_CODE:
+   e820_type = E820_RESERVED;
+   break;
+
+   case EFI_UNUSABLE_MEMORY:
+   e820_type = E820_UNUSABLE;
+   break;
+
+   case EFI_ACPI_RECLAIM_MEMORY:
+   e820_type = E820_ACPI;
+   break;
+
+   case EFI_LOADER_CODE:
+   case EFI_LOADER_DATA:
+   case EFI_BOOT_SERVICES_CODE:
+   case EFI_BOOT_SERVICES_DATA:
+   case EFI_CONVENTIONAL_MEMORY:
+   e820_type = E820_RAM;
+   break;
+
+   case EFI_ACPI_MEMORY_NVS:
+   e820_type = E820_NVS;
+   break;
+
+   default:
+   continue;
+   }
+
+   /* Merge adjacent mappings */
+   if (prev  prev-type == e820_type 
+   (prev-addr + prev-size) == d-phys_addr) {
+   prev-size += d-num_pages  12;
+   continue;
+   }
+
+   if (nr_entries == ARRAY_SIZE(params-e820_map)) {
+   u32 need = (nr_desc - i) * sizeof(struct e820entry) +
+  sizeof(struct setup_data);
+
+   if (!e820ext || e820ext_size  need)
+   return EFI_BUFFER_TOO_SMALL;
+
+   /* boot_params map full, switch to e820 extended */
+   e820_map = (struct e820entry *)e820ext-data;
+   }
+
+   e820_map-addr = d-phys_addr;
+   e820_map-size = d-num_pages  PAGE_SHIFT;
+   e820_map-type = e820_type;
+   prev = e820_map++;
+   nr_entries++;
+   }
+
+   if (nr_entries  ARRAY_SIZE(params-e820_map)) {
+   u32 nr_e820ext = nr_entries - ARRAY_SIZE(params-e820_map);
+
+   add_e820ext(params, e820ext, nr_e820ext);
+   nr_entries -= nr_e820ext;
+   }
+
+   params-e820_entries = (u8)nr_entries;
+
+   return EFI_SUCCESS;
+}
+
+static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
+ u32 *e820ext_size)
+{
+   efi_status_t status;
+   unsigned long size;
+
+   size = sizeof(struct setup_data) +
+   sizeof(struct e820entry) * nr_desc;
+
+   if (*e820ext

[RFC PATCH 4/4] x86: Fix EFI boot stub for large memory maps

2013-08-19 Thread Linn Crosetto 
This patch adds support for EFI memory maps larger than 128 entries when
booted using the EFI boot stub.

The e820 map in struct boot_params can only hold 128 entries, but the
memory map provided by EFI may be larger. If the map contained more than
128 entries, exit_boot() would write beyond the e820_map array in
boot_params and the system would eventually halt in the BUG_ON check in
sanitize_e820_map().

In the case we come in through efi_main(), the EFI memory map is used.
Instead of populating e820_map in boot_params, create the e820 from the
EFI memory map in setup_arch() via a memory_setup hook.

The EFI memory map may also be added in efi_init() if the command line
parameter add_efi_memmap is specified. This is left intact to allow
the command line parameter to remain effective.

Signed-off-by: Linn Crosetto l...@hp.com
---
 arch/x86/boot/compressed/eboot.c | 64 ++--
 arch/x86/kernel/setup.c  |  3 ++
 2 files changed, 6 insertions(+), 61 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b7388a4..66b8d3d 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -973,6 +973,9 @@ struct boot_params *make_boot_params(void *handle, 
efi_system_table_t *_table)
if (status != EFI_SUCCESS)
goto fail2;
 
+   /* Use EFI memory map */
+   boot_params-e820_entries = 0;
+
return boot_params;
 fail2:
if (options_size)
@@ -986,8 +989,6 @@ static efi_status_t exit_boot(struct boot_params 
*boot_params,
  void *handle)
 {
struct efi_info *efi = boot_params-efi_info;
-   struct e820entry *e820_map = boot_params-e820_map[0];
-   struct e820entry *prev = NULL;
unsigned long size, key, desc_size, _size;
efi_memory_desc_t *mem_map;
efi_status_t status;
@@ -1049,65 +1050,6 @@ get_map:
/* Historic? */
boot_params-alt_mem_k = 32 * 1024;
 
-   /*
-* Convert the EFI memory map to E820.
-*/
-   nr_entries = 0;
-   for (i = 0; i  size / desc_size; i++) {
-   efi_memory_desc_t *d;
-   unsigned int e820_type = 0;
-   unsigned long m = (unsigned long)mem_map;
-
-   d = (efi_memory_desc_t *)(m + (i * desc_size));
-   switch (d-type) {
-   case EFI_RESERVED_TYPE:
-   case EFI_RUNTIME_SERVICES_CODE:
-   case EFI_RUNTIME_SERVICES_DATA:
-   case EFI_MEMORY_MAPPED_IO:
-   case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
-   case EFI_PAL_CODE:
-   e820_type = E820_RESERVED;
-   break;
-
-   case EFI_UNUSABLE_MEMORY:
-   e820_type = E820_UNUSABLE;
-   break;
-
-   case EFI_ACPI_RECLAIM_MEMORY:
-   e820_type = E820_ACPI;
-   break;
-
-   case EFI_LOADER_CODE:
-   case EFI_LOADER_DATA:
-   case EFI_BOOT_SERVICES_CODE:
-   case EFI_BOOT_SERVICES_DATA:
-   case EFI_CONVENTIONAL_MEMORY:
-   e820_type = E820_RAM;
-   break;
-
-   case EFI_ACPI_MEMORY_NVS:
-   e820_type = E820_NVS;
-   break;
-
-   default:
-   continue;
-   }
-
-   /* Merge adjacent mappings */
-   if (prev  prev-type == e820_type 
-   (prev-addr + prev-size) == d-phys_addr)
-   prev-size += d-num_pages  12;
-   else {
-   e820_map-addr = d-phys_addr;
-   e820_map-size = d-num_pages  12;
-   e820_map-type = e820_type;
-   prev = e820_map++;
-   nr_entries++;
-   }
-   }
-
-   boot_params-e820_entries = nr_entries;
-
return EFI_SUCCESS;
 
 free_mem_map:
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f8ec578..9682c8c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -920,6 +920,9 @@ void __init setup_arch(char **cmdline_p)
 
if (efi_enabled(EFI_BOOT))
efi_memblock_x86_reserve_range();
+
+   if (efi_memmap_needed())
+   x86_init.resources.memory_setup = efi_memory_setup;
 #endif
 
x86_init.oem.arch_setup();
-- 
1.7.11.3

--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/4] EFI boot stub memory map fix

2013-08-19 Thread Linn Crosetto 
On Mon, Aug 19, 2013 at 01:47:41PM -0700, Yinghai Lu wrote:
 On Mon, Aug 19, 2013 at 1:06 PM, H. Peter Anvin h...@zytor.com wrote:
  I would strongly disagree that option 2 is the cleaner solution.
 
 Agreed.
 
 
  Linn Crosetto l...@hp.com wrote:
 I realize the EFI stub for ARM patches are in flight,
 
 https://lkml.org/lkml/2013/8/9/554
 
 and overlap with some of the files but I wanted to send these out for
 comment.
 
 This series fixes a problem with EFI memory maps larger than 128
 entries when
 booting using the EFI boot stub, which results in overflowing the
 e820_map in
 boot_params and an eventual halt when checking the map size in
 sanitize_e820_map().
 
 The fix implemented is to add the EFI memory map from setup_arch() via
 a
 memory_setup hook.
 
 Two options were considered:
 
  1. Use the SETUP_E820_EXT setup_data type to add the extra entries.
 
 2. Create a memory_setup function to be enabled when the EFI memory map
 is
 needed.
 
 Option 2 appeared to be the cleaner solution, reducing duplication with
 existing code, given a reasonable mechanism for determining when to
 replace the default memory_setup function.
 
 If boot_loader could create setup_data with SETUP_E820_EXT,
 efi_stub should go that path too.
 We should not add another path.

My consideration was in leveraging do_add_efi_memmap(), which duplicates what is
done with the map in exit_boot(), and can already be called via the
add_efi_memmap parameter. One complication with SETUP_E820_EXT is in
determining the size needed, since a call to allocate_pool will change the
memory map. 

I will send another version which uses SETUP_E820_EXT.

Thanks,
Linn
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html