From: Dave Young <dyoung@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org, vgoyal@redhat.com,
bhe@redhat.com, piliu@redhat.com, Yinghai Lu <yinghai@kernel.org>,
Eric Biederman <ebiederm@xmission.com>
Subject: [PATCH 1/2] X86/kdump: move crashkernel=X to reserve under 4G by default
Date: Sun, 21 Apr 2019 11:50:59 +0800 [thread overview]
Message-ID: <20190421035058.943630505@redhat.com> (raw)
The kdump crashkernel low reservation is limited to under 896M even for
X86_64. This obscure and miserable limitation exists for old kexec-tools
compatibility, but the reason is not documented anywhere.
Some more tests/investigations about the background:
a) Previously old kexec-tools can only load purgatory to memory under 2G,
Eric remove that limitation in 2012 in kexec-tools:
Commit b4f9f8599679 ("kexec x86_64: Make purgatory relocatable anywhere
in the 64bit address space.")
b) back in 2013 Yinghai removed all the limitations in new kexec-tools,
bzImage64 can be loaded to anywhere.
Commit 82c3dd2280d2 ("kexec, x86_64: Load bzImage64 above 4G")
c) test results with old kexec-tools with old and latest kernels.
1. old kexec-tools can not build with modern toolchain anymore,
I built it in a RHEL6 vm
2. 2.0.0 kexec-tools does not work with latest kernel even with
memory under 896M and give an error:
"ELF core (kcore) parse failed", it needs below kexec-tools fix
Commit ed15ba1b9977 ("build_mem_phdrs(): check if p_paddr is invalid")
3. even with patched kexec-tools which fixes 2), it still needs some
other fixes to work correctly for kaslr enabled kernels.
So the situation is:
* old kexec-tools is already broken with latest kernels
* we can not keep this limitations forever just for compatibility of very
old kexec-tools.
* If one must use old tools then he/she can choose crashkernel=X@Y
* people have reported bugs crashkernel=384M failed because kaslr makes
the 0-896M space sparse,
* crashkernel can reserve in low or high area, it is natural to understand
low as memory under 4G
Hence drop the 896M limitation, and change crashkernel low reservation to
reserve under 4G by default.
Signed-off-by: Dave Young <dyoung@redhat.com>
---
arch/x86/kernel/setup.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -71,6 +71,7 @@
#include <linux/tboot.h>
#include <linux/jiffies.h>
#include <linux/mem_encrypt.h>
+#include <linux/sizes.h>
#include <linux/usb/xhci-dbgp.h>
#include <video/edid.h>
@@ -448,18 +449,17 @@ static void __init memblock_x86_reserve_
#ifdef CONFIG_KEXEC_CORE
/* 16M alignment for crash kernel regions */
-#define CRASH_ALIGN (16 << 20)
+#define CRASH_ALIGN SZ_16M
/*
* Keep the crash kernel below this limit. On 32 bits earlier kernels
* would limit the kernel to the low 512 MiB due to mapping restrictions.
- * On 64bit, old kexec-tools need to under 896MiB.
*/
#ifdef CONFIG_X86_32
-# define CRASH_ADDR_LOW_MAX (512 << 20)
-# define CRASH_ADDR_HIGH_MAX (512 << 20)
+# define CRASH_ADDR_LOW_MAX SZ_512M
+# define CRASH_ADDR_HIGH_MAX SZ_512M
#else
-# define CRASH_ADDR_LOW_MAX (896UL << 20)
+# define CRASH_ADDR_LOW_MAX SZ_4G
# define CRASH_ADDR_HIGH_MAX MAXMEM
#endif
next reply other threads:[~2019-04-21 3:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 3:50 Dave Young [this message]
2019-04-21 3:51 ` [PATCH 2/2] X86/kdump: fall back to reserve high crashkernel memory Dave Young
2019-04-21 18:26 ` Ingo Molnar
2019-04-22 3:03 ` Dave Young
2019-04-22 3:19 ` [PATCH 2/2 update] " Dave Young
2019-04-22 3:29 ` Baoquan He
2019-04-22 8:28 ` [tip:x86/kdump] x86/kdump: Fall " tip-bot for Dave Young
2019-04-21 18:24 ` [PATCH 1/2] X86/kdump: move crashkernel=X to reserve under 4G by default Ingo Molnar
2019-04-22 8:28 ` [tip:x86/kdump] x86/kdump: Have crashkernel=X " tip-bot for Dave Young
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=20190421035058.943630505@redhat.com \
--to=dyoung@redhat.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=piliu@redhat.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox