Messages in this thread |  | | From | Ard Biesheuvel <> | | Date | Thu, 10 Apr 2025 15:28:05 +0200 | | Subject | Re: [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP |
| |
On Tue, 8 Apr 2025 at 17:53, Tom Lendacky <thomas.lendacky@amd.com> wrote: > > On 4/7/25 14:59, Ard Biesheuvel wrote: > > On Mon, 7 Apr 2025 at 20:05, Tom Lendacky <thomas.lendacky@amd.com> 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.
|  |