Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe

["Gupta, Pankaj" <pankaj.gupta@amd.com>]

>> - 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