我正在阅读一些教程，了解如何EFI存根（efistub）加载Linux内核。这些指令通常使用内核引导参数add_efi_memmap。预期的硬件是具有8GB RAM的Intel x64。我当前的设置正在运行grub-efi引导程序和内核v3.13。
GRUB引导，而不在add_efi_memmap引导参数：
23BIOS-e820行数dmesg | grep BIOS-e820: | wc -l243EFI内存行的计数dmesg | grep efi:\ mem | wc -l- DMA区域：
24保留页 - 内存：7840568K / 8283384K可用
- 442816K保留
GRUB引导与 add_efi_memmap EFI内存映射的大小似乎有所不同：
23BIOS-e820行57EFI内存线- DMA区域：
22保留页 - 内存：7885076K / 8283384K
- 398308K保留
EFI存根启动不包含 add_efi_memmap：
22BIOS-e820行60EFI内存线- DMA区域：
21保留页 - 内存：可用7885012K / 8283384K
EFI存根启动用 add_efi_memmap：
22BIOS-e820行66EFI内存线- DMA区域：
21保留页 - 内存：7882124K / 8283384K可用
阅读更多信息后（如下所示），我不知道是否要添加add_efi_memmap。它做了一些额外的事情，似乎并不需要绝对引导。另一方面，它可以给出更好（更完整）的可用内存视图。
在哪种情况下，应将此add_efi_memmap引导参数用于EFI存根引导？是否可以增加/减少EFI存根启动速度，以及增加或减少可用内存，供应用程序使用？如何（更好）检查我的EFI内存映射是否比E820映射包含更多条目？
已经参考了一些add_efi_memmep文档：
add_efi_memmap ：包括可用物理RAM的EFI内存映射。
如果EFI内存映射在E820映射中没有其他条目，则可以使用以下内核命令行参数将这些条目包括在可用物理RAM的内核内存映射中。- https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt
最初查找E820 BIOS内存映射条目和/或内核命令行内存映射条目之后，不总是将EFI内存映射条目（如果存在）添加到内存映射中，而是仅在内核启动选项下添加此类额外的EFI内存映射条目。 ：
add_efi_memmap指定。- http://www.gossamer-threads.com/lists/linux/kernel/937817
引导冻结 -如果在GRUB加载内核和初始ramdisk之后引导被卡住而没有任何错误消息，请尝试删除add_efi_memmap内核参数。- https://wiki.archlinux.org/index.php/GRUB#Boot_freezes
当
add_efi_memmap当前运行的内核命令行上存在该选项时，此修补程序会更改kexec加载程序的行为，以便从而/proc/iomem不是从中读取内核内存映射/sys/firmware/memmap。在EFI系统上，有时e820表丢失或不完整。诸如此类的系统使用该
add_efi_memmap选项将EFI的内存表条目添加到内核的内存表中，以构建系统内存的完整图片。但是，使用该选项不会将这些条目添加到用于填充的表中，该表/sys/firmware/memmap是原始副本。默认情况下，kexec加载程序使用原始内存映射，当加载程序没有完整的系统图片时，这会导致问题，并在实际上不可用的地方错误地加载内核或ramdisk。此更改使kexec加载程序检查正在运行的内核的命令行中是否存在该
add_efi_memmap选项，如果找到了该选项，它将使用修改后的映射而不是原始映射。- http://lists.infradead.org/pipermail/kexec/2011-April/005014.html
Linux内核开发人员在多次错误的启动之后于2009年提出了解决方案（hack），方法是添加内核命令行选项，
add_efi_memmap以告诉内核查看EFI内存映射并使用它来修复各种条目。在E820内存映射中。- http://blog.fpmurphy.com/2012/08/uefi-memory-v-e820-memory.html