All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"hbabus@us.ibm.com" <hbabus@us.ibm.com>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	ard.biesheuvel@linaro.org,
	"geoff@infradead.org" <geoff@infradead.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"david.griego@linaro.org" <david.griego@linaro.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"vgoyal@redhat.com" <vgoyal@redhat.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
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

WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"vgoyal@redhat.com" <vgoyal@redhat.com>,
	"hbabus@us.ibm.com" <hbabus@us.ibm.com>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"geoff@infradead.org" <geoff@infradead.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"david.griego@linaro.org" <david.griego@linaro.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	ard.biesheuvel@linaro.org
Subject: Re: [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: 87+ 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 ` AKASHI Takahiro
2015-04-24  7:53 ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24 10:11   ` Mark Rutland
2015-04-24 10:11     ` Mark Rutland
2015-04-24 10:11     ` Mark Rutland
2015-05-11  6:44     ` AKASHI Takahiro
2015-05-11  6:44       ` AKASHI Takahiro
2015-05-11  6:44       ` AKASHI Takahiro
2015-04-28  9:19   ` Baoquan He
2015-04-28  9:19     ` Baoquan He
2015-04-28  9:19     ` Baoquan He
2015-05-11  7:38     ` AKASHI Takahiro
2015-05-11  7:38       ` AKASHI Takahiro
2015-05-11  7:38       ` AKASHI Takahiro
2015-05-11  7:54       ` Baoquan He
2015-05-11  7:54         ` Baoquan He
2015-05-11  7:54         ` Baoquan He
2015-05-11  8:17         ` AKASHI Takahiro
2015-05-11  8:17           ` AKASHI Takahiro
2015-05-11  8:17           ` AKASHI Takahiro
2015-05-11  9:41           ` Baoquan He
2015-05-11  9:41             ` Baoquan He
2015-05-11  9:41             ` Baoquan He
2015-05-12  7:32             ` AKASHI Takahiro
2015-05-12  7:32               ` AKASHI Takahiro
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  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24 10:39   ` Mark Rutland
2015-04-24 10:39     ` Mark Rutland
2015-04-24 10:39     ` Mark Rutland
2015-04-24 10:43     ` Marc Zyngier
2015-04-24 10:43       ` Marc Zyngier
2015-04-24 10:43       ` Marc Zyngier
2015-08-06  7:09       ` AKASHI Takahiro
2015-08-06  7:09         ` AKASHI Takahiro
2015-08-06  7:09         ` AKASHI Takahiro
2015-08-06 15:51         ` Marc Zyngier
2015-08-06 15:51           ` Marc Zyngier
2015-08-06 15:51           ` Marc Zyngier
2015-08-07  4:24           ` AKASHI Takahiro
2015-08-07  4:24             ` AKASHI Takahiro
2015-08-07  4:24             ` AKASHI Takahiro
2015-05-11  7:10     ` AKASHI Takahiro
2015-05-11  7:10       ` AKASHI Takahiro
2015-05-11  7:10       ` AKASHI Takahiro
2015-05-22  5:56       ` AKASHI Takahiro
2015-05-22  5:56         ` 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   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53 ` [v2 4/5] arm64: add kdump support AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-05-08 12:19   ` Dave Young
2015-05-08 12:19     ` Dave Young
2015-05-08 12:19     ` Dave Young
2015-05-11  7:47     ` Dave Young
2015-05-11  7:47       ` Dave Young
2015-05-11  7:47       ` Dave Young
2015-05-11  7:58       ` AKASHI Takahiro
2015-05-11  7:58         ` AKASHI Takahiro
2015-05-11  7:58         ` AKASHI Takahiro
2015-05-11  8:39         ` Dave Young
2015-05-11  8:39           ` Dave Young
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  7:53   ` AKASHI Takahiro
2015-04-24  7:53   ` AKASHI Takahiro
2015-04-24  9:53 ` [v2 0/5] arm64: add kdump support Mark Rutland
2015-04-24  9:53   ` Mark Rutland
2015-04-24  9:53   ` Mark Rutland
2015-05-11  6:16   ` AKASHI Takahiro
2015-05-11  6:16     ` AKASHI Takahiro
2015-05-11  6:16     ` AKASHI Takahiro
2015-05-12  5:43     ` Dave Young [this message]
2015-05-12  5:43       ` Dave Young
2015-05-12  5:43       ` Dave Young
2015-05-18  8:08       ` AKASHI Takahiro
2015-05-18  8:08         ` AKASHI Takahiro
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=Catalin.Marinas@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=broonie@kernel.org \
    --cc=david.griego@linaro.org \
    --cc=geoff@infradead.org \
    --cc=hbabus@us.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=vgoyal@redhat.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.