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

Lendacky, Thomas thomas.lendacky at amd.com
Thu May 20 15:09:06 UTC 2021



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
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75422): https://edk2.groups.io/g/devel/message/75422
Mute This Topic: https://groups.io/mt/82833645/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-





More information about the edk2-devel-archive mailing list