From: Baoquan He <bhe@redhat.com>
To: "chenjiahao (C)" <chenjiahao16@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kexec@lists.infradead.org, linux-doc@vger.kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
conor.dooley@microchip.com, guoren@kernel.org, heiko@sntech.de,
bjorn@rivosinc.com, alex@ghiti.fr, akpm@linux-foundation.org,
atishp@rivosinc.com, thunder.leizhen@huawei.com,
horms@kernel.org
Subject: Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
Date: Tue, 4 Jul 2023 16:11:44 +0800 [thread overview]
Message-ID: <ZKPUQFMoDQFrFr2d@MiWiFi-R3L-srv> (raw)
In-Reply-To: <6f4c80ba-ec61-2ce8-3034-08162f0ee9fd@huawei.com>
On 07/04/23 at 10:18am, chenjiahao (C) wrote:
>
> On 2023/7/2 12:12, Baoquan He wrote:
> > On 07/01/23 at 05:11pm, Chen Jiahao wrote:
> > > On riscv, the current crash kernel allocation logic is trying to
> > > allocate within 32bit addressible memory region by default, if
> > > failed, try to allocate without 4G restriction.
> > >
> > > In need of saving DMA zone memory while allocating a relatively large
> > > crash kernel region, allocating the reserved memory top down in
> > > high memory, without overlapping the DMA zone, is a mature solution.
> > > Here introduce the parameter option crashkernel=X,[high,low].
> > >
> > > One can reserve the crash kernel from high memory above DMA zone range
> > > by explicitly passing "crashkernel=X,high"; or reserve a memory range
> > > below 4G with "crashkernel=X,low".
> > >
> > > Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
> > > Acked-by: Guo Ren <guoren@kernel.org>
> > > ---
> > > arch/riscv/kernel/setup.c | 5 +++
> > > arch/riscv/mm/init.c | 84 +++++++++++++++++++++++++++++++++++----
> > > 2 files changed, 82 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > > index 971fe776e2f8..376f5d49ce85 100644
> > > --- a/arch/riscv/kernel/setup.c
> > > +++ b/arch/riscv/kernel/setup.c
> > > @@ -178,6 +178,11 @@ static void __init init_resources(void)
> > > if (ret < 0)
> > > goto error;
> > > }
> > > + if (crashk_low_res.start != crashk_low_res.end) {
> > > + ret = add_resource(&iomem_resource, &crashk_low_res);
> > > + if (ret < 0)
> > > + goto error;
> > > + }
> > > #endif
> > > #ifdef CONFIG_CRASH_DUMP
> > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > index 4b95d8999120..eeb31c2cc843 100644
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@ -1298,6 +1298,28 @@ static inline void setup_vm_final(void)
> > > }
> > > #endif /* CONFIG_MMU */
> > > +/* Reserve 128M low memory by default for swiotlb buffer */
> > > +#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> > > +
> > > +static int __init reserve_crashkernel_low(unsigned long long low_size)
> > > +{
> > > + unsigned long long low_base;
> > > +
> > > + low_base = memblock_phys_alloc_range(low_size, PMD_SIZE, 0, dma32_phys_limit);
> > > + 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%016llx - 0x%016llx (%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;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /*
> > > * reserve_crashkernel() - reserves memory for crash kernel
> > > *
> > > @@ -1309,8 +1331,12 @@ static void __init reserve_crashkernel(void)
> > > {
> > > unsigned long long crash_base = 0;
> > > unsigned long long crash_size = 0;
> > > + unsigned long long crash_low_size = 0;
> > > unsigned long search_start = memblock_start_of_DRAM();
> > > - unsigned long search_end = memblock_end_of_DRAM();
> > > + unsigned long search_end = (unsigned long)dma32_phys_limit;
> > > + char *cmdline = boot_command_line;
> > > + bool fixed_base = false;
> > > + bool high = false;
> > > int ret = 0;
> > > @@ -1326,14 +1352,36 @@ static void __init reserve_crashkernel(void)
> > > return;
> > > }
> > > - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> > > + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> > > &crash_size, &crash_base);
> > > - if (ret || !crash_size)
> > > + if (ret == -ENOENT) {
> > > + /* Fallback to crashkernel=X,[high,low] */
> > > + ret = parse_crashkernel_high(cmdline, 0, &crash_size, &crash_base);
> > > + if (ret || !crash_size)
> > > + return;
> > > +
> > > + /*
> > > + * crashkernel=Y,low is valid only when crashkernel=X,high
> > > + * is passed.
> > > + */
> > > + ret = parse_crashkernel_low(cmdline, 0, &crash_low_size, &crash_base);
> > > + if (ret == -ENOENT)
> > > + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > > + else if (ret)
> > > + return;
> > > +
> > > + search_start = (unsigned long)dma32_phys_limit;
> > > + search_end = memblock_end_of_DRAM();
> > > + high = true;
> > > + } else if (ret || !crash_size) {
> > > + /* Invalid argument value specified */
> > > return;
> > > + }
> > > crash_size = PAGE_ALIGN(crash_size);
> > > if (crash_base) {
> > > + fixed_base = true;
> > > search_start = crash_base;
> > > search_end = crash_base + crash_size;
> > > }
> > > @@ -1346,17 +1394,39 @@ static void __init reserve_crashkernel(void)
> > > * swiotlb can work on the crash kernel.
> > > */
> > > crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> > > - search_start,
> > > - min(search_end, (unsigned long) SZ_4G));
> > > + search_start, search_end);
> > > if (crash_base == 0) {
> > > - /* Try again without restricting region to 32bit addressible memory */
> > > + if (fixed_base) {
> > > + pr_warn("crashkernel: allocating failed with given size@offset\n");
> > > + return;
> > > + }
> > > +
> > > + if (high) {
> > > + /* Fall back to lower 32G reservation */
> > > + search_start = memblock_start_of_DRAM();
> > > + search_end = (unsigned long)dma32_phys_limit;
> > > + } else {
> > > + /* Try again above the region of 32bit addressible memory */
> > > + search_start = (unsigned long)dma32_phys_limit;
> > > + search_end = memblock_end_of_DRAM();
> > > + }
> > > +
> > > crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> > > - search_start, search_end);
> > > + search_start, search_end);
> > > if (crash_base == 0) {
> > > pr_warn("crashkernel: couldn't allocate %lldKB\n",
> > > crash_size >> 10);
> > > return;
> > > }
> > > +
> > > + if (!crash_low_size)
> > > + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > How do you differentiate the case user specifies crashkernel=0M,low
> > explicitly with the case that user doesn't specify crashkernel=,low, but
> > only specify crsahkernel=xM,high? I saw you don't have the test case
> > crashkernel=xM,high crashkernel=0M,low listed in your cover letter.
>
> Yes, here is indeed a point not exactly aligned with Arm64 code.
> But testcases below seem to have the same result with Arm64:
>
> crashkernel=512M,high //high=512M, low=128M (default)
> crashkernel=512M,high crashkernel=0M,low //high=512M, low=0M
> crashkernel=512M,high crashkernel=256M,low //high=512M, low=256M
>
>
> When the first allocation succeed, it will not fallback into
> the if (crash_base == 0) case, the allocation result is the same
> as Arm64, both for explicitly given "crashkernel=0M,low" or not.
>
> The problem you mentioned might occurs when the first allocation
> failed.
>
> My logic here is when crashkernel=xM,high is specified, no matter
> crashkernel=0M,low is explicitly given or not, "high" flag is set.
> It will fallback to lower 4G allocation, additional lower 4G region
> with "crash_low_size" will never get reserved.
Ah, you are right. I was mistaken. crashkernel=xM,high crashkernel=0,low
works correctly with your v6 patch. I am fine if you want to take a
different code flow to implement, as long as the actual result is the
same. I personally would make the code logic the same as arm64. So this
patches looks good to me.
>
> So the results between Arm64 and riscv when crashkernel=,low is
> specified or not are the same. Is there any problem with my logic,
> or have I misunderstood your comment above?
>
> >
> > > + }
> > > +
> > > + if ((crash_base >= dma32_phys_limit) && crash_low_size &&
> > > + reserve_crashkernel_low(crash_low_size)) {
>
> Here, additional lower memory region will not reserve when
> crashkernel=xM,high is given
>
> > > + memblock_phys_free(crash_base, crash_size);
> > > + return;
> > > }
> > > pr_info("crashkernel: reserved 0x%016llx - 0x%016llx (%lld MB)\n",
> > > --
> > > 2.34.1
> > >
> Thanks,
>
> Jiahao
>
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: "chenjiahao (C)" <chenjiahao16@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kexec@lists.infradead.org, linux-doc@vger.kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
conor.dooley@microchip.com, guoren@kernel.org, heiko@sntech.de,
bjorn@rivosinc.com, alex@ghiti.fr, akpm@linux-foundation.org,
atishp@rivosinc.com, thunder.leizhen@huawei.com,
horms@kernel.org
Subject: Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
Date: Tue, 4 Jul 2023 16:11:44 +0800 [thread overview]
Message-ID: <ZKPUQFMoDQFrFr2d@MiWiFi-R3L-srv> (raw)
In-Reply-To: <6f4c80ba-ec61-2ce8-3034-08162f0ee9fd@huawei.com>
On 07/04/23 at 10:18am, chenjiahao (C) wrote:
>
> On 2023/7/2 12:12, Baoquan He wrote:
> > On 07/01/23 at 05:11pm, Chen Jiahao wrote:
> > > On riscv, the current crash kernel allocation logic is trying to
> > > allocate within 32bit addressible memory region by default, if
> > > failed, try to allocate without 4G restriction.
> > >
> > > In need of saving DMA zone memory while allocating a relatively large
> > > crash kernel region, allocating the reserved memory top down in
> > > high memory, without overlapping the DMA zone, is a mature solution.
> > > Here introduce the parameter option crashkernel=X,[high,low].
> > >
> > > One can reserve the crash kernel from high memory above DMA zone range
> > > by explicitly passing "crashkernel=X,high"; or reserve a memory range
> > > below 4G with "crashkernel=X,low".
> > >
> > > Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
> > > Acked-by: Guo Ren <guoren@kernel.org>
> > > ---
> > > arch/riscv/kernel/setup.c | 5 +++
> > > arch/riscv/mm/init.c | 84 +++++++++++++++++++++++++++++++++++----
> > > 2 files changed, 82 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > > index 971fe776e2f8..376f5d49ce85 100644
> > > --- a/arch/riscv/kernel/setup.c
> > > +++ b/arch/riscv/kernel/setup.c
> > > @@ -178,6 +178,11 @@ static void __init init_resources(void)
> > > if (ret < 0)
> > > goto error;
> > > }
> > > + if (crashk_low_res.start != crashk_low_res.end) {
> > > + ret = add_resource(&iomem_resource, &crashk_low_res);
> > > + if (ret < 0)
> > > + goto error;
> > > + }
> > > #endif
> > > #ifdef CONFIG_CRASH_DUMP
> > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > index 4b95d8999120..eeb31c2cc843 100644
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@ -1298,6 +1298,28 @@ static inline void setup_vm_final(void)
> > > }
> > > #endif /* CONFIG_MMU */
> > > +/* Reserve 128M low memory by default for swiotlb buffer */
> > > +#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> > > +
> > > +static int __init reserve_crashkernel_low(unsigned long long low_size)
> > > +{
> > > + unsigned long long low_base;
> > > +
> > > + low_base = memblock_phys_alloc_range(low_size, PMD_SIZE, 0, dma32_phys_limit);
> > > + 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%016llx - 0x%016llx (%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;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /*
> > > * reserve_crashkernel() - reserves memory for crash kernel
> > > *
> > > @@ -1309,8 +1331,12 @@ static void __init reserve_crashkernel(void)
> > > {
> > > unsigned long long crash_base = 0;
> > > unsigned long long crash_size = 0;
> > > + unsigned long long crash_low_size = 0;
> > > unsigned long search_start = memblock_start_of_DRAM();
> > > - unsigned long search_end = memblock_end_of_DRAM();
> > > + unsigned long search_end = (unsigned long)dma32_phys_limit;
> > > + char *cmdline = boot_command_line;
> > > + bool fixed_base = false;
> > > + bool high = false;
> > > int ret = 0;
> > > @@ -1326,14 +1352,36 @@ static void __init reserve_crashkernel(void)
> > > return;
> > > }
> > > - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> > > + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> > > &crash_size, &crash_base);
> > > - if (ret || !crash_size)
> > > + if (ret == -ENOENT) {
> > > + /* Fallback to crashkernel=X,[high,low] */
> > > + ret = parse_crashkernel_high(cmdline, 0, &crash_size, &crash_base);
> > > + if (ret || !crash_size)
> > > + return;
> > > +
> > > + /*
> > > + * crashkernel=Y,low is valid only when crashkernel=X,high
> > > + * is passed.
> > > + */
> > > + ret = parse_crashkernel_low(cmdline, 0, &crash_low_size, &crash_base);
> > > + if (ret == -ENOENT)
> > > + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > > + else if (ret)
> > > + return;
> > > +
> > > + search_start = (unsigned long)dma32_phys_limit;
> > > + search_end = memblock_end_of_DRAM();
> > > + high = true;
> > > + } else if (ret || !crash_size) {
> > > + /* Invalid argument value specified */
> > > return;
> > > + }
> > > crash_size = PAGE_ALIGN(crash_size);
> > > if (crash_base) {
> > > + fixed_base = true;
> > > search_start = crash_base;
> > > search_end = crash_base + crash_size;
> > > }
> > > @@ -1346,17 +1394,39 @@ static void __init reserve_crashkernel(void)
> > > * swiotlb can work on the crash kernel.
> > > */
> > > crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> > > - search_start,
> > > - min(search_end, (unsigned long) SZ_4G));
> > > + search_start, search_end);
> > > if (crash_base == 0) {
> > > - /* Try again without restricting region to 32bit addressible memory */
> > > + if (fixed_base) {
> > > + pr_warn("crashkernel: allocating failed with given size@offset\n");
> > > + return;
> > > + }
> > > +
> > > + if (high) {
> > > + /* Fall back to lower 32G reservation */
> > > + search_start = memblock_start_of_DRAM();
> > > + search_end = (unsigned long)dma32_phys_limit;
> > > + } else {
> > > + /* Try again above the region of 32bit addressible memory */
> > > + search_start = (unsigned long)dma32_phys_limit;
> > > + search_end = memblock_end_of_DRAM();
> > > + }
> > > +
> > > crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> > > - search_start, search_end);
> > > + search_start, search_end);
> > > if (crash_base == 0) {
> > > pr_warn("crashkernel: couldn't allocate %lldKB\n",
> > > crash_size >> 10);
> > > return;
> > > }
> > > +
> > > + if (!crash_low_size)
> > > + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > How do you differentiate the case user specifies crashkernel=0M,low
> > explicitly with the case that user doesn't specify crashkernel=,low, but
> > only specify crsahkernel=xM,high? I saw you don't have the test case
> > crashkernel=xM,high crashkernel=0M,low listed in your cover letter.
>
> Yes, here is indeed a point not exactly aligned with Arm64 code.
> But testcases below seem to have the same result with Arm64:
>
> crashkernel=512M,high //high=512M, low=128M (default)
> crashkernel=512M,high crashkernel=0M,low //high=512M, low=0M
> crashkernel=512M,high crashkernel=256M,low //high=512M, low=256M
>
>
> When the first allocation succeed, it will not fallback into
> the if (crash_base == 0) case, the allocation result is the same
> as Arm64, both for explicitly given "crashkernel=0M,low" or not.
>
> The problem you mentioned might occurs when the first allocation
> failed.
>
> My logic here is when crashkernel=xM,high is specified, no matter
> crashkernel=0M,low is explicitly given or not, "high" flag is set.
> It will fallback to lower 4G allocation, additional lower 4G region
> with "crash_low_size" will never get reserved.
Ah, you are right. I was mistaken. crashkernel=xM,high crashkernel=0,low
works correctly with your v6 patch. I am fine if you want to take a
different code flow to implement, as long as the actual result is the
same. I personally would make the code logic the same as arm64. So this
patches looks good to me.
>
> So the results between Arm64 and riscv when crashkernel=,low is
> specified or not are the same. Is there any problem with my logic,
> or have I misunderstood your comment above?
>
> >
> > > + }
> > > +
> > > + if ((crash_base >= dma32_phys_limit) && crash_low_size &&
> > > + reserve_crashkernel_low(crash_low_size)) {
>
> Here, additional lower memory region will not reserve when
> crashkernel=xM,high is given
>
> > > + memblock_phys_free(crash_base, crash_size);
> > > + return;
> > > }
> > > pr_info("crashkernel: reserved 0x%016llx - 0x%016llx (%lld MB)\n",
> > > --
> > > 2.34.1
> > >
> Thanks,
>
> Jiahao
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: "chenjiahao (C)" <chenjiahao16@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kexec@lists.infradead.org, linux-doc@vger.kernel.org,
paul.walmsley@sifive.com, palmer@dabbelt.com,
conor.dooley@microchip.com, guoren@kernel.org, heiko@sntech.de,
bjorn@rivosinc.com, alex@ghiti.fr, akpm@linux-foundation.org,
atishp@rivosinc.com, thunder.leizhen@huawei.com,
horms@kernel.org
Subject: Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
Date: Tue, 4 Jul 2023 16:11:44 +0800 [thread overview]
Message-ID: <ZKPUQFMoDQFrFr2d@MiWiFi-R3L-srv> (raw)
In-Reply-To: <6f4c80ba-ec61-2ce8-3034-08162f0ee9fd@huawei.com>
On 07/04/23 at 10:18am, chenjiahao (C) wrote:
>
> On 2023/7/2 12:12, Baoquan He wrote:
> > On 07/01/23 at 05:11pm, Chen Jiahao wrote:
> > > On riscv, the current crash kernel allocation logic is trying to
> > > allocate within 32bit addressible memory region by default, if
> > > failed, try to allocate without 4G restriction.
> > >
> > > In need of saving DMA zone memory while allocating a relatively large
> > > crash kernel region, allocating the reserved memory top down in
> > > high memory, without overlapping the DMA zone, is a mature solution.
> > > Here introduce the parameter option crashkernel=X,[high,low].
> > >
> > > One can reserve the crash kernel from high memory above DMA zone range
> > > by explicitly passing "crashkernel=X,high"; or reserve a memory range
> > > below 4G with "crashkernel=X,low".
> > >
> > > Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
> > > Acked-by: Guo Ren <guoren@kernel.org>
> > > ---
> > > arch/riscv/kernel/setup.c | 5 +++
> > > arch/riscv/mm/init.c | 84 +++++++++++++++++++++++++++++++++++----
> > > 2 files changed, 82 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > > index 971fe776e2f8..376f5d49ce85 100644
> > > --- a/arch/riscv/kernel/setup.c
> > > +++ b/arch/riscv/kernel/setup.c
> > > @@ -178,6 +178,11 @@ static void __init init_resources(void)
> > > if (ret < 0)
> > > goto error;
> > > }
> > > + if (crashk_low_res.start != crashk_low_res.end) {
> > > + ret = add_resource(&iomem_resource, &crashk_low_res);
> > > + if (ret < 0)
> > > + goto error;
> > > + }
> > > #endif
> > > #ifdef CONFIG_CRASH_DUMP
> > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > index 4b95d8999120..eeb31c2cc843 100644
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@ -1298,6 +1298,28 @@ static inline void setup_vm_final(void)
> > > }
> > > #endif /* CONFIG_MMU */
> > > +/* Reserve 128M low memory by default for swiotlb buffer */
> > > +#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> > > +
> > > +static int __init reserve_crashkernel_low(unsigned long long low_size)
> > > +{
> > > + unsigned long long low_base;
> > > +
> > > + low_base = memblock_phys_alloc_range(low_size, PMD_SIZE, 0, dma32_phys_limit);
> > > + 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%016llx - 0x%016llx (%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;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /*
> > > * reserve_crashkernel() - reserves memory for crash kernel
> > > *
> > > @@ -1309,8 +1331,12 @@ static void __init reserve_crashkernel(void)
> > > {
> > > unsigned long long crash_base = 0;
> > > unsigned long long crash_size = 0;
> > > + unsigned long long crash_low_size = 0;
> > > unsigned long search_start = memblock_start_of_DRAM();
> > > - unsigned long search_end = memblock_end_of_DRAM();
> > > + unsigned long search_end = (unsigned long)dma32_phys_limit;
> > > + char *cmdline = boot_command_line;
> > > + bool fixed_base = false;
> > > + bool high = false;
> > > int ret = 0;
> > > @@ -1326,14 +1352,36 @@ static void __init reserve_crashkernel(void)
> > > return;
> > > }
> > > - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> > > + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> > > &crash_size, &crash_base);
> > > - if (ret || !crash_size)
> > > + if (ret == -ENOENT) {
> > > + /* Fallback to crashkernel=X,[high,low] */
> > > + ret = parse_crashkernel_high(cmdline, 0, &crash_size, &crash_base);
> > > + if (ret || !crash_size)
> > > + return;
> > > +
> > > + /*
> > > + * crashkernel=Y,low is valid only when crashkernel=X,high
> > > + * is passed.
> > > + */
> > > + ret = parse_crashkernel_low(cmdline, 0, &crash_low_size, &crash_base);
> > > + if (ret == -ENOENT)
> > > + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > > + else if (ret)
> > > + return;
> > > +
> > > + search_start = (unsigned long)dma32_phys_limit;
> > > + search_end = memblock_end_of_DRAM();
> > > + high = true;
> > > + } else if (ret || !crash_size) {
> > > + /* Invalid argument value specified */
> > > return;
> > > + }
> > > crash_size = PAGE_ALIGN(crash_size);
> > > if (crash_base) {
> > > + fixed_base = true;
> > > search_start = crash_base;
> > > search_end = crash_base + crash_size;
> > > }
> > > @@ -1346,17 +1394,39 @@ static void __init reserve_crashkernel(void)
> > > * swiotlb can work on the crash kernel.
> > > */
> > > crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> > > - search_start,
> > > - min(search_end, (unsigned long) SZ_4G));
> > > + search_start, search_end);
> > > if (crash_base == 0) {
> > > - /* Try again without restricting region to 32bit addressible memory */
> > > + if (fixed_base) {
> > > + pr_warn("crashkernel: allocating failed with given size@offset\n");
> > > + return;
> > > + }
> > > +
> > > + if (high) {
> > > + /* Fall back to lower 32G reservation */
> > > + search_start = memblock_start_of_DRAM();
> > > + search_end = (unsigned long)dma32_phys_limit;
> > > + } else {
> > > + /* Try again above the region of 32bit addressible memory */
> > > + search_start = (unsigned long)dma32_phys_limit;
> > > + search_end = memblock_end_of_DRAM();
> > > + }
> > > +
> > > crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> > > - search_start, search_end);
> > > + search_start, search_end);
> > > if (crash_base == 0) {
> > > pr_warn("crashkernel: couldn't allocate %lldKB\n",
> > > crash_size >> 10);
> > > return;
> > > }
> > > +
> > > + if (!crash_low_size)
> > > + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> > How do you differentiate the case user specifies crashkernel=0M,low
> > explicitly with the case that user doesn't specify crashkernel=,low, but
> > only specify crsahkernel=xM,high? I saw you don't have the test case
> > crashkernel=xM,high crashkernel=0M,low listed in your cover letter.
>
> Yes, here is indeed a point not exactly aligned with Arm64 code.
> But testcases below seem to have the same result with Arm64:
>
> crashkernel=512M,high //high=512M, low=128M (default)
> crashkernel=512M,high crashkernel=0M,low //high=512M, low=0M
> crashkernel=512M,high crashkernel=256M,low //high=512M, low=256M
>
>
> When the first allocation succeed, it will not fallback into
> the if (crash_base == 0) case, the allocation result is the same
> as Arm64, both for explicitly given "crashkernel=0M,low" or not.
>
> The problem you mentioned might occurs when the first allocation
> failed.
>
> My logic here is when crashkernel=xM,high is specified, no matter
> crashkernel=0M,low is explicitly given or not, "high" flag is set.
> It will fallback to lower 4G allocation, additional lower 4G region
> with "crash_low_size" will never get reserved.
Ah, you are right. I was mistaken. crashkernel=xM,high crashkernel=0,low
works correctly with your v6 patch. I am fine if you want to take a
different code flow to implement, as long as the actual result is the
same. I personally would make the code logic the same as arm64. So this
patches looks good to me.
>
> So the results between Arm64 and riscv when crashkernel=,low is
> specified or not are the same. Is there any problem with my logic,
> or have I misunderstood your comment above?
>
> >
> > > + }
> > > +
> > > + if ((crash_base >= dma32_phys_limit) && crash_low_size &&
> > > + reserve_crashkernel_low(crash_low_size)) {
>
> Here, additional lower memory region will not reserve when
> crashkernel=xM,high is given
>
> > > + memblock_phys_free(crash_base, crash_size);
> > > + return;
> > > }
> > > pr_info("crashkernel: reserved 0x%016llx - 0x%016llx (%lld MB)\n",
> > > --
> > > 2.34.1
> > >
> Thanks,
>
> Jiahao
>
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-07-04 8:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-01 17:11 [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv Chen Jiahao
2023-07-01 17:11 ` Chen Jiahao
2023-07-01 17:11 ` Chen Jiahao
2023-07-01 13:45 ` Guo Ren
2023-07-01 13:45 ` Guo Ren
2023-07-01 13:45 ` Guo Ren
2023-07-03 13:07 ` chenjiahao (C)
2023-07-03 13:07 ` chenjiahao (C)
2023-07-03 13:07 ` chenjiahao (C)
2023-07-04 2:39 ` Guo Ren
2023-07-04 2:39 ` Guo Ren
2023-07-04 2:39 ` Guo Ren
2023-07-01 17:11 ` [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low] Chen Jiahao
2023-07-01 17:11 ` Chen Jiahao
2023-07-01 17:11 ` Chen Jiahao
2023-07-02 4:12 ` Baoquan He
2023-07-02 4:12 ` Baoquan He
2023-07-02 4:12 ` Baoquan He
2023-07-04 2:18 ` chenjiahao (C)
2023-07-04 2:18 ` chenjiahao (C)
2023-07-04 2:18 ` chenjiahao (C)
2023-07-04 8:11 ` Baoquan He [this message]
2023-07-04 8:11 ` Baoquan He
2023-07-04 8:11 ` Baoquan He
2023-07-01 17:11 ` [PATCH -next v6 2/2] docs: kdump: Update the crashkernel description for riscv Chen Jiahao
2023-07-01 17:11 ` Chen Jiahao
2023-07-01 17:11 ` Chen Jiahao
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=ZKPUQFMoDQFrFr2d@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=atishp@rivosinc.com \
--cc=bjorn@rivosinc.com \
--cc=chenjiahao16@huawei.com \
--cc=conor.dooley@microchip.com \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=horms@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=thunder.leizhen@huawei.com \
/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.