Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp116992yba; Wed, 15 May 2019 20:21:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyjy3rmfRkKmt3zJojjFLMbDC/XykHoNW1OG043L5RpyIlGYX1WCKK+4gT5wWQS8nLrSA1A X-Received: by 2002:a65:6497:: with SMTP id e23mr34034694pgv.388.1557976913146; Wed, 15 May 2019 20:21:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557976913; cv=none; d=google.com; s=arc-20160816; b=rtGZ3POrKXFj8ziceBM8rZyFNccN2wyLQso791CtduyBA/E3uekRXvonnmAlYqkYSp Ebw4Yh5/zcV61q9SLNohm9dSht0/tFFKNJ+ZEWzEoLhozJr0W4n/mUqXyujXzH77l4kh R40rUJVvLe/jURSoL7zzwEjT6w2nN3/CSUlm2+X8HusijAwiBxdj03B4cIM82U2ECcxw 889hGEy/T00HvxwoOUOjqiQ3fH6OZg99+oaeWP3HjMQDcOkJGzZSrZ+FcMgNSXHeq1On gy8gmaIpdg2KAx1uiBa3hRf0wzZRBRX950qhl0Roi4sAglWERMmyP53H5c4VvMOxXUDU /G/g== 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=wUPrlayxZAHEPFNnUw2o9RSmBgOUg082vXAxTNTDyj4=; b=rSnt3mY8XXhfWz3PAVkqO4fvdY7aG3LTr3Ux0tDDPid2bjvTGnpTkjKs/URh4PBepI Dw2ioqNZ4KQRFkgXU4Hi9HH9B2lTwtav1EhpwllkGEgaGPaMfZHf2q4F9F+EjH4dW2WL fvG78IUvvwQQvvhIBRIy7zZ6PSDb2NJ2Ko+wLEzMUYH3OrgTMW/UXadrYCrTxYdM904a e7HglIOsMGLmciFbaK+NVK2R7hcogHcnlNcAslboTILV5zqFaoKGynzCGthMheDsomxs J6dPuQcZa2kTEoGwrElB4UIUOGYK2+lfY3AsqxOoGvjQ49iV1j6rjRLi6ysYYjqq9cFO cDtQ== 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 n1si3519931pld.61.2019.05.15.20.21.37; Wed, 15 May 2019 20:21:53 -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 S1726394AbfEPDTP (ORCPT + 99 others); Wed, 15 May 2019 23:19:15 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:56726 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726157AbfEPDTP (ORCPT ); Wed, 15 May 2019 23:19:15 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 97C3BD4F352B9FFE6FAD; Thu, 16 May 2019 11:19:13 +0800 (CST) Received: from [127.0.0.1] (10.177.131.64) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.439.0; Thu, 16 May 2019 11:19:07 +0800 Subject: Re: [PATCH 0/4] support reserving crashkernel above 4G on arm64 kdump To: Bhupesh Sharma , , , , , , , , , References: <20190507035058.63992-1-chenzhou10@huawei.com> CC: , , , , , , , Bhupesh SHARMA From: Chen Zhou Message-ID: Date: Thu, 16 May 2019 11:19:05 +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: 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 Bhupesh, On 2019/5/15 13:06, Bhupesh Sharma wrote: > +Cc kexec-list. > > Hi Chen, > > I think we are still in the quiet period of the merge cycle, but this is a change which will be useful for systems like HPE Apollo where we are looking at reserving crashkernel across a larger range. > > Some comments inline and in respective patch threads.. > > On 05/07/2019 09:20 AM, Chen Zhou wrote: >> This patch series enable reserving crashkernel on high memory in arm64. > > Please fix the patch subject, it should be v5. > Also please Cc the kexec-list (kexec@lists.infradead.org) for future versions to allow wider review of the patchset. > >> We use crashkernel=X to reserve crashkernel below 4G, which will fail >> when there is no enough memory. Currently, crashkernel=Y@X can be used >> to reserve crashkernel above 4G, in this case, if swiotlb or DMA buffers >> are requierd, capture kernel will boot failure because of no low memory. > > ... ^^ required > > s/capture kernel will boot failure because of no low memory./capture kernel boot will fail because there is no low memory available for allocation. > >> When crashkernel is reserved above 4G in memory, kernel should reserve >> some amount of low memory for swiotlb and some DMA buffers. So there may >> be two crash kernel regions, one is below 4G, the other is above 4G. Then >> Crash dump kernel reads more than one crash kernel regions via a dtb >> property under node /chosen, >> linux,usable-memory-range = . > > Please use consistent naming for the second kernel, better to use crash dump kernel. > > I have tested this on my HPE Apollo machine and with crashkernel=886M,high syntax, I can get the board to reserve a larger memory range for the crashkernel (i.e. 886M): > > # dmesg | grep -i crash > [ 0.000000] kexec_core: Reserving 256MB of low memory at 3560MB for crashkernel (System low RAM: 2029MB) > [ 0.000000] crashkernel reserved: 0x0000000bc5a00000 - 0x0000000bfd000000 (886 MB) > > kexec/kdump can also work also work fine on the board. > > So, with the changes suggested in this cover letter and individual patches, please feel free to add: > > Reviewed-and-Tested-by: Bhupesh Sharma > > Thanks, > Bhupesh > Thanks for you review and test. I will fix these later. Thanks, Chen Zhou >> Besides, we need to modify kexec-tools: >> arm64: support more than one crash kernel regions(see [1]) >> >> I post this patch series about one month ago. The previous changes and >> discussions can be retrived from: >> >> 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-April/022792.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 >> >> Chen Zhou (3): >> x86: kdump: move reserve_crashkernel_low() into kexec_core.c >> arm64: kdump: support reserving crashkernel above 4G >> kdump: update Documentation about crashkernel on arm64 >> >> Mike Rapoport (1): >> memblock: extend memblock_cap_memory_range to multiple ranges >> >> Documentation/admin-guide/kernel-parameters.txt | 6 +-- >> arch/arm64/include/asm/kexec.h | 3 ++ >> arch/arm64/kernel/setup.c | 3 ++ >> arch/arm64/mm/init.c | 72 +++++++++++++++++++------ >> arch/x86/include/asm/kexec.h | 3 ++ >> arch/x86/kernel/setup.c | 66 +++-------------------- >> include/linux/kexec.h | 5 ++ >> include/linux/memblock.h | 2 +- >> kernel/kexec_core.c | 56 +++++++++++++++++++ >> mm/memblock.c | 44 +++++++-------- >> 10 files changed, 157 insertions(+), 103 deletions(-) >> > > > . >