On Tue, 22 Nov 2022 at 22:51, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > > On 11/22/22 15:42, Ard Biesheuvel wrote: > > On Tue, 22 Nov 2022 at 22:37, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > >> > >> On Tue, 22 Nov 2022 at 21:48, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > >>> > >>> On 11/22/22 10:10, Ard Biesheuvel wrote: > >>>> After doing some cleanup work on the EFI code in head_64.S, the mixed > >>>> mode code in particular, I noticed that the memory encryption pieces > >>>> could use some attention as well, so I cleaned that up too. > >>>> > >>>> Changes since v2: > >>>> - add some clarifying comments to the EFI mixed mode changes > >>>> - include patch to make the EFI handover protocol optional that was sent > >>>> out separately before > >>>> - rebase onto tip/master > >>>> > >>>> Changes since v1: > >>>> - at Boris's request, split the patches into smaller ones that are > >>>> easier to review > >>>> > >>>> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > >>>> Cc: Ingo Molnar <mingo@xxxxxxxxxx> > >>>> Cc: Borislav Petkov <bp@xxxxxxxxx> > >>>> Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > >>>> Cc: Michael Roth <michael.roth@xxxxxxx> > >>> > >>> This causes an SEV guest to blow up on boot in the early boot code. It > >>> looks like the stack pointer is not valid and it triple faults on a pushq > >>> instruction (pushq $__KERNEL_CS in arch/x86/boot/compressed/head_64.S of > >>> startup_64). > >>> > >> > >> Thanks for the report. > >> > >> So the mystery here (at least to me) is that all the changes are to > >> the 32-bit code, and startup_64 reloads the stack pointer from the > >> symbol > >> > >> Does your config have CONFIG_EFI_MIXED enabled? > >> > >> Can I reproduce this fully emulated with QEMU? Or do I need a SEV host? > >> > > > > Also, mind giving this a quick spin? > > Just saw this after I sent out my email. Yes, this fixes it. > Excellent, thanks for testing.
