Re: [PATCH v7 2/9] x86/startup_64: Defer assignment of 5-level paging global variables

[Borislav Petkov]

On Fri, Mar 01, 2024 at 06:09:53PM +0100, Ard Biesheuvel wrote:
> On Fri, 1 Mar 2024 at 17:09, Borislav Petkov <bp@xxxxxxxxx> wrote:
> >
> > On Fri, Mar 01, 2024 at 11:01:33AM +0100, Ard Biesheuvel wrote:
> > > The scenario that I have not managed to test is entering from EFI with
> > > 5 levels of paging enabled, and switching back to 4 levels (which
> > > should work regardless of CONFIG_X86_5LEVEL). However, no firmware in
> > > existence actually supports that today, and I am pretty sure that this
> > > code has never been tested under those conditions to begin with. (OVMF
> > > patches are under review atm to allow 5-level paging to be enabled in
> > > the firmware)
> >
> > Aha.
> >
> 
> I've built a debug OVMF image using the latest version of the series,
> and put it at [0]
> 
> Run like this
> 
> qemu-system-x86_64 -M q35 \
>   -cpu qemu64,+la57 -smp 4 \
>   -bios OVMF-5level.fd \
>   -kernel arch/x86/boot/bzImage \
>   -append console=ttyS0\ earlyprintk=ttyS0 \
>   -vga none -nographic -m 1g \
>   -initrd <initrd.img>
> 
> and you will get loads of DEBUG output from the firmware first, and
> then boot into Linux. (initrd can be omitted)
> 
> Right before entering, it will print
> 
> CpuDxe: 5-Level Paging = 1
> 
> which confirms that the firmware is running with 5 levels of paging.
> 
> I've confirmed that this boots happily with this series applied,
> including when using 'no5lvl' on the command line, or when disabling
> CONFIG_X86_5LEVEL [confirmed by inspecting
> /sys/kernel/debug/page_tables/kernel].
> 
> 
> [0] http://files.workofard.com/OVMF-5level.fd.gz

Nice, that might come in handy for other testing too.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette