Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752658AbbERIId (ORCPT ); Mon, 18 May 2015 04:08:33 -0400 Received: from mail-pd0-f180.google.com ([209.85.192.180]:34382 "EHLO mail-pd0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495AbbERII0 (ORCPT ); Mon, 18 May 2015 04:08:26 -0400 Message-ID: <55599DF0.7010507@linaro.org> Date: Mon, 18 May 2015 17:08:16 +0900 From: AKASHI Takahiro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Young CC: Mark Rutland , Catalin Marinas , Will Deacon , "vgoyal@redhat.com" , "hbabus@us.ibm.com" , "linaro-kernel@lists.linaro.org" , "geoff@infradead.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "broonie@kernel.org" , "david.griego@linaro.org" , "linux-arm-kernel@lists.infradead.org" , ard.biesheuvel@linaro.org Subject: Re: [v2 0/5] arm64: add kdump support References: <1429861989-8417-1-git-send-email-takahiro.akashi@linaro.org> <20150424095312.GD29183@leverpostej> <55504956.9020007@linaro.org> <20150512054304.GA29874@localhost.localdomain> In-Reply-To: <20150512054304.GA29874@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3493 Lines: 86 Mark, On 05/12/2015 02:43 PM, Dave Young wrote: > 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 > 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.. Do you still prefer "memmap=" approach? Just FYI, x86 arm arm64 powerpc{,64} (a) cmdline(crashkernel=) cmdline cmdline cmdline (b) iomem iomem iomem dev tree (c) cmdline(memmap=) cmdline(mem=) dev tree dev tree & cmdline(mem=) (a) how we specify/reserve crash dump kernel's memory on 1st kernel (b) how we inform userspace tool of crash dump kernel's memory on 1st kernel - iomem: add "Crash kernel" entry in /proc/iomem - dev tree: add /chosen/linux,crashkernel-base (and crashkernel-size) (c) how we specify usable memory on crash dump kernel - dev tree: add /chosen/memory/linux,usable-memory As you see, arm64, and arm as well, does things in a *hybrid* way of x86 and ppc. I think we should go for a uniform way with device tree as ppc does. (Even for (a), we can use a device tree.) > Another way is introducing a similar memmap=, but maybe consider only > system_ram type ranges. For other memory areas still use UEFI memmap. Yeah, I don't know whether we need additional formats of memmap=, like memmap=XX$YY or memmap=XX#YY, for ACPI stuffs. Thanks, -Takahiro AKASHI > Thanks > Dave > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/