All of lore.kernel.org
 help / color / mirror / Atom feed
From: chenzhou <chenzhou10@huawei.com>
To: Catalin Marinas <catalin.marinas@arm.com>, <bhe@redhat.com>
Cc: <mingo@redhat.com>, <tglx@linutronix.de>, <rppt@kernel.org>,
	<dyoung@redhat.com>, <will@kernel.org>, <nsaenzjulienne@suse.de>,
	<corbet@lwn.net>, <John.P.donnelly@oracle.com>,
	<bhsharma@redhat.com>, <prabhakar.pkin@gmail.com>,
	<horms@verge.net.au>, <robh+dt@kernel.org>, <arnd@arndb.de>,
	<james.morse@arm.com>, <xiexiuqi@huawei.com>,
	<guohanjun@huawei.com>, <huawei.libin@huawei.com>,
	<wangkefeng.wang@huawei.com>, <linux-doc@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <kexec@lists.infradead.org>
Subject: Re: [PATCH v14 08/11] arm64: kdump: reimplement crashkernel=X
Date: Fri, 26 Feb 2021 18:43:07 +0800	[thread overview]
Message-ID: <4722d365-154b-d3bb-3897-92f229e8e84f@huawei.com> (raw)
In-Reply-To: <94cc9191-4eff-355f-ff02-1c5da416960e@huawei.com>



On 2021/2/26 18:31, chenzhou wrote:
>
> On 2021/2/25 0:04, Catalin Marinas wrote:
>> On Sat, Jan 30, 2021 at 03:10:22PM +0800, Chen Zhou wrote:
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>>> will fail when there is no enough low memory.
>>> 2. If reserving crashkernel above 4G, in this case, crash dump
>>> kernel will boot failure because there is no low memory available
>>> for allocation.
>>>
>>> To solve these issues, change the behavior of crashkernel=X and
>>> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation
>>> in DMA zone, and fall back to high allocation if it fails.
>>> We can also use "crashkernel=X,high" to select a region above DMA zone,
>>> which also tries to allocate at least 256M in DMA zone automatically.
>>> "crashkernel=Y,low" can be used to allocate specified size low memory.
>>>
>>> Another minor change, there may be two regions reserved for crash
>>> dump kernel, in order to distinct from the high region and make no
>>> effect to the use of existing kexec-tools, rename the low region as
>>> "Crash kernel (low)".
>> I think we discussed this but I don't remember the conclusion. Is this
>> only renamed conditionally so that we don't break current kexec-tools?
> Yes.
>> IOW, assuming that the full crashkernel region is reserved below 4GB,
>> does the "(low)" suffix still appear or it's only if a high region is
>> additionally reserved?
> Suffix "low" only appear if a high region is additionally reserved.
>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>> index 3f6ecae0bc68..f0caed0cb5e1 100644
>>> --- a/arch/arm64/include/asm/kexec.h
>>> +++ b/arch/arm64/include/asm/kexec.h
>>> @@ -96,6 +96,10 @@ static inline void crash_prepare_suspend(void) {}
>>>  static inline void crash_post_resume(void) {}
>>>  #endif
>>>  
>>> +#ifdef CONFIG_KEXEC_CORE
>>> +extern void __init reserve_crashkernel(void);
>>> +#endif
>> Why not have this in some generic header?
>>
>>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>>> index c18aacde8bb0..69c592c546de 100644
>>> --- a/arch/arm64/kernel/setup.c
>>> +++ b/arch/arm64/kernel/setup.c
>>> @@ -238,7 +238,18 @@ static void __init request_standard_resources(void)
>>>  		    kernel_data.end <= res->end)
>>>  			request_resource(res, &kernel_data);
>>>  #ifdef CONFIG_KEXEC_CORE
>>> -		/* Userspace will find "Crash kernel" region in /proc/iomem. */
>>> +		/*
>>> +		 * Userspace will find "Crash kernel" or "Crash kernel (low)"
>>> +		 * region in /proc/iomem.
>>> +		 * In order to distinct from the high region and make no effect
>>> +		 * to the use of existing kexec-tools, rename the low region as
>>> +		 * "Crash kernel (low)".
>>> +		 */
>>> +		if (crashk_low_res.end && crashk_low_res.start >= res->start &&
>>> +				crashk_low_res.end <= res->end) {
>>> +			crashk_low_res.name = "Crash kernel (low)";
>>> +			request_resource(res, &crashk_low_res);
>>> +		}
>>>  		if (crashk_res.end && crashk_res.start >= res->start &&
>>>  		    crashk_res.end <= res->end)
>>>  			request_resource(res, &crashk_res);
>> My reading of the new generic reserve_crashkernel() is that
>> crashk_low_res will only be populated if crask_res is above 4GB. If
>> that's correct, I'm fine with the renaming here since current systems
>> would not get a renamed low reservation (as long as they don't change
>> the kernel cmdline).
>>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 912f64f505f7..d20f5c444ebf 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -35,6 +35,7 @@
>>>  #include <asm/fixmap.h>
>>>  #include <asm/kasan.h>
>>>  #include <asm/kernel-pgtable.h>
>>> +#include <asm/kexec.h>
>>>  #include <asm/memory.h>
>>>  #include <asm/numa.h>
>>>  #include <asm/sections.h>
>>> @@ -61,66 +62,11 @@ EXPORT_SYMBOL(memstart_addr);
>>>   */
>>>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>  
>>> -#ifdef CONFIG_KEXEC_CORE
>>> -/*
>>> - * reserve_crashkernel() - reserves memory for crash kernel
>>> - *
>>> - * This function reserves memory area given in "crashkernel=" kernel command
>>> - * line parameter. The memory reserved is used by dump capture kernel when
>>> - * primary kernel is crashing.
>>> - */
>>> +#ifndef CONFIG_KEXEC_CORE
>>>  static void __init reserve_crashkernel(void)
>>>  {
>> [...]
>>>  }
>>> +#endif
>> Can we not have the dummy reserve_crashkernel() in the generic code as
>> well and avoid the #ifndef here?
> You mean put the dummy reserve_crashkernel() and the relate function declaration in some generic header?
>  
> Baoquan also mentioned about this.
> Now all the arch that support kdump have the dummy reserve_crashkernel() and
> function declaration, such as arm/arm64/ppc/s390..
>
> But currently different arch may have different CONFIG and different function declaration about this,
> for example,
>
> for s390,
> static void __init reserve_crashkernel(void)
> {                  
> #ifdef CONFIG_CRASH_DUMP
> ...
> #endif        
> }
>
> for ppc,
> #ifdef CONFIG_KEXEC_CORE
> extern void reserve_crashkernel(void);
> #else
> static inline void reserve_crashkernel(void) { ; }
> #endif
>
> If we move these to generic header we need think about:
> 1. the related config in different arch
> 2. function declaration(static/non static)
>
> As Baoquan said in patch 9, how about leave with it for now and i try to solve this later?
>
>>>  #ifdef CONFIG_CRASH_DUMP
>>>  static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
>>> @@ -446,6 +392,14 @@ void __init bootmem_init(void)
>>>  	 * reserved, so do it here.
>>>  	 */
>>>  	reserve_crashkernel();
>>> +#ifdef CONFIG_KEXEC_CORE
>>> +	/*
>>> +	 * The low region is intended to be used for crash dump kernel devices,
>>> +	 * just mark the low region as "nomap" simply.
>>> +	 */
>>> +	if (crashk_low_res.end)
>>> +		memblock_mark_nomap(crashk_low_res.start, resource_size(&crashk_low_res));
>>> +#endif
>> Do we do something similar for crashk_res?
> Not. In the primary kernel(production kernel), we need to use crashk_res memory for crash kernel
> elf core header, initrd...

Sorry, missed one comma after crash kernel.
Not. In the primary kernel(production kernel), we need to use crashk_res memory for crash kernel,
elf core header, initrd and so on.


>
> Different with this, the crashk_low_res is only for crash dump kernel devices.
>> Also, I can see we call crash_exclude_mem_range() only for crashk_res.
>> Do we need to do this for crashk_low_res as well?
> You are right, i missed about this. Will do in next version.
>
> Thanks,
> Chen Zhou


WARNING: multiple messages have this Message-ID (diff)
From: chenzhou <chenzhou10@huawei.com>
To: Catalin Marinas <catalin.marinas@arm.com>, <bhe@redhat.com>
Cc: wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org,
	bhsharma@redhat.com, huawei.libin@huawei.com,
	guohanjun@huawei.com, will@kernel.org, corbet@lwn.net,
	mingo@redhat.com, dyoung@redhat.com, John.P.donnelly@oracle.com,
	arnd@arndb.de, xiexiuqi@huawei.com, horms@verge.net.au,
	tglx@linutronix.de, linux-arm-kernel@lists.infradead.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	robh+dt@kernel.org, james.morse@arm.com, nsaenzjulienne@suse.de,
	prabhakar.pkin@gmail.com, rppt@kernel.org
Subject: Re: [PATCH v14 08/11] arm64: kdump: reimplement crashkernel=X
Date: Fri, 26 Feb 2021 18:43:07 +0800	[thread overview]
Message-ID: <4722d365-154b-d3bb-3897-92f229e8e84f@huawei.com> (raw)
In-Reply-To: <94cc9191-4eff-355f-ff02-1c5da416960e@huawei.com>



On 2021/2/26 18:31, chenzhou wrote:
>
> On 2021/2/25 0:04, Catalin Marinas wrote:
>> On Sat, Jan 30, 2021 at 03:10:22PM +0800, Chen Zhou wrote:
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>>> will fail when there is no enough low memory.
>>> 2. If reserving crashkernel above 4G, in this case, crash dump
>>> kernel will boot failure because there is no low memory available
>>> for allocation.
>>>
>>> To solve these issues, change the behavior of crashkernel=X and
>>> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation
>>> in DMA zone, and fall back to high allocation if it fails.
>>> We can also use "crashkernel=X,high" to select a region above DMA zone,
>>> which also tries to allocate at least 256M in DMA zone automatically.
>>> "crashkernel=Y,low" can be used to allocate specified size low memory.
>>>
>>> Another minor change, there may be two regions reserved for crash
>>> dump kernel, in order to distinct from the high region and make no
>>> effect to the use of existing kexec-tools, rename the low region as
>>> "Crash kernel (low)".
>> I think we discussed this but I don't remember the conclusion. Is this
>> only renamed conditionally so that we don't break current kexec-tools?
> Yes.
>> IOW, assuming that the full crashkernel region is reserved below 4GB,
>> does the "(low)" suffix still appear or it's only if a high region is
>> additionally reserved?
> Suffix "low" only appear if a high region is additionally reserved.
>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>> index 3f6ecae0bc68..f0caed0cb5e1 100644
>>> --- a/arch/arm64/include/asm/kexec.h
>>> +++ b/arch/arm64/include/asm/kexec.h
>>> @@ -96,6 +96,10 @@ static inline void crash_prepare_suspend(void) {}
>>>  static inline void crash_post_resume(void) {}
>>>  #endif
>>>  
>>> +#ifdef CONFIG_KEXEC_CORE
>>> +extern void __init reserve_crashkernel(void);
>>> +#endif
>> Why not have this in some generic header?
>>
>>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>>> index c18aacde8bb0..69c592c546de 100644
>>> --- a/arch/arm64/kernel/setup.c
>>> +++ b/arch/arm64/kernel/setup.c
>>> @@ -238,7 +238,18 @@ static void __init request_standard_resources(void)
>>>  		    kernel_data.end <= res->end)
>>>  			request_resource(res, &kernel_data);
>>>  #ifdef CONFIG_KEXEC_CORE
>>> -		/* Userspace will find "Crash kernel" region in /proc/iomem. */
>>> +		/*
>>> +		 * Userspace will find "Crash kernel" or "Crash kernel (low)"
>>> +		 * region in /proc/iomem.
>>> +		 * In order to distinct from the high region and make no effect
>>> +		 * to the use of existing kexec-tools, rename the low region as
>>> +		 * "Crash kernel (low)".
>>> +		 */
>>> +		if (crashk_low_res.end && crashk_low_res.start >= res->start &&
>>> +				crashk_low_res.end <= res->end) {
>>> +			crashk_low_res.name = "Crash kernel (low)";
>>> +			request_resource(res, &crashk_low_res);
>>> +		}
>>>  		if (crashk_res.end && crashk_res.start >= res->start &&
>>>  		    crashk_res.end <= res->end)
>>>  			request_resource(res, &crashk_res);
>> My reading of the new generic reserve_crashkernel() is that
>> crashk_low_res will only be populated if crask_res is above 4GB. If
>> that's correct, I'm fine with the renaming here since current systems
>> would not get a renamed low reservation (as long as they don't change
>> the kernel cmdline).
>>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 912f64f505f7..d20f5c444ebf 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -35,6 +35,7 @@
>>>  #include <asm/fixmap.h>
>>>  #include <asm/kasan.h>
>>>  #include <asm/kernel-pgtable.h>
>>> +#include <asm/kexec.h>
>>>  #include <asm/memory.h>
>>>  #include <asm/numa.h>
>>>  #include <asm/sections.h>
>>> @@ -61,66 +62,11 @@ EXPORT_SYMBOL(memstart_addr);
>>>   */
>>>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>  
>>> -#ifdef CONFIG_KEXEC_CORE
>>> -/*
>>> - * reserve_crashkernel() - reserves memory for crash kernel
>>> - *
>>> - * This function reserves memory area given in "crashkernel=" kernel command
>>> - * line parameter. The memory reserved is used by dump capture kernel when
>>> - * primary kernel is crashing.
>>> - */
>>> +#ifndef CONFIG_KEXEC_CORE
>>>  static void __init reserve_crashkernel(void)
>>>  {
>> [...]
>>>  }
>>> +#endif
>> Can we not have the dummy reserve_crashkernel() in the generic code as
>> well and avoid the #ifndef here?
> You mean put the dummy reserve_crashkernel() and the relate function declaration in some generic header?
>  
> Baoquan also mentioned about this.
> Now all the arch that support kdump have the dummy reserve_crashkernel() and
> function declaration, such as arm/arm64/ppc/s390..
>
> But currently different arch may have different CONFIG and different function declaration about this,
> for example,
>
> for s390,
> static void __init reserve_crashkernel(void)
> {                  
> #ifdef CONFIG_CRASH_DUMP
> ...
> #endif        
> }
>
> for ppc,
> #ifdef CONFIG_KEXEC_CORE
> extern void reserve_crashkernel(void);
> #else
> static inline void reserve_crashkernel(void) { ; }
> #endif
>
> If we move these to generic header we need think about:
> 1. the related config in different arch
> 2. function declaration(static/non static)
>
> As Baoquan said in patch 9, how about leave with it for now and i try to solve this later?
>
>>>  #ifdef CONFIG_CRASH_DUMP
>>>  static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
>>> @@ -446,6 +392,14 @@ void __init bootmem_init(void)
>>>  	 * reserved, so do it here.
>>>  	 */
>>>  	reserve_crashkernel();
>>> +#ifdef CONFIG_KEXEC_CORE
>>> +	/*
>>> +	 * The low region is intended to be used for crash dump kernel devices,
>>> +	 * just mark the low region as "nomap" simply.
>>> +	 */
>>> +	if (crashk_low_res.end)
>>> +		memblock_mark_nomap(crashk_low_res.start, resource_size(&crashk_low_res));
>>> +#endif
>> Do we do something similar for crashk_res?
> Not. In the primary kernel(production kernel), we need to use crashk_res memory for crash kernel
> elf core header, initrd...

Sorry, missed one comma after crash kernel.
Not. In the primary kernel(production kernel), we need to use crashk_res memory for crash kernel,
elf core header, initrd and so on.


>
> Different with this, the crashk_low_res is only for crash dump kernel devices.
>> Also, I can see we call crash_exclude_mem_range() only for crashk_res.
>> Do we need to do this for crashk_low_res as well?
> You are right, i missed about this. Will do in next version.
>
> Thanks,
> Chen Zhou


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

WARNING: multiple messages have this Message-ID (diff)
From: chenzhou <chenzhou10@huawei.com>
To: Catalin Marinas <catalin.marinas@arm.com>, bhe@redhat.com
Cc: wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org,
	bhsharma@redhat.com, huawei.libin@huawei.com,
	guohanjun@huawei.com, will@kernel.org, corbet@lwn.net,
	mingo@redhat.com, dyoung@redhat.com, John.P.donnelly@oracle.com,
	arnd@arndb.de, xiexiuqi@huawei.com, horms@verge.net.au,
	tglx@linutronix.de, linux-arm-kernel@lists.infradead.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	robh+dt@kernel.org, james.morse@arm.com, nsaenzjulienne@suse.de,
	prabhakar.pkin@gmail.com, rppt@kernel.org
Subject: Re: [PATCH v14 08/11] arm64: kdump: reimplement crashkernel=X
Date: Fri, 26 Feb 2021 18:43:07 +0800	[thread overview]
Message-ID: <4722d365-154b-d3bb-3897-92f229e8e84f@huawei.com> (raw)
In-Reply-To: <94cc9191-4eff-355f-ff02-1c5da416960e@huawei.com>



On 2021/2/26 18:31, chenzhou wrote:
>
> On 2021/2/25 0:04, Catalin Marinas wrote:
>> On Sat, Jan 30, 2021 at 03:10:22PM +0800, Chen Zhou wrote:
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>>> will fail when there is no enough low memory.
>>> 2. If reserving crashkernel above 4G, in this case, crash dump
>>> kernel will boot failure because there is no low memory available
>>> for allocation.
>>>
>>> To solve these issues, change the behavior of crashkernel=X and
>>> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation
>>> in DMA zone, and fall back to high allocation if it fails.
>>> We can also use "crashkernel=X,high" to select a region above DMA zone,
>>> which also tries to allocate at least 256M in DMA zone automatically.
>>> "crashkernel=Y,low" can be used to allocate specified size low memory.
>>>
>>> Another minor change, there may be two regions reserved for crash
>>> dump kernel, in order to distinct from the high region and make no
>>> effect to the use of existing kexec-tools, rename the low region as
>>> "Crash kernel (low)".
>> I think we discussed this but I don't remember the conclusion. Is this
>> only renamed conditionally so that we don't break current kexec-tools?
> Yes.
>> IOW, assuming that the full crashkernel region is reserved below 4GB,
>> does the "(low)" suffix still appear or it's only if a high region is
>> additionally reserved?
> Suffix "low" only appear if a high region is additionally reserved.
>>> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
>>> index 3f6ecae0bc68..f0caed0cb5e1 100644
>>> --- a/arch/arm64/include/asm/kexec.h
>>> +++ b/arch/arm64/include/asm/kexec.h
>>> @@ -96,6 +96,10 @@ static inline void crash_prepare_suspend(void) {}
>>>  static inline void crash_post_resume(void) {}
>>>  #endif
>>>  
>>> +#ifdef CONFIG_KEXEC_CORE
>>> +extern void __init reserve_crashkernel(void);
>>> +#endif
>> Why not have this in some generic header?
>>
>>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>>> index c18aacde8bb0..69c592c546de 100644
>>> --- a/arch/arm64/kernel/setup.c
>>> +++ b/arch/arm64/kernel/setup.c
>>> @@ -238,7 +238,18 @@ static void __init request_standard_resources(void)
>>>  		    kernel_data.end <= res->end)
>>>  			request_resource(res, &kernel_data);
>>>  #ifdef CONFIG_KEXEC_CORE
>>> -		/* Userspace will find "Crash kernel" region in /proc/iomem. */
>>> +		/*
>>> +		 * Userspace will find "Crash kernel" or "Crash kernel (low)"
>>> +		 * region in /proc/iomem.
>>> +		 * In order to distinct from the high region and make no effect
>>> +		 * to the use of existing kexec-tools, rename the low region as
>>> +		 * "Crash kernel (low)".
>>> +		 */
>>> +		if (crashk_low_res.end && crashk_low_res.start >= res->start &&
>>> +				crashk_low_res.end <= res->end) {
>>> +			crashk_low_res.name = "Crash kernel (low)";
>>> +			request_resource(res, &crashk_low_res);
>>> +		}
>>>  		if (crashk_res.end && crashk_res.start >= res->start &&
>>>  		    crashk_res.end <= res->end)
>>>  			request_resource(res, &crashk_res);
>> My reading of the new generic reserve_crashkernel() is that
>> crashk_low_res will only be populated if crask_res is above 4GB. If
>> that's correct, I'm fine with the renaming here since current systems
>> would not get a renamed low reservation (as long as they don't change
>> the kernel cmdline).
>>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 912f64f505f7..d20f5c444ebf 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -35,6 +35,7 @@
>>>  #include <asm/fixmap.h>
>>>  #include <asm/kasan.h>
>>>  #include <asm/kernel-pgtable.h>
>>> +#include <asm/kexec.h>
>>>  #include <asm/memory.h>
>>>  #include <asm/numa.h>
>>>  #include <asm/sections.h>
>>> @@ -61,66 +62,11 @@ EXPORT_SYMBOL(memstart_addr);
>>>   */
>>>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>  
>>> -#ifdef CONFIG_KEXEC_CORE
>>> -/*
>>> - * reserve_crashkernel() - reserves memory for crash kernel
>>> - *
>>> - * This function reserves memory area given in "crashkernel=" kernel command
>>> - * line parameter. The memory reserved is used by dump capture kernel when
>>> - * primary kernel is crashing.
>>> - */
>>> +#ifndef CONFIG_KEXEC_CORE
>>>  static void __init reserve_crashkernel(void)
>>>  {
>> [...]
>>>  }
>>> +#endif
>> Can we not have the dummy reserve_crashkernel() in the generic code as
>> well and avoid the #ifndef here?
> You mean put the dummy reserve_crashkernel() and the relate function declaration in some generic header?
>  
> Baoquan also mentioned about this.
> Now all the arch that support kdump have the dummy reserve_crashkernel() and
> function declaration, such as arm/arm64/ppc/s390..
>
> But currently different arch may have different CONFIG and different function declaration about this,
> for example,
>
> for s390,
> static void __init reserve_crashkernel(void)
> {                  
> #ifdef CONFIG_CRASH_DUMP
> ...
> #endif        
> }
>
> for ppc,
> #ifdef CONFIG_KEXEC_CORE
> extern void reserve_crashkernel(void);
> #else
> static inline void reserve_crashkernel(void) { ; }
> #endif
>
> If we move these to generic header we need think about:
> 1. the related config in different arch
> 2. function declaration(static/non static)
>
> As Baoquan said in patch 9, how about leave with it for now and i try to solve this later?
>
>>>  #ifdef CONFIG_CRASH_DUMP
>>>  static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
>>> @@ -446,6 +392,14 @@ void __init bootmem_init(void)
>>>  	 * reserved, so do it here.
>>>  	 */
>>>  	reserve_crashkernel();
>>> +#ifdef CONFIG_KEXEC_CORE
>>> +	/*
>>> +	 * The low region is intended to be used for crash dump kernel devices,
>>> +	 * just mark the low region as "nomap" simply.
>>> +	 */
>>> +	if (crashk_low_res.end)
>>> +		memblock_mark_nomap(crashk_low_res.start, resource_size(&crashk_low_res));
>>> +#endif
>> Do we do something similar for crashk_res?
> Not. In the primary kernel(production kernel), we need to use crashk_res memory for crash kernel
> elf core header, initrd...

Sorry, missed one comma after crash kernel.
Not. In the primary kernel(production kernel), we need to use crashk_res memory for crash kernel,
elf core header, initrd and so on.


>
> Different with this, the crashk_low_res is only for crash dump kernel devices.
>> Also, I can see we call crash_exclude_mem_range() only for crashk_res.
>> Do we need to do this for crashk_low_res as well?
> You are right, i missed about this. Will do in next version.
>
> Thanks,
> Chen Zhou


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

  reply	other threads:[~2021-02-26 10:44 UTC|newest]

Thread overview: 126+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30  7:10 [PATCH v14 00/11] support reserving crashkernel above 4G on arm64 kdump Chen Zhou
2021-01-30  7:10 ` Chen Zhou
2021-01-30  7:10 ` Chen Zhou
2021-01-30  7:10 ` [PATCH v14 01/11] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-18  3:29   ` Baoquan He
2021-02-18  3:29     ` Baoquan He
2021-02-24 14:19   ` Catalin Marinas
2021-02-24 14:19     ` Catalin Marinas
2021-02-24 14:19     ` Catalin Marinas
2021-02-25  7:25     ` Baoquan He
2021-02-25  7:25       ` Baoquan He
2021-02-25  7:25       ` Baoquan He
2021-02-26  6:45       ` chenzhou
2021-02-26  6:45         ` chenzhou
2021-02-26  6:45         ` chenzhou
2021-02-26 15:38         ` Eric W. Biederman
2021-02-26 15:38           ` Eric W. Biederman
2021-02-26 15:38           ` Eric W. Biederman
2021-03-02  7:43           ` Baoquan He
2021-03-02  7:43             ` Baoquan He
2021-03-02  7:43             ` Baoquan He
2021-03-29  2:34             ` chenzhou
2021-03-29  2:34               ` chenzhou
2021-03-29  2:34               ` chenzhou
2021-01-30  7:10 ` [PATCH v14 02/11] x86: kdump: make the lower bound of crash kernel reservation consistent Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-18  3:33   ` Baoquan He
2021-02-18  3:33     ` Baoquan He
2021-02-24 14:35   ` Catalin Marinas
2021-02-24 14:35     ` Catalin Marinas
2021-02-24 14:35     ` Catalin Marinas
2021-02-25  7:08     ` Baoquan He
2021-02-25  7:08       ` Baoquan He
2021-02-25  7:08       ` Baoquan He
2021-02-25 14:42       ` Catalin Marinas
2021-02-25 14:42         ` Catalin Marinas
2021-02-25 14:42         ` Catalin Marinas
2021-02-25 15:44         ` Baoquan He
2021-02-25 15:44           ` Baoquan He
2021-02-25 15:44           ` Baoquan He
2021-02-26  7:32           ` chenzhou
2021-02-26  7:32             ` chenzhou
2021-02-26  7:32             ` chenzhou
2021-01-30  7:10 ` [PATCH v14 03/11] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel() Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-18  8:23   ` Baoquan He
2021-02-18  8:23     ` Baoquan He
2021-02-18  8:23     ` Baoquan He
2021-01-30  7:10 ` [PATCH v14 04/11] x86: kdump: move xen_pv_domain() check and insert_resource() to setup_arch() Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-18  4:14   ` Baoquan He
2021-02-18  4:14     ` Baoquan He
2021-01-30  7:10 ` [PATCH v14 05/11] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10 ` [PATCH v14 06/11] x86/elf: Move vmcore_elf_check_arch_cross to arch/x86/include/asm/elf.h Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-18  6:31   ` Baoquan He
2021-02-18  6:31     ` Baoquan He
2021-02-18  6:31     ` Baoquan He
2021-02-18  7:05     ` chenzhou
2021-02-18  7:05       ` chenzhou
2021-02-18  7:05       ` chenzhou
2021-01-30  7:10 ` [PATCH v14 07/11] arm64: kdump: introduce some macroes for crash kernel reservation Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-04 16:20   ` Nicolas Saenz Julienne
2021-02-04 16:20     ` Nicolas Saenz Julienne
2021-02-04 16:20     ` Nicolas Saenz Julienne
2021-02-04 16:27     ` Nicolas Saenz Julienne
2021-02-04 16:27       ` Nicolas Saenz Julienne
2021-02-04 16:27       ` Nicolas Saenz Julienne
2021-01-30  7:10 ` [PATCH v14 08/11] arm64: kdump: reimplement crashkernel=X Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-24 16:04   ` Catalin Marinas
2021-02-24 16:04     ` Catalin Marinas
2021-02-24 16:04     ` Catalin Marinas
2021-02-26 10:31     ` chenzhou
2021-02-26 10:31       ` chenzhou
2021-02-26 10:31       ` chenzhou
2021-02-26 10:43       ` chenzhou [this message]
2021-02-26 10:43         ` chenzhou
2021-02-26 10:43         ` chenzhou
2021-01-30  7:10 ` [PATCH v14 09/11] x86, arm64: Add ARCH_WANT_RESERVE_CRASH_KERNEL config Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-02-18  7:31   ` Baoquan He
2021-02-18  7:31     ` Baoquan He
2021-02-18  7:31     ` Baoquan He
2021-02-18  7:40     ` Baoquan He
2021-02-18  7:40       ` Baoquan He
2021-02-18  7:40       ` Baoquan He
2021-02-18  8:35   ` Baoquan He
2021-02-18  8:35     ` Baoquan He
2021-02-18  8:35     ` Baoquan He
2021-02-20  3:22     ` chenzhou
2021-02-20  3:22       ` chenzhou
2021-02-20  3:22       ` chenzhou
2021-01-30  7:10 ` [PATCH v14 10/11] arm64: kdump: add memory for devices by DT property linux,usable-memory-range Chen Zhou
2021-01-30  7:10   ` [PATCH v14 10/11] arm64: kdump: add memory for devices by DT property linux, usable-memory-range Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10 ` [PATCH v14 11/11] kdump: update Documentation about crashkernel Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30  7:10   ` Chen Zhou
2021-01-30 17:53   ` Randy Dunlap
2021-01-30 17:53     ` Randy Dunlap
2021-01-30 17:53     ` Randy Dunlap
2021-02-04  1:53     ` chenzhou
2021-02-04  1:53       ` chenzhou
2021-02-04  1:53       ` chenzhou
2021-02-18  8:40   ` Baoquan He
2021-02-18  8:40     ` Baoquan He
2021-02-18  8:40     ` Baoquan He
2021-02-20  3:25     ` chenzhou
2021-02-20  3:25       ` chenzhou
2021-02-20  3:25       ` chenzhou
2021-02-08  6:46 ` [PATCH v14 00/11] support reserving crashkernel above 4G on arm64 kdump chenzhou
2021-02-08  6:46   ` chenzhou
2021-02-08  6:46   ` chenzhou

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=4722d365-154b-d3bb-3897-92f229e8e84f@huawei.com \
    --to=chenzhou10@huawei.com \
    --cc=John.P.donnelly@oracle.com \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dyoung@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=horms@verge.net.au \
    --cc=huawei.libin@huawei.com \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=prabhakar.pkin@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=xiexiuqi@huawei.com \
    /path/to/YOUR_REPLY

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

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