[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1901292059260.1950@nanos.tec.linutronix.de>
Date: Tue, 29 Jan 2019 21:05:43 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Baoquan He <bhe@...hat.com>
cc: linux-kernel@...r.kernel.org, mingo@...nel.org, bp@...en8.de,
hpa@...or.com, kirill.shutemov@...ux.intel.com, dyoung@...hat.com,
x86@...nel.org, kexec@...ts.infradead.org
Subject: Re: [PATCH RESEND 1/3] x86/boot: Add bit fields into xloadflags for
5-level kernel checking
On Fri, 25 Jan 2019, Baoquan He wrote:
> Add two bit fields XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel.
These are not bit fields. These are simple bits.
> 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.
I'm confused.
> - .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
So this actually stores the bits, but looking at the following patch which
fixes the real issue:
> + 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;
> + }
So what is XLF_5LEVEL_ENABLED used for and why does it exist at all?
Thanks,
tglx
Powered by blists - more mailing lists