From nobody Mon Feb 9 12:00:48 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08D1E1F94C for ; Tue, 28 Jan 2025 13:32:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738071157; cv=none; b=UIXxIr6xlSu7ucQiCIRfCAhbfa3/uRrAD76G2GnsvXH91lG3m2KhsVftUutw4dHGA+VD6SxZDdFaz8ahRPunI0rn9luVE+/kW0UnKOP+8Ji4FVPaQgtY0d2HIXFIv93r/eSvowyiawQ+cTRUUJtSm4bxiB3vKs/S+mt/jtj7Um4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738071157; c=relaxed/simple; bh=Gcu1WlFqsJWtRPoe7y31OgR1uYWFLPbZcdC1b8zTjWs=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=e/e5eXewwwB1kNzjxYKCJf+myuHYAJPxRztLNB21Y6oB9onUltExtadK6pS9oHOG3PL7r+ilJR0yCOZlxKIP81JNGuikiLaO0vf+lpOcsEs0Jj+46Q547aQdndeGtg7vj5o7BvLO9hlaEbVHw6i31erSe1dXB3Zod/PeqiFfePQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=RFCS2/24; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RFCS2/24" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738071154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=7uGPDiM/aT21JK8Udc8cgfvM3p7HgJwTb2VLlWtFODk=; b=RFCS2/243oVV9WNgC0QCDu6OhgKurP6i5P1KTFootNTj8Ms0+zBw1J/xY9U0rmcx8QA9Mz NRuy3eupsrVBe2YpV61asZk1ZskNSaZejc75ZzfTpkrk94WgSC2LPSnfN/AuDm0aMXxhYK It8SwOsGKBvKbXE2/62r7jVI0SKBx28= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-317-kvesU07HPAmL6V3NHYGJtg-1; Tue, 28 Jan 2025 08:32:31 -0500 X-MC-Unique: kvesU07HPAmL6V3NHYGJtg-1 X-Mimecast-MFC-AGG-ID: kvesU07HPAmL6V3NHYGJtg Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 090C61800A11; Tue, 28 Jan 2025 13:32:24 +0000 (UTC) Received: from darkstar.users.ipa.redhat.com (unknown [10.72.112.4]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3E1E919560A3; Tue, 28 Jan 2025 13:32:16 +0000 (UTC) Date: Tue, 28 Jan 2025 21:32:31 +0800 From: Dave Young To: Borislav Petkov , Ingo Molnar , x86@kernel.org Cc: Chen Yu , Andrew Morton , linux-kernel@vger.kernel.org, Ashish Kalra , kexec@lists.infradead.org Subject: [PATCH] x86/kexec: export e820_table_kexec to sysfs Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 se= tup_data") Signed-off-by: Dave Young --- 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 r= emaining * (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 C= RC32 * checksum of the physical memory layout of a system. * * - 'e820_table_kexec': a slightly modified (by the kernel) firmware vers= ion * passed to us by the bootloader - the major difference between - * e820_table_firmware[] and this one is that, the latter marks the setu= p_data - * list created by the EFI boot stub as reserved, so that kexec can reus= e the - * setup_data information in the second kernel. Besides, e820_table_kexe= c[] - * 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++; } =20 - /* Expose the bootloader-provided memory layout to the sysfs. */ - for (i =3D 0; i < e820_table_firmware->nr_entries; i++) { - struct e820_entry *entry =3D e820_table_firmware->entries + i; + /* Expose the kexec e820 table to the sysfs. */ + for (i =3D 0; i < e820_table_kexec->nr_entries; i++) { + struct e820_entry *entry =3D e820_table_kexec->entries + i; =20 firmware_map_add_early(entry->addr, entry->addr + entry->size, e820_type= _to_string(entry)); } Index: linux/arch/x86/virt/svm/sev.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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_RA= M, E820_TYPE_RESERVED); if (!memblock_is_region_reserved(pa, PMD_SIZE)) memblock_reserve(pa, PMD_SIZE); }