linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dyoung@redhat.com (Dave Young)
To: linux-arm-kernel@lists.infradead.org
Subject: [v2 0/5] arm64: add kdump support
Date: Tue, 12 May 2015 13:43:04 +0800	[thread overview]
Message-ID: <20150512054304.GA29874@localhost.localdomain> (raw)
In-Reply-To: <55504956.9020007@linaro.org>

On 05/11/15 at 03:16pm, AKASHI Takahiro wrote:
> Hi
> 
> Sorry for late response. I was on vacation.
> 
> On 04/24/2015 06:53 PM, Mark Rutland wrote:
> >Hi,
> >
> >On Fri, Apr 24, 2015 at 08:53:03AM +0100, AKASHI Takahiro wrote:
> >>This patch set enables kdump (crash dump kernel) support on arm64 on top of
> >>Geoff's kexec patchset.
> >>
> >>In this version, there are some arm64-specific usage/constraints:
> >>1) "mem=" boot parameter must be specified on crash dump kernel
> >>    if the system starts on uefi.
> >
> >This sounds very painful. Why is this the case, and how do x86 and/or
> >ia64 get around that?
> 
> As Dave (Young) said, x86 uses "memmap=XX" kernel commandline parameters
> to specify usable memory for crash dump kernel.

Originally x86 use memmap=exactmap memmap=XX to specify each section of
memories for 2nd kernel. But later because a lot of reserved type ranges
need to be passed ie. for pci mmconfig, and kernel cmdline buffer is
limited so kexec-tools later switch to passing these in x86 boot params as
E820 memory ranges directly.

> On my arm64 implementation, "linux,usable-memory" property is added
> to device tree blob by kexec-tools for this purpose.
> This is because, when I first implemented kdump on arm64, ppc is the only
> architecture that supports kdump AND utilizes device trees.
> Since kexec-tools as well as the kernel already has this framework,
> I believed that device-tree approach was smarter than a commandline
> parameter.
> 
> However, uefi-based kernel ignores all the memory-related properties
> in a device tree and so this "mem=" workaround was added.

Kdump kernel reuses the memmap info getting from firmware during 1st kernel
boot, I do not think the memmap info can be cooked for crash kernel usable
memory. But it might be a better way to use a special fdt node for crash
kernel memory even for UEFI..

Another way is introducing a similar memmap=, but maybe consider only
system_ram type ranges. For other memory areas still use UEFI memmap.

Thanks
Dave

  reply	other threads:[~2015-05-12  5:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24  7:53 [v2 0/5] arm64: add kdump support AKASHI Takahiro
2015-04-24  7:53 ` [v2 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-04-24 10:11   ` Mark Rutland
2015-05-11  6:44     ` AKASHI Takahiro
2015-04-28  9:19   ` Baoquan He
2015-05-11  7:38     ` AKASHI Takahiro
2015-05-11  7:54       ` Baoquan He
2015-05-11  8:17         ` AKASHI Takahiro
2015-05-11  9:41           ` Baoquan He
2015-05-12  7:32             ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 2/5] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2015-04-24 10:39   ` Mark Rutland
2015-04-24 10:43     ` Marc Zyngier
2015-08-06  7:09       ` AKASHI Takahiro
2015-08-06 15:51         ` Marc Zyngier
2015-08-07  4:24           ` AKASHI Takahiro
2015-05-11  7:10     ` AKASHI Takahiro
2015-05-22  5:56       ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel AKASHI Takahiro
2015-04-24  7:53 ` [v2 4/5] arm64: add kdump support AKASHI Takahiro
2015-05-08 12:19   ` Dave Young
2015-05-11  7:47     ` Dave Young
2015-05-11  7:58       ` AKASHI Takahiro
2015-05-11  8:39         ` Dave Young
2015-04-24  7:53 ` [v2 5/5] arm64: enable kdump in the arm64 defconfig AKASHI Takahiro
2015-04-24  9:53 ` [v2 0/5] arm64: add kdump support Mark Rutland
2015-05-11  6:16   ` AKASHI Takahiro
2015-05-12  5:43     ` Dave Young [this message]
2015-05-18  8:08       ` AKASHI Takahiro

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=20150512054304.GA29874@localhost.localdomain \
    --to=dyoung@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).