mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org
Cc: Chen Yu <yu.c.chen@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Ashish Kalra <ashish.kalra@amd.com>,
	kexec@lists.infradead.org
Subject: [PATCH] x86/kexec: export e820_table_kexec to sysfs
Date: Tue, 28 Jan 2025 21:32:31 +0800	[thread overview]
Message-ID: <Z5jcb1GKhLvH8kDc@darkstar.users.ipa.redhat.com> (raw)

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@redhat.com>
---
 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);
 	}


             reply	other threads:[~2025-01-28 13:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 13:32 Dave Young [this message]
2025-02-22 11:56 ` [tip: x86/boot] x86/kexec: Export e820_table_kexec[] " tip-bot2 for Dave Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z5jcb1GKhLvH8kDc@darkstar.users.ipa.redhat.com \
    --to=dyoung@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®