On July 23, 2021 1:08 AM, Tom Lendacky wrote:
On 7/22/21 12:52 AM, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429Is the memory area guaranteed to be zeroed for legacy guests? Hopefully,
diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
index c6d0d898bcd1..2206ca719593 100644
@@ -17,6 +17,9 @@ Transition32FlatTo64Flat:
+ cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
+ jz TdxTransition32FlatTo64Flat
this won't trip up a non-TDX guest with a false match (highly unlikely, though).
TDX_WORK_AREA is piece of TdxMailbox which is located in the MEMFD started
from PcdOvmfSecGhcbBackupBase. In Td guest, this memory region is initialized
to all-0 by host VMM. In legacy guests, I am not sure what's the initialized value
it is. So 'TDXG' is checked to guarantee it is Td-guest or not.
Since Tdx re-use the memory region (PcdOvmfSecGhcbBackupBase) as the
TDX_WORK_AREA, and @Tom Lendacky you should be the original owner of
PcdOvmfSecGhcbBackupBase, can this area be cleared in the beginning of
ResetVector in legacy guests? Or I should better create a TDX specific work
area in MEMFD to guarantee the Td And Non-Td check?
mov eax, cr452bit is supported.
bts eax, 5 ; enable PAE
mov cr4, eax
@@ -65,10 +68,54 @@ EnablePaging:
bts eax, 31 ; set PG
mov cr0, eax ; enable paging
+ jmp _jumpTo64Bit
+; Tdx Transition from 32Flat to 64Flat ;
+ mov eax, cr4
+ bts eax, 5 ; enable PAE
+ ; byte[TDX_WORK_AREA_PAGELEVEL5] holds the indicator whether
+ ; if it is the case, need to set LA57 and use 5-level pagingIf you clear ebx here...
+ cmp byte[TDX_WORK_AREA_PAGELEVEL5], 0
+ jz .set_cr4
+ bts eax, 12
+ mov cr4, eax
+ mov ebx, cr3
+ ; if la57 is not set, we are ok
+ ; if using 5-level paging, adjust top-level page directory
+ bt eax, 12
+ jnc .set_cr3
+ mov ebx, TDX_PT_ADDR (0)
+ mov cr3, ebx
+ mov eax, cr0
+ bts eax, 31 ; set PG
+ mov cr0, eax ; enable paging
+... you can remove these instructions. You'll jump to InsnCompare and that
+ ; For Td guest we are done and jump to the end
+ mov eax, TDX_WORK_AREA
+ cmp dword [eax], 0x47584454 ; 'TDXG'
+ jz GoodCompare
check should succeed, right?
Ah, I see. Thanks for reminder. I will update it in next version.
; Check if the second step of the SEV-ES mitigation is to be performed.