Jordan L
> ; Erdem Aktas ; James
> Bottomley ; Tom Lendacky
> Subject: RE: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> ResetVector
>
> On July 29, 2021 8:13 PM, Yao Jiewen wrote:
> > Hey
> > I am not sure why Min did not response to my latest email.
> > ; devel@edk2.groups.io
> > Cc: Ard Biesheuvel ; Justen, Jordan L
> > ; Erdem Aktas ;
> > James Bottomley ; Tom Lendacky
> >
> > Subject: RE: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> > ResetVector
> >
> > On July 29, 2021 6:08
-
>> From: Xu, Min M
>> Sent: Thursday, July 29, 2021 7:54 PM
>> To: Brijesh Singh ; Yao, Jiewen
>> ; devel@edk2.groups.io
>> Cc: Ard Biesheuvel ; Justen, Jordan L
>> ; Erdem Aktas ; James
>> Bottomley ; Tom Lendacky
>> Subject: RE: [edk2-devel] [PATCH V
age-
> From: Xu, Min M
> Sent: Thursday, July 29, 2021 7:54 PM
> To: Brijesh Singh ; Yao, Jiewen
> ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Justen, Jordan L
> ; Erdem Aktas ; James
> Bottomley ; Tom Lendacky
> Subject: RE: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add
On July 29, 2021 6:08 PM, Brijesh Singh wrote:
> On 7/29/21 1:07 AM, Xu, Min M wrote:
> > On July 29, 2021 12:29 PM, Brijesh Singh wrote:
> >> On 7/28/21 9:44 PM, Xu, Min M wrote:
> >>> Jiewen & Singh
> >>>
> >>> From the discussion I am thinking we have below rules to follow to
> >>> the design th
On 7/29/21 1:07 AM, Xu, Min M wrote:
> On July 29, 2021 12:29 PM, Brijesh Singh wrote:
>> On 7/28/21 9:44 PM, Xu, Min M wrote:
>>> Jiewen & Singh
>>>
>>> From the discussion I am thinking we have below rules to follow to the
>>> design the structure of TEE_WORK_AREA:
>>> 1. Design should be flexi
On July 29, 2021 12:29 PM, Brijesh Singh wrote:
> On 7/28/21 9:44 PM, Xu, Min M wrote:
> > Jiewen & Singh
> >
> > From the discussion I am thinking we have below rules to follow to the
> > design the structure of TEE_WORK_AREA:
> > 1. Design should be flexible but not too complicated 2. Reuse the
>
workarea gets reused for totally different
> purpose after the PEI phase.
[jiewen] Sorry. I am not aware of that.
Any documentation?
Is that SEV specific purpose? Or generic CC purpose?
>
> thanks
>
>>> -Original Message-
>>> From: Yao, Jiewen
>>>
d for totally different
purpose after the PEI phase.
thanks
>> -Original Message-
>> From: Yao, Jiewen
>> Sent: Thursday, July 29, 2021 7:49 AM
>> To: Brijesh Singh ; devel@edk2.groups.io; Xu, Min M
>>
>> Cc: Ard Biesheuvel ; Justen, Jordan L
>>
ps.io; Xu, Min
> > M
> > Cc: brijesh.si...@amd.com; Ard Biesheuvel ;
> > Justen, Jordan L ; Erdem Aktas
> > ; James Bottomley ; Tom
> > Lendacky
> > Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> > ResetVector
> >
> >
>
gt; Lendacky
> Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> ResetVector
>
>
>
> On 7/28/21 11:26 AM, Yao, Jiewen wrote:
> > I would say it is NOT the best software practice to define 2 enable fields
> > to
> indicate one type.
> >
&g
heuvel ;
Justen, Jordan L ; Erdem Aktas
; James Bottomley ; Tom
Lendacky
Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
ResetVector
Hi Yao Jiewen,
I guess I am still trying to figure out why we need the header in the
work area. Can't we do something like this:
typedef st
9 PM
> To: Yao, Jiewen ; devel@edk2.groups.io; Xu, Min M
>
> Cc: brijesh.si...@amd.com; Ard Biesheuvel ;
> Justen, Jordan L ; Erdem Aktas
> ; James Bottomley ; Tom
> Lendacky
> Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> ResetVector
>
> Hi
Min M
Cc: brijesh.si...@amd.com; devel@edk2.groups.io; Ard Biesheuvel
; Justen, Jordan L ;
Erdem Aktas ; James Bottomley
; Tom Lendacky
Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
ResetVector
Hi Jiewen and Min,
See my comments below.
On 7/28/21 2:54 AM, Yao, Jiewen w
gt; Cc: brijesh.si...@amd.com; devel@edk2.groups.io; Ard Biesheuvel
> ; Justen, Jordan L ;
> Erdem Aktas ; James Bottomley
> ; Tom Lendacky
> Subject: Re: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> ResetVector
>
> Hi Jiewen and Min,
>
> See my comments b
Hi Jiewen and Min,
See my comments below.
On 7/28/21 2:54 AM, Yao, Jiewen wrote:
Yes. I am thinking the same thing.
[CC Flag memory location]
1) A general purpose register, such as EBP.
2) A global variable, such as
.data
TeeFlags: DD 0
3) A fixed region in stack, such as
dword[STACK_TOP -
I noticed SEV has the memory region of SEV_ES_WORK_AREA
(gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase) in MEMFD
The definition is below:
typedef struct _SEC_SEV_ES_WORK_AREA {
UINT8SevEsEnabled;
UINT8Reserved1[7];
UINT64 RandomData;
UINT64 EncryptionMask;
} SEC_SE
Yes. I am thinking the same thing.
[CC Flag memory location]
1) A general purpose register, such as EBP.
2) A global variable, such as
.data
TeeFlags: DD 0
3) A fixed region in stack, such as
dword[STACK_TOP - 4]
4) A new CC common fixed region, such as
dword[CC_COMMON_FLAGS]
5) A fixed regi
On July 28, 2021 2:05 PM, Yao, Jiewen wrote:
> It does not necessary to be a working area.
>
> We just need a common TEE flag to indicate if the system run in legacy, SEV,
> or
> TDX, right?
Right. We need somewhere to store this flag, either in a Register or in Memory.
If it is memory, then in
It does not necessary to be a working area.
We just need a common TEE flag to indicate if the system run in legacy, SEV, or
TDX, right?
thank you!
Yao, Jiewen
> 在 2021年7月28日，下午1:07，Xu, Min M 写道：
>
> On July 27, 2021 8:46 PM, Yao, Jiewen wrote:
>> HI Min
>> I agree with Brijesh.
>>
>> The b
On July 27, 2021 8:46 PM, Yao, Jiewen wrote:
> HI Min
> 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
On July 27, 2021 8:31 PM, Brijesh Singh wrote:
> On 7/27/21 6:51 AM, Xu, Min M wrote:
> > On July 27, 2021 6:57 PM, Brijesh Singh wrote:
> >> Hi Min,
> >>
> >> This refactoring is already done by the SNP patch series.
> >>
> >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk
HI Min
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?
Thank you
Yao Jiewen
> -Original Message-
On 7/27/21 6:51 AM, Xu, Min M wrote:
> On July 27, 2021 6:57 PM, Brijesh Singh wrote:
>> Hi Min,
>>
>> This refactoring is already done by the SNP patch series.
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F77336%3Fp%3D%2C%2C%2C20%2
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 ins
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,,posterid%3A5969970,20,2,20,83891510
It appears that you are also pulling in some of TDX logic inside the
AMDSev.asm such as
;
+PostJump64BitAndLandHereSev:
+
+
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
AmdSev.asm includes below routines:
- CheckSevFeatures
Check if Secure Encrypted Virtualization (SEV) features are enabled.
- PreSetCr3ForPageTables64Sev
It is called before SetCr3ForPageTables64 in SEV guests.
- PostSetCr3PageTable
27 matches
Mail list logo
