All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Dave Young <dyoung@redhat.com>, Geoff Levand <geoff@infradead.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	AKASHI@infradead.org, marc.zyngier@arm.com,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	christoffer.dall@linaro.org, kexec@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 13/16] arm64: kdump: add kdump support
Date: Thu, 22 Oct 2015 13:29:31 +0900	[thread overview]
Message-ID: <5628662B.1020605@linaro.org> (raw)
In-Reply-To: <20151022032534.GC11227@dhcp-129-115.nay.redhat.com>

Hi Dave,

Thank you for your comment.

On 10/22/2015 12:25 PM, Dave Young wrote:
> Hi, AKASHI,
>
> On 10/19/15 at 11:38pm, Geoff Levand wrote:
>> From: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>
>> On crash dump kernel, all the information about primary kernel's core
>> image is available in elf core header specified by "elfcorehdr=" boot
>> parameter. reserve_elfcorehdr() will set aside the region to avoid any
>> corruption by crash dump kernel.
>>
>> Crash dump kernel will access the system memory of primary kernel via
>> copy_oldmem_page(), which reads one page by ioremap'ing it since it does
>> not reside in linear mapping on crash dump kernel.
>> Please note that we should add "mem=X[MG]" boot parameter to limit the
>> memory size and avoid the following assertion at ioremap():
>> 	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>> 		return NULL;
>> when accessing any pages beyond the usable memories of crash dump kernel.
>
> How does kexec-tools pass usable memory ranges to kernel? using dtb?
> Passing an extra mem=X sounds odd in the design. Kdump kernel should get
> usable ranges and hanle the limit better than depending on an extern kernel
> param.

Well, regarding "depending on an external kernel param,"
- this limitation ("mem=") is compatible with arm(32) implementation although
   it is not clearly described in kernel's Documentation/kdump/kdump.txt.
- "elfcorehdr" kernel parameter is mandatory on x86 as well as on arm/arm64.
   The parameter is explicitly generated and added by kexec-tools.

Do I miss your point?

Thanks,
-Takahiro AKASHI

> 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: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 13/16] arm64: kdump: add kdump support
Date: Thu, 22 Oct 2015 13:29:31 +0900	[thread overview]
Message-ID: <5628662B.1020605@linaro.org> (raw)
In-Reply-To: <20151022032534.GC11227@dhcp-129-115.nay.redhat.com>

Hi Dave,

Thank you for your comment.

On 10/22/2015 12:25 PM, Dave Young wrote:
> Hi, AKASHI,
>
> On 10/19/15 at 11:38pm, Geoff Levand wrote:
>> From: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>
>> On crash dump kernel, all the information about primary kernel's core
>> image is available in elf core header specified by "elfcorehdr=" boot
>> parameter. reserve_elfcorehdr() will set aside the region to avoid any
>> corruption by crash dump kernel.
>>
>> Crash dump kernel will access the system memory of primary kernel via
>> copy_oldmem_page(), which reads one page by ioremap'ing it since it does
>> not reside in linear mapping on crash dump kernel.
>> Please note that we should add "mem=X[MG]" boot parameter to limit the
>> memory size and avoid the following assertion at ioremap():
>> 	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>> 		return NULL;
>> when accessing any pages beyond the usable memories of crash dump kernel.
>
> How does kexec-tools pass usable memory ranges to kernel? using dtb?
> Passing an extra mem=X sounds odd in the design. Kdump kernel should get
> usable ranges and hanle the limit better than depending on an extern kernel
> param.

Well, regarding "depending on an external kernel param,"
- this limitation ("mem=") is compatible with arm(32) implementation although
   it is not clearly described in kernel's Documentation/kdump/kdump.txt.
- "elfcorehdr" kernel parameter is mandatory on x86 as well as on arm/arm64.
   The parameter is explicitly generated and added by kexec-tools.

Do I miss your point?

Thanks,
-Takahiro AKASHI

> Thanks
> Dave
>

  reply	other threads:[~2015-10-22  4:30 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19 23:38 [PATCH 00/16] arm64 kexec kernel patches v10 Geoff Levand
2015-10-19 23:38 ` Geoff Levand
2015-10-19 23:38 ` [PATCH 05/16] arm64: Add back cpu_reset routines Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 02/16] arm64: Convert hcalls to use HVC immediate value Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 06/16] arm64: Add EL2 switch to cpu_reset Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 03/16] arm64: Add new hcall HVC_CALL_FUNC Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 08/16] arm64/kexec: Add core kexec support Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-20  8:56   ` Pratyush Anand
2015-10-20  8:56     ` Pratyush Anand
2015-10-20 17:19     ` Geoff Levand
2015-10-20 17:19       ` Geoff Levand
2015-10-23  7:29       ` Pratyush Anand
2015-10-23  7:29         ` Pratyush Anand
2015-10-21 18:30   ` [PATCH v10.2 " Geoff Levand
2015-10-21 18:30     ` Geoff Levand
2015-10-30 16:29   ` [PATCH " James Morse
2015-10-30 16:29     ` James Morse
2015-10-30 16:54     ` Mark Rutland
2015-10-30 16:54       ` Mark Rutland
2015-11-02  9:26     ` Pratyush Anand
2015-11-02  9:26       ` Pratyush Anand
2015-11-03  0:30     ` Geoff Levand
2015-11-03  0:30       ` Geoff Levand
2015-10-19 23:38 ` [PATCH 07/16] Revert "arm64: remove dead code" Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 01/16] arm64: Fold proc-macros.S into assembler.h Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 04/16] arm64: kvm: allows kvm cpu hotplug Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-20 18:57   ` [PATCH v10.1 " Geoff Levand
2015-10-20 18:57     ` Geoff Levand
2015-10-19 23:38 ` [PATCH 12/16] arm64: kdump: implement machine_crash_shutdown() Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-20 18:54   ` [PATCH v10.1 " Geoff Levand
2015-10-20 18:54     ` Geoff Levand
2015-10-19 23:38 ` [PATCH 11/16] arm64: kdump: reserve memory for crash dump kernel Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 13/16] arm64: kdump: add kdump support Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-22  3:25   ` Dave Young
2015-10-22  3:25     ` Dave Young
2015-10-22  4:29     ` AKASHI Takahiro [this message]
2015-10-22  4:29       ` AKASHI Takahiro
2015-10-22  5:15       ` Dave Young
2015-10-22  5:15         ` Dave Young
2015-10-22  9:57         ` AKASHI Takahiro
2015-10-22  9:57           ` AKASHI Takahiro
2015-10-23  9:50           ` Dave Young
2015-10-23  9:50             ` Dave Young
2015-10-29  5:55             ` AKASHI Takahiro
2015-10-29  5:55               ` AKASHI Takahiro
2015-10-29  6:40               ` Dave Young
2015-10-29  6:40                 ` Dave Young
2015-10-29  6:53                 ` AKASHI Takahiro
2015-10-29  6:53                   ` AKASHI Takahiro
2015-10-29  7:01                   ` Dave Young
2015-10-29  7:01                     ` Dave Young
2015-10-19 23:38 ` [PATCH 16/16] arm64: kdump: relax BUG_ON() if more than one cpus are still active Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 15/16] arm64: kdump: enable kdump in the arm64 defconfig Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 10/16] arm64/kexec: Enable kexec " Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 14/16] arm64: kdump: update a kernel doc Geoff Levand
2015-10-19 23:38   ` Geoff Levand
2015-10-19 23:38 ` [PATCH 09/16] arm64/kexec: Add pr_devel output Geoff Levand
2015-10-19 23:38   ` Geoff Levand

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=5628662B.1020605@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=AKASHI@infradead.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=dyoung@redhat.com \
    --cc=geoff@infradead.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=will.deacon@arm.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.