Linux s390 Architecture development
 help / color / mirror / Atom feed
* [PATCH v1 0/8] s390/kdump: Add crashkernel CMA support
@ 2026-11-12 11:20 Mikhail Zaslonko
  2026-11-12 11:20 ` [PATCH v1 1/8] s390/kdump: Enable crashkernel CMA infrastructure Mikhail Zaslonko
                   ` (7 more replies)
  0 siblings, 8 replies; 17+ messages in thread
From: Mikhail Zaslonko @ 2026-11-12 11:20 UTC (permalink / raw)
  To: Heiko Carstens, Vasily Gorbik, Alexander Gordeev
  Cc: Ilya Leoshkevich, Andrew Morton, Baoquan He, Mike Rapoport,
	Pasha Tatashin, Pratyush Yadav, Dave Young, Jiri Bohac,
	Jonathan Corbet, Usama Arif, linux-s390, kexec, linux-kernel

This series adds support for crashkernel=size,cma on s390, as already
available on x86, arm64, riscv and powerpc. In addition to the regular
crashkernel reservation, CMA memory is reserved. The production kernel
uses it for movable allocations, and the kdump kernel uses it as
additional memory. The regular reservation then only needs to hold the
kdump kernel and its initrd.

On s390 the kdump kernel runs in the crashkernel memory, which is
swapped to address 0, and its decompressor limits usable memory to the
crashkernel size. All other memory belongs to the crashed kernel and
makes up the dump. To use the CMA memory, the kdump kernel has to know
where it is, and the decompressor has to handle usable memory above
that limit.

Patches 1-3 reserve the CMA memory with the generic
reserve_crashkernel_cma() and store the ranges in the parmarea of a
kdump kernel loaded with kexec_file_load(). They use 64 of the 72
padding bytes before the command line, enough for the four ranges the
generic code reserves at most. Kernel images have this area zeroed, so
older and newer kernels keep working together, just without CMA memory
for kdump. kexec_load() needs a matching kexec-tools change, which can
read the ranges from /sys/kernel/kexec_crash_cma_ranges.

Patch 4 replaces the decompressor's usable memory limit with a small
sorted array of usable ranges, physmem_info.usable[]. The iterator
returns their intersection with online memory, and the boot allocator
walks only these ranges, top-down from ident_map_size. The identity
mapping, the KASAN shadow and memblock use the same iterator. A normal
boot has a single range from 0 to ident_map_size and behaves as before.

Patch 5 excludes the CMA ranges from /proc/vmcore. They are kept in
oldmem_data and added to oldmem_type next to the crashkernel memory, so
no PT_LOAD headers are created for them.

Patch 6 lets the kdump kernel use the CMA memory. If the parmarea
contains CMA ranges, the decompressor does not limit ident_map_size to
the crashkernel size and adds the crashkernel memory and the CMA ranges
as usable ranges. All other memory up to ident_map_size is treated as
a memory hole. The CMA memory is then mapped, added to memblock and
freed to the buddy allocator like any other memory. Boot allocations can
use it as well: page tables, the KASAN shadow and the initrd.

Patch 7 skips the generic 10 second wait for pending DMA before the
kdump kernel is started. s390 does not need it, as s390_reset_system()
terminates all in-flight I/O before the kdump kernel starts. The patch
makes the timeout overridable in kernel/crash_core.c and sets it to 0
on s390. It is the only patch in the series that touches generic code.

Patch 8 updates the documentation.

Without ",cma", the behavior is the same as before: the decompressor
has a single usable range, and a kdump kernel uses only the crashkernel
memory.

Tested on a 32G z/VM guest and on a 64G LPAR:
- crashkernel=82M crashkernel=1G,cma: the kdump kernel has ~1.1G of
  memory and writes a dump that contains all memory except the
  crashkernel and CMA ranges. With crashkernel=128M alone, the same
  kdump kernel and initrd run out of memory.
- 26G of CMA in four ranges (z/VM, with the two generic fixes below):
  same result.
- With ",cma", the kdump kernel starts without the 10 second wait.
- Without ",cma": same memory layout and dump as before.

Two generic crashkernel CMA fixes are queued in kexec-next. This series
applies without them, but both problems show up on s390:
- kdump: Give crashkernel CMA areas unique names [1]
  When the reservation is split into several CMA areas, the CMA sysfs
  setup fails, and debugfs shows only the first crashkernel area.
- crash: keep crashkernel CMA pages reserved if activation fails [2]
  A CMA area that crosses a zone boundary fails to activate, and its
  pages go to the buddy allocator although the kdump kernel still uses
  that memory. On s390 ZONE_DMA ends at 2G so this can happen when an
  area does not fit above 4G.

Usama Arif's hugetlb CMA v2 [3] changes reserve_crashkernel_cma() for
all architectures. This series needs to adapt the s390 call in patch 2
if hugetlb CMA patch goes in.

[1] https://lore.kernel.org/lkml/20261106104309.3669583-1-zaslonko@linux.ibm.com/
[2] https://lore.kernel.org/lkml/20261104145600.3708886-1-usama.arif@linux.dev/
[3] https://lore.kernel.org/r/20261106165142.2847916-1-usama.arif@linux.dev/

Mikhail Zaslonko (8):
  s390/kdump: Enable crashkernel CMA infrastructure
  s390/kdump: Reserve crashkernel CMA memory
  s390/kexec: Pass crashkernel CMA ranges to the kdump kernel
  s390/boot: Allow additional usable memory ranges
  s390/kdump: Exclude crashkernel CMA memory from vmcore
  s390/kdump: Use crashkernel CMA memory in the kdump kernel
  s390/kdump: Skip the crashkernel CMA DMA wait
  Documentation: kdump: Add s390 to crashkernel CMA

 Documentation/admin-guide/kdump/kdump.rst     |  3 +
 .../admin-guide/kernel-parameters.txt         |  4 +-
 arch/s390/Kconfig                             |  3 +
 arch/s390/boot/boot.h                         |  3 +-
 arch/s390/boot/kaslr.c                        |  4 +-
 arch/s390/boot/physmem_info.c                 | 65 ++++++++++++++++---
 arch/s390/boot/startup.c                      | 30 +++++++--
 arch/s390/boot/vmem.c                         |  7 +-
 arch/s390/include/asm/crash_reserve.h         | 24 +++++++
 arch/s390/include/asm/kexec.h                 |  3 +
 arch/s390/include/asm/physmem_info.h          | 63 +++++++++++++-----
 arch/s390/include/asm/setup.h                 | 10 ++-
 arch/s390/kernel/crash_dump.c                 | 48 +++++++++++---
 arch/s390/kernel/machine_kexec_file.c         |  5 ++
 arch/s390/kernel/setup.c                      | 17 ++++-
 kernel/crash_core.c                           |  2 +
 16 files changed, 241 insertions(+), 50 deletions(-)
 create mode 100644 arch/s390/include/asm/crash_reserve.h


base-commit: 067c5c24cef23d913b67eaaf71ae67e7169a6620
-- 
2.55.0


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2026-11-12 11:52 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-12 11:20 [PATCH v1 0/8] s390/kdump: Add crashkernel CMA support Mikhail Zaslonko
2026-11-12 11:20 ` [PATCH v1 1/8] s390/kdump: Enable crashkernel CMA infrastructure Mikhail Zaslonko
2026-11-12 11:30   ` sashiko-bot
2026-11-12 11:20 ` [PATCH v1 2/8] s390/kdump: Reserve crashkernel CMA memory Mikhail Zaslonko
2026-11-12 11:38   ` sashiko-bot
2026-11-12 11:21 ` [PATCH v1 3/8] s390/kexec: Pass crashkernel CMA ranges to the kdump kernel Mikhail Zaslonko
2026-11-12 11:34   ` sashiko-bot
2026-11-12 11:21 ` [PATCH v1 4/8] s390/boot: Allow additional usable memory ranges Mikhail Zaslonko
2026-11-12 11:33   ` sashiko-bot
2026-11-12 11:21 ` [PATCH v1 5/8] s390/kdump: Exclude crashkernel CMA memory from vmcore Mikhail Zaslonko
2026-11-12 11:30   ` sashiko-bot
2026-11-12 11:21 ` [PATCH v1 6/8] s390/kdump: Use crashkernel CMA memory in the kdump kernel Mikhail Zaslonko
2026-11-12 11:52   ` sashiko-bot
2026-11-12 11:21 ` [PATCH v1 7/8] s390/kdump: Skip the crashkernel CMA DMA wait Mikhail Zaslonko
2026-11-12 11:30   ` sashiko-bot
2026-11-12 11:21 ` [PATCH v1 8/8] Documentation: kdump: Add s390 to crashkernel CMA Mikhail Zaslonko
2026-11-12 11:25   ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox