[PATCH v4 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel

[PATCH v4 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel

[Baoquan He]

This patchset is trying to fix several issues for kexec/kdump when
dynamic switching of paging mode is enabled in x86_64. The current
kernel supports 5-level paging mode, and supports dynamically choosing
paging mode during bootup according to kernel image, hardware and
kernel parameter setting. This flexibility brings several issues for
kexec/kdump:

Issues:
1)
Dynamic switching between paging mode requires code change in target
kernel. So we can't kexec jump from 5-level kernel to old 4-level
kernel which lacks the code change.

2)
Switching from 5-level paging to 4-level paging kernel would fail, if
kexec() put kernel image above 64TiB of memory.

3)
Kdump jumping has similar issue as 2). This require us to only
reserve crashkernel below 64TB, otherwise jumping from 5-level to
4-level kernel will fail.

Note:
Since we have two interfaces kexec_load() and kexec_file_load() to load
kexec/kdump kernel, handling for them is a little different. For
kexec_load(), most of the loading job is done in user space utility
kexec_tools. However, for kexec_file_load(), most of the loading codes
have moved into kernel because of kernel image verification.

Fixes:
a) For issue 1), we need check if XLF_5LEVEL is set, otherwise error out
   a message.
  -This need be done in both kernel and kexec_tools utility.
  -Patch 2/3 is the handling of kernel part.
  -Will post user space patch to kexec mailing list later.

b) For issue 2), we need check if both XLF_5LEVEL and XLF_5LEVEL_ENABLED
   are set, otherwise error out a message.
  -This only need be done in kexec_tools utility. Because for
   kexec_file_load(), the current code searches area to put kernel from
   bottom to up in system RAM, we usually can always find an area below
   4 GB, no need to worry about 5-level kernel jumping to 4-level
   kernel. While for kexec_load(), it's top down seraching area for kernel
   loading, and implemented in user space. We need make sure that
   5-level kernel find an area under 64 TB for a kexec-ed kernel of
   4-level.
  -Will post user space patch to kexec mailing list later.

c) For issues 3), just limit kernel to reserve crashkernel below 64 TB.
  -This only need be done in kernel.
  -It doesn't need to check bit XLF_5LEVEL or XLF_5LEVEL_ENABLED, we
   just simply limit it below 64 TB which should be enough. Because
   crashernel is reserved during the 1st kernel's bootup, we don't know
   what kernel will be loaded for kdump usage.
  -Patch 3/3 handles this.

Changelog:
v3->v4:
  No functional change.
  - Rewrite log of patch 1/3 tell who the newly added bits are gonna be
    used.
  - Rewrite log of patch 2/3 per tglx's words.
  - Add Kirill's Acked-by.
  
  
v2->v3:
  Change the constant to match the notation for the rest of defines as
  Kirill suggested;
v1->v2:
  Correct the subject of patch 1 according to tglx's comment;
  Add more information to cover-letter to address reviewers' concerns;

The original v1 post can be found here:
http://lkml.kernel.org/r/20180829141624.13985-1-bhe@redhat.com

Later a v1 RESEND version:
http://lkml.kernel.org/r/20190125022817.29506-1-bhe@redhat.com

V2 post is here:
http://lkml.kernel.org/r/20190312005004.19182-1-bhe@redhat.com

v3 post:
http://lkml.kernel.org/r/20190312103051.18086-1-bhe@redhat.com

Baoquan He (3):
  x86/boot: Add xloadflags bits for 5-level kernel checking
  x86/kexec/64: Error out if try to jump to old 4-level kernel from
    5-level kernel
  x86/kdump/64: Change the upper limit of crashkernel reservation

 arch/x86/boot/header.S                | 12 +++++++++++-
 arch/x86/include/uapi/asm/bootparam.h |  2 ++
 arch/x86/kernel/kexec-bzimage64.c     |  5 +++++
 arch/x86/kernel/setup.c               | 17 ++++++++++++++---
 4 files changed, 32 insertions(+), 4 deletions(-)

-- 
2.17.2

[PATCH v4 1/3] x86/boot: Add xloadflags bits for 5-level kernel checking

[Baoquan He]

The current kernel supports 5-level paging mode, and supports dynamically
choosing paging mode during bootup according to kernel image, hardware and
kernel parameter setting. This flexibility brings several issues to
kexec/kdump:
1)
Dynamic switching between paging modes requires code change in target
kernel. So we can't do kexec-jumping from 5-level kernel to old 4-level
kernel which lacks the code change.

2)
Kexec jumping from 5-level kernel to 4-level kernel would fail, if kexec
loading puts kernel image above 64 TB of memory. Because kexec loading
searches area to put kernel from top to down in system RAM, the 2nd kernel
will be loaded above 64 TB if the amount of system RAM is bigger than 64
TB. Here no need to worry about kexec_file loading, because it searches
area from bottom to up, and can always find area below 4 GB.

Solution:

Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel.
- Bit XLF_5LEVEL indicates if 5-level related code is contained in this
  kernel.
- Bit XLF_5LEVEL_ENABLED indicates if CONFIG_X86_5LEVEL=y is set.

a) For issue 1), need check if XLF_5LEVEL is set, otherwise print out error
   message.
  - This checking need be added in kernel, for the code of kexec_file
    loading;
  - And also need be added into kexec_tools utility, for kexec loading.

b) For issue 2), need check if both XLF_5LEVEL and XLF_5LEVEL_ENABLED are
   set, otherwise print out error message.
  - This only need be done in kexec_tools utility, because kexec loading
    does the searching in user space kexec_tools.

So here add XLF_5LEVEL and XLF_5LEVEL_ENABLED into xloadflags. The later
code will check XLF_5LEVEL bit in kexec_file implementation of kernel. And
the kexec_tools code will check both XLF_5LEVEL and XLF_5LEVEL_ENABLED for
kexec loading.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/boot/header.S                | 12 +++++++++++-
 arch/x86/include/uapi/asm/bootparam.h |  2 ++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --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__
 
-- 
2.17.2

[PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

[Baoquan He]

If the running kernel has 5-level paging activated, the 5-level paging
mode is preserved across kexec. If the kexec'ed kernel does not contain
support for handling active 5-level paging mode in the decompressor, the
decompressor will crash with #GP.

Prevent this situation at load time. If 5-level paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out error
message.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/kernel/kexec-bzimage64.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 22f60dd26460..858cc892672f 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long len)
 		return ret;
 	}
 
+	if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
+		pr_err("Can not jump to old 4-level kernel from 5-level kernel.\n");
+		return ret;
+	}
+
 	/* I've got a bzImage */
 	pr_debug("It's a relocatable bzImage64\n");
 	ret = 0;
-- 
2.17.2

[PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation

[Baoquan He]

Restrict kdump to only reserve crashkernel below 64TB.

The reaons is that the kdump may jump from 5-level to 4-level, and if
the kdump kernel is put above 64TB, then the jumping will fail. While the
1st kernel reserves crashkernel region during bootup, we don't know yet
which kind of kernel will be loaded after system bootup, 5-level kernel
or 5-level kernel.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/kernel/setup.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 905dae880563..efb0934a46f6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -452,15 +452,26 @@ static void __init memblock_x86_reserve_range_setup_data(void)
 #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.
+ * 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 be under 896MiB. The later
+ * supports to put kernel above 4G, up to system RAM top. Here
+ * kdump kernel need be restricted to be under 64TB, which is
+ * the upper limit of system RAM in 4-level paing mode. Since
+ * the kdump jumping could be from 5-level to 4-level, the jumping
+ * will fail if kernel is put above 64TB, and there's no way to
+ * detect the paging mode of the kernel which will be loaded for
+ * dumping during the 1st kernel bootup.
  */
 #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	MAXMEM
+# define CRASH_ADDR_HIGH_MAX	(64UL << 40)
 #endif
 
 static int __init reserve_crashkernel_low(void)
-- 
2.17.2

Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

[Baoquan He]

On 05/09/19 at 09:36am, Baoquan He wrote:
> If the running kernel has 5-level paging activated, the 5-level paging
> mode is preserved across kexec. If the kexec'ed kernel does not contain
> support for handling active 5-level paging mode in the decompressor, the
> decompressor will crash with #GP.
> 
> Prevent this situation at load time. If 5-level paging is active, check the
> xloadflags whether the kexec kernel can handle 5-level paging at least in
> the decompressor. If not, reject the load attempt and print out error
> message.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/kernel/kexec-bzimage64.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 22f60dd26460..858cc892672f 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long len)
>  		return ret;
>  	}
>  
> +	if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
> +		pr_err("Can not jump to old 4-level kernel from 5-level kernel.\n");

Check the old thread again, found Thomas also had comment about this
error message. Just forgot updating it. Will update it with a new one.

> +		return ret;
> +	}
> +
>  	/* I've got a bzImage */
>  	pr_debug("It's a relocatable bzImage64\n");
>  	ret = 0;
> -- 
> 2.17.2
> 

[PATCH v5 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

[Baoquan He]

If the running kernel has 5-level paging activated, the 5-level paging
mode is preserved across kexec. If the kexec'ed kernel does not contain
support for handling active 5-level paging mode in the decompressor, the
decompressor will crash with #GP.

Prevent this situation at load time. If 5-level paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out error
message.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
v4->v5:
  Update the output error message per tglx's comment.

 arch/x86/kernel/kexec-bzimage64.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 22f60dd26460..7f439739ea3d 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long len)
 		return ret;
 	}
 
+	if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
+		pr_err("bzImage cannot handle 5-level paging mode.\n");
+		return ret;
+	}
+
 	/* I've got a bzImage */
 	pr_debug("It's a relocatable bzImage64\n");
 	ret = 0;
-- 
2.17.2

Re: [PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation

[Dave Young]

Hi Baoquan,

A few nitpicks, otherwise
Acked-by: Dave Young <dyoung@redhat.com>

On 05/09/19 at 09:36am, Baoquan He wrote:
> Restrict kdump to only reserve crashkernel below 64TB.
> 
> The reaons is that the kdump may jump from 5-level to 4-level, and if
> the kdump kernel is put above 64TB, then the jumping will fail. While the
> 1st kernel reserves crashkernel region during bootup, we don't know yet
> which kind of kernel will be loaded after system bootup, 5-level kernel
> or 5-level kernel.

5-level kernel or 4-level kernel ?
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/kernel/setup.c | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 905dae880563..efb0934a46f6 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -452,15 +452,26 @@ static void __init memblock_x86_reserve_range_setup_data(void)
>  #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.
> + * 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 be under 896MiB. The later
> + * supports to put kernel above 4G, up to system RAM top. Here

Above two lines are not reflected in code because we have removed
the 896M limitation, it would be better to drop the two lines to
avoid confusion. 

> + * kdump kernel need be restricted to be under 64TB, which is
> + * the upper limit of system RAM in 4-level paing mode. Since
> + * the kdump jumping could be from 5-level to 4-level, the jumping
> + * will fail if kernel is put above 64TB, and there's no way to
> + * detect the paging mode of the kernel which will be loaded for
> + * dumping during the 1st kernel bootup.
>   */
>  #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	MAXMEM
> +# define CRASH_ADDR_HIGH_MAX	(64UL << 40)

Maybe add a new macro in sizes.h like SZ_64T

>  #endif
>  
>  static int __init reserve_crashkernel_low(void)
> -- 
> 2.17.2
> 

Thanks
Dave

Re: [PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation

[Baoquan He]

On 05/22/19 at 11:11am, Dave Young wrote:
> Hi Baoquan,
> 
> A few nitpicks, otherwise
> Acked-by: Dave Young <dyoung@redhat.com>
> 
> On 05/09/19 at 09:36am, Baoquan He wrote:
> > Restrict kdump to only reserve crashkernel below 64TB.
> > 
> > The reaons is that the kdump may jump from 5-level to 4-level, and if
> > the kdump kernel is put above 64TB, then the jumping will fail. While the
> > 1st kernel reserves crashkernel region during bootup, we don't know yet
> > which kind of kernel will be loaded after system bootup, 5-level kernel
> > or 5-level kernel.
> 
> 5-level kernel or 4-level kernel ?

Right, it's typo. Should be '5-level kernel or 4-level kernel'. Thanks.

Will update.

> > 
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> >  arch/x86/kernel/setup.c | 17 ++++++++++++++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index 905dae880563..efb0934a46f6 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -452,15 +452,26 @@ static void __init memblock_x86_reserve_range_setup_data(void)
> >  #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.
> > + * 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 be under 896MiB. The later
> > + * supports to put kernel above 4G, up to system RAM top. Here
> 
> Above two lines are not reflected in code because we have removed
> the 896M limitation, it would be better to drop the two lines to
> avoid confusion. 
> 
> > + * kdump kernel need be restricted to be under 64TB, which is
> > + * the upper limit of system RAM in 4-level paing mode. Since
> > + * the kdump jumping could be from 5-level to 4-level, the jumping
> > + * will fail if kernel is put above 64TB, and there's no way to
> > + * detect the paging mode of the kernel which will be loaded for
> > + * dumping during the 1st kernel bootup.
> >   */
> >  #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	MAXMEM
> > +# define CRASH_ADDR_HIGH_MAX	(64UL << 40)
> 
> Maybe add a new macro in sizes.h like SZ_64T
> 
> >  #endif
> >  
> >  static int __init reserve_crashkernel_low(void)
> > -- 
> > 2.17.2
> > 
> 
> Thanks
> Dave

Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

[Dave Young]

On 05/09/19 at 09:36am, Baoquan He wrote:
> If the running kernel has 5-level paging activated, the 5-level paging
> mode is preserved across kexec. If the kexec'ed kernel does not contain
> support for handling active 5-level paging mode in the decompressor, the
> decompressor will crash with #GP.
> 
> Prevent this situation at load time. If 5-level paging is active, check the
> xloadflags whether the kexec kernel can handle 5-level paging at least in
> the decompressor. If not, reject the load attempt and print out error
> message.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/kernel/kexec-bzimage64.c | 5 +++++

How about the userspace kexec-tools?  It needs a similar detection, but
I'm not sure how to detect paging mode, maybe some sysfs entry or
vmcoreinfo in /proc/vmcore


>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 22f60dd26460..858cc892672f 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long len)
>  		return ret;
>  	}
>  
> +	if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
> +		pr_err("Can not jump to old 4-level kernel from 5-level kernel.\n");

4-level kernel sounds not very clear, maybe something like below?

"5-level paging enabled, can not kexec into an old kernel without 5-level
paging facility"?

> +		return ret;
> +	}
> +
>  	/* I've got a bzImage */
>  	pr_debug("It's a relocatable bzImage64\n");
>  	ret = 0;
> -- 
> 2.17.2
> 

Thanks
Dave

Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

[Dave Young]

On 05/22/19 at 11:20am, Dave Young wrote:
> On 05/09/19 at 09:36am, Baoquan He wrote:
> > If the running kernel has 5-level paging activated, the 5-level paging
> > mode is preserved across kexec. If the kexec'ed kernel does not contain
> > support for handling active 5-level paging mode in the decompressor, the
> > decompressor will crash with #GP.
> > 
> > Prevent this situation at load time. If 5-level paging is active, check the
> > xloadflags whether the kexec kernel can handle 5-level paging at least in
> > the decompressor. If not, reject the load attempt and print out error
> > message.
> > 
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> >  arch/x86/kernel/kexec-bzimage64.c | 5 +++++
> 
> How about the userspace kexec-tools?  It needs a similar detection, but
> I'm not sure how to detect paging mode, maybe some sysfs entry or
> vmcoreinfo in /proc/vmcore

meant /proc/kcore ...

Thanks
Dave

Re: [PATCH v4 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel

[Baoquan He]

On 05/22/19 at 11:20am, Dave Young wrote:
> How about the userspace kexec-tools?  It needs a similar detection, but
> I'm not sure how to detect paging mode, maybe some sysfs entry or
> vmcoreinfo in /proc/vmcore

In usersapce, I plan to parse /proc/kcore to get the starting address
of page_offset or vmalloc. You can see the different level has different
value range.

4-level:
   ffff888000000000 | -119.5  TB | ffffc87fffffffff |   64 TB | direct mapping of all physical memory (page_offset_base)
   ffffc88000000000 |  -55.5  TB | ffffc8ffffffffff |  0.5 TB | ... unused hole
   ffffc90000000000 |  -55    TB | ffffe8ffffffffff |   32 TB | vmalloc/ioremap space (vmalloc_base)
   ffffe90000000000 |  -23    TB | ffffe9ffffffffff |    1 TB | ... unused hole
   ffffea0000000000 |  -22    TB | ffffeaffffffffff |    1 TB | virtual memory map (vmemmap_base)


5-level:
   ff11000000000000 |  -59.75 PB | ff90ffffffffffff |   32 PB | direct mapping of all physical memory (page_offset_base)
   ff91000000000000 |  -27.75 PB | ff9fffffffffffff | 3.75 PB | ... unused hole
   ffa0000000000000 |  -24    PB | ffd1ffffffffffff | 12.5 PB | vmalloc/ioremap space (vmalloc_base)
   ffd2000000000000 |  -11.5  PB | ffd3ffffffffffff |  0.5 PB | ... unused hole
   ffd4000000000000 |  -11    PB | ffd5ffffffffffff |  0.5 PB | virtual memory map (vmemmap_base)
> 
> 
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> > index 22f60dd26460..858cc892672f 100644
> > --- a/arch/x86/kernel/kexec-bzimage64.c
> > +++ b/arch/x86/kernel/kexec-bzimage64.c
> > @@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long len)
> >  		return ret;
> >  	}
> >  
> > +	if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
> > +		pr_err("Can not jump to old 4-level kernel from 5-level kernel.\n");
> 
> 4-level kernel sounds not very clear, maybe something like below?
> 
> "5-level paging enabled, can not kexec into an old kernel without 5-level
> paging facility"?

Oops, tglx commented on this message. He suggested changing it like:

	"bzImage cannot handle 5-level paging mode\n"

I forgot updating this part. Any one is fine to me. Will update.

Thanks
Baoquan

Re: [PATCH v4 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation

[Baoquan He]

On 05/22/19 at 11:11am, Dave Young wrote:
> >  /*
> > - * 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.
> > + * 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 be under 896MiB. The later
> > + * supports to put kernel above 4G, up to system RAM top. Here
> 
> Above two lines are not reflected in code because we have removed
> the 896M limitation, it would be better to drop the two lines to
> avoid confusion. 

Missed these comments at bottom of mail.

Yes, will remove these two lines.

> 
> > + * kdump kernel need be restricted to be under 64TB, which is
> > + * the upper limit of system RAM in 4-level paing mode. Since
> > + * the kdump jumping could be from 5-level to 4-level, the jumping
> > + * will fail if kernel is put above 64TB, and there's no way to
> > + * detect the paging mode of the kernel which will be loaded for
> > + * dumping during the 1st kernel bootup.
> >   */
> >  #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	MAXMEM
> > +# define CRASH_ADDR_HIGH_MAX	(64UL << 40)
> 
> Maybe add a new macro in sizes.h like SZ_64T

I am fine, will add and use it here. Thanks.