[lkml]   [2019]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/4] support reserving crashkernel above 4G on arm64 kdump
+Cc kexec-list.

Hi Chen,

I think we are still in the quiet period of the merge cycle, but this is
a change which will be useful for systems like HPE Apollo where we are
looking at reserving crashkernel across a larger range.

Some comments inline and in respective patch threads..

On 05/07/2019 09:20 AM, Chen Zhou wrote:
> This patch series enable reserving crashkernel on high memory in arm64.

Please fix the patch subject, it should be v5.
Also please Cc the kexec-list ( for future
versions to allow wider review of the patchset.

> We use crashkernel=X to reserve crashkernel below 4G, which will fail
> when there is no enough memory. Currently, crashkernel=Y@X can be used
> to reserve crashkernel above 4G, in this case, if swiotlb or DMA buffers
> are requierd, capture kernel will boot failure because of no low memory.

... ^^ required

s/capture kernel will boot failure because of no low memory./capture
kernel boot will fail because there is no low memory available for

> When crashkernel is reserved above 4G in memory, kernel should reserve
> some amount of low memory for swiotlb and some DMA buffers. So there may
> be two crash kernel regions, one is below 4G, the other is above 4G. Then
> Crash dump kernel reads more than one crash kernel regions via a dtb
> property under node /chosen,
> linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]>.

Please use consistent naming for the second kernel, better to use crash
dump kernel.

I have tested this on my HPE Apollo machine and with
crashkernel=886M,high syntax, I can get the board to reserve a larger
memory range for the crashkernel (i.e. 886M):

# dmesg | grep -i crash
[ 0.000000] kexec_core: Reserving 256MB of low memory at 3560MB for
crashkernel (System low RAM: 2029MB)
[ 0.000000] crashkernel reserved: 0x0000000bc5a00000 -
0x0000000bfd000000 (886 MB)

kexec/kdump can also work also work fine on the board.

So, with the changes suggested in this cover letter and individual
patches, please feel free to add:

Reviewed-and-Tested-by: Bhupesh Sharma <>


> Besides, we need to modify kexec-tools:
> arm64: support more than one crash kernel regions(see [1])
> I post this patch series about one month ago. The previous changes and
> discussions can be retrived from:
> Changes since [v4]
> - reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
> Changes since [v3]
> - Add memblock_cap_memory_ranges back for multiple ranges.
> - Fix some compiling warnings.
> Changes since [v2]
> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as
> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
> patch.
> Changes since [v1]:
> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
> - Remove memblock_cap_memory_ranges() i added in v1 and implement that
> in fdt_enforce_memory_region().
> There are at most two crash kernel regions, for two crash kernel regions
> case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
> and then remove the memory range in the middle.
> [1]:
> [v1]:
> [v2]:
> [v3]:
> [v4]:
> Chen Zhou (3):
> x86: kdump: move reserve_crashkernel_low() into kexec_core.c
> arm64: kdump: support reserving crashkernel above 4G
> kdump: update Documentation about crashkernel on arm64
> Mike Rapoport (1):
> memblock: extend memblock_cap_memory_range to multiple ranges
> Documentation/admin-guide/kernel-parameters.txt | 6 +--
> arch/arm64/include/asm/kexec.h | 3 ++
> arch/arm64/kernel/setup.c | 3 ++
> arch/arm64/mm/init.c | 72 +++++++++++++++++++------
> arch/x86/include/asm/kexec.h | 3 ++
> arch/x86/kernel/setup.c | 66 +++--------------------
> include/linux/kexec.h | 5 ++
> include/linux/memblock.h | 2 +-
> kernel/kexec_core.c | 56 +++++++++++++++++++
> mm/memblock.c | 44 +++++++--------
> 10 files changed, 157 insertions(+), 103 deletions(-)

 \ /
  Last update: 2019-05-15 07:07    [W:0.052 / U:4.672 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site