On 2/13/23 12:31, Dionna Amalie Glaze wrote:
I'm rather confused at the moment how our internal testing succeeds
given the premise of the protocol is to use the specified behavior
that the OS must call get_memory_map again if ebs fails with
efi_invalid_parameter, but upstream does not appear to do this.
If you're able to make progress by applying this patch to your linux
build, then we might be back at square one, since the protocol's whole
purpose is to work with older SEV-SNP kernels.
diff --git a/drivers/firmware/efi/libstub/x86-stub.c
b/drivers/firmware/efi/libstub/x86-stub.c
index a0bfd31358ba..795db2315f35 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -747,6 +747,18 @@ static efi_status_t exit_boot(struct boot_params
*boot_params, void *handle)
/* Might as well exit boot services now */
status = efi_exit_boot_services(handle, &priv, exit_boot_func);
+ /*
+ * EBS may fail once with INVALID_PARAMETER, which means the
OS must call
+ * get_memory_map again and try EBS one more time.
+ */
+ if (status == EFI_INVALID_PARAMETER) {
+ status = allocate_e820(boot_params, &e820ext, &e820ext_size);
+ if (status != EFI_SUCCESS)
+ return status;
+
+ status = efi_exit_boot_services(handle, &priv, exit_boot_func);
+ }
+
As far as I can tell this logic is present in the efi_exit_boot_services()
function, so this shouldn't be needed.
Thanks,
Tom
if (status != EFI_SUCCESS)
return status;
On Mon, Feb 13, 2023 at 9:56 AM Gupta, Pankaj <pankaj.gu...@amd.com> wrote:
- If no memory is getting accepted at all, should guest boot fail with
below errors?
No, the guest should not error. EBS should return success on the
second call and permit progress.
- Why unaccepted memory not being set in my setup but works fine for
you? Does it require any other change?
We have an internal fork of EDK2 that we regularly rebase on top of
upstream, and we have our own hypervisor called Vanadium. So there's a
lot different. We don't have an easy way to test with upstream EDK2
and Qemu.
A recent import found incompatibilities with measured boot only in
SEV-SNP that we have disabled, but that's related to NVdata, which we
deal with differently in GCE due to the cloud IVARS service and our
allergy to SMM emulation. Should be unrelated.
I've looked over our OvmfPkg.patch that we maintain after every rebase
and most everything is related to our paravirtualized UEFI package
that eschews SMM to talk to Vanadium directly through either shared
memory or port I/O depending on whether the guest OS owns cr3 or not.
You've added a log for the if != unaccepted memory, but will you log
what status the function ultimately returns? And both the MapKey what
status CoreTerminateMemoryMap returns in DxeMain.c's
CoreExitBootServices? I'm wondering if maybe the EFI stub calling EBS
isn't calling GetMemoryMap to update the MapKey after the
invalid_param result that this semantics depends on. If the stub is
the Linux kernel's own stub, then it should be doing the right
thing...
CoreTerminateMemoryMap::MapKey::18033 ^M
CoreTerminateMemoryMap::Status::2
....
CoreTerminateMemoryMap::MapKey::18035 ^M
CoreTerminateMemoryMap::Status::2 ^M
Thanks,
Pankaj
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100129): https://edk2.groups.io/g/devel/message/100129
Mute This Topic: https://groups.io/mt/96534752/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
