[PATCH v26 0/7] arm64: add kdump support
takahiro.akashi at linaro.org
Wed Sep 21 00:42:50 PDT 2016
On Mon, Sep 19, 2016 at 05:05:48PM +0100, James Morse wrote:
> On 16/09/16 21:17, Ard Biesheuvel wrote:
> > On 16 September 2016 at 17:04, James Morse <james.morse at arm.com> wrote:
> >> Mark, Ard, how does/will reserved-memory work on an APCI only system?
> > It works by accident, at the moment. We used to ignore both
> > /memreserve/s and the /reserved-memory node, but due to some unrelated
> > refactoring, we ended up honouring the reserved-memory node when
> > booting via UEFI
> Okay, so kdump probably shouldn't rely on this behaviour...
> For an acpi-only system, we could get reserve_crashkernel() to copy the uefi
> memory map into the reserved region, changing the region types for existing
> kernel memory to EfiReservedMemoryType (for example) and fixing up the reserved
> region boundaries.
> This second memory map could then be added alongside the real one in the
> DT/chosen, and used in preference the second time we go through uefi_init() in
> the crash kernel.
Do we need add this map as the second one?
Why not replace "linux,uefi-mmap-start" in a new blob?
> kexec-tools would still need to keep the '/reserved-memory' node for non-uefi
Yeah, but if we go in our own way on UEFI/ACPI systems, we may want to
go in a DT-specific way, like PPC does, on DT systems.
(That is, "linux,usable-memory" in memory nodes.)
> Doing this doesn't depend on userspace, and means the uefi memory map is still
> the one and only true source of memory layout information. If fixing it like
> this is valid I don't think it should block kdump.
> ... I will think about this some more before trying to put it together.
More information about the kexec