Re: [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP

[Ard Biesheuvel]

On Tue, 8 Apr 2025 at 17:53, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
>
> On 4/7/25 14:59, Ard Biesheuvel wrote:
> > On Mon, 7 Apr 2025 at 20:05, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
> >>
> >> On 4/7/25 04:25, Kirill A. Shutemov wrote:
> >>> On Fri, Apr 04, 2025 at 08:07:03AM -0700, Dionna Amalie Glaze wrote:
> >>>> If the GHCB is available, we should always prefer it.
> >>>
> >>> I believe we should consider the cost of code duplication in this
> >>> situation.
> >>>
> >>> If the non-early version is only used in the kexec path, it will not be
> >>> tested as frequently and could be more easily broken. I think it would be
> >>> acceptable for kexec to be slightly slower if it results in more
> >>> maintainable code.
> >>>
> >>
> >> Is accept_memory() in the decompressor or efistub only used in the kexec
> >> path?
> >>
> >
> > The EFI stub does not call accept_memory(), only the decompressor
> > does. The only use case for explicit memory acceptance in the EFI stub
>
> Since EFI stub never uses accept_memory() I looked at moving enablement
> of SEV to be before the setup of the accepted memory bitmap, as SEV
> enablement doesn't need any e820 info. But that didn't work because the
> real issue is early_setup_ghcb() calls set_page_decrypted() which calls
> set_clr_page_flags(). The latter function is not meant to work with EFI
> page tables, so there is an incompatibility.
>

I would prefer to go into the other direction, and not enable SEV at
all in the EFI stub. The core kernel will happily enable SEV anyway,
right?

> If we had a way to check for whether we are coming through the EFI stub
> vs the decompressor, then snp_accept_memory() could decide to skip
> early_setup_ghcb() when called from the EFI stub and call either
> __snp_accept_memory() from the decompressor or __page_state_change()
> from the EFI stub (the latter having to be updated to return a value).
>
> I think there are other areas that might need investigating because I
> noticed that efi_warn() is successful before efi_exit_boot_services()
> but blows up immediately after (possibly in the EFI #VC handler having
> to do with addressing the string?).
>

efi_warn() blows up because the console is gone after
ExitBootServices(). That is not SEV related.