The current fadump crash memory reservation policy places the crash
memory area at an offset derived from the crashkernel reservation
size. For example, with crashkernel=768M, the crash memory area starts
at 768M physical address.
This layout assumes that bootloader memory usage remains below the
crash memory reservation area during the reboot flow after a kernel
crash.
With fadump enabled, a crashed system reboots and firmware preserves
the crashed kernel memory while passing special device tree properties
to the next kernel. Before the capture kernel boots, GRUB is invoked
again as part of the normal reboot sequence.
Currently GRUB limits its memory usage below 768M, which aligns with
the minimum crashkernel reservation supported by fadump. However, if
GRUB increases this limit in future, it can potentially overwrite the
preserved crash memory and corrupt the dump before the capture kernel
boots.
To avoid depending on bootloader memory limits, place the fadump crash
memory reservation area in the middle of system RAM instead of deriving
its base from the crashkernel reservation size.
Since we have changed the fadump crash memory reservation base address
policy in the past, I am sending this patch as RFC to discuss any
potential side effects before moving the fadump base address to the
middle of system RAM again.
The following commits are related to the previous reservation policy
changes:
Commit 140777a3d8df ("powerpc/fadump: consider reserved ranges while
reserving memory")
Commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset
closer to bottom of RAM")
Sourabh Jain (1):
powerpc/fadump: move crash memory reservation to middle of RAM
arch/powerpc/kernel/fadump.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.52.0
