From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
ard.biesheuvel@linaro.org, Geoff Levand <geoff@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
marc.zyngier@arm.com, James Morse <james.morse@arm.com>,
christoffer.dall@linaro.org, kexec@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 18/19] arm64: kdump: update a kernel doc
Date: Wed, 20 Jan 2016 16:26:17 +0800 [thread overview]
Message-ID: <20160120082617.GJ2999@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <569F3EC2.4020807@linaro.org>
On 01/20/16 at 05:01pm, AKASHI Takahiro wrote:
> On 01/20/2016 04:00 PM, Dave Young wrote:
> >>>So I'm not still sure about what are advantages of a property under /chosen
> >>>over "memmap=" kernel parameter.
> >>>Both are simple and can have the same effect with minimizing changes to dtb.
> >>>(But if, in the latter case, we have to provide *all* the memory-related information
> >>>through "memmap=" parameters, it would be much complicated.)
> >>
> >>Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
> >>or uefi-memmap so that we do not need any extra kernel cmdline.
>
> Yes, I understand.
> But on arm64, kexec-tools can generate a "memmap=" parameter for crash kernel's
> memory region without any user's interaction.
> (please note that this parameter eventually goes into dtb's cmdline property in
> /chosen.)
>
> In this sense, it is no different from an extra property under /chosen
> as kexec-tools can also add it to dtb passed to the crash dump kernel.
>
> (See what I mean?)
I think I understand your points, what I would prefer is not an extra property
but modifying uefi memmap or recreating memory nodes for !EFI to be used in kdump kernel.
>
> >>For x86 we would like to drop the memmap= usage in kexec-tools
>
> I didn't know that :)
>
> >>but we can not
> >>do that for a compatibility problem about calgary iommu. So that currently
> >>kexec-tools supports both recreating E820 maps and passing memmap=.
> >>
> >>We should think it carefully because it will be hard to remove once we support it.
>
> Absolutely.
>
> >>IMO handling it in code is better than using an external interface.
> >
> >Also seems semantic of memmap=exactmap is different than current use in the implementation
> >exactmap means we need pass each range seperately including reserved, acpi and other types
> >We can not reuse ranges in uefi memmap for other than usable memory.
>
>
> If necessary, we may use a different name, say, "usablememmap=" for arm64
> or just extend "mem=" semantics (allowing XX@YY format) to avoid any confusion.
For either of above what is the 1st kernel behavior with these params?
>
> Thanks,
> -Takahiro AKASHI
>
> >It will also have the cmdline array size issue.k
> >
> >Thanks
> >Dave
> >
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2016-01-20 8:26 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 19:18 [PATCH 00/19] arm64 kexec kernel patches v13 Geoff Levand
2016-01-15 19:18 ` [PATCH 03/19] arm64: Add new asm macro copy_page Geoff Levand
2016-01-20 14:01 ` James Morse
2016-01-15 19:18 ` [PATCH 09/19] Revert "arm64: remove dead code" Geoff Levand
2016-01-15 19:55 ` Mark Rutland
2016-01-20 21:18 ` Geoff Levand
2016-01-15 19:18 ` [PATCH 06/19] arm64: Add new hcall HVC_CALL_FUNC Geoff Levand
2016-01-15 19:18 ` [PATCH 08/19] Revert "arm64: mm: remove unused cpu_set_idmap_tcr_t0sz function" Geoff Levand
2016-01-15 19:18 ` [PATCH 02/19] arm64: kernel: Include _AC definition in page.h Geoff Levand
2016-01-18 10:05 ` Mark Rutland
2016-01-15 19:18 ` [PATCH 05/19] arm64: Convert hcalls to use HVC immediate value Geoff Levand
2016-01-15 19:18 ` [PATCH 04/19] arm64: Cleanup SCTLR flags Geoff Levand
2016-01-15 20:07 ` Mark Rutland
2016-01-18 10:12 ` Marc Zyngier
2016-01-19 11:59 ` Dave Martin
2016-01-25 15:09 ` James Morse
2016-01-15 19:18 ` [PATCH 07/19] arm64: Add back cpu_reset routines Geoff Levand
2016-01-15 19:18 ` [PATCH 01/19] arm64: Fold proc-macros.S into assembler.h Geoff Levand
2016-01-15 19:18 ` [PATCH 17/19] arm64: kdump: enable kdump in the arm64 defconfig Geoff Levand
2016-01-15 19:18 ` [PATCH 11/19] arm64/kexec: Add core kexec support Geoff Levand
2016-01-15 19:18 ` [PATCH 10/19] arm64: kvm: allows kvm cpu hotplug Geoff Levand
2016-01-26 17:42 ` James Morse
2016-01-27 7:37 ` AKASHI Takahiro
2016-01-15 19:18 ` [PATCH 18/19] arm64: kdump: update a kernel doc Geoff Levand
2016-01-15 20:16 ` Mark Rutland
2016-01-18 10:26 ` AKASHI Takahiro
2016-01-18 11:29 ` Mark Rutland
2016-01-19 5:31 ` AKASHI Takahiro
2016-01-19 12:10 ` Mark Rutland
2016-01-20 4:34 ` AKASHI Takahiro
2016-01-19 1:43 ` Dave Young
2016-01-19 1:50 ` Dave Young
2016-01-19 5:35 ` AKASHI Takahiro
2016-01-19 12:28 ` Dave Young
2016-01-19 12:51 ` Mark Rutland
2016-01-19 13:45 ` Dave Young
2016-01-19 14:01 ` Mark Rutland
2016-01-20 2:49 ` Dave Young
2016-01-20 6:07 ` AKASHI Takahiro
2016-01-20 6:38 ` Dave Young
2016-01-20 7:00 ` Dave Young
2016-01-20 8:01 ` AKASHI Takahiro
2016-01-20 8:26 ` Dave Young [this message]
2016-01-20 11:54 ` Mark Rutland
2016-01-21 2:57 ` Dave Young
2016-01-21 3:03 ` Dave Young
2016-01-20 11:49 ` Mark Rutland
2016-01-21 6:53 ` AKASHI Takahiro
2016-01-21 12:02 ` Mark Rutland
2016-01-22 6:23 ` AKASHI Takahiro
2016-01-22 11:13 ` Mark Rutland
2016-02-02 5:18 ` AKASHI Takahiro
2016-01-25 3:19 ` Dave Young
2016-01-25 4:23 ` Dave Young
2016-01-20 11:28 ` Mark Rutland
2016-01-21 2:54 ` Dave Young
2016-01-20 5:25 ` AKASHI Takahiro
2016-01-20 12:02 ` Mark Rutland
2016-01-20 12:36 ` Mark Rutland
2016-01-20 14:59 ` Ard Biesheuvel
2016-01-20 15:04 ` Mark Rutland
2016-01-21 5:43 ` AKASHI Takahiro
2016-01-21 13:02 ` Mark Rutland
2016-01-19 12:17 ` Mark Rutland
2016-01-19 13:52 ` Dave Young
2016-01-19 14:05 ` Mark Rutland
2016-01-20 2:54 ` Dave Young
2016-01-15 19:18 ` [PATCH 12/19] arm64/kexec: Enable kexec in the arm64 defconfig Geoff Levand
2016-01-15 19:18 ` [PATCH 16/19] arm64: kdump: add kdump support Geoff Levand
2016-01-21 14:17 ` James Morse
2016-01-22 4:50 ` AKASHI Takahiro
2016-01-15 19:18 ` [PATCH 15/19] arm64: kdump: implement machine_crash_shutdown() Geoff Levand
2016-01-15 19:18 ` [PATCH 13/19] arm64/kexec: Add pr_debug output Geoff Levand
2016-01-15 19:18 ` [PATCH 19/19] arm64: kdump: relax BUG_ON() if more than one cpus are still active Geoff Levand
2016-01-15 19:18 ` [PATCH 14/19] arm64: kdump: reserve memory for crash dump kernel Geoff Levand
2016-01-19 12:32 ` [PATCH 00/19] arm64 kexec kernel patches v13 Dave Young
2016-01-20 0:15 ` Geoff Levand
2016-01-20 2:56 ` Dave Young
2016-01-20 21:15 ` Geoff Levand
2016-01-21 12:11 ` Mark Rutland
[not found] ` <c7575f853ccc491bb0212e025aab1cc9@NASANEXM01H.na.qualcomm.com>
2016-03-01 17:54 ` Azriel Samson
2016-03-02 1:17 ` Geoff Levand
2016-03-02 1:38 ` Will Deacon
2016-03-02 2:28 ` AKASHI Takahiro
2016-03-02 8:07 ` Marc Zyngier
2016-03-02 12:33 ` Pratyush Anand
2016-03-02 16:51 ` Azriel Samson
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=20160120082617.GJ2999@dhcp-128-65.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=geoff@infradead.org \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=takahiro.akashi@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox