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 <hpa@xxxxxxxxx> wrote: > > I would strongly disagree that option 2 is the cleaner solution. > > Agreed. > > > > > Linn Crosetto <linn@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html