Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES

["Lendacky, Thomas" <thomas.lendacky@amd.com>]

On 10/3/19 10:12 AM, Tom Lendacky wrote:
> 
> 
> On 10/3/19 5:32 AM, Laszlo Ersek wrote:
>> On 10/03/19 12:12, Laszlo Ersek wrote:
>>
>>>   UINT32   ApEntryPoint;
>>>   EFI_GUID SevEsFooterGuid;
>>>   UINT16   Size;
>>
>> It's probably better to reverse the order of "Size" and
>> "SevEsFooterGuid", like this:
>>
>>   UINT32   ApEntryPoint;
>>   UINT16   Size;
>>   EFI_GUID SevEsFooterGuid;
>>
>> because then even the "Size" field can be changed (or resized), as a
>> function of the footer GUID.
> 
> Cool, I'll look into doing this and see how it works out.

Just an update on this idea. This has worked out well, but has a couple of
caveats. Removing the Qemu change to make the flash mapped read-only in
the nested page tables, caused the following:

1. QemuFlashDetected() will attempt to detect how the flash memory device
   behaves. Because it is marked as read-only by the hypervisor, writing
   to the area results in a #NPF for the write-fault. With SEV-ES,
   emulation of the instruction can't be performed (can't read guest
   memory and not provided the faulting instruction bytes), so the vCPU is
   just restarted. This results in an infinite #NPF occurring.

   The solution here was to check for SEV-ES being enabled and just return
   false from QemuFlashDetected(). Any downfalls to doing that?

2. Commit 2db0ccc2d7fe ("UefiCpuPkg: Update CpuExceptionHandlerLib pass
   XCODE5 tool chain") causes a similar situation to #1. It attempts to do
   some address fixups and write to the flash device.

   Reverting that commit fixes the issue. I don't think that will be an
   acceptable solution, though, so need to think about what to do here.

After those two changes, the above method works well.

Thanks,
Tom

> 
> Thanks!
> Tom
> 
>>
>> Thanks
>> Laszlo
>>