From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pf0-x231.google.com ([2607:f8b0:400e:c00::231]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aL715-0005sx-8k for kexec@lists.infradead.org; Mon, 18 Jan 2016 10:26:32 +0000 Received: by mail-pf0-x231.google.com with SMTP id e65so156305842pfe.0 for ; Mon, 18 Jan 2016 02:26:10 -0800 (PST) Subject: Re: [PATCH 18/19] arm64: kdump: update a kernel doc References: <20160115201601.GR3262@leverpostej> From: AKASHI Takahiro Message-ID: <569CBDBC.5050500@linaro.org> Date: Mon, 18 Jan 2016 19:26:04 +0900 MIME-Version: 1.0 In-Reply-To: <20160115201601.GR3262@leverpostej> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Mark Rutland , Geoff Levand Cc: ard.biesheuvel@linaro.org, marc.zyngier@arm.com, Catalin Marinas , Will Deacon , James Morse , linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, christoffer.dall@linaro.org 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 >> >> This patch adds arch specific descriptions about kdump usage on arm64 >> to kdump.txt. >> >> Signed-off-by: AKASHI Takahiro >> --- >> 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(). (I thought that this approach was not smart as we have three different ways to specify memory regions, dtb, efi and this kernel parameter.) Do you have any other ideas? Thanks, -Takahiro AKASHI > Thanks, > Mark. > >> + >> +2) Currently, kvm will not be enabled on the dump-capture kernel even >> + if it is configured. >> + >> Extended crashkernel syntax >> =========================== >> >> @@ -312,6 +326,8 @@ Boot into System Kernel >> any space below the alignment point may be overwritten by the dump-capture kernel, >> which means it is possible that the vmcore is not that precise as expected. >> >> + On arm64, use "crashkernel=Y[@X]". Note that the start address of >> + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). >> >> Load the Dump-capture Kernel >> ============================ >> @@ -334,6 +350,8 @@ For s390x: >> - Use image or bzImage >> For arm: >> - Use zImage >> +For arm64: >> + - Use vmlinux or Image >> >> If you are using a uncompressed vmlinux image then use following command >> to load dump-capture kernel. >> @@ -377,6 +395,9 @@ For s390x: >> For arm: >> "1 maxcpus=1 reset_devices" >> >> +For arm64: >> + "1 mem=X[MG] maxcpus=1 reset_devices" >> + >> Notes on loading the dump-capture kernel: >> >> * By default, the ELF headers are stored in ELF64 format to support >> -- >> 2.5.0 >> >> > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398527.html > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec