From: Baoquan He <bhe@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
Date: Fri, 11 Feb 2022 18:30:34 +0800 [thread overview]
Message-ID: <YgY6yvX7PEeZpdTr@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220124084708.683-4-thunder.leizhen@huawei.com>
On 01/24/22 at 04:47pm, Zhen Lei wrote:
> From: Chen Zhou <chenzhou10@huawei.com>
......
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 6c653a2c7cff052..a5d43feac0d7d96 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> + unsigned long long low_base;
> +
> + /* passed with crashkernel=0,low ? */
> + if (!low_size)
> + return 0;
> +
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0, CRASH_ADDR_LOW_MAX);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> + insert_resource(&iomem_resource, &crashk_low_res);
> +
> + return 0;
> +}
> +
> /*
> * reserve_crashkernel() - reserves memory for crash kernel
> *
> @@ -81,29 +105,62 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_base, crash_size;
> + unsigned long long crash_low_size = SZ_256M;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> int ret;
> + bool fixed_base;
> + char *cmdline = boot_command_line;
>
> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> + /* crashkernel=X[@offset] */
> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> &crash_size, &crash_base);
> - /* no crashkernel= or invalid value specified */
> - if (ret || !crash_size)
> - return;
> + if (ret || !crash_size) {
> + unsigned long long low_size;
>
> + /* crashkernel=X,high */
> + ret = parse_crashkernel_high(cmdline, 0, &crash_size, &crash_base);
> + if (ret || !crash_size)
> + return;
> +
> + /* crashkernel=X,low */
> + ret = parse_crashkernel_low(cmdline, 0, &low_size, &crash_base);
> + if (!ret)
> + crash_low_size = low_size;
Here, the error case is not checked and handled. But it still gets
expeced result which is the default SZ_256M. Is this designed on
purpose?
> +
> + crash_max = CRASH_ADDR_HIGH_MAX;
> + }
> +
> + fixed_base = !!crash_base;
> crash_size = PAGE_ALIGN(crash_size);
>
> /* User specifies base address explicitly. */
> if (crash_base)
> crash_max = crash_base + crash_size;
>
> +retry:
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> crash_base, crash_max);
> if (!crash_base) {
> + /*
> + * Attempt to fully allocate low memory failed, fall back
> + * to high memory, the minimum required low memory will be
> + * reserved later.
> + */
> + if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
> + crash_max = CRASH_ADDR_HIGH_MAX;
> + goto retry;
> + }
> +
> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> crash_size);
> return;
> }
>
> + if (crash_base >= SZ_4G && reserve_crashkernel_low(crash_low_size)) {
> + memblock_phys_free(crash_base, crash_size);
> + return;
> + }
> +
> pr_info("crashkernel reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
> crash_base, crash_base + crash_size, crash_size >> 20);
>
> @@ -112,6 +169,9 @@ static void __init reserve_crashkernel(void)
> * map. Inform kmemleak so that it won't try to access it.
> */
> kmemleak_ignore_phys(crash_base);
> + if (crashk_low_res.end)
> + kmemleak_ignore_phys(crashk_low_res.start);
> +
> crashk_res.start = crash_base;
> crashk_res.end = crash_base + crash_size - 1;
> insert_resource(&iomem_resource, &crashk_res);
> --
> 2.25.1
>
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
kexec@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
Feng Zhou <zhoufeng.zf@bytedance.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Chen Zhou <dingguo.cz@antgroup.com>,
John Donnelly <John.p.donnelly@oracle.com>,
Dave Kleikamp <dave.kleikamp@oracle.com>
Subject: Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
Date: Fri, 11 Feb 2022 18:30:34 +0800 [thread overview]
Message-ID: <YgY6yvX7PEeZpdTr@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220124084708.683-4-thunder.leizhen@huawei.com>
On 01/24/22 at 04:47pm, Zhen Lei wrote:
> From: Chen Zhou <chenzhou10@huawei.com>
......
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 6c653a2c7cff052..a5d43feac0d7d96 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> + unsigned long long low_base;
> +
> + /* passed with crashkernel=0,low ? */
> + if (!low_size)
> + return 0;
> +
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0, CRASH_ADDR_LOW_MAX);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> + insert_resource(&iomem_resource, &crashk_low_res);
> +
> + return 0;
> +}
> +
> /*
> * reserve_crashkernel() - reserves memory for crash kernel
> *
> @@ -81,29 +105,62 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_base, crash_size;
> + unsigned long long crash_low_size = SZ_256M;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> int ret;
> + bool fixed_base;
> + char *cmdline = boot_command_line;
>
> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> + /* crashkernel=X[@offset] */
> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> &crash_size, &crash_base);
> - /* no crashkernel= or invalid value specified */
> - if (ret || !crash_size)
> - return;
> + if (ret || !crash_size) {
> + unsigned long long low_size;
>
> + /* crashkernel=X,high */
> + ret = parse_crashkernel_high(cmdline, 0, &crash_size, &crash_base);
> + if (ret || !crash_size)
> + return;
> +
> + /* crashkernel=X,low */
> + ret = parse_crashkernel_low(cmdline, 0, &low_size, &crash_base);
> + if (!ret)
> + crash_low_size = low_size;
Here, the error case is not checked and handled. But it still gets
expeced result which is the default SZ_256M. Is this designed on
purpose?
> +
> + crash_max = CRASH_ADDR_HIGH_MAX;
> + }
> +
> + fixed_base = !!crash_base;
> crash_size = PAGE_ALIGN(crash_size);
>
> /* User specifies base address explicitly. */
> if (crash_base)
> crash_max = crash_base + crash_size;
>
> +retry:
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> crash_base, crash_max);
> if (!crash_base) {
> + /*
> + * Attempt to fully allocate low memory failed, fall back
> + * to high memory, the minimum required low memory will be
> + * reserved later.
> + */
> + if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
> + crash_max = CRASH_ADDR_HIGH_MAX;
> + goto retry;
> + }
> +
> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> crash_size);
> return;
> }
>
> + if (crash_base >= SZ_4G && reserve_crashkernel_low(crash_low_size)) {
> + memblock_phys_free(crash_base, crash_size);
> + return;
> + }
> +
> pr_info("crashkernel reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
> crash_base, crash_base + crash_size, crash_size >> 20);
>
> @@ -112,6 +169,9 @@ static void __init reserve_crashkernel(void)
> * map. Inform kmemleak so that it won't try to access it.
> */
> kmemleak_ignore_phys(crash_base);
> + if (crashk_low_res.end)
> + kmemleak_ignore_phys(crashk_low_res.start);
> +
> crashk_res.start = crash_base;
> crashk_res.end = crash_base + crash_size - 1;
> insert_resource(&iomem_resource, &crashk_res);
> --
> 2.25.1
>
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
kexec@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
Feng Zhou <zhoufeng.zf@bytedance.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Chen Zhou <dingguo.cz@antgroup.com>,
John Donnelly <John.p.donnelly@oracle.com>,
Dave Kleikamp <dave.kleikamp@oracle.com>
Subject: Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
Date: Fri, 11 Feb 2022 18:30:34 +0800 [thread overview]
Message-ID: <YgY6yvX7PEeZpdTr@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220124084708.683-4-thunder.leizhen@huawei.com>
On 01/24/22 at 04:47pm, Zhen Lei wrote:
> From: Chen Zhou <chenzhou10@huawei.com>
......
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 6c653a2c7cff052..a5d43feac0d7d96 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> + unsigned long long low_base;
> +
> + /* passed with crashkernel=0,low ? */
> + if (!low_size)
> + return 0;
> +
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0, CRASH_ADDR_LOW_MAX);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> + insert_resource(&iomem_resource, &crashk_low_res);
> +
> + return 0;
> +}
> +
> /*
> * reserve_crashkernel() - reserves memory for crash kernel
> *
> @@ -81,29 +105,62 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_base, crash_size;
> + unsigned long long crash_low_size = SZ_256M;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> int ret;
> + bool fixed_base;
> + char *cmdline = boot_command_line;
>
> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> + /* crashkernel=X[@offset] */
> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> &crash_size, &crash_base);
> - /* no crashkernel= or invalid value specified */
> - if (ret || !crash_size)
> - return;
> + if (ret || !crash_size) {
> + unsigned long long low_size;
>
> + /* crashkernel=X,high */
> + ret = parse_crashkernel_high(cmdline, 0, &crash_size, &crash_base);
> + if (ret || !crash_size)
> + return;
> +
> + /* crashkernel=X,low */
> + ret = parse_crashkernel_low(cmdline, 0, &low_size, &crash_base);
> + if (!ret)
> + crash_low_size = low_size;
Here, the error case is not checked and handled. But it still gets
expeced result which is the default SZ_256M. Is this designed on
purpose?
> +
> + crash_max = CRASH_ADDR_HIGH_MAX;
> + }
> +
> + fixed_base = !!crash_base;
> crash_size = PAGE_ALIGN(crash_size);
>
> /* User specifies base address explicitly. */
> if (crash_base)
> crash_max = crash_base + crash_size;
>
> +retry:
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> crash_base, crash_max);
> if (!crash_base) {
> + /*
> + * Attempt to fully allocate low memory failed, fall back
> + * to high memory, the minimum required low memory will be
> + * reserved later.
> + */
> + if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
> + crash_max = CRASH_ADDR_HIGH_MAX;
> + goto retry;
> + }
> +
> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> crash_size);
> return;
> }
>
> + if (crash_base >= SZ_4G && reserve_crashkernel_low(crash_low_size)) {
> + memblock_phys_free(crash_base, crash_size);
> + return;
> + }
> +
> pr_info("crashkernel reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
> crash_base, crash_base + crash_size, crash_size >> 20);
>
> @@ -112,6 +169,9 @@ static void __init reserve_crashkernel(void)
> * map. Inform kmemleak so that it won't try to access it.
> */
> kmemleak_ignore_phys(crash_base);
> + if (crashk_low_res.end)
> + kmemleak_ignore_phys(crashk_low_res.start);
> +
> crashk_res.start = crash_base;
> crashk_res.end = crash_base + crash_size - 1;
> insert_resource(&iomem_resource, &crashk_res);
> --
> 2.25.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-02-11 10:30 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 8:47 [PATCH v20 0/5] support reserving crashkernel above 4G on arm64 kdump Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` [PATCH v20 1/5] arm64: Use insert_resource() to simplify code Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-26 15:16 ` john.p.donnelly
2022-01-26 15:16 ` john.p.donnelly
2022-01-26 15:16 ` john.p.donnelly
2022-02-08 1:43 ` Baoquan He
2022-02-08 1:43 ` Baoquan He
2022-02-08 1:43 ` Baoquan He
2022-01-24 8:47 ` [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-26 15:17 ` john.p.donnelly
2022-01-26 15:17 ` john.p.donnelly
2022-01-26 15:17 ` john.p.donnelly
2022-02-11 10:39 ` Baoquan He
2022-02-11 10:39 ` Baoquan He
2022-02-11 10:39 ` Baoquan He
2022-02-14 6:22 ` Leizhen
2022-02-14 6:22 ` Leizhen (ThunderTown)
2022-02-14 6:22 ` Leizhen (ThunderTown)
2022-02-21 3:22 ` Baoquan He
2022-02-21 3:22 ` Baoquan He
2022-02-21 3:22 ` Baoquan He
2022-02-21 6:19 ` Leizhen
2022-02-21 6:19 ` Leizhen (ThunderTown)
2022-02-21 6:19 ` Leizhen (ThunderTown)
2022-01-24 8:47 ` [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-26 15:18 ` john.p.donnelly
2022-01-26 15:18 ` john.p.donnelly
2022-01-26 15:18 ` john.p.donnelly
2022-02-11 10:30 ` Baoquan He [this message]
2022-02-11 10:30 ` Baoquan He
2022-02-11 10:30 ` Baoquan He
2022-02-11 10:41 ` Leizhen
2022-02-11 10:41 ` Leizhen (ThunderTown)
2022-02-11 10:41 ` Leizhen (ThunderTown)
2022-02-11 10:51 ` Baoquan He
2022-02-11 10:51 ` Baoquan He
2022-02-11 10:51 ` Baoquan He
2022-02-14 6:44 ` Leizhen
2022-02-14 6:44 ` Leizhen (ThunderTown)
2022-02-14 6:44 ` Leizhen (ThunderTown)
2022-02-14 7:09 ` Baoquan He
2022-02-14 7:09 ` Baoquan He
2022-02-14 7:09 ` Baoquan He
2022-02-14 3:52 ` Baoquan He
2022-02-14 3:52 ` Baoquan He
2022-02-14 3:52 ` Baoquan He
2022-02-14 7:53 ` Leizhen
2022-02-14 7:53 ` Leizhen (ThunderTown)
2022-02-14 7:53 ` Leizhen (ThunderTown)
2022-02-16 2:58 ` Leizhen
2022-02-16 2:58 ` Leizhen (ThunderTown)
2022-02-16 2:58 ` Leizhen (ThunderTown)
2022-02-16 10:20 ` Baoquan He
2022-02-16 10:20 ` Baoquan He
2022-02-16 10:20 ` Baoquan He
2022-02-17 1:57 ` Leizhen
2022-02-17 1:57 ` Leizhen (ThunderTown)
2022-02-17 1:57 ` Leizhen (ThunderTown)
2022-01-24 8:47 ` [PATCH v20 4/5] of: fdt: Add memory for devices by DT property "linux, usable-memory-range" Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` [PATCH v20 4/5] of: fdt: Add memory for devices by DT property "linux,usable-memory-range" Zhen Lei
2022-01-26 15:19 ` john.p.donnelly
2022-01-26 15:19 ` john.p.donnelly
2022-01-26 15:19 ` john.p.donnelly
2022-01-24 8:47 ` [PATCH v20 5/5] kdump: update Documentation about crashkernel Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-24 8:47 ` Zhen Lei
2022-01-26 15:19 ` john.p.donnelly
2022-01-26 15:19 ` john.p.donnelly
2022-01-26 15:19 ` john.p.donnelly
2022-02-21 3:48 ` Baoquan He
2022-02-21 3:48 ` Baoquan He
2022-02-21 3:48 ` Baoquan He
2022-02-21 6:38 ` Leizhen
2022-02-21 6:38 ` Leizhen (ThunderTown)
2022-02-21 6:38 ` Leizhen (ThunderTown)
2022-02-07 4:04 ` [PATCH v20 0/5] support reserving crashkernel above 4G on arm64 kdump Leizhen
2022-02-07 4:04 ` Leizhen (ThunderTown)
2022-02-07 4:04 ` Leizhen (ThunderTown)
2022-02-08 2:34 ` Baoquan He
2022-02-08 2:34 ` Baoquan He
2022-02-08 2:34 ` Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YgY6yvX7PEeZpdTr@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=kexec@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.