From: dyoung@redhat.com (Dave Young) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 18/19] arm64: kdump: update a kernel doc Date: Tue, 19 Jan 2016 21:45:53 +0800 [thread overview] Message-ID: <20160119134553.GA2986@dhcp-128-65.nay.redhat.com> (raw) In-Reply-To: <20160119125114.GH25024@leverpostej> On 01/19/16 at 12:51pm, Mark Rutland wrote: > On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote: > > On 01/19/16 at 02:35pm, AKASHI Takahiro wrote: > > > On 01/19/2016 10:43 AM, Dave Young wrote: > > > >On 01/18/16 at 07:26pm, AKASHI Takahiro wrote: > > > >>On 01/16/2016 05:16 AM, Mark Rutland wrote: > > > >>>On Fri, Jan 15, 2016 at 07:18:38PM +0000, Geoff Levand wrote: > > > >>>>From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > >>>> > > > >>>>This patch adds arch specific descriptions about kdump usage on arm64 > > > >>>>to kdump.txt. > > > >>>> > > > >>>>Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > >>>>--- > > > >>>> Documentation/kdump/kdump.txt | 23 ++++++++++++++++++++++- > > > >>>> 1 file changed, 22 insertions(+), 1 deletion(-) > > > >>>> > > > >>>>diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > > > >>>>index bc4bd5a..36cf978 100644 > > > >>>>--- a/Documentation/kdump/kdump.txt > > > >>>>+++ b/Documentation/kdump/kdump.txt > > > >>>>@@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > > > >>>> a remote system. > > > >>>> > > > >>>> Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > > > >>>>-s390x and arm architectures. > > > >>>>+s390x, arm and arm64 architectures. > > > >>>> > > > >>>> When the system kernel boots, it reserves a small section of memory for > > > >>>> the dump-capture kernel. This ensures that ongoing Direct Memory Access > > > >>>>@@ -249,6 +249,20 @@ Dump-capture kernel config options (Arch Dependent, arm) > > > >>>> > > > >>>> AUTO_ZRELADDR=y > > > >>>> > > > >>>>+Dump-capture kernel config options (Arch Dependent, arm64) > > > >>>>+---------------------------------------------------------- > > > >>>>+ > > > >>>>+1) The maximum memory size on the dump-capture kernel must be limited by > > > >>>>+ specifying: > > > >>>>+ > > > >>>>+ mem=X[MG] > > > >>>>+ > > > >>>>+ where X should be less than or equal to the size in "crashkernel=" > > > >>>>+ boot parameter. Kexec-tools will automatically add this. > > > >>> > > > >>> > > > >>>This is extremely fragile, and will trivially fail when the kernel can > > > >>>be loaded anywhere (see [1]). > > > >> > > > >>As I said before, this restriction also exists on arm, but I understand > > > >>that recent Ard's patches break it. > > > >> > > > >>>We must explicitly describe the set of regions the crash kernel may use > > > >>>(i.e. we need base and size). NAK in the absence of that. > > > >> > > > >>There seem to exist several approaches: > > > >>(a) use a device-tree property, "linux,usable-memory", in addition to "reg" > > > >> under "memory" node > > > >>(b) use a kernel's early parameter, "memmap=nn[@#$]ss" > > > >> > > > >>Power PC takes (a), while this does not work on efi-started kernel > > > >>because dtb has no "memory" nodes under efi. > > > >>X86 takes (b). If we take this, we will need to overwrite a weak > > > >>early_init_dt_add_memory(). > > > > > > > >X86 takes another way in latest kexec-tools and kexec_file_load, that is > > > >recreating E820 table and pass it to kexec/kdump kernel, if the entries > > > >are over E820 limitation then turn to use setup_data list for remain > > > >entries. > > > > > > Thanks. I will visit x86 code again. > > > > > > >I think it is X86 specific. Personally I think device tree property is > > > >better. > > > > > > Do you think so? > > > > I'm not sure it is the best way. For X86 we run into problem with > > memmap= design, one example is pci domain X (X>1) need the pci memory > > ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem > > to 2nd kernel we find that cmdline[] array is not big enough. > > I'm not sure how PCI ranges relate to the memory map used for normal > memory (i.e. RAM), though I'm probably missing some caveat with the way > ACPI and UEFI describe PCI. Why does memmap= affect PCI memory? Here is the old patch which was rejected in kexec-tools: http://lists.infradead.org/pipermail/kexec/2013-February/007924.html > > If the kernel got the rest of its system topology from DT, the PCI > regions would be described there. Yes, if kdump kernel use same DT as 1st kernel. > > > Do you think for arm64 only usable memory is necessary to let kdump kernel > > know? I'm curious about how arm64 kernel get all memory layout from boot loader, > > via UEFI memmap? > > When booted via EFI, we use the EFI memory map. The EFI stub handles > acquring the relevant information and passing that to the first kernel > in the DTB (see Documentation/arm/uefi.txt). Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation instead of memory nodes details.. > > A kexec'd kernel should simply inherit that. So long as the DTB and/or > UEFI tables in memory are the same, it would be the same as a cold boot. For kexec all memory ranges are same, for kdump we need use original reserved range with crashkernel= as usable memory and all other orignal usable ranges are not usable anymore. Is it possible to modify uefi memmap for kdump case? > > In the !EFI case, we use the memory nodes in the DTB. Only in this case > could usable-memory properties in memory nodes make sense. I'd prefer a > uniform property under /chosen for both cases. We stil use same DTB, need to modify the DT and update the usable and unusable nodes for kdump? > Thanks, > Mark. Thanks Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com> To: Mark Rutland <mark.rutland@arm.com> Cc: ard.biesheuvel@linaro.org, Geoff Levand <geoff@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, AKASHI Takahiro <takahiro.akashi@linaro.org>, James Morse <james.morse@arm.com>, christoffer.dall@linaro.org, marc.zyngier@arm.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 18/19] arm64: kdump: update a kernel doc Date: Tue, 19 Jan 2016 21:45:53 +0800 [thread overview] Message-ID: <20160119134553.GA2986@dhcp-128-65.nay.redhat.com> (raw) In-Reply-To: <20160119125114.GH25024@leverpostej> On 01/19/16 at 12:51pm, Mark Rutland wrote: > On Tue, Jan 19, 2016 at 08:28:48PM +0800, Dave Young wrote: > > On 01/19/16 at 02:35pm, AKASHI Takahiro wrote: > > > On 01/19/2016 10:43 AM, Dave Young wrote: > > > >On 01/18/16 at 07:26pm, AKASHI Takahiro wrote: > > > >>On 01/16/2016 05:16 AM, Mark Rutland wrote: > > > >>>On Fri, Jan 15, 2016 at 07:18:38PM +0000, Geoff Levand wrote: > > > >>>>From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > >>>> > > > >>>>This patch adds arch specific descriptions about kdump usage on arm64 > > > >>>>to kdump.txt. > > > >>>> > > > >>>>Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > > > >>>>--- > > > >>>> Documentation/kdump/kdump.txt | 23 ++++++++++++++++++++++- > > > >>>> 1 file changed, 22 insertions(+), 1 deletion(-) > > > >>>> > > > >>>>diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > > > >>>>index bc4bd5a..36cf978 100644 > > > >>>>--- a/Documentation/kdump/kdump.txt > > > >>>>+++ b/Documentation/kdump/kdump.txt > > > >>>>@@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to > > > >>>> a remote system. > > > >>>> > > > >>>> Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, > > > >>>>-s390x and arm architectures. > > > >>>>+s390x, arm and arm64 architectures. > > > >>>> > > > >>>> When the system kernel boots, it reserves a small section of memory for > > > >>>> the dump-capture kernel. This ensures that ongoing Direct Memory Access > > > >>>>@@ -249,6 +249,20 @@ Dump-capture kernel config options (Arch Dependent, arm) > > > >>>> > > > >>>> AUTO_ZRELADDR=y > > > >>>> > > > >>>>+Dump-capture kernel config options (Arch Dependent, arm64) > > > >>>>+---------------------------------------------------------- > > > >>>>+ > > > >>>>+1) The maximum memory size on the dump-capture kernel must be limited by > > > >>>>+ specifying: > > > >>>>+ > > > >>>>+ mem=X[MG] > > > >>>>+ > > > >>>>+ where X should be less than or equal to the size in "crashkernel=" > > > >>>>+ boot parameter. Kexec-tools will automatically add this. > > > >>> > > > >>> > > > >>>This is extremely fragile, and will trivially fail when the kernel can > > > >>>be loaded anywhere (see [1]). > > > >> > > > >>As I said before, this restriction also exists on arm, but I understand > > > >>that recent Ard's patches break it. > > > >> > > > >>>We must explicitly describe the set of regions the crash kernel may use > > > >>>(i.e. we need base and size). NAK in the absence of that. > > > >> > > > >>There seem to exist several approaches: > > > >>(a) use a device-tree property, "linux,usable-memory", in addition to "reg" > > > >> under "memory" node > > > >>(b) use a kernel's early parameter, "memmap=nn[@#$]ss" > > > >> > > > >>Power PC takes (a), while this does not work on efi-started kernel > > > >>because dtb has no "memory" nodes under efi. > > > >>X86 takes (b). If we take this, we will need to overwrite a weak > > > >>early_init_dt_add_memory(). > > > > > > > >X86 takes another way in latest kexec-tools and kexec_file_load, that is > > > >recreating E820 table and pass it to kexec/kdump kernel, if the entries > > > >are over E820 limitation then turn to use setup_data list for remain > > > >entries. > > > > > > Thanks. I will visit x86 code again. > > > > > > >I think it is X86 specific. Personally I think device tree property is > > > >better. > > > > > > Do you think so? > > > > I'm not sure it is the best way. For X86 we run into problem with > > memmap= design, one example is pci domain X (X>1) need the pci memory > > ranges being passed to kdump kernel. When we passed reserved ranges in /proc/iomem > > to 2nd kernel we find that cmdline[] array is not big enough. > > I'm not sure how PCI ranges relate to the memory map used for normal > memory (i.e. RAM), though I'm probably missing some caveat with the way > ACPI and UEFI describe PCI. Why does memmap= affect PCI memory? Here is the old patch which was rejected in kexec-tools: http://lists.infradead.org/pipermail/kexec/2013-February/007924.html > > If the kernel got the rest of its system topology from DT, the PCI > regions would be described there. Yes, if kdump kernel use same DT as 1st kernel. > > > Do you think for arm64 only usable memory is necessary to let kdump kernel > > know? I'm curious about how arm64 kernel get all memory layout from boot loader, > > via UEFI memmap? > > When booted via EFI, we use the EFI memory map. The EFI stub handles > acquring the relevant information and passing that to the first kernel > in the DTB (see Documentation/arm/uefi.txt). Ok, thanks for the pointer. So in dt we are just have uefi memmap infomation instead of memory nodes details.. > > A kexec'd kernel should simply inherit that. So long as the DTB and/or > UEFI tables in memory are the same, it would be the same as a cold boot. For kexec all memory ranges are same, for kdump we need use original reserved range with crashkernel= as usable memory and all other orignal usable ranges are not usable anymore. Is it possible to modify uefi memmap for kdump case? > > In the !EFI case, we use the memory nodes in the DTB. Only in this case > could usable-memory properties in memory nodes make sense. I'd prefer a > uniform property under /chosen for both cases. We stil use same DTB, need to modify the DT and update the usable and unusable nodes for kdump? > Thanks, > Mark. Thanks Dave _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2016-01-19 13:45 UTC|newest] Thread overview: 174+ 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 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 07/19] arm64: Add back cpu_reset routines Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 03/19] arm64: Add new asm macro copy_page Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-20 14:01 ` James Morse 2016-01-20 14:01 ` James Morse 2016-01-15 19:18 ` [PATCH 05/19] arm64: Convert hcalls to use HVC immediate value Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 02/19] arm64: kernel: Include _AC definition in page.h Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-18 10:05 ` Mark Rutland 2016-01-18 10:05 ` Mark Rutland 2016-01-15 19:18 ` [PATCH 09/19] Revert "arm64: remove dead code" Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:55 ` Mark Rutland 2016-01-15 19:55 ` Mark Rutland 2016-01-20 21:18 ` Geoff Levand 2016-01-20 21:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 04/19] arm64: Cleanup SCTLR flags Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 20:07 ` Mark Rutland 2016-01-15 20:07 ` Mark Rutland 2016-01-18 10:12 ` Marc Zyngier 2016-01-18 10:12 ` Marc Zyngier 2016-01-19 11:59 ` Dave Martin 2016-01-19 11:59 ` Dave Martin 2016-01-25 15:09 ` James Morse 2016-01-25 15:09 ` James Morse 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 ` 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 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 06/19] arm64: Add new hcall HVC_CALL_FUNC Geoff Levand 2016-01-15 19:18 ` 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 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 15/19] arm64: kdump: implement machine_crash_shutdown() Geoff Levand 2016-01-15 19:18 ` 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 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 12/19] arm64/kexec: Enable kexec in the arm64 defconfig Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 18/19] arm64: kdump: update a kernel doc Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 20:16 ` Mark Rutland 2016-01-15 20:16 ` Mark Rutland 2016-01-18 10:26 ` AKASHI Takahiro 2016-01-18 10:26 ` AKASHI Takahiro 2016-01-18 11:29 ` Mark Rutland 2016-01-18 11:29 ` Mark Rutland 2016-01-19 5:31 ` AKASHI Takahiro 2016-01-19 5:31 ` AKASHI Takahiro 2016-01-19 12:10 ` Mark Rutland 2016-01-19 12:10 ` Mark Rutland 2016-01-20 4:34 ` AKASHI Takahiro 2016-01-20 4:34 ` AKASHI Takahiro 2016-01-19 1:43 ` Dave Young 2016-01-19 1:43 ` Dave Young 2016-01-19 1:50 ` Dave Young 2016-01-19 1:50 ` Dave Young 2016-01-19 5:35 ` AKASHI Takahiro 2016-01-19 5:35 ` AKASHI Takahiro 2016-01-19 12:28 ` Dave Young 2016-01-19 12:28 ` Dave Young 2016-01-19 12:51 ` Mark Rutland 2016-01-19 12:51 ` Mark Rutland 2016-01-19 13:45 ` Dave Young [this message] 2016-01-19 13:45 ` Dave Young 2016-01-19 14:01 ` Mark Rutland 2016-01-19 14:01 ` Mark Rutland 2016-01-20 2:49 ` Dave Young 2016-01-20 2:49 ` Dave Young 2016-01-20 6:07 ` AKASHI Takahiro 2016-01-20 6:07 ` AKASHI Takahiro 2016-01-20 6:38 ` Dave Young 2016-01-20 6:38 ` Dave Young 2016-01-20 7:00 ` Dave Young 2016-01-20 7:00 ` Dave Young 2016-01-20 8:01 ` AKASHI Takahiro 2016-01-20 8:01 ` AKASHI Takahiro 2016-01-20 8:26 ` Dave Young 2016-01-20 8:26 ` Dave Young 2016-01-20 11:54 ` Mark Rutland 2016-01-20 11:54 ` Mark Rutland 2016-01-21 2:57 ` Dave Young 2016-01-21 2:57 ` Dave Young 2016-01-21 3:03 ` Dave Young 2016-01-21 3:03 ` Dave Young 2016-01-20 11:49 ` Mark Rutland 2016-01-20 11:49 ` Mark Rutland 2016-01-21 6:53 ` AKASHI Takahiro 2016-01-21 6:53 ` AKASHI Takahiro 2016-01-21 12:02 ` Mark Rutland 2016-01-21 12:02 ` Mark Rutland 2016-01-22 6:23 ` AKASHI Takahiro 2016-01-22 6:23 ` AKASHI Takahiro 2016-01-22 11:13 ` Mark Rutland 2016-01-22 11:13 ` Mark Rutland 2016-02-02 5:18 ` AKASHI Takahiro 2016-02-02 5:18 ` AKASHI Takahiro 2016-01-25 3:19 ` Dave Young 2016-01-25 3:19 ` Dave Young 2016-01-25 4:23 ` Dave Young 2016-01-25 4:23 ` Dave Young 2016-01-20 11:28 ` Mark Rutland 2016-01-20 11:28 ` Mark Rutland 2016-01-21 2:54 ` Dave Young 2016-01-21 2:54 ` Dave Young 2016-01-20 5:25 ` AKASHI Takahiro 2016-01-20 5:25 ` AKASHI Takahiro 2016-01-20 12:02 ` Mark Rutland 2016-01-20 12:02 ` Mark Rutland 2016-01-20 12:36 ` Mark Rutland 2016-01-20 12:36 ` Mark Rutland 2016-01-20 14:59 ` Ard Biesheuvel 2016-01-20 14:59 ` Ard Biesheuvel 2016-01-20 15:04 ` Mark Rutland 2016-01-20 15:04 ` Mark Rutland 2016-01-21 5:43 ` AKASHI Takahiro 2016-01-21 5:43 ` AKASHI Takahiro 2016-01-21 13:02 ` Mark Rutland 2016-01-21 13:02 ` Mark Rutland 2016-01-19 12:17 ` Mark Rutland 2016-01-19 12:17 ` Mark Rutland 2016-01-19 13:52 ` Dave Young 2016-01-19 13:52 ` Dave Young 2016-01-19 14:05 ` Mark Rutland 2016-01-19 14:05 ` Mark Rutland 2016-01-20 2:54 ` Dave Young 2016-01-20 2:54 ` Dave Young 2016-01-15 19:18 ` [PATCH 10/19] arm64: kvm: allows kvm cpu hotplug Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-26 17:42 ` James Morse 2016-01-26 17:42 ` James Morse 2016-01-27 7:37 ` AKASHI Takahiro 2016-01-27 7:37 ` AKASHI Takahiro 2016-01-15 19:18 ` [PATCH 14/19] arm64: kdump: reserve memory for crash dump kernel Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 11/19] arm64/kexec: Add core kexec support Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 13/19] arm64/kexec: Add pr_debug output Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 16/19] arm64: kdump: add kdump support Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-21 14:17 ` James Morse 2016-01-21 14:17 ` James Morse 2016-01-22 4:50 ` AKASHI Takahiro 2016-01-22 4:50 ` AKASHI Takahiro 2016-01-19 12:32 ` [PATCH 00/19] arm64 kexec kernel patches v13 Dave Young 2016-01-19 12:32 ` Dave Young 2016-01-20 0:15 ` Geoff Levand 2016-01-20 0:15 ` Geoff Levand 2016-01-20 2:56 ` Dave Young 2016-01-20 2:56 ` Dave Young 2016-01-20 21:15 ` Geoff Levand 2016-01-20 21:15 ` Geoff Levand 2016-01-21 12:11 ` Mark Rutland 2016-01-21 12:11 ` Mark Rutland [not found] ` <c7575f853ccc491bb0212e025aab1cc9@NASANEXM01H.na.qualcomm.com> 2016-03-01 17:54 ` Azriel Samson 2016-03-01 17:54 ` Azriel Samson 2016-03-02 1:17 ` Geoff Levand 2016-03-02 1:17 ` Geoff Levand 2016-03-02 1:38 ` Will Deacon 2016-03-02 1:38 ` Will Deacon 2016-03-02 2:28 ` AKASHI Takahiro 2016-03-02 2:28 ` AKASHI Takahiro 2016-03-02 8:07 ` Marc Zyngier 2016-03-02 8:07 ` Marc Zyngier 2016-03-02 12:33 ` Pratyush Anand 2016-03-02 12:33 ` Pratyush Anand 2016-03-02 16:51 ` Azriel Samson 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=20160119134553.GA2986@dhcp-128-65.nay.redhat.com \ --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: linkBe 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.