I am reading some tutorials how to EFI stub (efistub) load the Linux kernel. These instructions often use kernel boot parameter add_efi_memmap. The intended hardware is Intel x64 having 8GB of RAM. My current setup is running grub-efi bootloader and kernel v3.13.GRUB boot without the add_efi_memmap boot argument:23 BIOS-e820 lines counted by dmesg | grep BIOS-e820: | wc -l 243 EFI memory lines counted by dmesg | grep efi:\ mem | wc -lDMA zone: 24 pages reservedMemory: 7840568K/8283384K available442816K reservedGRUB boot with add_efi_memmap and the EFI memory map size does seem to differ:23 BIOS-e820 lines57 EFI memory linesDMA zone: 22 pages reservedMemory: 7885076K/8283384K available398308K reservedEFI stub boot without add_efi_memmap:22 BIOS-e820 lines60 EFI memory linesDMA zone: 21 pages reservedMemory: 7885012K/8283384K availableEFI stub boot with add_efi_memmap:22 BIOS-e820 lines66 EFI memory linesDMA zone: 21 pages reservedMemory: 7882124K/8283384K availableAfter reading more information - as inlined below - I can't figure out whether to add add_efi_memmap or not. It does something extra which doesn't seem absolutely necessary to boot. On the other hand it can give to give a better (more complete) view of usable memory.In which cases should this add_efi_memmap boot argument be used for EFI stub booting? Would that increase/decrease EFI stub boot speed, and increase or decrease free memory, available for applications? How to (better) check if my EFI memory map includes more entries then my E820 map?Some add_efi_memmep documentation already consulted:add_efi_memmap    : include EFI memory map of available physical RAM.If the EFI memory map has additional entries not in the E820 map,    you can include those entries in the kernels memory map of available    physical RAM by using the following kernel command line parameter. - https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txtInstead of always adding EFI memory map entries (if present) to the memory map after initially finding either E820 BIOS memory map entries and/or kernel command line memmap entries, -instead- only add such additional EFI memory map entries if the kernel boot option: add_efi_memmap is specified. - http://www.gossamer-threads.com/lists/linux/kernel/937817Boot freezes - If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the add_efi_memmap kernel parameter. - https://wiki.archlinux.org/index.php/GRUB#Boot_freezesThis patch changes the behavior of the kexec loader when the add_efi_memmap option is present on the currently running kernel's command line, to read the kernel memory map from /proc/iomem instead of /sys/firmware/memmap. On EFI systems, sometimes the e820 table is missing or incomplete. Systems like these use the add_efi_memmap option to add EFI's memory table entries to the kernel's memory table to build a complete picture of the system's memory; however, using the option does not add these entries to the table used to populate /sys/firmware/memmap, which is meant to be a pristine original copy. The kexec loader uses the pristine memory map by default, which causes problems when the loader doesn't have a complete picture of the system and incorrectly loads the kernel or ramdisk in places that aren't actually usable. This change makes the kexec loader check the running kernel's command line for the add_efi_memmap option and if it finds it, will use the modified map instead of the original map. - http://lists.infradead.org/pipermail/kexec/2011-April/005014.htmlThe solution (hack), arrived at by the Linux kernel developers in 2009 after a number of false starts was to add a kernel command line option, add_efi_memmap  to tell the kernel to look at the EFI memory map and use it to fix up various entries in the E820 memory map. - http://blog.fpmurphy.com/2012/08/uefi-memory-v-e820-memory.html
When do I need to specify add_efi_memmap as kernel argument in UEFI/EFI boot?
boot;linux kernel;arguments;uefi