All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation
Date: Fri, 11 Feb 2022 18:39:49 +0800	[thread overview]
Message-ID: <YgY89RxkAl12n/dd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220124084708.683-3-thunder.leizhen@huawei.com>

On 01/24/22 at 04:47pm, Zhen Lei wrote:
> From: Chen Zhou <chenzhou10@huawei.com>
> 
> Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
> for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
> upper bound of high crash memory, use macros instead.
> 
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> Tested-by: John Donnelly <John.p.donnelly@oracle.com>
> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
> ---
>  arch/arm64/mm/init.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 90f276d46b93bc6..6c653a2c7cff052 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -65,6 +65,12 @@ EXPORT_SYMBOL(memstart_addr);
>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>  
>  #ifdef CONFIG_KEXEC_CORE
> +/* Current arm64 boot protocol requires 2MB alignment */
> +#define CRASH_ALIGN		SZ_2M
> +
> +#define CRASH_ADDR_LOW_MAX	arm64_dma_phys_limit
> +#define CRASH_ADDR_HIGH_MAX	MEMBLOCK_ALLOC_ACCESSIBLE

MEMBLOCK_ALLOC_ACCESSIBLE is obvoiously a alloc flag for memblock
allocator, I don't think it's appropriate to make HIGH_MAX get its value.
You can make it as memblock.current_limit, or do not define it, but using
MEMBLOCK_ALLOC_ACCESSIBLE direclty in memblock_phys_alloc_range() with
a code comment. 


> +
>  /*
>   * reserve_crashkernel() - reserves memory for crash kernel
>   *
> @@ -75,7 +81,7 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>  static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_base, crash_size;
> -	unsigned long long crash_max = arm64_dma_phys_limit;
> +	unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>  	int ret;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> @@ -90,8 +96,7 @@ static void __init reserve_crashkernel(void)
>  	if (crash_base)
>  		crash_max = crash_base + crash_size;
>  
> -	/* Current arm64 boot protocol requires 2MB alignment */
> -	crash_base = memblock_phys_alloc_range(crash_size, SZ_2M,
> +	crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>  					       crash_base, crash_max);
>  	if (!crash_base) {
>  		pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> -- 
> 2.25.1
> 



WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
	Feng Zhou <zhoufeng.zf@bytedance.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Chen Zhou <dingguo.cz@antgroup.com>,
	John Donnelly <John.p.donnelly@oracle.com>,
	Dave Kleikamp <dave.kleikamp@oracle.com>
Subject: Re: [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation
Date: Fri, 11 Feb 2022 18:39:49 +0800	[thread overview]
Message-ID: <YgY89RxkAl12n/dd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220124084708.683-3-thunder.leizhen@huawei.com>

On 01/24/22 at 04:47pm, Zhen Lei wrote:
> From: Chen Zhou <chenzhou10@huawei.com>
> 
> Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
> for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
> upper bound of high crash memory, use macros instead.
> 
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> Tested-by: John Donnelly <John.p.donnelly@oracle.com>
> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
> ---
>  arch/arm64/mm/init.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 90f276d46b93bc6..6c653a2c7cff052 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -65,6 +65,12 @@ EXPORT_SYMBOL(memstart_addr);
>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>  
>  #ifdef CONFIG_KEXEC_CORE
> +/* Current arm64 boot protocol requires 2MB alignment */
> +#define CRASH_ALIGN		SZ_2M
> +
> +#define CRASH_ADDR_LOW_MAX	arm64_dma_phys_limit
> +#define CRASH_ADDR_HIGH_MAX	MEMBLOCK_ALLOC_ACCESSIBLE

MEMBLOCK_ALLOC_ACCESSIBLE is obvoiously a alloc flag for memblock
allocator, I don't think it's appropriate to make HIGH_MAX get its value.
You can make it as memblock.current_limit, or do not define it, but using
MEMBLOCK_ALLOC_ACCESSIBLE direclty in memblock_phys_alloc_range() with
a code comment. 


> +
>  /*
>   * reserve_crashkernel() - reserves memory for crash kernel
>   *
> @@ -75,7 +81,7 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>  static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_base, crash_size;
> -	unsigned long long crash_max = arm64_dma_phys_limit;
> +	unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>  	int ret;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> @@ -90,8 +96,7 @@ static void __init reserve_crashkernel(void)
>  	if (crash_base)
>  		crash_max = crash_base + crash_size;
>  
> -	/* Current arm64 boot protocol requires 2MB alignment */
> -	crash_base = memblock_phys_alloc_range(crash_size, SZ_2M,
> +	crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>  					       crash_base, crash_max);
>  	if (!crash_base) {
>  		pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> -- 
> 2.25.1
> 


WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
	Feng Zhou <zhoufeng.zf@bytedance.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Chen Zhou <dingguo.cz@antgroup.com>,
	John Donnelly <John.p.donnelly@oracle.com>,
	Dave Kleikamp <dave.kleikamp@oracle.com>
Subject: Re: [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation
Date: Fri, 11 Feb 2022 18:39:49 +0800	[thread overview]
Message-ID: <YgY89RxkAl12n/dd@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220124084708.683-3-thunder.leizhen@huawei.com>

On 01/24/22 at 04:47pm, Zhen Lei wrote:
> From: Chen Zhou <chenzhou10@huawei.com>
> 
> Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
> for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
> upper bound of high crash memory, use macros instead.
> 
> Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> Tested-by: John Donnelly <John.p.donnelly@oracle.com>
> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
> ---
>  arch/arm64/mm/init.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 90f276d46b93bc6..6c653a2c7cff052 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -65,6 +65,12 @@ EXPORT_SYMBOL(memstart_addr);
>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>  
>  #ifdef CONFIG_KEXEC_CORE
> +/* Current arm64 boot protocol requires 2MB alignment */
> +#define CRASH_ALIGN		SZ_2M
> +
> +#define CRASH_ADDR_LOW_MAX	arm64_dma_phys_limit
> +#define CRASH_ADDR_HIGH_MAX	MEMBLOCK_ALLOC_ACCESSIBLE

MEMBLOCK_ALLOC_ACCESSIBLE is obvoiously a alloc flag for memblock
allocator, I don't think it's appropriate to make HIGH_MAX get its value.
You can make it as memblock.current_limit, or do not define it, but using
MEMBLOCK_ALLOC_ACCESSIBLE direclty in memblock_phys_alloc_range() with
a code comment. 


> +
>  /*
>   * reserve_crashkernel() - reserves memory for crash kernel
>   *
> @@ -75,7 +81,7 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>  static void __init reserve_crashkernel(void)
>  {
>  	unsigned long long crash_base, crash_size;
> -	unsigned long long crash_max = arm64_dma_phys_limit;
> +	unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>  	int ret;
>  
>  	ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> @@ -90,8 +96,7 @@ static void __init reserve_crashkernel(void)
>  	if (crash_base)
>  		crash_max = crash_base + crash_size;
>  
> -	/* Current arm64 boot protocol requires 2MB alignment */
> -	crash_base = memblock_phys_alloc_range(crash_size, SZ_2M,
> +	crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>  					       crash_base, crash_max);
>  	if (!crash_base) {
>  		pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
> -- 
> 2.25.1
> 


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

  parent reply	other threads:[~2022-02-11 10:39 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24  8:47 [PATCH v20 0/5] support reserving crashkernel above 4G on arm64 kdump Zhen Lei
2022-01-24  8:47 ` Zhen Lei
2022-01-24  8:47 ` Zhen Lei
2022-01-24  8:47 ` [PATCH v20 1/5] arm64: Use insert_resource() to simplify code Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-26 15:16   ` john.p.donnelly
2022-01-26 15:16     ` john.p.donnelly
2022-01-26 15:16     ` john.p.donnelly
2022-02-08  1:43   ` Baoquan He
2022-02-08  1:43     ` Baoquan He
2022-02-08  1:43     ` Baoquan He
2022-01-24  8:47 ` [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-26 15:17   ` john.p.donnelly
2022-01-26 15:17     ` john.p.donnelly
2022-01-26 15:17     ` john.p.donnelly
2022-02-11 10:39   ` Baoquan He [this message]
2022-02-11 10:39     ` Baoquan He
2022-02-11 10:39     ` Baoquan He
2022-02-14  6:22     ` Leizhen
2022-02-14  6:22       ` Leizhen (ThunderTown)
2022-02-14  6:22       ` Leizhen (ThunderTown)
2022-02-21  3:22       ` Baoquan He
2022-02-21  3:22         ` Baoquan He
2022-02-21  3:22         ` Baoquan He
2022-02-21  6:19         ` Leizhen
2022-02-21  6:19           ` Leizhen (ThunderTown)
2022-02-21  6:19           ` Leizhen (ThunderTown)
2022-01-24  8:47 ` [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-26 15:18   ` john.p.donnelly
2022-01-26 15:18     ` john.p.donnelly
2022-01-26 15:18     ` john.p.donnelly
2022-02-11 10:30   ` Baoquan He
2022-02-11 10:30     ` Baoquan He
2022-02-11 10:30     ` Baoquan He
2022-02-11 10:41     ` Leizhen
2022-02-11 10:41       ` Leizhen (ThunderTown)
2022-02-11 10:41       ` Leizhen (ThunderTown)
2022-02-11 10:51       ` Baoquan He
2022-02-11 10:51         ` Baoquan He
2022-02-11 10:51         ` Baoquan He
2022-02-14  6:44         ` Leizhen
2022-02-14  6:44           ` Leizhen (ThunderTown)
2022-02-14  6:44           ` Leizhen (ThunderTown)
2022-02-14  7:09           ` Baoquan He
2022-02-14  7:09             ` Baoquan He
2022-02-14  7:09             ` Baoquan He
2022-02-14  3:52   ` Baoquan He
2022-02-14  3:52     ` Baoquan He
2022-02-14  3:52     ` Baoquan He
2022-02-14  7:53     ` Leizhen
2022-02-14  7:53       ` Leizhen (ThunderTown)
2022-02-14  7:53       ` Leizhen (ThunderTown)
2022-02-16  2:58       ` Leizhen
2022-02-16  2:58         ` Leizhen (ThunderTown)
2022-02-16  2:58         ` Leizhen (ThunderTown)
2022-02-16 10:20         ` Baoquan He
2022-02-16 10:20           ` Baoquan He
2022-02-16 10:20           ` Baoquan He
2022-02-17  1:57           ` Leizhen
2022-02-17  1:57             ` Leizhen (ThunderTown)
2022-02-17  1:57             ` Leizhen (ThunderTown)
2022-01-24  8:47 ` [PATCH v20 4/5] of: fdt: Add memory for devices by DT property "linux, usable-memory-range" Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-24  8:47   ` [PATCH v20 4/5] of: fdt: Add memory for devices by DT property "linux,usable-memory-range" Zhen Lei
2022-01-26 15:19   ` john.p.donnelly
2022-01-26 15:19     ` john.p.donnelly
2022-01-26 15:19     ` john.p.donnelly
2022-01-24  8:47 ` [PATCH v20 5/5] kdump: update Documentation about crashkernel Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-24  8:47   ` Zhen Lei
2022-01-26 15:19   ` john.p.donnelly
2022-01-26 15:19     ` john.p.donnelly
2022-01-26 15:19     ` john.p.donnelly
2022-02-21  3:48   ` Baoquan He
2022-02-21  3:48     ` Baoquan He
2022-02-21  3:48     ` Baoquan He
2022-02-21  6:38     ` Leizhen
2022-02-21  6:38       ` Leizhen (ThunderTown)
2022-02-21  6:38       ` Leizhen (ThunderTown)
2022-02-07  4:04 ` [PATCH v20 0/5] support reserving crashkernel above 4G on arm64 kdump Leizhen
2022-02-07  4:04   ` Leizhen (ThunderTown)
2022-02-07  4:04   ` Leizhen (ThunderTown)
2022-02-08  2:34   ` Baoquan He
2022-02-08  2:34     ` Baoquan He
2022-02-08  2:34     ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YgY89RxkAl12n/dd@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.