Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5525351ybf; Thu, 5 Mar 2020 02:15:22 -0800 (PST) X-Google-Smtp-Source: ADFU+vteUiKAE4K5QJEktIT2E5YVx6w44Wz6uFkKW+LscymQ6hCXOJrSpqa35ak7xGmr4enpb1sD X-Received: by 2002:a54:478b:: with SMTP id o11mr204459oic.146.1583403322495; Thu, 05 Mar 2020 02:15:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583403322; cv=none; d=google.com; s=arc-20160816; b=Eo+jEzNEdSaxiPqlS7QckQKT/Vrk6DNpxdaddeNiXSfMAQBigy36yqY7bNeep3mcgd K8mWIV4VhajQanf1AwlRhCXwITnj8JsE7teeiKELl7ZucYSPalwB9EZA83xHe1mhK2QY B1clyPKxUYoCEBZl6ab+9uID5Smwy4n6irLOO9K7ljCGms4IsscochMLGRbbU87ZNatE O6tBCgM0eIg7TftRJFAn7zo4cmtAvv1rqZI1dztFow2cmrfxs4ZQ8CMt8cB9T6qwdWJr qOQjWLwVW4ZmCNJzF89JajOoA+jwS8GGaRP7DCjwJrYXFJQEchM89dpsogDipxQFO3Mt S7Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ouu4WXxCaevxlmC9Uhz7tTOBhGUlnzRHTVeHp1aOhiI=; b=U4iU25K4P0GVBIpI6Mpf4LJuov+xA+ZD/c1pOUZgSegmc/UcH9AARe1yqs1E2yQrQU FQ7XbccRGUD2YY6uZ+E/6lzUiHkLwyqo2kykcDS2S1R/Itg6SbagSTM4XMnkbOmovYeP W7AOo3yJ64P9rHXeekS3oxLEV0SgUOZOXXJQFwBEFRnyrgUYgaOWDhjEQRTz2PElFt3I OoZeQoXSVorGGhEx+3lxKNZ30p5X2/fJ4yDKlDG0t3zO3u1fyAm56DZESuk0QpLsl9ks XV1Hjt70GeDZX5UZSvbc3o1EsKhhKb6VbrML4yvz6k6F+IxD1kGUZajSsa67Qj/lGhoC 1w4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TaYxDEie; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 45si3542409otu.264.2020.03.05.02.15.10; Thu, 05 Mar 2020 02:15:22 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=TaYxDEie; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727222AbgCEKOV (ORCPT + 99 others); Thu, 5 Mar 2020 05:14:21 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:40523 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727304AbgCEKOU (ORCPT ); Thu, 5 Mar 2020 05:14:20 -0500 Received: by mail-wm1-f67.google.com with SMTP id e26so5040964wme.5; Thu, 05 Mar 2020 02:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ouu4WXxCaevxlmC9Uhz7tTOBhGUlnzRHTVeHp1aOhiI=; b=TaYxDEiehx09bbma3RrgW09W2c0LlA1BkOiJvjGkNPusdexeODgG4SuNhkwsrMwY0o 4007WMrc/4m39OYw4UUkMcQLVpGdZn4c9jBY2o6By1cbNmG1Z9uVdbmAgVrsqfMxqqmW ZMkjrkmS0MwfFDQzyVrGWV3v1HB6q0WnW8LVg+iUXsC7ck7Y1I7myp0Ygg3nNArFQbSn v5nJAENj2gi81V077ki2FvmLt82EfVsLTSytj7KqD5d5XejoEzpIyQUFH/QofGhvwzeb usDNXUIu2OCq9K9SjznaVah+2+9KoN6CsvNnqeIep32vZvTKQtG2UG4e0mnYpBw9+Yxl 2Giw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ouu4WXxCaevxlmC9Uhz7tTOBhGUlnzRHTVeHp1aOhiI=; b=JQfX8aV/8oKKKHzpSq+PTdE8RUm8tGnKkDDazAQJVnVzy4fwDvEJe0XICutsq4jB/1 pyY1Zi8wwttU17/pxu2+pTQbTC7n+EBhu7sCIHQAt3FzFIX0YI0hA+IR0eJ9VCEIxbOy oQbTfF0uZSzEhbqrkQVjYbcaek3h0mpt6TR3pK7wPFwxIrOVVLYMTSjMPjVa4Tx9FeDj 0ZaishPBzdcgZugU+wnnDrOvRsfSyK1ctPFlj0vT5HJoFdbAJ4NRqEoDXpHi0rl5dwAE 3NMtRdqzYcPgaEcUFaSJtd8RKhcXsMX22sZC6CFJ5ZzxJnQ4Jv3GxAMOrGyJs1iqlQeE BCNA== X-Gm-Message-State: ANhLgQ10fWvLKdUZsa3GiyDrUyFMgeBjatHL/v2Ds9gfpmOAPwDfeehf vZ/t7ZTvEKOdojG5BC3HyhedEkpkb69RD96vBz9MqZUZ X-Received: by 2002:a05:600c:4108:: with SMTP id j8mr8669423wmi.188.1583403257961; Thu, 05 Mar 2020 02:14:17 -0800 (PST) MIME-Version: 1.0 References: <20191223152349.180172-1-chenzhou10@huawei.com> <20191223152349.180172-3-chenzhou10@huawei.com> In-Reply-To: <20191223152349.180172-3-chenzhou10@huawei.com> From: Prabhakar Kushwaha Date: Thu, 5 Mar 2020 15:43:40 +0530 Message-ID: Subject: Re: [PATCH v7 2/4] arm64: kdump: reserve crashkenel above 4G for crash dump kernel To: Chen Zhou Cc: Thomas Gleixner , mingo@redhat.com, Catalin Marinas , Will Deacon , James Morse , dyoung@redhat.com, Bhupesh Sharma , xiexiuqi@huawei.com, Linux Doc Mailing List , kexec mailing list , Linux Kernel Mailing List , horms@verge.net.au, linux-arm-kernel , Ganapatrao Prabhakerrao Kulkarni Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 23, 2019 at 8:57 PM Chen Zhou wrote: > > Crashkernel=X tries to reserve memory for the crash dump kernel under > 4G. If crashkernel=X,low is specified simultaneously, reserve spcified > size low memory for crash kdump kernel devices firstly and then reserve > memory above 4G. > > Signed-off-by: Chen Zhou > --- > arch/arm64/kernel/setup.c | 8 +++++++- > arch/arm64/mm/init.c | 31 +++++++++++++++++++++++++++++-- > 2 files changed, 36 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index 56f6645..04d1c87 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -238,7 +238,13 @@ static void __init request_standard_resources(void) > kernel_data.end <= res->end) > request_resource(res, &kernel_data); > #ifdef CONFIG_KEXEC_CORE > - /* Userspace will find "Crash kernel" region in /proc/iomem. */ > + /* > + * Userspace will find "Crash kernel" region in /proc/iomem. > + * Note: the low region is renamed as Crash kernel (low). > + */ > + if (crashk_low_res.end && crashk_low_res.start >= res->start && > + crashk_low_res.end <= res->end) > + request_resource(res, &crashk_low_res); > if (crashk_res.end && crashk_res.start >= res->start && > crashk_res.end <= res->end) > request_resource(res, &crashk_res); > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index b65dffd..0d7afd5 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -80,6 +80,7 @@ static void __init reserve_crashkernel(void) > { > unsigned long long crash_base, crash_size; > int ret; > + phys_addr_t crash_max = arm64_dma32_phys_limit; > > ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(), > &crash_size, &crash_base); > @@ -87,12 +88,38 @@ static void __init reserve_crashkernel(void) > if (ret || !crash_size) > return; > > + ret = reserve_crashkernel_low(); > + if (!ret && crashk_low_res.end) { > + /* > + * If crashkernel=X,low specified, there may be two regions, > + * we need to make some changes as follows: > + * > + * 1. rename the low region as "Crash kernel (low)" > + * In order to distinct from the high region and make no effect > + * to the use of existing kexec-tools, rename the low region as > + * "Crash kernel (low)". > + * > + * 2. change the upper bound for crash memory > + * Set MEMBLOCK_ALLOC_ACCESSIBLE upper bound for crash memory. > + * > + * 3. mark the low region as "nomap" > + * The low region is intended to be used for crash dump kernel > + * devices, just mark the low region as "nomap" simply. > + */ > + const char *rename = "Crash kernel (low)"; > + > + crashk_low_res.name = rename; > + crash_max = MEMBLOCK_ALLOC_ACCESSIBLE; > + memblock_mark_nomap(crashk_low_res.start, > + resource_size(&crashk_low_res)); > + } > + > crash_size = PAGE_ALIGN(crash_size); > > if (crash_base == 0) { > /* Current arm64 boot protocol requires 2MB alignment */ > - crash_base = memblock_find_in_range(0, arm64_dma32_phys_limit, > - crash_size, SZ_2M); > + crash_base = memblock_find_in_range(0, crash_max, crash_size, > + SZ_2M); > if (crash_base == 0) { > pr_warn("cannot allocate crashkernel (size:0x%llx)\n", > crash_size); > -- I tested this patch series on ARM64-ThunderX2 with no issue with bootargs crashkenel=X@Y crashkernel=250M,low $ dmesg | grep crash [ 0.000000] crashkernel reserved: 0x0000000b81200000 - 0x0000000c81200000 (4096 MB) [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc4+ root=UUID=866b8df3-14f4-4e11-95a1-74a90ee9b694 ro crashkernel=4G@0xb81200000 crashkernel=250M,low nowatchdog earlycon [ 29.310209] crashkernel=250M,low $ kexec -p -i /boot/vmlinuz-`uname -r` --initrd=/boot/initrd.img-`uname -r` --reuse-cmdline $ echo 1 > /proc/sys/kernel/sysrq ; echo c > /proc/sysrq-trigger But when i tried with crashkernel=4G crashkernel=250M,low as bootargs. Kernel is not able to allocate memory. [ 0.000000] cannot allocate crashkernel (size:0x100000000) [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc4+ root=UUID=866b8df3-14f4-4e11-95a1-74a90ee9b694 ro crashkernel=4G crashkernel=250M,low nowatchdog [ 29.332081] crashkernel=250M,low does crashkernel=X@Y mandatory to get allocated beyond 4G? am I missing something? --pk