On Sun, 4 May 2025 at 09:38, Ingo Molnar mingo@kernel.org wrote:
- Ard Biesheuvel ardb@kernel.org wrote:
On Thu, 1 May 2025 at 20:05, Tom Lendacky thomas.lendacky@amd.com wrote:
On 4/28/25 12:43, Ard Biesheuvel wrote:
From: Ard Biesheuvel ardb@kernel.org
Commit
d54d610243a4 ("x86/boot/sev: Avoid shared GHCB page for early memory acceptance")
provided a fix for SEV-SNP memory acceptance from the EFI stub when running at VMPL #0. However, that fix was insufficient for SVSM SEV-SNP guests running at VMPL >0, as those rely on a SVSM calling area, which is a shared buffer whose address is programmed into a SEV-SNP MSR, and the SEV init code that sets up this calling area executes much later during the boot.
Given that booting via the EFI stub at VMPL >0 implies that the firmware has configured this calling area already, reuse it for performing memory acceptance in the EFI stub.
This looks to be working for SNP guest boot and kexec. SNP guest boot with an SVSM is also working, but kexec isn't. But the kexec failure of an SVSM SNP guest is unrelated to this patch, I'll send a fix for that separately.
Thanks for confirming.
Ingo, Boris, can we get this queued as a fix, please, and merge it back into x86/boot as was done before?
Just to clarify, memory acceptance trough the EFI stub from VMPL >0 SEV-SNP guests was broken last summer via fcd042e86422, and it hasn't worked since then?
It never worked correctly at all for SEV-SNP, since it was enabled in d54d610243a4.
We never noticed because it appears that the SEV-SNP firmware rarely exposes EFI_UNACCEPTED regions in chunks that are not 2M aligned, and the EFI stub only accepts the misaligned bits so it can populate the unaccepted_memory table accurately, which keeps track of unaccepted memory with 2M granularity.