From: Catalin Marinas <catalin.marinas@arm.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org,
bhsharma@redhat.com, huawei.libin@huawei.com,
guohanjun@huawei.com, will@kernel.org, bhe@redhat.com,
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, rppt@kernel.org, prabhakar.pkin@gmail.com,
nsaenzjulienne@suse.de
Subject: Re: [PATCH v14 08/11] arm64: kdump: reimplement crashkernel=X
Date: Wed, 24 Feb 2021 16:04:08 +0000 [thread overview]
Message-ID: <20210224160408.GC28965@arm.com> (raw)
In-Reply-To: <20210130071025.65258-9-chenzhou10@huawei.com>
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?
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?
> 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?
> #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?
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?
--
Catalin
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: mingo@redhat.com, tglx@linutronix.de, rppt@kernel.org,
dyoung@redhat.com, bhe@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: Wed, 24 Feb 2021 16:04:08 +0000 [thread overview]
Message-ID: <20210224160408.GC28965@arm.com> (raw)
In-Reply-To: <20210130071025.65258-9-chenzhou10@huawei.com>
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?
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?
> 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?
> #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?
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?
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Chen Zhou <chenzhou10@huawei.com>
Cc: wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org,
bhsharma@redhat.com, huawei.libin@huawei.com,
guohanjun@huawei.com, will@kernel.org, bhe@redhat.com,
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, rppt@kernel.org, prabhakar.pkin@gmail.com,
nsaenzjulienne@suse.de
Subject: Re: [PATCH v14 08/11] arm64: kdump: reimplement crashkernel=X
Date: Wed, 24 Feb 2021 16:04:08 +0000 [thread overview]
Message-ID: <20210224160408.GC28965@arm.com> (raw)
In-Reply-To: <20210130071025.65258-9-chenzhou10@huawei.com>
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?
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?
> 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?
> #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?
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?
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-24 16:04 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 [this message]
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
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 ` 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 ` [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=20210224160408.GC28965@arm.com \
--to=catalin.marinas@arm.com \
--cc=John.P.donnelly@oracle.com \
--cc=arnd@arndb.de \
--cc=bhe@redhat.com \
--cc=bhsharma@redhat.com \
--cc=chenzhou10@huawei.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.