Message ID | 20211222130820.1754-2-thunder.leizhen@huawei.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | support reserving crashkernel above 4G on arm64 kdump | expand |
On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote: > From: Chen Zhou <chenzhou10@huawei.com> > > We want to make function reserve_crashkernel[_low](), which is implemented ^^ Please use passive voice in your commit message: no "we" or "I", etc, and describe your changes in imperative mood. Also, pls read section "2) Describe your changes" in Documentation/process/submitting-patches.rst for more details. Bottom line is: personal pronouns are ambiguous in text, especially with so many parties/companies/etc developing the kernel so let's avoid them please. > by X86, available to other architectures. It references macro CRASH_ALIGN "x86" > and will be moved to public crash_core.c. But the defined values of > CRASH_ALIGN may be different in different architectures. So moving the > definition of CRASH_ALIGN to asm/kexec.h is a good choice. > > The reason for moving CRASH_ADDR_{LOW|HIGH}_MAX is the same as above. This commit message needs to say something along the lines of: "Move CRASH_ALIGN and ... to the arch-specific header in preparation of making reserve_crashkernel[_low]() generic, used by other architectures." or so.
On 2021/12/23 4:43, Borislav Petkov wrote: > On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote: >> From: Chen Zhou <chenzhou10@huawei.com> >> >> We want to make function reserve_crashkernel[_low](), which is implemented > ^^ > > Please use passive voice in your commit message: no "we" or "I", etc, > and describe your changes in imperative mood. My bad language habits. I've made this mistake several times. > > Also, pls read section "2) Describe your changes" in > Documentation/process/submitting-patches.rst for more details. > > Bottom line is: personal pronouns are ambiguous in text, especially with > so many parties/companies/etc developing the kernel so let's avoid them > please. OK, I'll check the description of the other patches. > >> by X86, available to other architectures. It references macro CRASH_ALIGN > > "x86" OK > >> and will be moved to public crash_core.c. But the defined values of >> CRASH_ALIGN may be different in different architectures. So moving the >> definition of CRASH_ALIGN to asm/kexec.h is a good choice. >> >> The reason for moving CRASH_ADDR_{LOW|HIGH}_MAX is the same as above. > > This commit message needs to say something along the lines of: > > "Move CRASH_ALIGN and ... to the arch-specific header in preparation > of making reserve_crashkernel[_low]() generic, used by other > architectures." OK, I will use this one, thanks. By the way, patch 0004-0006 were written based on your suggestion. Can you take a moment to review it? I think I forgot to add "Suggested-by". > > or so. >
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h index 11b7c06e2828c30..a0223a6c0238a15 100644 --- a/arch/x86/include/asm/kexec.h +++ b/arch/x86/include/asm/kexec.h @@ -18,6 +18,30 @@ # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 +/* 16M alignment for crash kernel regions */ +#define CRASH_ALIGN SZ_16M + +/* + * Keep the crash kernel below this limit. + * + * Earlier 32-bits kernels would limit the kernel to the low 512 MB range + * due to mapping restrictions. + * + * 64-bit kdump kernels need to be restricted to be under 64 TB, which is + * the upper limit of system RAM in 4-level paging mode. Since the kdump + * jump could be from 5-level paging to 4-level paging, the jump will fail if + * the kernel is put above 64 TB, and during the 1st kernel bootup there's + * no good way to detect the paging mode of the target kernel which will be + * loaded for dumping. + */ +#ifdef CONFIG_X86_32 +# define CRASH_ADDR_LOW_MAX SZ_512M +# define CRASH_ADDR_HIGH_MAX SZ_512M +#else +# define CRASH_ADDR_LOW_MAX SZ_4G +# define CRASH_ADDR_HIGH_MAX SZ_64T +#endif + #ifndef __ASSEMBLY__ #include <linux/string.h> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 6a190c7f4d71b05..ae8f63661363e25 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -392,30 +392,6 @@ static void __init memblock_x86_reserve_range_setup_data(void) #ifdef CONFIG_KEXEC_CORE -/* 16M alignment for crash kernel regions */ -#define CRASH_ALIGN SZ_16M - -/* - * Keep the crash kernel below this limit. - * - * Earlier 32-bits kernels would limit the kernel to the low 512 MB range - * due to mapping restrictions. - * - * 64-bit kdump kernels need to be restricted to be under 64 TB, which is - * the upper limit of system RAM in 4-level paging mode. Since the kdump - * jump could be from 5-level paging to 4-level paging, the jump will fail if - * the kernel is put above 64 TB, and during the 1st kernel bootup there's - * no good way to detect the paging mode of the target kernel which will be - * loaded for dumping. - */ -#ifdef CONFIG_X86_32 -# define CRASH_ADDR_LOW_MAX SZ_512M -# define CRASH_ADDR_HIGH_MAX SZ_512M -#else -# define CRASH_ADDR_LOW_MAX SZ_4G -# define CRASH_ADDR_HIGH_MAX SZ_64T -#endif - static int __init reserve_crashkernel_low(void) { #ifdef CONFIG_X86_64