Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3251728yba; Mon, 6 May 2019 20:43:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqyMeJrZn+Z2p0lyIv8pWFKoRcLmVXl2lTCX9oyt1k6/dfFndIGyxyunFoFFtqoETFSRmLer X-Received: by 2002:a17:902:8343:: with SMTP id z3mr21110038pln.240.1557200599842; Mon, 06 May 2019 20:43:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557200599; cv=none; d=google.com; s=arc-20160816; b=xeqAJjQ+6a1fbz80Jako9dtTag/7C0miPVrnbaFuBbrEHpS2TB/Ozjv6r29ICWcgqD bMspaIl2p0J1iDmg8F6AmwoHnzSg3CaPvBtYfaZFENF1zwW+IiZ0DhIhR6uucVFr/6VL rD3ja2Er0SSZpYWcCj0/OzjVXoO9iEE4S32Zdpw+7BlTuROvdwdtcihHemxLK+e3VLtm 1Lmp4fK1k90QSp4x2etQf/Ol0/dJuVc5UumhqdoklXJ6bA8TL01FuNqFNcT0BLX50ZhI UING0ubljnCSPbntJmewQERtCix9Oi3h16surlBb7KmPWmiDBIJKWJiTkG9wCwFioExz G4lQ== 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:mime-version :message-id:date:subject:cc:to:from; bh=nkSEtngruEPgV7UOd57ZmxJxTXxp73Kn+Vlqw0twJIw=; b=pfhx/M9Q7tY9xaaoHRrbLgHl9GmqjOR+WJzmd90gg8mI2jxKIJ/s3p3gRzlfEljMxr KG59wC/hkqffCBtbs/RB/bcnAqC2wllcUM+T0xgga+6iauwV717eI5+XEbq5DID7IrW0 i44/mXGNmKMhrv0Jdg5dNzscUA9j0Z5FxXYP9ngXY+mXRCo6W2BeOxXQFOqk3ipsKRLq sZ/pmPNGW5CSbjuFRtak4xIMMVvG6Z5qJLDC75ZWrJNii1ImI9LDLEynVVLMB6GsAjps SsW8m4/B9LcIgxkp0bg6cyUSex9aG7IRMC/PGGnIAxxoRCUb6WGFtgbOltiBfbMbWMX8 S7XA== 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 y1si18940609plb.276.2019.05.06.20.43.00; Mon, 06 May 2019 20:43:19 -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 S1727348AbfEGDmI (ORCPT + 99 others); Mon, 6 May 2019 23:42:08 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:38284 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726912AbfEGDmH (ORCPT ); Mon, 6 May 2019 23:42:07 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 44A7083ABDF68C9C0024; Tue, 7 May 2019 11:42:05 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.439.0; Tue, 7 May 2019 11:41:55 +0800 From: Chen Zhou To: , , , , , , , , CC: , , , , , , , Chen Zhou Subject: [PATCH 0/4] support reserving crashkernel above 4G on arm64 kdump Date: Tue, 7 May 2019 11:50:54 +0800 Message-ID: <20190507035058.63992-1-chenzhou10@huawei.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.25] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch series enable reserving crashkernel on high memory in arm64. 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. 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 = . 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(-) -- 2.7.4