Pro*_*kup 30 boot linux-kernel arguments uefi
我正在阅读一些如何使用 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 -l 243EFI 内存行计数dmesg | grep efi:\ mem | wc -l24保留的页面GRUB引导与 add_efi_memmap和EFI存储器映射大小似乎确实有所不同：
23 BIOS-e820线57 EFI 内存线22保留的页面EFI 存根启动没有 add_efi_memmap：
22 BIOS-e820线60 EFI 内存线21保留的页面EFI存根启动用 add_efi_memmap：
22 BIOS-e820线66 EFI 内存线21保留的页面阅读更多信息后 - 如下内联 - 我不知道是否添加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
引导加载程序（或 Grub）会像 e820 一样重建内存映射，我想这就是您在 GRUB 和 EFI 存根加载程序之间看到不同值的原因。
Linux 源代码中有一条注释，指出 EFI 允许“超过 e820 旧版（零页）内存映射所能容纳的最大 128 个条目”。根据您发布的数字，情况似乎并非如此，因此我怀疑添加 add_efi_memmap 是否有帮助...但是，解析此表当然也没有什么坏处...