linux-stable.git/arch/x86/kernel/e820.c, branch linux-rolling-stable

x86: Restrict KVM-induced symbol exports to KVM modules where obvious/possible

2025-11-12T23:29:38+00:00

Extend KVM's export macro framework to provide EXPORT_SYMBOL_FOR_KVM(),
and use the helper macro to export symbols for KVM throughout x86 if and
only if KVM will build one or more modules, and only for those modules.

To avoid unnecessary exports when CONFIG_KVM=m but kvm.ko will not be
built (because no vendor modules are selected), let arch code #define
EXPORT_SYMBOL_FOR_KVM to suppress/override the exports.

Note, the set of symbols to restrict to KVM was generated by manual search
and audit; any "misses" are due to human error, not some grand plan.

Signed-off-by: Sean Christopherson 
Signed-off-by: Dave Hansen 
Acked-by: Kai Huang 
Tested-by: Kai Huang 
Link: https://patch.msgid.link/20251112173944.1380633-5-seanjc%40google.com

x86/e820: temporarily enable KHO scratch for memory below 1M

2025-05-13T06:50:41+00:00

KHO kernels are special and use only scratch memory for memblock
allocations, but memory below 1M is ignored by kernel after early boot and
cannot be naturally marked as scratch.

To allow allocation of the real-mode trampoline and a few (if any) other
very early allocations from below 1M forcibly mark the memory below 1M as
scratch.

After real mode trampoline is allocated, clear that scratch marking.

Link: https://lkml.kernel.org/r/20250509074635.3187114-13-changyuanl@google.com
Signed-off-by: Alexander Graf 
Co-developed-by: Mike Rapoport (Microsoft) 
Signed-off-by: Mike Rapoport (Microsoft) 
Co-developed-by: Changyuan Lyu 
Signed-off-by: Changyuan Lyu 
Acked-by: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Anthony Yznaga 
Cc: Arnd Bergmann 
Cc: Ashish Kalra 
Cc: Ben Herrenschmidt 
Cc: Borislav Betkov 
Cc: Catalin Marinas 
Cc: David Woodhouse 
Cc: Eric Biederman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: James Gowans 
Cc: Jason Gunthorpe 
Cc: Jonathan Corbet 
Cc: Krzysztof Kozlowski 
Cc: Marc Rutland 
Cc: Paolo Bonzini 
Cc: Pasha Tatashin 
Cc: Peter Zijlstra 
Cc: Pratyush Yadav 
Cc: Rob Herring 
Cc: Saravana Kannan 
Cc: Stanislav Kinsburskii 
Cc: Steven Rostedt 
Cc: Thomas Gleinxer 
Cc: Thomas Lendacky 
Cc: Will Deacon 
Signed-off-by: Andrew Morton

x86/e820: Discard high memory that can't be addressed by 32-bit systems

2025-04-19T14:48:18+00:00

Dave Hansen reports the following crash on a 32-bit system with
CONFIG_HIGHMEM=y and CONFIG_X86_PAE=y:

  > 0xf75fe000 is the mem_map[] entry for the first page >4GB. It
  > obviously wasn't allocated, thus the oops.

  BUG: unable to handle page fault for address: f75fe000
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  *pdpt = 0000000002da2001 *pde = 000000000300c067 *pte = 0000000000000000
  Oops: Oops: 0002 [#1] SMP NOPTI
  CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc1-00288-ge618ee89561b-dirty #311 PREEMPT(undef)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  EIP: __free_pages_core+0x3c/0x74
  ...
  Call Trace:
   memblock_free_pages+0x11/0x2c
   memblock_free_all+0x2ce/0x3a0
   mm_core_init+0xf5/0x320
   start_kernel+0x296/0x79c
   i386_start_kernel+0xad/0xb0
   startup_32_smp+0x151/0x154

The mem_map[] is allocated up to the end of ZONE_HIGHMEM which is defined
by max_pfn.

The bug was introduced by this recent commit:

  6faea3422e3b ("arch, mm: streamline HIGHMEM freeing")

Previously, freeing of high memory was also clamped to the end of
ZONE_HIGHMEM but after this change, memblock_free_all() tries to
free memory above the of ZONE_HIGHMEM as well and that causes
access to mem_map[] entries beyond the end of the memory map.

To fix this, discard the memory after max_pfn from memblock on
32-bit systems so that core MM would be aware only of actually
usable memory.

Fixes: 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing")
Reported-by: Dave Hansen 
Tested-by: Arnd Bergmann 
Signed-off-by: Mike Rapoport (Microsoft) 
Signed-off-by: Ingo Molnar 
Cc: Andy Shevchenko 
Cc: Arnd Bergmann 
Cc: Davide Ciminaghi 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Matthew Wilcox 
Cc: Paolo Bonzini 
Cc: Sean Christopherson 
Cc: kvm@vger.kernel.org
Link: https://lore.kernel.org/r/20250413080858.743221-1-rppt@kernel.org # discussion and submission

x86/e820: Fix handling of subpage regions when calculating nosave ranges in e820__register_nosave_regions()

2025-04-07T17:20:08+00:00

While debugging kexec/hibernation hangs and crashes, it turned out that
the current implementation of e820__register_nosave_regions() suffers from
multiple serious issues:

 - The end of last region is tracked by PFN, causing it to find holes
   that aren't there if two consecutive subpage regions are present

 - The nosave PFN ranges derived from holes are rounded out (instead of
   rounded in) which makes it inconsistent with how explicitly reserved
   regions are handled

Fix this by:

 - Treating reserved regions as if they were holes, to ensure consistent
   handling (rounding out nosave PFN ranges is more correct as the
   kernel does not use partial pages)

 - Tracking the end of the last RAM region by address instead of pages
   to detect holes more precisely

These bugs appear to have been introduced about ~18 years ago with the very
first version of e820_mark_nosave_regions(), and its flawed assumptions were
carried forward uninterrupted through various waves of rewrites and renames.

[ mingo: Added Git archeology details, for kicks and giggles. ]

Fixes: e8eff5ac294e ("[PATCH] Make swsusp avoid memory holes and reserved memory regions on x86_64")
Reported-by: Roberto Ricci 
Tested-by: Roberto Ricci 
Signed-off-by: Myrrh Periwinkle 
Signed-off-by: Ingo Molnar 
Cc: Rafael J. Wysocki 
Cc: Ard Biesheuvel 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: David Woodhouse 
Cc: Len Brown 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250406-fix-e820-nosave-v3-1-f3787bc1ee1d@qtmlabs.xyz
Closes: https://lore.kernel.org/all/Z4WFjBVHpndct7br@desktop0a/

x86/kexec: Export e820_table_kexec[] to sysfs

2025-02-22T11:44:45+00:00

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.

The following commit, ~8 years ago, introduced e820_table_firmware[] and changed
the behavior to export the firmware table instead:

  12df216c61c8 ("x86/boot/e820: Introduce the bootloader provided e820_table_firmware[] table")

Originally the kexec_file_load and kexec_load syscalls both used 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 the kexec_load and kexec_file_load syscalls 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 this change was made
a year ago:

  fc7f27cda843 ("x86/kexec: Do not update E820 kexec table for setup_data")

[ mingo: Tidy up the changelog and comments. ]

Signed-off-by: Dave Young 
Signed-off-by: Ingo Molnar 
Cc: Ashish Kalra 
Cc: Sean Christopherson 
Cc: Joerg Roedel 
Cc: Baoquan He 
Cc: Vivek Goyal 
Cc: Eric Biederman 
Link: https://lore.kernel.org/r/Z5jcb1GKhLvH8kDc@darkstar.users.ipa.redhat.com

x86/e820: Drop obsolete E820_TYPE_RESERVED_KERN and related code

2025-02-21T15:05:00+00:00

E820_TYPE_RESERVED_KERN is a relict from the ancient history that was used
to early reserve setup_data, see:

  28bb22379513 ("x86: move reserve_setup_data to setup.c")

Nowadays setup_data is anyway reserved in memblock and there is no point in
carrying E820_TYPE_RESERVED_KERN that behaves exactly like E820_TYPE_RAM
but only complicates the code.

A bonus for removing E820_TYPE_RESERVED_KERN is a small but measurable
speedup of 20 microseconds in init_mem_mappings() on a VM with 32GB or RAM.

Signed-off-by: Mike Rapoport (Microsoft) 
Signed-off-by: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Ard Biesheuvel 
Cc: Kees Cook 
Link: https://lore.kernel.org/r/20250214090651.3331663-5-rppt@kernel.org

x86/boot: Move setting of memblock parameters to e820__memblock_setup()

2025-02-21T15:05:00+00:00

Changing memblock parameters, namely bottom_up and allocation upper
limit does not have any effect before memblock initialization in
e820__memblock_setup().

Move the calls to memblock_set_bottom_up() and memblock_set_current_limit()
to e820__memblock_setup() to group all the memblock initial setup and make
setup_arch() more readable.

No functional changes.

Signed-off-by: Mike Rapoport (Microsoft) 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20250214090651.3331663-2-rppt@kernel.org

mm/memblock: add memblock_alloc_or_panic interface

2025-01-26T04:22:38+00:00

Before SLUB initialization, various subsystems used memblock_alloc to
allocate memory.  In most cases, when memory allocation fails, an
immediate panic is required.  To simplify this behavior and reduce
repetitive checks, introduce `memblock_alloc_or_panic`.  This function
ensures that memory allocation failures result in a panic automatically,
improving code readability and consistency across subsystems that require
this behavior.

[guoweikang.kernel@gmail.com: arch/s390: save_area_alloc default failure behavior changed to panic]
  Link: https://lkml.kernel.org/r/20250109033136.2845676-1-guoweikang.kernel@gmail.com
  Link: https://lore.kernel.org/lkml/Z2fknmnNtiZbCc7x@kernel.org/
Link: https://lkml.kernel.org/r/20250102072528.650926-1-guoweikang.kernel@gmail.com
Signed-off-by: Guo Weikang 
Acked-by: Geert Uytterhoeven 	[m68k]
Reviewed-by: Alexander Gordeev 	[s390]
Acked-by: Mike Rapoport (Microsoft) 
Cc: Alexander Gordeev 
Signed-off-by: Andrew Morton

x86/mm: Make e820__end_ram_pfn() cover E820_TYPE_ACPI ranges

2024-06-17T15:46:08+00:00

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 pre-allocated 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 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Dave Hansen 
Tested-by: Tao Liu 
Link: https://lore.kernel.org/r/20240614095904.1345461-13-kirill.shutemov@linux.intel.com

x86/e820: Add a new e820 table update helper

2024-04-29T09:15:31+00:00

Add a new API helper e820__range_update_table() with which to update an
arbitrary e820 table. Move all current users of
e820__range_update_kexec() to this new helper.

  [ bp: Massage. ]

Signed-off-by: Ashish Kalra 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/b726af213ad55053f8a7a1e793b01bb3f1ca9dd5.1714090302.git.ashish.kalra@amd.com