Re: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector

["Min Xu" <min.m.xu@intel.com>]

On July 27, 2021 6:57 PM, Brijesh Singh wrote:
> Hi Min,
> 
> This refactoring is already done by the SNP patch series.
> 
> https://edk2.groups.io/g/devel/message/77336?p=,,,20,0,0,0::Created,,post
> erid%3A5969970,20,2,20,83891510
> 
> It appears that you are also pulling in some of TDX logic inside the
> AMDSev.asm such as
> 
> ;
> +PostJump64BitAndLandHereSev:
> +
> +    ;
> +    ; If it is Tdx guest, jump to exit point directly.
> +    ; This is because following code may access the memory region which has
> +    ; not been accepted. It is not allowed in Tdx guests.
> +    ;
> +    mov     eax, dword[TDX_WORK_AREA]
> +    cmp     eax, 0x47584454             ; 'TDXG'
> +    jz      GoodCompare
> 
> Why we are referring the TDX workarea inside the AmdSev.asm ?
See my explanation in the above comments. In Tdx guests memory region cannot
be accessed unless it is accepted by guest or initialized by the host VMM. In 
PostJump64BitAndLandHereSev there is access to dword[SEV_ES_WORK_AREA_RDRAND]
which is not initialized by host VMM. If this code will not be executed in 
Tdx guest, then the above check is not needed. I need your help to confirm it.

There are similar Tdx check in my patch of AmdSev.asm. For example in CheckSevFeatures
byte[SEV_ES_WORK_AREA] is used to record the SEV-ES flag. This memory region is
not initialized by host VMM either. So in Tdx it will trigger error.

Another solution is that the memory region used by SEV in ResetVector are added
Into Tdx metadata so that host VMM will initialize those memory region when 
It creates the Td guest. What's your opinion?
> 
> I will take out my refactoring patch outside of the SNP series and submit it so
> that you can build on top of. This will simplify review process.
>
Thank you very much for the refactoring.  I will refine my patch based on it. 
>
> thanks
> 
>