From: Simon Horman <horms@kernel.org>
To: Rui Qi <qirui.001@bytedance.com>
Cc: kexec@lists.infradead.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 0/2] kexec-tools: Fix split crash kernel reservations
Date: Mon, 24 Aug 2026 16:27:14 +0100 [thread overview]
Message-ID: <20260824152714.GA102316@horms.kernel.org> (raw)
In-Reply-To: <20260818123504.12022-4-qirui.001@bytedance.com>
On Tue, Aug 18, 2026 at 08:35:05PM +0800, Rui Qi wrote:
> Hi,
>
> This series fixes two kexec-tools issues seen with split crash kernel
> reservations.
>
> The first patch makes --print-ckr-size prefer
> /sys/kernel/kexec_crash_size. This restores the option's original
> user-visible contract: report the same crash kernel reserved size and
> unit as the kernel sysfs attribute when that attribute is available.
> The existing arch load-range based calculation is kept as a fallback for
> older kernels.
>
> The second patch fixes the RISC-V kexec_load crash path. RISC-V records
> all Crash kernel ranges from /proc/iomem, but it currently writes only
> the selected load range to linux,usable-memory-range. On systems with
> high/low crash kernel reservations, that prevents the crash kernel from
> seeing the low reservation after boot.
>
> Keep placing the crash image segments in the selected load range, but
> pass all crash kernel ranges to the crash kernel through
> linux,usable-memory-range. This follows the split-reservation handoff
> model already used by arm64 kexec-tools, where
> linux,usable-memory-range = <BASE1 SIZE1 BASE2 SIZE2> advertises both
> high and low crash kernel ranges to the crash dump kernel.
>
> Tested on riscv64 with:
>
> /proc/iomem:
> f7e00000-ffdfffff : Crash kernel (128 MiB low)
> 1f88c00000-1ff6bfffff : Crash kernel (1760 MiB high)
>
> /sys/kernel/kexec_crash_size:
> 1979711488
>
> With the patched kexec binary:
>
> kexec --print-ckr-size
> 1979711488
>
> kexec -c -p ... followed by a panic completed kdump successfully.
> The crash kernel reported both ranges as System RAM in /proc/iomem:
>
> f7e00000-ffdfffff : System RAM
> 1f88c00000-1ff6bfffff : System RAM
>
> The vmcore was saved successfully.
>
> Rui Qi (2):
> kexec: Print crash kernel reserved size from sysfs
> RISC-V: Pass all crash kernel ranges to crash kernel
Thanks, applied.
- RISC-V: Pass all crash kernel ranges to crash kernel
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=6b8b27fbe5cc
- kexec: Print crash kernel reserved size from sysfs
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=97061549e25f
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Rui Qi <qirui.001@bytedance.com>
Cc: kexec@lists.infradead.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 0/2] kexec-tools: Fix split crash kernel reservations
Date: Mon, 24 Aug 2026 16:27:14 +0100 [thread overview]
Message-ID: <20260824152714.GA102316@horms.kernel.org> (raw)
In-Reply-To: <20260818123504.12022-4-qirui.001@bytedance.com>
On Tue, Aug 18, 2026 at 08:35:05PM +0800, Rui Qi wrote:
> Hi,
>
> This series fixes two kexec-tools issues seen with split crash kernel
> reservations.
>
> The first patch makes --print-ckr-size prefer
> /sys/kernel/kexec_crash_size. This restores the option's original
> user-visible contract: report the same crash kernel reserved size and
> unit as the kernel sysfs attribute when that attribute is available.
> The existing arch load-range based calculation is kept as a fallback for
> older kernels.
>
> The second patch fixes the RISC-V kexec_load crash path. RISC-V records
> all Crash kernel ranges from /proc/iomem, but it currently writes only
> the selected load range to linux,usable-memory-range. On systems with
> high/low crash kernel reservations, that prevents the crash kernel from
> seeing the low reservation after boot.
>
> Keep placing the crash image segments in the selected load range, but
> pass all crash kernel ranges to the crash kernel through
> linux,usable-memory-range. This follows the split-reservation handoff
> model already used by arm64 kexec-tools, where
> linux,usable-memory-range = <BASE1 SIZE1 BASE2 SIZE2> advertises both
> high and low crash kernel ranges to the crash dump kernel.
>
> Tested on riscv64 with:
>
> /proc/iomem:
> f7e00000-ffdfffff : Crash kernel (128 MiB low)
> 1f88c00000-1ff6bfffff : Crash kernel (1760 MiB high)
>
> /sys/kernel/kexec_crash_size:
> 1979711488
>
> With the patched kexec binary:
>
> kexec --print-ckr-size
> 1979711488
>
> kexec -c -p ... followed by a panic completed kdump successfully.
> The crash kernel reported both ranges as System RAM in /proc/iomem:
>
> f7e00000-ffdfffff : System RAM
> 1f88c00000-1ff6bfffff : System RAM
>
> The vmcore was saved successfully.
>
> Rui Qi (2):
> kexec: Print crash kernel reserved size from sysfs
> RISC-V: Pass all crash kernel ranges to crash kernel
Thanks, applied.
- RISC-V: Pass all crash kernel ranges to crash kernel
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=6b8b27fbe5cc
- kexec: Print crash kernel reserved size from sysfs
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=97061549e25f
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-08-24 15:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 12:35 [PATCH 0/2] kexec-tools: Fix split crash kernel reservations Rui Qi
2026-08-18 12:35 ` Rui Qi
2026-08-18 12:35 ` [PATCH 1/2] kexec: Print crash kernel reserved size from sysfs Rui Qi
2026-08-18 12:35 ` Rui Qi
2026-08-18 12:35 ` [PATCH 2/2] RISC-V: Pass all crash kernel ranges to crash kernel Rui Qi
2026-08-18 12:35 ` Rui Qi
2026-08-24 15:27 ` Simon Horman [this message]
2026-08-24 15:27 ` [PATCH 0/2] kexec-tools: Fix split crash kernel reservations Simon Horman
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=20260824152714.GA102316@horms.kernel.org \
--to=horms@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=qirui.001@bytedance.com \
/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.