Previously the e820_table_kexec was exported to sysfs since kexec-tools uses the memmap entries to prepare the e820 table for the new kernel. Commit[1] introduced e820_table_firmware and changed the behavior to export the firmware table instead. Originally kexec_file_load and kexec_load both use e820_table_kexec. Since the sysfs exported entries are from e820_table_firmware people now need to tune both tables for kexec. Restore the old behavior so kexec_load and kexec_file_load work with only one table update. The e820_table_firmware is used by hibernation kernel code and it works without the sysfs exporting. Also remove the sev e820_table_firmware updating code. Also update the code comments here and drop the comments about setup_data reservation since it is not needed any more after commit [2]. [1]: commit 12df216c61c8 ("x86/boot/e820: Introduce the bootloader provided e820_table_firmware[] table") [2]: commit fc7f27cda843 ("x86/kexec: Do not update E820 kexec table for setup_data") Signed-off-by: Dave Young <dyoung@xxxxxxxxxx> --- arch/x86/kernel/e820.c | 20 ++++++++++---------- arch/x86/virt/svm/sev.c | 1 - 2 files changed, 10 insertions(+), 11 deletions(-) Index: linux/arch/x86/kernel/e820.c =================================================================== --- linux.orig/arch/x86/kernel/e820.c 2025-01-28 11:27:02.372171910 +0800 +++ linux/arch/x86/kernel/e820.c 2025-01-28 20:36:00.031075385 +0800 @@ -28,18 +28,13 @@ * the first 128 E820 memory entries in boot_params.e820_table and the remaining * (if any) entries of the SETUP_E820_EXT nodes. We use this to: * - * - inform the user about the firmware's notion of memory layout - * via /sys/firmware/memmap - * * - the hibernation code uses it to generate a kernel-independent CRC32 * checksum of the physical memory layout of a system. * * - 'e820_table_kexec': a slightly modified (by the kernel) firmware version * passed to us by the bootloader - the major difference between - * e820_table_firmware[] and this one is that, the latter marks the setup_data - * list created by the EFI boot stub as reserved, so that kexec can reuse the - * setup_data information in the second kernel. Besides, e820_table_kexec[] - * might also be modified by the kexec itself to fake a mptable. + * e820_table_firmware[] and this one is that e820_table_kexec[] + * might be modified by the kexec itself to fake a mptable. * We use this to: * * - kexec, which is a bootloader in disguise, uses the original E820 @@ -47,6 +42,11 @@ * can have a restricted E820 map while the kexec()-ed kexec-kernel * can have access to full memory - etc. * + * Export the memory layout via /sys/firmware/memmap. kexec-tools uses + * the entries to create an E820 table for kexec kernel. + * + * kexec_file_load in-kernel code uses the table for kexec kernel. + * * - 'e820_table': this is the main E820 table that is massaged by the * low level x86 platform code, or modified by boot parameters, before * passed on to higher level MM layers. @@ -1176,9 +1176,9 @@ res++; } - /* Expose the bootloader-provided memory layout to the sysfs. */ - for (i = 0; i < e820_table_firmware->nr_entries; i++) { - struct e820_entry *entry = e820_table_firmware->entries + i; + /* Expose the kexec e820 table to the sysfs. */ + for (i = 0; i < e820_table_kexec->nr_entries; i++) { + struct e820_entry *entry = e820_table_kexec->entries + i; firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type_to_string(entry)); } Index: linux/arch/x86/virt/svm/sev.c =================================================================== --- linux.orig/arch/x86/virt/svm/sev.c 2025-01-28 20:21:32.253078107 +0800 +++ linux/arch/x86/virt/svm/sev.c 2025-01-28 20:23:19.653201528 +0800 @@ -198,7 +198,6 @@ pr_info("Reserving start/end of RMP table on a 2MB boundary [0x%016llx]\n", pa); e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED); e820__range_update_table(e820_table_kexec, pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED); - e820__range_update_table(e820_table_firmware, pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED); if (!memblock_is_region_reserved(pa, PMD_SIZE)) memblock_reserve(pa, PMD_SIZE); }