toggle quoted messageShow quoted text
I agree with Brijesh.
The basic rule is: SEV file shall never refer to TDX data structure. TDX file shall never refer to SEV data structure.
These code should be isolated clearly.
Do we still need that logic if we follow the new pattern?
From: Brijesh Singh <email@example.com>
Sent: Tuesday, July 27, 2021 8:31 PM
To: Xu, Min M <firstname.lastname@example.org>; email@example.com
Cc: firstname.lastname@example.org; Ard Biesheuvel <email@example.com>;
Justen, Jordan L <firstname.lastname@example.org>; Erdem Aktas
<email@example.com>; James Bottomley <firstname.lastname@example.org>; Yao,
Jiewen <email@example.com>; Tom Lendacky <firstname.lastname@example.org>
Subject: Re: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector
On 7/27/21 6:51 AM, Xu, Min M wrote:
On July 27, 2021 6:57 PM, Brijesh Singh wrote:https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.gr
This refactoring is already done by the SNP patch series.
erid%3A5969970,20,2,20,83891510See my explanation in the above comments. In Tdx guests memory region
It appears that you are also pulling in some of TDX logic inside the
AMDSev.asm such as
+ ; 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 ?
be accessed unless it is accepted by guest or initialized by the host VMM. Indword[SEV_ES_WORK_AREA_RDRAND]
PostJump64BitAndLandHereSev there is access to
which is not initialized by host VMM. If this code will not be executed inCheckSevFeatures
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
byte[SEV_ES_WORK_AREA] is used to record the SEV-ES flag. This memoryregion is
not initialized by host VMM either. So in Tdx it will trigger error.added
Another solution is that the memory region used by SEV in ResetVector are
Into Tdx metadata so that host VMM will initialize those memory region whenI am not full versed on TDX yet and sorry I am not able to follow you
It creates the Td guest. What's your opinion?
question completely to provide any advice. With SEV and SEV-ES, a guest
can access the memory without going through the validation process, but
with the SEV-SNP, the page need to be validated (aka accepted) before
the access. In SNP series, we ensure that the data pages used in the
reset vector are pre-validated during the VM creation time -- this
allows us to access the pages without going through accept process. If I
follow you correctly on your metadata comment then it is similar to
saying is pre-validate these range of pages used in the reset vector
code (that include GHCB page, Page table pages etc), right ?
For SEV-SNP, see this patch
A VMM (qemu) looks for the range of page it need to prevalidate before
the boot, the range is provided through the GUID (SevSnpBootBlock).
I will take out my refactoring patch outside of the SNP series and submit it soThank you very much for the refactoring. I will refine my patch based on it.
that you can build on top of. This will simplify review process.