Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3600906yba; Tue, 9 Apr 2019 00:23:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxBjfSwQBZzUlEs2OPDYUY16XPaN6tXfA1GaOZjXmrI1/Ks1xHur+D8UaRLXKHX8WIj/7+/ X-Received: by 2002:aa7:82d6:: with SMTP id f22mr34934428pfn.190.1554794582837; Tue, 09 Apr 2019 00:23:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554794582; cv=none; d=google.com; s=arc-20160816; b=KbAgzW7y0/phJEHvxplkkopo+puudZwDBIgnKubVxn4+pzFu1zuyOlm6gmTU3m0iHZ A9ZxElR3jrWsUw5d4d9LD9f5at0T+7fD9o60EN/dL00eMo5Tn4RaLpUxLzQJAGmASB6L zogDh3KE1kRU1pCLuzY+l/ZGG82Ht8o7eM5UKI0pOw0PdCnyxBvo24lWdjMtNypEBF0e UKwNyFmXGzYhj4oGxm5qACMPB+Lytcd8UE2QaLmb9paRslV4DLy+Lg/scljUhTtH3yS6 GBMFhXBLagdZWszmbnwUUWp5JXf62x6L+8fP834LS22mEGjMrIsGXn3sEmgYGS7lHySP BlnA== 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=V/4ZPsKLpexL5//Y8vfNyh5DxmEh2PT2Q9CiBEnNMOk=; b=WCui2plCRNXrq+E03kAzDkvng4niCFyLsY3N98J4NVhBT3SyswAKv+S3bZy3tABo2/ +3EhcUYYN+SLXg1AwtLmJ3kajLP+CHWos8AS1GnFgShzwIOYMZ+R28eWIjtxkMWWyo5W C+Lxz33hGQa5NtRuBMKuzXZdeKQHU/FyK4JcXe4QuaUTnH3nxqn1IGf7kGNYDvIF6/o8 kYnG2qcf6U6K/0KoJaQdipcGB0x3lAQ+2YFvo+sJLk0Kp94AGeLNk4/OkRguMPu9Xf7o 8xnYBTTiRWVvIv17JDPfcjPD95W2cKWxfz+g+HLjnK7PscRxfXJLU2s9l+df6/w3Ykz2 zAVw== 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 q3si27767331pgp.40.2019.04.09.00.22.47; Tue, 09 Apr 2019 00:23:02 -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 S1726602AbfDIHVC (ORCPT + 99 others); Tue, 9 Apr 2019 03:21:02 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:6713 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726112AbfDIHVA (ORCPT ); Tue, 9 Apr 2019 03:21:00 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 7D041955658E41FF5A87; Tue, 9 Apr 2019 15:20:55 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.408.0; Tue, 9 Apr 2019 15:20:45 +0800 From: Chen Zhou To: , , , , CC: , , , , , , , Chen Zhou Subject: [PATCH v2 0/3] support reserving crashkernel above 4G on arm64 kdump Date: Tue, 9 Apr 2019 15:31:40 +0800 Message-ID: <20190409073143.75808-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 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. 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]) 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/8/628 Chen Zhou (3): arm64: kdump: support reserving crashkernel above 4G arm64: kdump: support more than one crash kernel regions kdump: update Documentation about crashkernel on arm64 Documentation/admin-guide/kernel-parameters.txt | 4 +- arch/arm64/include/asm/kexec.h | 3 + arch/arm64/kernel/setup.c | 3 + arch/arm64/mm/init.c | 92 +++++++++++++++++++++---- arch/x86/include/asm/kexec.h | 3 + arch/x86/kernel/setup.c | 66 ++---------------- include/linux/kexec.h | 1 + include/linux/memblock.h | 6 ++ kernel/kexec_core.c | 53 ++++++++++++++ mm/memblock.c | 7 +- 10 files changed, 159 insertions(+), 79 deletions(-) -- 2.7.4