All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
  2023-07-01 17:11 ` Chen Jiahao
  (?)
@ 2023-07-01 13:45   ` Guo Ren
  -1 siblings, 0 replies; 27+ messages in thread
From: Guo Ren @ 2023-07-01 13:45 UTC (permalink / raw)
  To: Chen Jiahao
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms

On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
> Hence this patchset introduces 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". Besides, there are few rules need
> to take notice:
> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
>    is specified.
> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
>    and there is enough memory to be allocated under 4G.
> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
>    specified, a 128M low memory will be allocated automatically for
>    swiotlb bounce buffer.
> See Documentation/admin-guide/kernel-parameters.txt for more information.
>
> To verify loading the crashkernel, adapted kexec-tools is attached below:
> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>
> Following test cases have been performed as expected:
> 1) crashkernel=256M                          //low=256M
> 2) crashkernel=1G                            //low=1G
Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/

> 3) crashkernel=4G                            //high=4G, low=128M(default)
> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
> 7) crashkernel=256M,low                      //low=0M, invalid
> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
> 10) crashkernel=512M@0xd0000000              //low=512M
>
> Changes since [v6]:
> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
>    is passed. Fix the retrying logic between "crashkernel=X,high"
>    case and others when the first allocation attempt fails.
>
> Changes since [v5]:
> 1. Update the crashkernel allocation logic when crashkernel=X,high
>    is specified. In this case, region above 4G will directly get
>    reserved as crashkernel, rather than trying lower 32bit allocation
>    first.
>
> Changes since [v4]:
> 1. Update some imprecise code comments for cmdline parsing.
>
> Changes since [v3]:
> 1. Update to print warning and return explicitly on failure when
>    crashkernel=size@offset is specified. Not changing the result
>    in this case but making the logic more straightforward.
> 2. Some minor cleanup.
>
> Changes since [v2]:
> 1. Update the allocation logic to ensure the high crashkernel
>    region is reserved strictly above dma32_phys_limit.
> 2. Clean up some minor format problems.
>
> Chen Jiahao (2):
>   riscv: kdump: Implement crashkernel=X,[high,low]
>   docs: kdump: Update the crashkernel description for riscv
>
>  .../admin-guide/kernel-parameters.txt         | 15 ++--
>  arch/riscv/kernel/setup.c                     |  5 ++
>  arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
>  3 files changed, 90 insertions(+), 14 deletions(-)
>
> --
> 2.34.1
>


-- 
Best Regards
 Guo Ren

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-01 13:45   ` Guo Ren
  0 siblings, 0 replies; 27+ messages in thread
From: Guo Ren @ 2023-07-01 13:45 UTC (permalink / raw)
  To: Chen Jiahao
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms

On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
> Hence this patchset introduces 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". Besides, there are few rules need
> to take notice:
> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
>    is specified.
> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
>    and there is enough memory to be allocated under 4G.
> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
>    specified, a 128M low memory will be allocated automatically for
>    swiotlb bounce buffer.
> See Documentation/admin-guide/kernel-parameters.txt for more information.
>
> To verify loading the crashkernel, adapted kexec-tools is attached below:
> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>
> Following test cases have been performed as expected:
> 1) crashkernel=256M                          //low=256M
> 2) crashkernel=1G                            //low=1G
Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/

> 3) crashkernel=4G                            //high=4G, low=128M(default)
> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
> 7) crashkernel=256M,low                      //low=0M, invalid
> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
> 10) crashkernel=512M@0xd0000000              //low=512M
>
> Changes since [v6]:
> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
>    is passed. Fix the retrying logic between "crashkernel=X,high"
>    case and others when the first allocation attempt fails.
>
> Changes since [v5]:
> 1. Update the crashkernel allocation logic when crashkernel=X,high
>    is specified. In this case, region above 4G will directly get
>    reserved as crashkernel, rather than trying lower 32bit allocation
>    first.
>
> Changes since [v4]:
> 1. Update some imprecise code comments for cmdline parsing.
>
> Changes since [v3]:
> 1. Update to print warning and return explicitly on failure when
>    crashkernel=size@offset is specified. Not changing the result
>    in this case but making the logic more straightforward.
> 2. Some minor cleanup.
>
> Changes since [v2]:
> 1. Update the allocation logic to ensure the high crashkernel
>    region is reserved strictly above dma32_phys_limit.
> 2. Clean up some minor format problems.
>
> Chen Jiahao (2):
>   riscv: kdump: Implement crashkernel=X,[high,low]
>   docs: kdump: Update the crashkernel description for riscv
>
>  .../admin-guide/kernel-parameters.txt         | 15 ++--
>  arch/riscv/kernel/setup.c                     |  5 ++
>  arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
>  3 files changed, 90 insertions(+), 14 deletions(-)
>
> --
> 2.34.1
>


-- 
Best Regards
 Guo Ren

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-01 13:45   ` Guo Ren
  0 siblings, 0 replies; 27+ messages in thread
From: Guo Ren @ 2023-07-01 13:45 UTC (permalink / raw)
  To: Chen Jiahao
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms

On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
> Hence this patchset introduces 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". Besides, there are few rules need
> to take notice:
> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
>    is specified.
> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
>    and there is enough memory to be allocated under 4G.
> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
>    specified, a 128M low memory will be allocated automatically for
>    swiotlb bounce buffer.
> See Documentation/admin-guide/kernel-parameters.txt for more information.
>
> To verify loading the crashkernel, adapted kexec-tools is attached below:
> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>
> Following test cases have been performed as expected:
> 1) crashkernel=256M                          //low=256M
> 2) crashkernel=1G                            //low=1G
Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/

> 3) crashkernel=4G                            //high=4G, low=128M(default)
> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
> 7) crashkernel=256M,low                      //low=0M, invalid
> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
> 10) crashkernel=512M@0xd0000000              //low=512M
>
> Changes since [v6]:
> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
>    is passed. Fix the retrying logic between "crashkernel=X,high"
>    case and others when the first allocation attempt fails.
>
> Changes since [v5]:
> 1. Update the crashkernel allocation logic when crashkernel=X,high
>    is specified. In this case, region above 4G will directly get
>    reserved as crashkernel, rather than trying lower 32bit allocation
>    first.
>
> Changes since [v4]:
> 1. Update some imprecise code comments for cmdline parsing.
>
> Changes since [v3]:
> 1. Update to print warning and return explicitly on failure when
>    crashkernel=size@offset is specified. Not changing the result
>    in this case but making the logic more straightforward.
> 2. Some minor cleanup.
>
> Changes since [v2]:
> 1. Update the allocation logic to ensure the high crashkernel
>    region is reserved strictly above dma32_phys_limit.
> 2. Clean up some minor format problems.
>
> Chen Jiahao (2):
>   riscv: kdump: Implement crashkernel=X,[high,low]
>   docs: kdump: Update the crashkernel description for riscv
>
>  .../admin-guide/kernel-parameters.txt         | 15 ++--
>  arch/riscv/kernel/setup.c                     |  5 ++
>  arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
>  3 files changed, 90 insertions(+), 14 deletions(-)
>
> --
> 2.34.1
>


-- 
Best Regards
 Guo Ren

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-01 17:11 ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

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.
Hence this patchset introduces 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". Besides, there are few rules need
to take notice:
1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
   is specified.
2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
   and there is enough memory to be allocated under 4G.
3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
   specified, a 128M low memory will be allocated automatically for
   swiotlb bounce buffer.
See Documentation/admin-guide/kernel-parameters.txt for more information.

To verify loading the crashkernel, adapted kexec-tools is attached below:
https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2

Following test cases have been performed as expected:
1) crashkernel=256M                          //low=256M
2) crashkernel=1G                            //low=1G
3) crashkernel=4G                            //high=4G, low=128M(default)
4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
6) crashkernel=4G,high                       //high=4G, low=128M(default)
7) crashkernel=256M,low                      //low=0M, invalid
8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
10) crashkernel=512M@0xd0000000              //low=512M

Changes since [v6]:
1. Introduce the "high" flag to mark whether "crashkernel=X,high"
   is passed. Fix the retrying logic between "crashkernel=X,high"
   case and others when the first allocation attempt fails.

Changes since [v5]:
1. Update the crashkernel allocation logic when crashkernel=X,high
   is specified. In this case, region above 4G will directly get
   reserved as crashkernel, rather than trying lower 32bit allocation
   first.

Changes since [v4]:
1. Update some imprecise code comments for cmdline parsing.

Changes since [v3]:
1. Update to print warning and return explicitly on failure when
   crashkernel=size@offset is specified. Not changing the result
   in this case but making the logic more straightforward.
2. Some minor cleanup.

Changes since [v2]:
1. Update the allocation logic to ensure the high crashkernel
   region is reserved strictly above dma32_phys_limit.
2. Clean up some minor format problems.

Chen Jiahao (2):
  riscv: kdump: Implement crashkernel=X,[high,low]
  docs: kdump: Update the crashkernel description for riscv

 .../admin-guide/kernel-parameters.txt         | 15 ++--
 arch/riscv/kernel/setup.c                     |  5 ++
 arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
 3 files changed, 90 insertions(+), 14 deletions(-)

-- 
2.34.1


^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-01 17:11 ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

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.
Hence this patchset introduces 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". Besides, there are few rules need
to take notice:
1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
   is specified.
2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
   and there is enough memory to be allocated under 4G.
3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
   specified, a 128M low memory will be allocated automatically for
   swiotlb bounce buffer.
See Documentation/admin-guide/kernel-parameters.txt for more information.

To verify loading the crashkernel, adapted kexec-tools is attached below:
https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2

Following test cases have been performed as expected:
1) crashkernel=256M                          //low=256M
2) crashkernel=1G                            //low=1G
3) crashkernel=4G                            //high=4G, low=128M(default)
4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
6) crashkernel=4G,high                       //high=4G, low=128M(default)
7) crashkernel=256M,low                      //low=0M, invalid
8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
10) crashkernel=512M@0xd0000000              //low=512M

Changes since [v6]:
1. Introduce the "high" flag to mark whether "crashkernel=X,high"
   is passed. Fix the retrying logic between "crashkernel=X,high"
   case and others when the first allocation attempt fails.

Changes since [v5]:
1. Update the crashkernel allocation logic when crashkernel=X,high
   is specified. In this case, region above 4G will directly get
   reserved as crashkernel, rather than trying lower 32bit allocation
   first.

Changes since [v4]:
1. Update some imprecise code comments for cmdline parsing.

Changes since [v3]:
1. Update to print warning and return explicitly on failure when
   crashkernel=size@offset is specified. Not changing the result
   in this case but making the logic more straightforward.
2. Some minor cleanup.

Changes since [v2]:
1. Update the allocation logic to ensure the high crashkernel
   region is reserved strictly above dma32_phys_limit.
2. Clean up some minor format problems.

Chen Jiahao (2):
  riscv: kdump: Implement crashkernel=X,[high,low]
  docs: kdump: Update the crashkernel description for riscv

 .../admin-guide/kernel-parameters.txt         | 15 ++--
 arch/riscv/kernel/setup.c                     |  5 ++
 arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
 3 files changed, 90 insertions(+), 14 deletions(-)

-- 
2.34.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-01 17:11 ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

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.
Hence this patchset introduces 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". Besides, there are few rules need
to take notice:
1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
   is specified.
2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
   and there is enough memory to be allocated under 4G.
3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
   specified, a 128M low memory will be allocated automatically for
   swiotlb bounce buffer.
See Documentation/admin-guide/kernel-parameters.txt for more information.

To verify loading the crashkernel, adapted kexec-tools is attached below:
https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2

Following test cases have been performed as expected:
1) crashkernel=256M                          //low=256M
2) crashkernel=1G                            //low=1G
3) crashkernel=4G                            //high=4G, low=128M(default)
4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
6) crashkernel=4G,high                       //high=4G, low=128M(default)
7) crashkernel=256M,low                      //low=0M, invalid
8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
10) crashkernel=512M@0xd0000000              //low=512M

Changes since [v6]:
1. Introduce the "high" flag to mark whether "crashkernel=X,high"
   is passed. Fix the retrying logic between "crashkernel=X,high"
   case and others when the first allocation attempt fails.

Changes since [v5]:
1. Update the crashkernel allocation logic when crashkernel=X,high
   is specified. In this case, region above 4G will directly get
   reserved as crashkernel, rather than trying lower 32bit allocation
   first.

Changes since [v4]:
1. Update some imprecise code comments for cmdline parsing.

Changes since [v3]:
1. Update to print warning and return explicitly on failure when
   crashkernel=size@offset is specified. Not changing the result
   in this case but making the logic more straightforward.
2. Some minor cleanup.

Changes since [v2]:
1. Update the allocation logic to ensure the high crashkernel
   region is reserved strictly above dma32_phys_limit.
2. Clean up some minor format problems.

Chen Jiahao (2):
  riscv: kdump: Implement crashkernel=X,[high,low]
  docs: kdump: Update the crashkernel description for riscv

 .../admin-guide/kernel-parameters.txt         | 15 ++--
 arch/riscv/kernel/setup.c                     |  5 ++
 arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
 3 files changed, 90 insertions(+), 14 deletions(-)

-- 
2.34.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 27+ messages in thread

* [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
  2023-07-01 17:11 ` Chen Jiahao
  (?)
@ 2023-07-01 17:11   ` Chen Jiahao
  -1 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

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;
+	}
+
+	if ((crash_base >= dma32_phys_limit) && crash_low_size &&
+	     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",
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-01 17:11   ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

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;
+	}
+
+	if ((crash_base >= dma32_phys_limit) && crash_low_size &&
+	     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",
-- 
2.34.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-01 17:11   ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

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;
+	}
+
+	if ((crash_base >= dma32_phys_limit) && crash_low_size &&
+	     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",
-- 
2.34.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH -next v6 2/2] docs: kdump: Update the crashkernel description for riscv
  2023-07-01 17:11 ` Chen Jiahao
  (?)
@ 2023-07-01 17:11   ` Chen Jiahao
  -1 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

Now "crashkernel=" parameter on riscv has been updated to support
crashkernel=X,[high,low]. Through which we can reserve memory region
above/within 32bit addressible DMA zone.

Here update the parameter description accordingly.

Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 24477a616cd2..991f436ee39d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -862,7 +862,7 @@
 			memory region [offset, offset + size] for that kernel
 			image. If '@offset' is omitted, then a suitable offset
 			is selected automatically.
-			[KNL, X86-64, ARM64] Select a region under 4G first, and
+			[KNL, X86-64, ARM64, RISCV] Select a region under 4G first, and
 			fall back to reserve region above 4G when '@offset'
 			hasn't been specified.
 			See Documentation/admin-guide/kdump/kdump.rst for further details.
@@ -875,14 +875,14 @@
 			Documentation/admin-guide/kdump/kdump.rst for an example.
 
 	crashkernel=size[KMG],high
-			[KNL, X86-64, ARM64] range could be above 4G. Allow kernel
-			to allocate physical memory region from top, so could
-			be above 4G if system have more than 4G ram installed.
-			Otherwise memory region will be allocated below 4G, if
-			available.
+			[KNL, X86-64, ARM64, RISCV] range could be above 4G.
+			Allow kernel to allocate physical memory region from top,
+			so could be above 4G if system have more than 4G ram
+			installed. Otherwise memory region will be allocated
+			below 4G, if available.
 			It will be ignored if crashkernel=X is specified.
 	crashkernel=size[KMG],low
-			[KNL, X86-64, ARM64] range under 4G. When crashkernel=X,high
+			[KNL, X86-64, ARM64, RISCV] range under 4G. When crashkernel=X,high
 			is passed, kernel could allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that require some amount of low memory, e.g. swiotlb
@@ -893,6 +893,7 @@
 			size is	platform dependent.
 			  --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB)
 			  --> arm64: 128MiB
+			  --> riscv: 128MiB
 			This one lets the user specify own low range under 4G
 			for second kernel instead.
 			0: to disable low allocation.
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH -next v6 2/2] docs: kdump: Update the crashkernel description for riscv
@ 2023-07-01 17:11   ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

Now "crashkernel=" parameter on riscv has been updated to support
crashkernel=X,[high,low]. Through which we can reserve memory region
above/within 32bit addressible DMA zone.

Here update the parameter description accordingly.

Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 24477a616cd2..991f436ee39d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -862,7 +862,7 @@
 			memory region [offset, offset + size] for that kernel
 			image. If '@offset' is omitted, then a suitable offset
 			is selected automatically.
-			[KNL, X86-64, ARM64] Select a region under 4G first, and
+			[KNL, X86-64, ARM64, RISCV] Select a region under 4G first, and
 			fall back to reserve region above 4G when '@offset'
 			hasn't been specified.
 			See Documentation/admin-guide/kdump/kdump.rst for further details.
@@ -875,14 +875,14 @@
 			Documentation/admin-guide/kdump/kdump.rst for an example.
 
 	crashkernel=size[KMG],high
-			[KNL, X86-64, ARM64] range could be above 4G. Allow kernel
-			to allocate physical memory region from top, so could
-			be above 4G if system have more than 4G ram installed.
-			Otherwise memory region will be allocated below 4G, if
-			available.
+			[KNL, X86-64, ARM64, RISCV] range could be above 4G.
+			Allow kernel to allocate physical memory region from top,
+			so could be above 4G if system have more than 4G ram
+			installed. Otherwise memory region will be allocated
+			below 4G, if available.
 			It will be ignored if crashkernel=X is specified.
 	crashkernel=size[KMG],low
-			[KNL, X86-64, ARM64] range under 4G. When crashkernel=X,high
+			[KNL, X86-64, ARM64, RISCV] range under 4G. When crashkernel=X,high
 			is passed, kernel could allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that require some amount of low memory, e.g. swiotlb
@@ -893,6 +893,7 @@
 			size is	platform dependent.
 			  --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB)
 			  --> arm64: 128MiB
+			  --> riscv: 128MiB
 			This one lets the user specify own low range under 4G
 			for second kernel instead.
 			0: to disable low allocation.
-- 
2.34.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [PATCH -next v6 2/2] docs: kdump: Update the crashkernel description for riscv
@ 2023-07-01 17:11   ` Chen Jiahao
  0 siblings, 0 replies; 27+ messages in thread
From: Chen Jiahao @ 2023-07-01 17:11 UTC (permalink / raw)
  To: linux-kernel, linux-riscv, kexec, linux-doc
  Cc: paul.walmsley, palmer, conor.dooley, guoren, heiko, bjorn, alex,
	akpm, atishp, bhe, thunder.leizhen, horms

Now "crashkernel=" parameter on riscv has been updated to support
crashkernel=X,[high,low]. Through which we can reserve memory region
above/within 32bit addressible DMA zone.

Here update the parameter description accordingly.

Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 24477a616cd2..991f436ee39d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -862,7 +862,7 @@
 			memory region [offset, offset + size] for that kernel
 			image. If '@offset' is omitted, then a suitable offset
 			is selected automatically.
-			[KNL, X86-64, ARM64] Select a region under 4G first, and
+			[KNL, X86-64, ARM64, RISCV] Select a region under 4G first, and
 			fall back to reserve region above 4G when '@offset'
 			hasn't been specified.
 			See Documentation/admin-guide/kdump/kdump.rst for further details.
@@ -875,14 +875,14 @@
 			Documentation/admin-guide/kdump/kdump.rst for an example.
 
 	crashkernel=size[KMG],high
-			[KNL, X86-64, ARM64] range could be above 4G. Allow kernel
-			to allocate physical memory region from top, so could
-			be above 4G if system have more than 4G ram installed.
-			Otherwise memory region will be allocated below 4G, if
-			available.
+			[KNL, X86-64, ARM64, RISCV] range could be above 4G.
+			Allow kernel to allocate physical memory region from top,
+			so could be above 4G if system have more than 4G ram
+			installed. Otherwise memory region will be allocated
+			below 4G, if available.
 			It will be ignored if crashkernel=X is specified.
 	crashkernel=size[KMG],low
-			[KNL, X86-64, ARM64] range under 4G. When crashkernel=X,high
+			[KNL, X86-64, ARM64, RISCV] range under 4G. When crashkernel=X,high
 			is passed, kernel could allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that require some amount of low memory, e.g. swiotlb
@@ -893,6 +893,7 @@
 			size is	platform dependent.
 			  --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB)
 			  --> arm64: 128MiB
+			  --> riscv: 128MiB
 			This one lets the user specify own low range under 4G
 			for second kernel instead.
 			0: to disable low allocation.
-- 
2.34.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
  2023-07-01 17:11   ` Chen Jiahao
  (?)
@ 2023-07-02  4:12     ` Baoquan He
  -1 siblings, 0 replies; 27+ messages in thread
From: Baoquan He @ 2023-07-02  4:12 UTC (permalink / raw)
  To: Chen Jiahao
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms

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.

> +	}
> +
> +	if ((crash_base >= dma32_phys_limit) && crash_low_size &&
> +	     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",
> -- 
> 2.34.1
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-02  4:12     ` Baoquan He
  0 siblings, 0 replies; 27+ messages in thread
From: Baoquan He @ 2023-07-02  4:12 UTC (permalink / raw)
  To: Chen Jiahao
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms

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.

> +	}
> +
> +	if ((crash_base >= dma32_phys_limit) && crash_low_size &&
> +	     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",
> -- 
> 2.34.1
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-02  4:12     ` Baoquan He
  0 siblings, 0 replies; 27+ messages in thread
From: Baoquan He @ 2023-07-02  4:12 UTC (permalink / raw)
  To: Chen Jiahao
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms

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.

> +	}
> +
> +	if ((crash_base >= dma32_phys_limit) && crash_low_size &&
> +	     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",
> -- 
> 2.34.1
> 


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
  2023-07-01 13:45   ` Guo Ren
  (?)
@ 2023-07-03 13:07     ` chenjiahao (C)
  -1 siblings, 0 replies; 27+ messages in thread
From: chenjiahao (C) @ 2023-07-03 13:07 UTC (permalink / raw)
  To: Guo Ren
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms


On 2023/7/1 21:45, Guo Ren wrote:
> On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
>> Hence this patchset introduces 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". Besides, there are few rules need
>> to take notice:
>> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
>>     is specified.
>> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
>>     and there is enough memory to be allocated under 4G.
>> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
>>     specified, a 128M low memory will be allocated automatically for
>>     swiotlb bounce buffer.
>> See Documentation/admin-guide/kernel-parameters.txt for more information.
>>
>> To verify loading the crashkernel, adapted kexec-tools is attached below:
>> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>>
>> Following test cases have been performed as expected:
>> 1) crashkernel=256M                          //low=256M
>> 2) crashkernel=1G                            //low=1G
> Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
> https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/

I have tested on QEMU with sv57 mmu, so it seems the synchronization problem
was not reproduce when reserving 1G memory and loading the capture kernel.


Thanks,
Jiahao

>
>> 3) crashkernel=4G                            //high=4G, low=128M(default)
>> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
>> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
>> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
>> 7) crashkernel=256M,low                      //low=0M, invalid
>> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
>> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
>> 10) crashkernel=512M@0xd0000000              //low=512M
>>
>> Changes since [v6]:
>> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
>>     is passed. Fix the retrying logic between "crashkernel=X,high"
>>     case and others when the first allocation attempt fails.
>>
>> Changes since [v5]:
>> 1. Update the crashkernel allocation logic when crashkernel=X,high
>>     is specified. In this case, region above 4G will directly get
>>     reserved as crashkernel, rather than trying lower 32bit allocation
>>     first.
>>
>> Changes since [v4]:
>> 1. Update some imprecise code comments for cmdline parsing.
>>
>> Changes since [v3]:
>> 1. Update to print warning and return explicitly on failure when
>>     crashkernel=size@offset is specified. Not changing the result
>>     in this case but making the logic more straightforward.
>> 2. Some minor cleanup.
>>
>> Changes since [v2]:
>> 1. Update the allocation logic to ensure the high crashkernel
>>     region is reserved strictly above dma32_phys_limit.
>> 2. Clean up some minor format problems.
>>
>> Chen Jiahao (2):
>>    riscv: kdump: Implement crashkernel=X,[high,low]
>>    docs: kdump: Update the crashkernel description for riscv
>>
>>   .../admin-guide/kernel-parameters.txt         | 15 ++--
>>   arch/riscv/kernel/setup.c                     |  5 ++
>>   arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
>>   3 files changed, 90 insertions(+), 14 deletions(-)
>>
>> --
>> 2.34.1
>>
>

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-03 13:07     ` chenjiahao (C)
  0 siblings, 0 replies; 27+ messages in thread
From: chenjiahao (C) @ 2023-07-03 13:07 UTC (permalink / raw)
  To: Guo Ren
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms


On 2023/7/1 21:45, Guo Ren wrote:
> On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
>> Hence this patchset introduces 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". Besides, there are few rules need
>> to take notice:
>> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
>>     is specified.
>> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
>>     and there is enough memory to be allocated under 4G.
>> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
>>     specified, a 128M low memory will be allocated automatically for
>>     swiotlb bounce buffer.
>> See Documentation/admin-guide/kernel-parameters.txt for more information.
>>
>> To verify loading the crashkernel, adapted kexec-tools is attached below:
>> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>>
>> Following test cases have been performed as expected:
>> 1) crashkernel=256M                          //low=256M
>> 2) crashkernel=1G                            //low=1G
> Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
> https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/

I have tested on QEMU with sv57 mmu, so it seems the synchronization problem
was not reproduce when reserving 1G memory and loading the capture kernel.


Thanks,
Jiahao

>
>> 3) crashkernel=4G                            //high=4G, low=128M(default)
>> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
>> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
>> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
>> 7) crashkernel=256M,low                      //low=0M, invalid
>> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
>> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
>> 10) crashkernel=512M@0xd0000000              //low=512M
>>
>> Changes since [v6]:
>> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
>>     is passed. Fix the retrying logic between "crashkernel=X,high"
>>     case and others when the first allocation attempt fails.
>>
>> Changes since [v5]:
>> 1. Update the crashkernel allocation logic when crashkernel=X,high
>>     is specified. In this case, region above 4G will directly get
>>     reserved as crashkernel, rather than trying lower 32bit allocation
>>     first.
>>
>> Changes since [v4]:
>> 1. Update some imprecise code comments for cmdline parsing.
>>
>> Changes since [v3]:
>> 1. Update to print warning and return explicitly on failure when
>>     crashkernel=size@offset is specified. Not changing the result
>>     in this case but making the logic more straightforward.
>> 2. Some minor cleanup.
>>
>> Changes since [v2]:
>> 1. Update the allocation logic to ensure the high crashkernel
>>     region is reserved strictly above dma32_phys_limit.
>> 2. Clean up some minor format problems.
>>
>> Chen Jiahao (2):
>>    riscv: kdump: Implement crashkernel=X,[high,low]
>>    docs: kdump: Update the crashkernel description for riscv
>>
>>   .../admin-guide/kernel-parameters.txt         | 15 ++--
>>   arch/riscv/kernel/setup.c                     |  5 ++
>>   arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
>>   3 files changed, 90 insertions(+), 14 deletions(-)
>>
>> --
>> 2.34.1
>>
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-03 13:07     ` chenjiahao (C)
  0 siblings, 0 replies; 27+ messages in thread
From: chenjiahao (C) @ 2023-07-03 13:07 UTC (permalink / raw)
  To: Guo Ren
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms


On 2023/7/1 21:45, Guo Ren wrote:
> On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
>> Hence this patchset introduces 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". Besides, there are few rules need
>> to take notice:
>> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
>>     is specified.
>> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
>>     and there is enough memory to be allocated under 4G.
>> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
>>     specified, a 128M low memory will be allocated automatically for
>>     swiotlb bounce buffer.
>> See Documentation/admin-guide/kernel-parameters.txt for more information.
>>
>> To verify loading the crashkernel, adapted kexec-tools is attached below:
>> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
>>
>> Following test cases have been performed as expected:
>> 1) crashkernel=256M                          //low=256M
>> 2) crashkernel=1G                            //low=1G
> Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
> https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/

I have tested on QEMU with sv57 mmu, so it seems the synchronization problem
was not reproduce when reserving 1G memory and loading the capture kernel.


Thanks,
Jiahao

>
>> 3) crashkernel=4G                            //high=4G, low=128M(default)
>> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
>> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
>> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
>> 7) crashkernel=256M,low                      //low=0M, invalid
>> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
>> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
>> 10) crashkernel=512M@0xd0000000              //low=512M
>>
>> Changes since [v6]:
>> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
>>     is passed. Fix the retrying logic between "crashkernel=X,high"
>>     case and others when the first allocation attempt fails.
>>
>> Changes since [v5]:
>> 1. Update the crashkernel allocation logic when crashkernel=X,high
>>     is specified. In this case, region above 4G will directly get
>>     reserved as crashkernel, rather than trying lower 32bit allocation
>>     first.
>>
>> Changes since [v4]:
>> 1. Update some imprecise code comments for cmdline parsing.
>>
>> Changes since [v3]:
>> 1. Update to print warning and return explicitly on failure when
>>     crashkernel=size@offset is specified. Not changing the result
>>     in this case but making the logic more straightforward.
>> 2. Some minor cleanup.
>>
>> Changes since [v2]:
>> 1. Update the allocation logic to ensure the high crashkernel
>>     region is reserved strictly above dma32_phys_limit.
>> 2. Clean up some minor format problems.
>>
>> Chen Jiahao (2):
>>    riscv: kdump: Implement crashkernel=X,[high,low]
>>    docs: kdump: Update the crashkernel description for riscv
>>
>>   .../admin-guide/kernel-parameters.txt         | 15 ++--
>>   arch/riscv/kernel/setup.c                     |  5 ++
>>   arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
>>   3 files changed, 90 insertions(+), 14 deletions(-)
>>
>> --
>> 2.34.1
>>
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
  2023-07-02  4:12     ` Baoquan He
  (?)
@ 2023-07-04  2:18       ` chenjiahao (C)
  -1 siblings, 0 replies; 27+ messages in thread
From: chenjiahao (C) @ 2023-07-04  2:18 UTC (permalink / raw)
  To: Baoquan He
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms


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.

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-04  2:18       ` chenjiahao (C)
  0 siblings, 0 replies; 27+ messages in thread
From: chenjiahao (C) @ 2023-07-04  2:18 UTC (permalink / raw)
  To: Baoquan He
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms


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.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-04  2:18       ` chenjiahao (C)
  0 siblings, 0 replies; 27+ messages in thread
From: chenjiahao (C) @ 2023-07-04  2:18 UTC (permalink / raw)
  To: Baoquan He
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms


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.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
  2023-07-03 13:07     ` chenjiahao (C)
  (?)
@ 2023-07-04  2:39       ` Guo Ren
  -1 siblings, 0 replies; 27+ messages in thread
From: Guo Ren @ 2023-07-04  2:39 UTC (permalink / raw)
  To: chenjiahao (C)
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms

On Mon, Jul 3, 2023 at 9:07 PM chenjiahao (C) <chenjiahao16@huawei.com> wrote:
>
>
> On 2023/7/1 21:45, Guo Ren wrote:
> > On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
> >> Hence this patchset introduces 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". Besides, there are few rules need
> >> to take notice:
> >> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
> >>     is specified.
> >> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
> >>     and there is enough memory to be allocated under 4G.
> >> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
> >>     specified, a 128M low memory will be allocated automatically for
> >>     swiotlb bounce buffer.
> >> See Documentation/admin-guide/kernel-parameters.txt for more information.
> >>
> >> To verify loading the crashkernel, adapted kexec-tools is attached below:
> >> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
> >>
> >> Following test cases have been performed as expected:
> >> 1) crashkernel=256M                          //low=256M
> >> 2) crashkernel=1G                            //low=1G
> > Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
> > https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/
>
> I have tested on QEMU with sv57 mmu, so it seems the synchronization problem
> was not reproduce when reserving 1G memory and loading the capture kernel.
Yes, the pud of sv57 is not the pgd entries, so you didn't get problem.

>
>
> Thanks,
> Jiahao
>
> >
> >> 3) crashkernel=4G                            //high=4G, low=128M(default)
> >> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
> >> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
> >> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
> >> 7) crashkernel=256M,low                      //low=0M, invalid
> >> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
> >> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
> >> 10) crashkernel=512M@0xd0000000              //low=512M
> >>
> >> Changes since [v6]:
> >> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
> >>     is passed. Fix the retrying logic between "crashkernel=X,high"
> >>     case and others when the first allocation attempt fails.
> >>
> >> Changes since [v5]:
> >> 1. Update the crashkernel allocation logic when crashkernel=X,high
> >>     is specified. In this case, region above 4G will directly get
> >>     reserved as crashkernel, rather than trying lower 32bit allocation
> >>     first.
> >>
> >> Changes since [v4]:
> >> 1. Update some imprecise code comments for cmdline parsing.
> >>
> >> Changes since [v3]:
> >> 1. Update to print warning and return explicitly on failure when
> >>     crashkernel=size@offset is specified. Not changing the result
> >>     in this case but making the logic more straightforward.
> >> 2. Some minor cleanup.
> >>
> >> Changes since [v2]:
> >> 1. Update the allocation logic to ensure the high crashkernel
> >>     region is reserved strictly above dma32_phys_limit.
> >> 2. Clean up some minor format problems.
> >>
> >> Chen Jiahao (2):
> >>    riscv: kdump: Implement crashkernel=X,[high,low]
> >>    docs: kdump: Update the crashkernel description for riscv
> >>
> >>   .../admin-guide/kernel-parameters.txt         | 15 ++--
> >>   arch/riscv/kernel/setup.c                     |  5 ++
> >>   arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
> >>   3 files changed, 90 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.34.1
> >>
> >



-- 
Best Regards
 Guo Ren

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-04  2:39       ` Guo Ren
  0 siblings, 0 replies; 27+ messages in thread
From: Guo Ren @ 2023-07-04  2:39 UTC (permalink / raw)
  To: chenjiahao (C)
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms

On Mon, Jul 3, 2023 at 9:07 PM chenjiahao (C) <chenjiahao16@huawei.com> wrote:
>
>
> On 2023/7/1 21:45, Guo Ren wrote:
> > On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
> >> Hence this patchset introduces 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". Besides, there are few rules need
> >> to take notice:
> >> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
> >>     is specified.
> >> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
> >>     and there is enough memory to be allocated under 4G.
> >> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
> >>     specified, a 128M low memory will be allocated automatically for
> >>     swiotlb bounce buffer.
> >> See Documentation/admin-guide/kernel-parameters.txt for more information.
> >>
> >> To verify loading the crashkernel, adapted kexec-tools is attached below:
> >> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
> >>
> >> Following test cases have been performed as expected:
> >> 1) crashkernel=256M                          //low=256M
> >> 2) crashkernel=1G                            //low=1G
> > Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
> > https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/
>
> I have tested on QEMU with sv57 mmu, so it seems the synchronization problem
> was not reproduce when reserving 1G memory and loading the capture kernel.
Yes, the pud of sv57 is not the pgd entries, so you didn't get problem.

>
>
> Thanks,
> Jiahao
>
> >
> >> 3) crashkernel=4G                            //high=4G, low=128M(default)
> >> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
> >> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
> >> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
> >> 7) crashkernel=256M,low                      //low=0M, invalid
> >> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
> >> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
> >> 10) crashkernel=512M@0xd0000000              //low=512M
> >>
> >> Changes since [v6]:
> >> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
> >>     is passed. Fix the retrying logic between "crashkernel=X,high"
> >>     case and others when the first allocation attempt fails.
> >>
> >> Changes since [v5]:
> >> 1. Update the crashkernel allocation logic when crashkernel=X,high
> >>     is specified. In this case, region above 4G will directly get
> >>     reserved as crashkernel, rather than trying lower 32bit allocation
> >>     first.
> >>
> >> Changes since [v4]:
> >> 1. Update some imprecise code comments for cmdline parsing.
> >>
> >> Changes since [v3]:
> >> 1. Update to print warning and return explicitly on failure when
> >>     crashkernel=size@offset is specified. Not changing the result
> >>     in this case but making the logic more straightforward.
> >> 2. Some minor cleanup.
> >>
> >> Changes since [v2]:
> >> 1. Update the allocation logic to ensure the high crashkernel
> >>     region is reserved strictly above dma32_phys_limit.
> >> 2. Clean up some minor format problems.
> >>
> >> Chen Jiahao (2):
> >>    riscv: kdump: Implement crashkernel=X,[high,low]
> >>    docs: kdump: Update the crashkernel description for riscv
> >>
> >>   .../admin-guide/kernel-parameters.txt         | 15 ++--
> >>   arch/riscv/kernel/setup.c                     |  5 ++
> >>   arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
> >>   3 files changed, 90 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.34.1
> >>
> >



-- 
Best Regards
 Guo Ren

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 0/2] support allocating crashkernel above 4G explicitly on riscv
@ 2023-07-04  2:39       ` Guo Ren
  0 siblings, 0 replies; 27+ messages in thread
From: Guo Ren @ 2023-07-04  2:39 UTC (permalink / raw)
  To: chenjiahao (C)
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, heiko, bjorn, alex, akpm, atishp, bhe,
	thunder.leizhen, horms

On Mon, Jul 3, 2023 at 9:07 PM chenjiahao (C) <chenjiahao16@huawei.com> wrote:
>
>
> On 2023/7/1 21:45, Guo Ren wrote:
> > On Sat, Jul 1, 2023 at 5:12 PM Chen Jiahao <chenjiahao16@huawei.com> 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.
> >> Hence this patchset introduces 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". Besides, there are few rules need
> >> to take notice:
> >> 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size"
> >>     is specified.
> >> 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed
> >>     and there is enough memory to be allocated under 4G.
> >> 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is
> >>     specified, a 128M low memory will be allocated automatically for
> >>     swiotlb bounce buffer.
> >> See Documentation/admin-guide/kernel-parameters.txt for more information.
> >>
> >> To verify loading the crashkernel, adapted kexec-tools is attached below:
> >> https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
> >>
> >> Following test cases have been performed as expected:
> >> 1) crashkernel=256M                          //low=256M
> >> 2) crashkernel=1G                            //low=1G
> > Have you tried 1GB memory? we found a pud mapping problem on Sv39 of kexec, See:
> > https://lore.kernel.org/linux-riscv/20230629082032.3481237-1-guoren@kernel.org/
>
> I have tested on QEMU with sv57 mmu, so it seems the synchronization problem
> was not reproduce when reserving 1G memory and loading the capture kernel.
Yes, the pud of sv57 is not the pgd entries, so you didn't get problem.

>
>
> Thanks,
> Jiahao
>
> >
> >> 3) crashkernel=4G                            //high=4G, low=128M(default)
> >> 4) crashkernel=4G crashkernel=256M,high      //high=4G, low=128M(default), high is ignored
> >> 5) crashkernel=4G crashkernel=256M,low       //high=4G, low=128M(default), low is ignored
> >> 6) crashkernel=4G,high                       //high=4G, low=128M(default)
> >> 7) crashkernel=256M,low                      //low=0M, invalid
> >> 8) crashkernel=4G,high crashkernel=256M,low  //high=4G, low=256M
> >> 9) crashkernel=4G,high crashkernel=4G,low    //high=0M, low=0M, invalid
> >> 10) crashkernel=512M@0xd0000000              //low=512M
> >>
> >> Changes since [v6]:
> >> 1. Introduce the "high" flag to mark whether "crashkernel=X,high"
> >>     is passed. Fix the retrying logic between "crashkernel=X,high"
> >>     case and others when the first allocation attempt fails.
> >>
> >> Changes since [v5]:
> >> 1. Update the crashkernel allocation logic when crashkernel=X,high
> >>     is specified. In this case, region above 4G will directly get
> >>     reserved as crashkernel, rather than trying lower 32bit allocation
> >>     first.
> >>
> >> Changes since [v4]:
> >> 1. Update some imprecise code comments for cmdline parsing.
> >>
> >> Changes since [v3]:
> >> 1. Update to print warning and return explicitly on failure when
> >>     crashkernel=size@offset is specified. Not changing the result
> >>     in this case but making the logic more straightforward.
> >> 2. Some minor cleanup.
> >>
> >> Changes since [v2]:
> >> 1. Update the allocation logic to ensure the high crashkernel
> >>     region is reserved strictly above dma32_phys_limit.
> >> 2. Clean up some minor format problems.
> >>
> >> Chen Jiahao (2):
> >>    riscv: kdump: Implement crashkernel=X,[high,low]
> >>    docs: kdump: Update the crashkernel description for riscv
> >>
> >>   .../admin-guide/kernel-parameters.txt         | 15 ++--
> >>   arch/riscv/kernel/setup.c                     |  5 ++
> >>   arch/riscv/mm/init.c                          | 84 +++++++++++++++++--
> >>   3 files changed, 90 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.34.1
> >>
> >



-- 
Best Regards
 Guo Ren

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
  2023-07-04  2:18       ` chenjiahao (C)
  (?)
@ 2023-07-04  8:11         ` Baoquan He
  -1 siblings, 0 replies; 27+ messages in thread
From: Baoquan He @ 2023-07-04  8:11 UTC (permalink / raw)
  To: chenjiahao (C)
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-04  8:11         ` Baoquan He
  0 siblings, 0 replies; 27+ messages in thread
From: Baoquan He @ 2023-07-04  8:11 UTC (permalink / raw)
  To: chenjiahao (C)
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms

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
> 
> 


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [PATCH -next v6 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
@ 2023-07-04  8:11         ` Baoquan He
  0 siblings, 0 replies; 27+ messages in thread
From: Baoquan He @ 2023-07-04  8:11 UTC (permalink / raw)
  To: chenjiahao (C)
  Cc: linux-kernel, linux-riscv, kexec, linux-doc, paul.walmsley,
	palmer, conor.dooley, guoren, heiko, bjorn, alex, akpm, atishp,
	thunder.leizhen, horms

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2023-07-04  8:12 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.