When do I need to specify add_efi_memmap as kernel argument in UEFI/EFI boot?

Question

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 -l}
• DMA zone: 24 pages reserved
• Memory: 7840568K/8283384K available
• 442816K reserved

GRUB boot with add_efi_memmap and the EFI memory map size does seem to differ:

• 23 BIOS-e820 lines
• 57 EFI memory lines
• DMA zone: 22 pages reserved
• Memory: 7885076K/8283384K available
• 398308K reserved

EFI stub boot without add_efi_memmap:

• 22 BIOS-e820 lines
• 60 EFI memory lines
• DMA zone: 21 pages reserved
• Memory: 7885012K/8283384K available

EFI stub boot with add_efi_memmap:

• 22 BIOS-e820 lines
• 66 EFI memory lines
• DMA zone: 21 pages reserved
• Memory: 7882124K/8283384K available

After 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.txt

---

Instead 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/937817

---

Boot 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_freezes

---

This 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.html

---

The 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

Answer 1

Boot loaders, or Grub for that matter, rebuilds the memory map like e820, I guess this is the reason why you are seeing different values between GRUB and the EFI stub loader.

There is a comment in the Linux source code which says that EFI allows "more than the max 128 entries that can fit in the e820 legacy (zeropage) memory map.". This seems not to be the case according to the numbers you posted, hence I doubt that adding add_efi_memmap is helpful... However, it certainly doesn't hurt to parse this table too...

Answer 2

If your Linux distribution successfully EFI STUB boots, there is no need to use add_efi_memmap. This kernel command line option is rarely needed nowadays - UEFI firmware and Linux kernel support for same has significantly improved since 2009 era.