From: tip-bot for Baoquan He <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: hpa@zytor.com, kirill.shutemov@linux.intel.com, bhe@redhat.com,
mingo@kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de
Subject: [tip:x86/boot] x86/boot: Add xloadflags bits to check for 5-level paging support
Date: Thu, 27 Jun 2019 22:19:08 -0700 [thread overview]
Message-ID: <tip-f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0@git.kernel.org> (raw)
In-Reply-To: <20190524073810.24298-2-bhe@redhat.com>
Commit-ID: f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0
Gitweb: https://git.kernel.org/tip/f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0
Author: Baoquan He <bhe@redhat.com>
AuthorDate: Fri, 24 May 2019 15:38:08 +0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 28 Jun 2019 07:14:59 +0200
x86/boot: Add xloadflags bits to check for 5-level paging support
The current kernel supports 5-level paging mode, and supports dynamically
choosing the paging mode during bootup depending on the kernel image,
hardware and kernel parameter settings. This flexibility brings several
issues to kexec/kdump:
1) Dynamic switching between paging modes requires support in the target
kernel. This means kexec from a 5-level paging kernel into a kernel
which does not support mode switching is not possible. So the loader
needs to be able to analyze the supported paging modes of the kexec
target kernel.
2) If running on a 5-level paging kernel and the kexec target kernel is a
4-level paging kernel, the target immage cannot be loaded above the 64TB
address space limit. But the kexec loader searches for a load area from
top to bottom which would eventually put the target kernel above 64TB
when the machine has large enough RAM size. So the loader needs to be
able to analyze the paging mode of the target kernel to load it at a
suitable spot in the address space.
Solution:
Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED:
- Bit XLF_5LEVEL indicates whether 5-level paging mode switching support
is available. (Issue #1)
- Bit XLF_5LEVEL_ENABLED indicates whether the kernel was compiled with
full 5-level paging support (CONFIG_X86_5LEVEL=y). (Issue #2)
The loader will use these bits to verify whether the target kernel is
suitable to be kexec'ed to from a 5-level paging kernel and to determine
the constraints of the target kernel load address.
The flags will be used by the kernel kexec subsystem and the userspace
kexec tools.
[ tglx: Massaged changelog ]
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: bp@alien8.de
Cc: hpa@zytor.com
Cc: dyoung@redhat.com
Link: https://lkml.kernel.org/r/20190524073810.24298-2-bhe@redhat.com
---
| 12 +++++++++++-
arch/x86/include/uapi/asm/bootparam.h | 2 ++
2 files changed, 13 insertions(+), 1 deletion(-)
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889..be19f4199727 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -419,7 +419,17 @@ xloadflags:
# define XLF4 0
#endif
- .word XLF0 | XLF1 | XLF23 | XLF4
+#ifdef CONFIG_X86_64
+#ifdef CONFIG_X86_5LEVEL
+#define XLF56 (XLF_5LEVEL|XLF_5LEVEL_ENABLED)
+#else
+#define XLF56 XLF_5LEVEL
+#endif
+#else
+#define XLF56 0
+#endif
+
+ .word XLF0 | XLF1 | XLF23 | XLF4 | XLF56
cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line,
#added with boot protocol
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 60733f137e9a..c895df5482c5 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -29,6 +29,8 @@
#define XLF_EFI_HANDOVER_32 (1<<2)
#define XLF_EFI_HANDOVER_64 (1<<3)
#define XLF_EFI_KEXEC (1<<4)
+#define XLF_5LEVEL (1<<5)
+#define XLF_5LEVEL_ENABLED (1<<6)
#ifndef __ASSEMBLY__
next prev parent reply other threads:[~2019-06-28 5:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-24 7:38 [PATCH v5 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel Baoquan He
2019-05-24 7:38 ` [PATCH v5 1/3] x86/boot: Add xloadflags bits for 5-level kernel checking Baoquan He
2019-06-28 5:19 ` tip-bot for Baoquan He [this message]
2019-05-24 7:38 ` [PATCH v5 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel Baoquan He
2019-06-28 5:19 ` [tip:x86/boot] x86/kexec/64: Prevent kexec from 5-level paging to a 4-level only kernel tip-bot for Baoquan He
2019-05-24 7:38 ` [PATCH v5 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation Baoquan He
2019-06-28 5:20 ` [tip:x86/boot] x86/kdump/64: Restrict kdump kernel reservation to <64TB tip-bot for Baoquan He
2019-06-11 5:47 ` [PATCH v5 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel 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=tip-f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0@git.kernel.org \
--to=tipbot@zytor.com \
--cc=bhe@redhat.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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
Powered by JetHome