All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Rick Edgecombe  <rick.p.edgecombe@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"Kalra, Ashish" <ashish.kalra@amd.com>,
	Sean Christopherson <seanjc@google.com>,
	"Huang, Kai" <kai.huang@intel.com>, Baoquan He <bhe@redhat.com>,
	kexec@lists.infradead.org, linux-coco@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>
Subject: [PATCHv8 11/17] x86/mm: Make e820_end_ram_pfn() cover E820_TYPE_ACPI ranges
Date: Tue, 27 Feb 2024 23:24:46 +0200	[thread overview]
Message-ID: <20240227212452.3228893-12-kirill.shutemov@linux.intel.com> (raw)
In-Reply-To: <20240227212452.3228893-1-kirill.shutemov@linux.intel.com>

e820__end_of_ram_pfn() is used to calculate max_pfn which, among other
things, guides where direct mapping ends. Any memory above max_pfn is
not going to be present in the direct mapping.

e820__end_of_ram_pfn() finds the end of the ram based on the highest
E820_TYPE_RAM range. But it doesn't includes E820_TYPE_ACPI ranges into
calculation.

Despite the name, E820_TYPE_ACPI covers not only ACPI data, but also EFI
tables and might be required by kernel to function properly.

Usually the problem is hidden because there is some E820_TYPE_RAM memory
above E820_TYPE_ACPI. But crashkernel only presents pre-allocated crash
memory as E820_TYPE_RAM on boot. If the preallocated range is small, it
can fit under the last E820_TYPE_ACPI range.

Modify e820__end_of_ram_pfn() and e820__end_of_low_ram_pfn() to cover
E820_TYPE_ACPI memory.

The problem was discovered during debugging kexec for TDX guest. TDX
guest uses E820_TYPE_ACPI to store the unaccepted memory bitmap and pass
it between the kernels on kexec.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
---
 arch/x86/kernel/e820.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index fb8cf953380d..99c80680dc9e 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -827,7 +827,7 @@ u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
 /*
  * Find the highest page frame number we have available
  */
-static unsigned long __init e820_end_pfn(unsigned long limit_pfn, enum e820_type type)
+static unsigned long __init e820_end_ram_pfn(unsigned long limit_pfn)
 {
 	int i;
 	unsigned long last_pfn = 0;
@@ -838,7 +838,8 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn, enum e820_type
 		unsigned long start_pfn;
 		unsigned long end_pfn;
 
-		if (entry->type != type)
+		if (entry->type != E820_TYPE_RAM &&
+		    entry->type != E820_TYPE_ACPI)
 			continue;
 
 		start_pfn = entry->addr >> PAGE_SHIFT;
@@ -864,12 +865,12 @@ static unsigned long __init e820_end_pfn(unsigned long limit_pfn, enum e820_type
 
 unsigned long __init e820__end_of_ram_pfn(void)
 {
-	return e820_end_pfn(MAX_ARCH_PFN, E820_TYPE_RAM);
+	return e820_end_ram_pfn(MAX_ARCH_PFN);
 }
 
 unsigned long __init e820__end_of_low_ram_pfn(void)
 {
-	return e820_end_pfn(1UL << (32 - PAGE_SHIFT), E820_TYPE_RAM);
+	return e820_end_ram_pfn(1UL << (32 - PAGE_SHIFT));
 }
 
 static void __init early_panic(char *msg)
-- 
2.43.0


  parent reply	other threads:[~2024-02-27 21:25 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 21:24 [PATCHv8 00/17, CORRECTED] x86/tdx: Add kexec support Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 01/17] x86/acpi: Extract ACPI MADT wakeup code into a separate file Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 02/17] x86/apic: Mark acpi_mp_wake_* variables as __ro_after_init Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 03/17] cpu/hotplug: Add support for declaring CPU offlining not supported Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 04/17] cpu/hotplug, x86/acpi: Disable CPU offlining for ACPI MADT wakeup Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 05/17] x86/kexec: Keep CR4.MCE set during kexec for TDX guest Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 06/17] x86/mm: Make x86_platform.guest.enc_status_change_*() return errno Kirill A. Shutemov
2024-02-27 23:33   ` Huang, Kai
2024-02-27 23:33     ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 07/17] x86/mm: Return correct level from lookup_address() if pte is none Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 08/17] x86/tdx: Account shared memory Kirill A. Shutemov
2024-02-27 23:12   ` Huang, Kai
2024-02-27 23:12     ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 09/17] x86/mm: Adding callbacks to prepare encrypted memory for kexec Kirill A. Shutemov
2024-02-27 23:16   ` Huang, Kai
2024-02-27 23:16     ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 10/17] x86/tdx: Convert shared memory back to private on kexec Kirill A. Shutemov
2024-02-27 23:30   ` Huang, Kai
2024-02-27 23:30     ` Huang, Kai
2024-02-27 21:24 ` Kirill A. Shutemov [this message]
2024-02-27 21:24 ` [PATCHv8 12/17] x86/acpi: Rename fields in acpi_madt_multiproc_wakeup structure Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 13/17] x86/acpi: Do not attempt to bring up secondary CPUs in kexec case Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 14/17] x86/smp: Add smp_ops.stop_this_cpu() callback Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 15/17] x86/mm: Introduce kernel_ident_mapping_free() Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 16/17] x86/acpi: Add support for CPU offlining for ACPI MADT wakeup method Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 17/17] ACPI: tables: Print MULTIPROC_WAKEUP when MADT is parsed Kirill A. Shutemov
2024-02-27 21:30   ` Kuppuswamy Sathyanarayanan
2024-02-27 21:30     ` Kuppuswamy Sathyanarayanan
2024-02-27 22:08   ` Huang, Kai
2024-02-27 22:08     ` Huang, Kai
2024-02-28 15:22     ` Kirill A. Shutemov
2024-02-28 15:22       ` Kirill A. Shutemov
2024-02-28 21:19       ` Huang, Kai
2024-02-28 21:19         ` Huang, Kai
2024-03-06 15:02 ` [PATCHv8 00/17, CORRECTED] x86/tdx: Add kexec support Kirill A. Shutemov
2024-03-06 15:02   ` Kirill A. Shutemov
2024-03-07  6:57   ` Tao Liu
2024-03-07  6:57     ` Tao Liu
2024-03-18  7:02 ` [PATCH v2 0/3] x86/snp: " Ashish Kalra
2024-03-18  7:02   ` Ashish Kalra
2024-03-18  7:02   ` [PATCH v2 1/3] efi/x86: skip efi_arch_mem_reserve() in case of kexec Ashish Kalra
2024-03-18  7:02     ` Ashish Kalra
2024-03-19  4:00     ` Dave Young
2024-03-19  4:00       ` Dave Young
2024-03-24 22:32       ` Kalra, Ashish
2024-03-24 22:32         ` Kalra, Ashish
2024-03-18  7:02   ` [PATCH v2 2/3] x86/mm: Do not zap page table entries mapping unaccepted memory table during kdump Ashish Kalra
2024-03-18  7:02     ` Ashish Kalra
2024-03-21 14:58     ` Kirill A. Shutemov
2024-03-21 14:58       ` Kirill A. Shutemov
2024-03-18  7:02   ` [PATCH v2 3/3] x86/snp: Convert shared memory back to private on kexec Ashish Kalra
2024-03-18  7:02     ` Ashish Kalra

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=20240227212452.3228893-12-kirill.shutemov@linux.intel.com \
    --to=kirill.shutemov@linux.intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=ashish.kalra@amd.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=elena.reshetova@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.