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

[Tom Lendacky]

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.

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?).

Thanks,
Tom


> is process_unaccepted_memory(), which accepts the misaligned chunk of
> memory that cannot be described at 2M granularity by the accepted
> memory table.
> 
> Remember that the EFI stub no longer calls into the legacy
> decompressor at all - it decompresses the kernel while executing the
> EFI boot services and branches straight to it.