Re: [edk2-devel] [PATCH v2] UefiCpuPkg/MpInitLib: Allocate a separate SEV-ES AP reset stack area

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

On 5/19/21 2:27 AM, Laszlo Ersek wrote:
> On 05/17/21 17:03, Lendacky, Thomas wrote:
>> On 5/16/21 11:22 PM, Laszlo Ersek wrote:
> 
>>> But now, with SEV-ES enabled, we'll have a separate, discontiguous area
>>> -- and neither BackupAndPrepareWakeupBuffer(), nor its counterpart
>>> RestoreWakeupBuffer() take that into account.
>>>
>>> Therefore I think, while this patch is regression-free for the SEV-ES
>>> *disabled* case, it may corrupt memory (through not restoring the AP
>>> stack area's original contents) with SEV-ES enabled.
>>
>> This is the current behavior for SEV-ES. The wakeup buffer memory is
>> marked as reserved, at least in the DXE phase.
> 
> Another question that occurred to me later: where does this reservation
> happen? If we have a separate allocation for the AP stacks now, do we
> need to reserve that too, separately?

The GetWakeupBuffer() in DxeMpLib.c will perform AllocatePages() with a
memory type of "EfiReservedMemoryType" for SEV-ES. Since, with this patch,
it is called twice (once for the reset vector area and once for the stack
area) and both allocations will be EfiReservedMemoryType.

> 
> What about PEI in general? Why is there no risk of corruption there?

That's a good question. The PEI GetWakeupBuffer() looks for memory that
hasn't been allocated below 1MB and just uses it - no reservation or
allocation. For OVMF, I imagine that nothing is really populated there and
so it is truly just "free" memory that doesn't need to be restored.

Thanks,
Tom

> 
> (Sorry if these are lame questions!)
> 
> Thanks,
> Laszlo
>