Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1281805ybb; Wed, 25 Mar 2020 20:11:24 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvu772Ptg+0nWVk2oEo6769PXisGPkCSsdeC+Mvlnx6JjRVEjUzJELHRoV0A9fk41mYL6vk X-Received: by 2002:aca:5211:: with SMTP id g17mr478165oib.19.1585192284795; Wed, 25 Mar 2020 20:11:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585192284; cv=none; d=google.com; s=arc-20160816; b=gbyGMcQKuE1qTsqaIWYqoGQTH55pLORtbXe8dA/XOB8dIHIFfC+i15JO/XG/Qj4qnZ TMKJrIeGYq12AcRsemnWgKbI6D/Fy/wLzIA/m5TO5GXVMsPBXikTGbGGVSeG3FG5LwFk cAEz/Xbnew399/h4WVR4trPm9gSGmsrj2nr4HZ+n+yMHwVgQQE1/MYQxJvQGJw1Q4QAz EsjzPucgRfUjMOsPQFWsSMo+hkDvzwz8SsDX8XHxKj+/NHgmcRc8Q7w42FDrk1N/cq8k sgAuci35zMfsnwyfIOAQEJf2a38JFymWn57EH4oMe3uAiY/XPGEY6tINAVPgh4vqGdw5 z+sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=Sag4LBaRgPpBAGdvDlZICIrFil0/sJypQnQKR6ky83M=; b=k93GR+p1CWkN62hmSA5N8wRESzN6myZmHGYPVl8wDNqZo4bSvdYO1HuQ/pZGRazoWg 9+yn+C34bEjozPlAVVXfuJnqxUP7h3TdPwjMAwdOWkGSFMgwDYPuu6O0+A2ubBqBDa4a WVOdul5sRf9I70TQwEyer9VzGlUpK0K6F1xDCqTWek1f93RayV9HHxZIuX7eCLTA2bo3 2d6j0720AitdL8JbR0n04QjkegWcXkGNTWJfT5KFMoPeVnCMEHOUopN8hMGFarKa+R9i 7zHri041J6FupnX76QTVhi44NFcSWuucml6TlP5ZypPE80rvXlSnAASGW2qDl75Lj2DQ JAmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n82si430882oih.195.2020.03.25.20.11.11; Wed, 25 Mar 2020 20:11:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727697AbgCZDJn (ORCPT + 99 others); Wed, 25 Mar 2020 23:09:43 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:12134 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727585AbgCZDJn (ORCPT ); Wed, 25 Mar 2020 23:09:43 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 112EDC7C64946249E08A; Thu, 26 Mar 2020 11:09:40 +0800 (CST) Received: from [127.0.0.1] (10.177.131.64) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.487.0; Thu, 26 Mar 2020 11:09:39 +0800 Subject: Re: [PATCH v7 0/4] support reserving crashkernel above 4G on arm64 kdump To: , , , , , , , , References: <20191223152349.180172-1-chenzhou10@huawei.com> CC: , , , , From: Chen Zhou Message-ID: Date: Thu, 26 Mar 2020 11:09:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20191223152349.180172-1-chenzhou10@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.131.64] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Friendly ping... On 2019/12/23 23:23, Chen Zhou wrote: > This patch series enable reserving crashkernel above 4G in arm64. > > There are following issues in arm64 kdump: > 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail > when there is no enough low memory. > 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G, > in this case, if swiotlb or DMA buffers are required, crash dump kernel > will boot failure because there is no low memory available for allocation. > > To solve these issues, introduce crashkernel=X,low to reserve specified > size low memory. > Crashkernel=X tries to reserve memory for the crash dump kernel under > 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified > size low memory for crash kdump kernel devices firstly and then reserve > memory above 4G. > > When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low > is specified simultaneously, kernel should reserve specified size low memory > for crash dump kernel devices. So there may be two crash kernel regions, one > is below 4G, the other is above 4G. > In order to distinct from the high region and make no effect to the use of > kexec-tools, rename the low region as "Crash kernel (low)", and add DT property > "linux,low-memory-range" to crash dump kernel's dtb to pass the low region. > > Besides, we need to modify kexec-tools: > arm64: kdump: add another DT property to crash dump kernel's dtb(see [1]) > > The previous changes and discussions can be retrieved from: > > Changes since [v6] > - Fix build errors reported by kbuild test robot. > > Changes since [v5] > - Move reserve_crashkernel_low() into kernel/crash_core.c. > - Delete crashkernel=X,high. > - Modify crashkernel=X,low. > If crashkernel=X,low is specified simultaneously, reserve spcified size low > memory for crash kdump kernel devices firstly and then reserve memory above 4G. > In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then > pass to crash dump kernel by DT property "linux,low-memory-range". > - Update Documentation/admin-guide/kdump/kdump.rst. > > Changes since [v4] > - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike. > > Changes since [v3] > - Add memblock_cap_memory_ranges back for multiple ranges. > - Fix some compiling warnings. > > Changes since [v2] > - Split patch "arm64: kdump: support reserving crashkernel above 4G" as > two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate > patch. > > Changes since [v1]: > - Move common reserve_crashkernel_low() code into kernel/kexec_core.c. > - Remove memblock_cap_memory_ranges() i added in v1 and implement that > in fdt_enforce_memory_region(). > There are at most two crash kernel regions, for two crash kernel regions > case, we cap the memory range [min(regs[*].start), max(regs[*].end)] > and then remove the memory range in the middle. > > [1]: http://lists.infradead.org/pipermail/kexec/2019-August/023569.html > [v1]: https://lkml.org/lkml/2019/4/2/1174 > [v2]: https://lkml.org/lkml/2019/4/9/86 > [v3]: https://lkml.org/lkml/2019/4/9/306 > [v4]: https://lkml.org/lkml/2019/4/15/273 > [v5]: https://lkml.org/lkml/2019/5/6/1360 > [v6]: https://lkml.org/lkml/2019/8/30/142 > > Chen Zhou (4): > x86: kdump: move reserve_crashkernel_low() into crash_core.c > arm64: kdump: reserve crashkenel above 4G for crash dump kernel > arm64: kdump: add memory for devices by DT property, low-memory-range > kdump: update Documentation about crashkernel on arm64 > > Documentation/admin-guide/kdump/kdump.rst | 13 +++- > Documentation/admin-guide/kernel-parameters.txt | 12 +++- > arch/arm64/kernel/setup.c | 8 ++- > arch/arm64/mm/init.c | 61 ++++++++++++++++- > arch/x86/kernel/setup.c | 62 ++---------------- > include/linux/crash_core.h | 3 + > include/linux/kexec.h | 2 - > kernel/crash_core.c | 87 +++++++++++++++++++++++++ > kernel/kexec_core.c | 17 ----- > 9 files changed, 183 insertions(+), 82 deletions(-) >