Re: [edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg/UefiSortLib:Add UefiSortLib unit test

[Wu, Hao A]

Thanks for the patch.
Some inline comments below:


> -Original Message-
> From: Wenyi Xie 
> Sent: Wednesday, July 28, 2021 1:58 PM
> To: devel@edk2.groups.io; Wang, Jian J ; Wu, Hao A
> 
> Cc: songdongku...@huawei.com; xiewen...@huawei.com
> Subject: [PATCH EDK2 v1 1/1] MdeModulePkg/UefiSortLib:Add UefiSortLib unit
> test
> 
> Adding unit test for UefiSortLib.


Could you help to give a brief summary on what tests are added?


> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Signed-off-by: Wenyi Xie 
> ---
>  MdeModulePkg/Test/MdeModulePkgHostTest.dsc|   6 +
>  MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf |  32 
>  MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c   | 188
> 
>  3 files changed, 226 insertions(+)
> 
> diff --git a/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
> b/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
> index 4da4692c8451..c9ec835df65d 100644
> --- a/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
> +++ b/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
> @@ -41,3 +41,9 @@ [Components]
>  
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdAllowVariablePolicyEnforcementDisable
> |TRUE
>}
> +
> +  MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf {
> +
> +  UefiSortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> +
> + DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
> +  }
> diff --git a/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf
> b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf
> new file mode 100644
> index ..d9dac307934e
> --- /dev/null
> +++ b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf
> @@ -0,0 +1,32 @@
> +## @file
> +# This is a unit test for the UefiSortLib.
> +#
> +# Copyright (c) Microsoft Corporation.


Please help to use the 'copyright' information of Huawei like in file 
UefiSortLibUnitTest.c.


> +# SPDX-License-Identifier: BSD-2-Clause-Patent ##
> +
> +[Defines]
> +  INF_VERSION = 0x00010017
> +  BASE_NAME   = UefiSortLibUnitTest
> +  FILE_GUID   = 271337A3-0D79-BA3E-BC03-714E518E3B1B
> +  VERSION_STRING  = 1.0
> +  MODULE_TYPE = HOST_APPLICATION
> +
> +#
> +# The following information is for reference only and not required by the 
> build
> tools.
> +#
> +#  VALID_ARCHITECTURES   = IA32 X64
> +#
> +
> +[Sources]
> +  UefiSortLibUnitTest.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> +
> +[LibraryClasses]
> +  UnitTestLib
> +  DebugLib
> +  UefiSortLib
> diff --git a/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c
> b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c
> new file mode 100644
> index ..f2f89daef7ba
> --- /dev/null
> +++ b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c
> @@ -0,0 +1,188 @@
> +/** @file
> +  Unit tests of the UefiSortLib
> +
> +  Copyright (C) Huawei Technologies Co., Ltd. All rights reserved
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define UNIT_TEST_APP_NAME"UefiSortLib Unit Tests"
> +#define UNIT_TEST_APP_VERSION "1.0"
> +
> +#define TEST_ARRAY_SIZE_9 9
> +
> +/**
> +  The function is called by PerformQuickSort to compare int values.
> +
> +  @param[in] LeftThe pointer to first buffer.
> +  @param[in] Right   The pointer to second buffer.
> +
> +  @retval 0  Buffer1 equal to Buffer2.
> +  @return <0 Buffer1 is less than Buffer2.
> +  @return >0 Buffer1 is greater than Buffer2.
> +
> +**/
> +INTN
> +EFIAPI
> +TestCompareFunction (
> +  IN CONST VOID *Left,
> +  IN CONST VOID *Right
> +  )
> +{
> +  if (*(UINT32*)Right > *(UINT32*)Left) {
> +return 1;
> +  } else if (*(UINT32*)Right < *(UINT32*)Left) {
> +return -1;
> +  }
> +
> +  return 0;
> +}
> +
> +/**
> +  Unit test for PerformQuickSort () API of the UefiSortLib.
> +
> +  @param[in]  Context[Optional] An optional parameter that enables:
> + 1) test-case reuse with varied parameters and
> + 2) test-case re-entry for Target tests that need a
> + reboot.  This parameter is a VOID* and it is the
> + responsibility of the test author to ensure that the
> + contents are well understood by all test cases that 
> may
> + consume it.
> +
> +  @retval  UNIT_TEST_PASSED The Unit test has completed and the 
> test
> +case was successful.
> +  @retval  UNIT_TEST_ERROR_TEST_FAILED  A test case 

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

[Yao, Jiewen]

comment below

thank you!
Yao, Jiewen


> 在 2021年7月29日，下午12:29，Brijesh Singh via groups.io 
>  写道：
> 
> 
>> 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 current SEV_ES_WORK_AREA (PcdSevEsWorkAreaBase) as TEE_WORK_AREA
>> 3. TEE_WORK_AREA should be initialized to all-0 at the beginning of 
>> ResetVecotr
>> 4. Reduce the changes to exiting code if possible
>> 
>> So I try to make below conclusions below: (Please review)
>> 1. SEV_ES_WORK_AREA is used as the TEE_WORK_AREA by both TDX and SEV, maybe 
>> in
>> the future it can be used by other CC technologies.
>> 
>> 2. In MEMFD, add below initial value. So that TEE_WORK_AREA is guaranteed to 
>> be cleared
>> in legacy guest. In TDX this memory region is initialized to be all-0 by 
>> host VMM. In SEV the memory
>> region is cleared as well.
>>  0x00B000|0x001000
>>  
>> gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
>>  DATA = {
>>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>>  }
> 
> Hmm, I thought the contents of the data pages are controlled by the host
> VMM. If the backing pages are not zero filled then there is no guarantee
> that memory will be zero.  To verify it:
> 
> 1. I applied your above change in OvmfPkgX86.fdt. I modified the DATA
> values from 0x00 -> 0xCC
> 
> 2. Modified the SecMain.c to dump the SevEsWorkArea on entry
> 
> And dump does not contain the 0xcc.
> 
> And to confirm further,  I attached to the qemu with the GDB before the
> booting the OVMF, and modified the SevEsWorkArea with some garbage
> number  and this time the dump printed garbage value I put through the
> debugger.
> 
> In summary, the OVMF to zero the workarea memory on the entry and we
> cannot rely on the DATA={0x00, 0x00...} to zero the CCWorkArea.
> 
> Did I miss something ?
[jiewen] I am not sure how SEV works. 
For TDX, this memory is private memory. VMM or QEMU cannot modify it *after* 
launch.
VMM or QEMU may modify it *before* launch. That will be detected by attestation 
later if it is added memory. That will be zeroed with accept page if it is 
auged memory. 
So in TDX, I have no concern.

Anyway, I think the logic can be:
=
CcWorkArea.Type = 0;
InitCcWorkAreaSev(); // set Type=1 if SEV
InitCcWorkAreaTdx(); // set Type=2 if TDX
=

> 
> 
>> 
>> 3. The structure of TEE_WORK_AREA
>>  The current SEV_ES_WORK_AREA is defined as below:
>>  typedef struct {
>>UINT8SevEsEnabled;
>>UINT8Reserved1[7];
>>[Others...]
>> } SEC_SEV_ES_WORK_AREA;
>> 
>> So I think the TEE_WORK_AREA can be:
>>  Byte[0] Type:
>>0: legacy 1: SEV2: TDX 
>>  Byte[1] Subtype:
>>  If Type is 0, then it is 0
>>If Type is 1, then it is up to SEV's definition
>>If Type is 2, then it is up to TDX's definition
>> Byte[] other bytes are defined based on the Type/Subtype
> 
> I personally like Yao Jiewen's struct definition, but I can also live
> with this one as well :). The only question I had was with his proposal
> was what if we remove the Length and Version fields. If the header
> length was fixed then life would be much easier in the ASM code. 
[jiewen] I am ok to remove version and length. The we need very carefully 
maintain the compatibility. 

How about below:

typedef struct {
  UINT8 Type;
  UINT8 SubType;
  UINT8 Reserved[6];
} CC_WORK_AREA_HEAD;

That almost aligns with existing SEV_ES. 

> 
> 
>> I check the code in SecMain.c.
>> SevEsIsEnabled() need updated to check SevEsWorkarea->SevEsEnabled == 1, not 
>> non-0.
>> @Brijesh Singh Is there any other code need update?
> 
> As noted before, the SevEsWorkAreas is used to pass the information from
> the Sec to PEI phase. 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 
>>> Sent: Thursday, July 29, 2021 7:49 AM
>>> To: Brijesh Singh ; devel@edk2.groups.io; Xu, Min M
>>> 
>>> 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
>>> 
>>> Comment below:
>>> 
 -Original Message-
 From: Brijesh Singh 
 Sent: Thursday, July 29, 2021 2:59 AM
 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
 

Re: [edk2-devel] [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0

[Digant H Solanki]

Thanks for review and suggestion, Sai..!!

-Original Message-
From: Chaganty, Rangasai V  
Sent: Wednesday, July 28, 2021 11:24 PM
To: Solanki, Digant H ; devel@edk2.groups.io
Cc: Ni, Ray ; S, Ashraf Ali 
Subject: RE: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

Digant,
The notation "PATCH 3/3" indicates part 3 of a 3 patch series. 
However since this is a single patch, the subject line could simply indicate 
[PATCH v3]. Something to consider for future reviews. 

Thanks,
Sai

-Original Message-
From: Chaganty, Rangasai V
Sent: Wednesday, July 28, 2021 10:48 AM
To: Solanki, Digant H ; devel@edk2.groups.io
Cc: Ni, Ray ; S, Ashraf Ali 
Subject: RE: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

Reviewed-by: Sai Chaganty  

-Original Message-
From: Solanki, Digant H 
Sent: Thursday, July 22, 2021 4:47 AM
To: devel@edk2.groups.io
Cc: Solanki, Digant H ; Ni, Ray ; 
Chaganty, Rangasai V ; S, Ashraf Ali 

Subject: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3426

- There are many OpRegion fields obsoleted in MBOX1
- MBOX2 is re-purposed for Backlight related fields for dual LFP.
- Backlight related fields moved to MBOX2 from MBOX3 and some fields are 
obsoleted in MBOX3.

Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Ashraf Ali S 
---
 Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 
+
 1 file changed, 101 insertions(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
new file mode 100644
index 00..c9948ab55f
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion
+++ 30.h
@@ -0,0 +1,101 @@
+/** @file
+  IGD OpRegion definition from Intel Integrated Graphics Device 
+OpRegion
+  Specification based on version 3.0.
+
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef _IGD_OPREGION_3_0_H_
+#define _IGD_OPREGION_3_0_H_
+
+#include "IgdOpRegion.h"
+
+#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5
+
+#pragma pack(1)
+///
+/// OpRegion Mailbox 1 - Public ACPI Methods /// Offset 0x100, Size
+0x100 /// typedef struct {
+  UINT32 DRDY;  ///< Offset 0x100 Driver Readiness
+  UINT32 CSTS;  ///< Offset 0x104 Status
+  UINT32 CEVT;  ///< Offset 0x108 Current Event
+  UINT8  RM11[0x14];///< Offset 0x10C Reserved Must be Zero
+  UINT32 DIDL[8];   ///< Offset 0x120 Supported Display Devices ID List
+  UINT32 CPDL[8];   ///< Offset 0x140 obsolete
+  UINT32 CADL[8];   ///< Offset 0x160 obsolete
+  UINT32 NADL[8];   ///< Offset 0x180 obsolete
+  UINT32 ASLP;  ///< Offset 0x1A0 ASL Sleep Time Out
+  UINT32 TIDX;  ///< Offset 0x1A4 obsolete
+  UINT32 CHPD;  ///< Offset 0x1A8 obsolete
+  UINT32 CLID;  ///< Offset 0x1AC Current Lid State Indicator
+  UINT32 CDCK;  ///< Offset 0x1B0 Current Docking State Indicator
+  UINT32 SXSW;  ///< Offset 0x1B4 obsolete
+  UINT32 EVTS;  ///< Offset 0x1B8 obsolete
+  UINT32 CNOT;  ///< Offset 0x1BC obsolete
+  UINT32 NRDY;  ///< Offset 0x1C0 Driver Status
+  UINT8  DID2[0x1C];///< Offset 0x1C4 Extended Supported Devices ID List 
(DOD)
+  UINT8  CPD2[0x1C];///< Offset 0x1E0 obsolete
+  UINT8  RM12[4];   ///< Offset 0x1FC - 0x1FF Reserved Must be zero
+} IGD_OPREGION_MBOX1_VER_3_0;
+
+///
+/// OpRegion Mailbox 2 - Backlight communication /// Offset 0x200, Size
+0x100 /// typedef struct {
+  UINT32 BCL1;  ///< Offset 0x200 Backlight Brightness for LFP1
+  UINT32 BCL2;  ///< Offset 0x204 Backlight Brightness for LFP2
+  UINT32 CBL1;  ///< Offset 0x208 Current User Brightness Level for 
LFP1
+  UINT32 CBL2;  ///< Offset 0x20C Current User Brightness Level for 
LFP2
+  UINT32 BCM1[0x1E];///< Offset 0x210 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP1
+  UINT32 BCM2[0x1E];///< Offset 0x288 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP2
+} IGD_OPREGION_MBOX2_VER_3_0;
+
+///
+/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support /// 
+Offset 0x300, Size 0x100 /// typedef struct {
+  UINT32 ARDY;  ///< Offset 0x300 obsolete
+  UINT32 ASLC;  ///< Offset 0x304 obsolete
+  UINT32 TCHE;  ///< Offset 0x308 obsolete
+  UINT32 ALSI;  ///< Offset 0x30C obsolete
+  UINT32 BCLP;  ///< Offset 0x310 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 PFIT;  ///< Offset 0x314 obsolete
+  UINT32 CBLV;  ///< Offset 0x318 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT16 BCLM[0x14];///< Offset 0x31C 

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

[Brijesh Singh via groups.io]

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 current SEV_ES_WORK_AREA (PcdSevEsWorkAreaBase) as TEE_WORK_AREA
> 3. TEE_WORK_AREA should be initialized to all-0 at the beginning of 
> ResetVecotr
> 4. Reduce the changes to exiting code if possible
>
> So I try to make below conclusions below: (Please review)
> 1. SEV_ES_WORK_AREA is used as the TEE_WORK_AREA by both TDX and SEV, maybe in
> the future it can be used by other CC technologies.
>
> 2. In MEMFD, add below initial value. So that TEE_WORK_AREA is guaranteed to 
> be cleared
> in legacy guest. In TDX this memory region is initialized to be all-0 by host 
> VMM. In SEV the memory
> region is cleared as well.
>   0x00B000|0x001000
>   
> gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
>   DATA = {
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>   }

Hmm, I thought the contents of the data pages are controlled by the host
VMM. If the backing pages are not zero filled then there is no guarantee
that memory will be zero.  To verify it:

1. I applied your above change in OvmfPkgX86.fdt. I modified the DATA
values from 0x00 -> 0xCC

2. Modified the SecMain.c to dump the SevEsWorkArea on entry

And dump does not contain the 0xcc.

And to confirm further,  I attached to the qemu with the GDB before the
booting the OVMF, and modified the SevEsWorkArea with some garbage
number  and this time the dump printed garbage value I put through the
debugger.

In summary, the OVMF to zero the workarea memory on the entry and we
cannot rely on the DATA={0x00, 0x00...} to zero the CCWorkArea.

Did I miss something ?


>
> 3. The structure of TEE_WORK_AREA
>   The current SEV_ES_WORK_AREA is defined as below:
>   typedef struct {
> UINT8SevEsEnabled;
> UINT8Reserved1[7];
> [Others...]
> } SEC_SEV_ES_WORK_AREA;
>
> So I think the TEE_WORK_AREA can be:
>   Byte[0] Type:
>   0: legacy 1: SEV2: TDX 
>   Byte[1] Subtype:
>   If Type is 0, then it is 0
>   If Type is 1, then it is up to SEV's definition
>   If Type is 2, then it is up to TDX's definition
>  Byte[] other bytes are defined based on the Type/Subtype

I personally like Yao Jiewen's struct definition, but I can also live
with this one as well :). The only question I had was with his proposal
was what if we remove the Length and Version fields. If the header
length was fixed then life would be much easier in the ASM code. 


> I check the code in SecMain.c.
>  SevEsIsEnabled() need updated to check SevEsWorkarea->SevEsEnabled == 1, not 
> non-0.
> @Brijesh Singh Is there any other code need update?

As noted before, the SevEsWorkAreas is used to pass the information from
the Sec to PEI phase. The workarea gets reused 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
>> ; Erdem Aktas ; James
>> Bottomley ; Tom Lendacky 
>> Subject: RE: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
>> ResetVector
>>
>> Comment below:
>>
>>> -Original Message-
>>> From: Brijesh Singh 
>>> Sent: Thursday, July 29, 2021 2:59 AM
>>> 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
>>>
>>>
>>>
>>> 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.
 What if some software error, set both TdxEnable and SevEnable at same
>> time?
 How do you detect such error?
>>> Hmm, aren't we saying it is a software bug. In that case another bug
>>> can also mess up the structure header.
>> [Jiewen] Yes. I treat it as a software implementation bug.
>> The key thing in software design is to avoid the developer making mistake, 
>> help
>> debug issues, help maintain the code easily.
>>
>>
 If some code may check the SEV only, and some code may check TDX
 only,
>>> then both code can run. That will be a disaster. The code is hard to
>>> maintain and hard to debug.
 Another consideration is: what if someone wants to set the third type?
 Do we want to reserve the 3rd byte? To indicate the third type? It
 is not
>>> scalable.
 The best software practice it to just define one field as
 enumeration. So any
>>> software can only set Tdx or 

[edk2-devel] AcpiViewApp is for ARM platform

[Tiger Liu(BJ-RD)]

Hi, All:
I tried to comple ShellPkg\Application\AcpiViewApp

I found the default compiled AcpiViewApp version is for ARM platform
For example:
I used it in shell on a x86 platform, found it checked GICC structure.

So, Is there a X86 version?

Thanks


?
?
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78337): https://edk2.groups.io/g/devel/message/78337
Mute This Topic: https://groups.io/mt/84521388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Min Xu]

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 current SEV_ES_WORK_AREA (PcdSevEsWorkAreaBase) as TEE_WORK_AREA
3. TEE_WORK_AREA should be initialized to all-0 at the beginning of ResetVecotr
4. Reduce the changes to exiting code if possible

So I try to make below conclusions below: (Please review)
1. SEV_ES_WORK_AREA is used as the TEE_WORK_AREA by both TDX and SEV, maybe in
the future it can be used by other CC technologies.

2. In MEMFD, add below initial value. So that TEE_WORK_AREA is guaranteed to be 
cleared
in legacy guest. In TDX this memory region is initialized to be all-0 by host 
VMM. In SEV the memory
region is cleared as well.
  0x00B000|0x001000
  
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
  DATA = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  }

3. The structure of TEE_WORK_AREA
  The current SEV_ES_WORK_AREA is defined as below:
  typedef struct {
UINT8SevEsEnabled;
UINT8Reserved1[7];
[Others...]
} SEC_SEV_ES_WORK_AREA;

So I think the TEE_WORK_AREA can be:
  Byte[0] Type:
0: legacy 1: SEV2: TDX 
  Byte[1] Subtype:
  If Type is 0, then it is 0
If Type is 1, then it is up to SEV's definition
If Type is 2, then it is up to TDX's definition
 Byte[] other bytes are defined based on the Type/Subtype

I check the code in SecMain.c.
 SevEsIsEnabled() need updated to check SevEsWorkarea->SevEsEnabled == 1, not 
non-0.
@Brijesh Singh Is there any other code need update?

> -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
> ; Erdem Aktas ; James
> Bottomley ; Tom Lendacky 
> Subject: RE: [edk2-devel] [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in
> ResetVector
> 
> Comment below:
> 
> > -Original Message-
> > From: Brijesh Singh 
> > Sent: Thursday, July 29, 2021 2:59 AM
> > 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
> >
> >
> >
> > 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.
> > >
> > > What if some software error, set both TdxEnable and SevEnable at same
> time?
> > > How do you detect such error?
> >
> > Hmm, aren't we saying it is a software bug. In that case another bug
> > can also mess up the structure header.
> [Jiewen] Yes. I treat it as a software implementation bug.
> The key thing in software design is to avoid the developer making mistake, 
> help
> debug issues, help maintain the code easily.
> 
> 
> >
> > >
> > > If some code may check the SEV only, and some code may check TDX
> > > only,
> > then both code can run. That will be a disaster. The code is hard to
> > maintain and hard to debug.
> > >
> > > Another consideration is: what if someone wants to set the third type?
> > > Do we want to reserve the 3rd byte? To indicate the third type? It
> > > is not
> > scalable.
> > >
> > > The best software practice it to just define one field as
> > > enumeration. So any
> > software can only set Tdx or Sev. The result is consistent, no matter
> > you check the SEV at first or TDX at first.
> > > If there is 3rd bytes, we just need assign the 3rd value to it,
> > > without impact any
> > other field.
> > >
> >
> > I was trying to see if we can make it work without requiring any
> > changes to UefiCpuPkg etc (which uses the EsWorkArea).
> [Jiewen] I agree with you.
> And I think the priority should be:
> 1) make a good design following the best practice.
> 2) minimize the change.
> 
> I don’t think two *enable* fields can satisfy #1.
> And I am open on how to do #2. (See rest comment below)
> 
> 
> 
> >
> >
> > >
> > > I think we can add "must zero" in the comment. But it does not mean
> > > there will
> > be no error during development.
> > >
> > > UNION is not a type safe structure. Usually, the consumer of UNION
> > > shall
> > refer to a common field to know what the type of union is - I treat
> > that as header.
> > >
> > > Since we are defining a common data structure, I think we can do
> > > some clean
> > up.
> > > Or if you have concern to change SEC_SEV_ES_WORK_AREA, we can define
> > > a
> > new CC WORK_AREA without touching SEV_SEV_ES_WORKING_AREA.
> > >
> >
> > In your below structure, I assume the SEV or TDX probe will set the
> > Type only when it detects that feature is active. But 

Re: [edk2-devel] [edk2-platforms] [PATCH V1 0/2] Support for TiogaPass Platform and Override generic PciBus Driver with

[Nate DeSimone]

The series has been pushed as 2959a92~.. 65c5a73

Thanks,
Nate

> -Original Message-
> From: manickavasakam karpagavinayagam 
> Sent: Wednesday, June 16, 2021 2:44 PM
> To: devel@edk2.groups.io
> Cc: Oram, Isaac W ; Desimone, Nathaniel L
> ; fel...@ami.com; DOPPALAPUDI,
> HARIKRISHNA ; Jha, Manish ;
> Bobroff, Zachary ; KARPAGAVINAYAGAM,
> MANICKAVASAKAM 
> Subject: [edk2-platforms] [PATCH V1 0/2] Support for TiogaPass Platform and
> Override generic PciBus Driver with
> 
> Add BoardTiogaPass packages to support TiogaPass Platform Enabled
> Network, ISCSI,IPMI, SMBIOS, Performance Measurement Remove AST2500
> UEFI option ROM driver from PurleyOpenBoardPkg
> AST2500 UEFI option ROM move to edk2-non-osi ASpeedGopBinPkg Update
> copyright headers
> 
> manickavasakam karpagavinayagam (2):
>   PurleyOpenBoardPkg : Support for TiogaPass Platform
>   PurleyOpenBoardPkg : Override generic PciBus Driver with Platform
> specific instance of PciBus driver.
> 
>  .../IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c |8 +-
>  .../Acpi/BoardAcpiDxe/AmlOffsetTable.c|  453 +-
>  .../Acpi/BoardAcpiDxe/BoardAcpiDxeDsdt.c  |3 +
>  .../BoardTiogaPass/CoreDxeInclude.dsc |  168 +
>  .../BoardTiogaPass/CoreUefiBootInclude.fdf|   82 +
>  .../BoardTiogaPass/GitEdk2MinTiogaPass.bat|   93 +
>  .../BasePlatformHookLib/BasePlatformHookLib.c |  389 +
>  .../BasePlatformHookLib.inf   |   36 +
>  .../BoardAcpiLib/DxeBoardAcpiTableLib.c   |   36 +
>  .../BoardAcpiLib/DxeBoardAcpiTableLib.inf |   40 +
>  .../BoardAcpiLib/DxeTiogaPassAcpiTableLib.c   |   53 +
>  .../BoardAcpiLib/SmmBoardAcpiEnableLib.c  |   62 +
>  .../BoardAcpiLib/SmmBoardAcpiEnableLib.inf|   41 +
>  .../BoardAcpiLib/SmmSiliconAcpiEnableLib.c|  120 +
>  .../BoardAcpiLib/SmmTiogaPassAcpiEnableLib.c  |   37 +
>  .../Library/BoardInitLib/AllLanesEparam.c |   44 +
>  .../Library/BoardInitLib/GpioTable.c  |  296 +
>  .../Library/BoardInitLib/IioBifur.c   |   70 +
>  .../BoardInitLib/PeiBoardInitPostMemLib.c |   46 +
>  .../BoardInitLib/PeiBoardInitPostMemLib.inf   |   37 +
>  .../BoardInitLib/PeiBoardInitPreMemLib.c  |  112 +
>  .../BoardInitLib/PeiBoardInitPreMemLib.inf|   69 +
>  .../Library/BoardInitLib/PeiTiogaPassDetect.c |   28 +
>  .../BoardInitLib/PeiTiogaPassInitLib.h|   18 +
>  .../BoardInitLib/PeiTiogaPassInitPostMemLib.c |   86 +
>  .../BoardInitLib/PeiTiogaPassInitPreMemLib.c  |  638 ++
>  .../Library/BoardInitLib/UsbOC.c  |   46 +
>  .../Library/PeiReportFvLib/PeiReportFvLib.c   |  138 +
>  .../Library/PeiReportFvLib/PeiReportFvLib.inf |   51 +
>  .../BoardTiogaPass/OpenBoardPkg.dsc   |  245 +
>  .../BoardTiogaPass/OpenBoardPkg.fdf   |  600 ++
>  .../BoardTiogaPass/PlatformPkgBuildOption.dsc |   84 +
>  .../BoardTiogaPass/PlatformPkgConfig.dsc  |   58 +
>  .../BoardTiogaPass/PlatformPkgPcd.dsc |  392 ++
>  .../BoardTiogaPass/StructureConfig.dsc| 6236 +
>  .../BoardTiogaPass/__init__.py|0
>  .../PurleyOpenBoardPkg/BoardTiogaPass/bld.bat |  139 +
>  .../BoardTiogaPass/build_board.py |  195 +
>  .../BoardTiogaPass/build_config.cfg   |   34 +
>  .../BoardTiogaPass/logo.txt   |   10 +
>  .../BoardTiogaPass/postbuild.bat  |   96 +
>  .../BoardTiogaPass/prebuild.bat   |  213 +
>  .../Ipmi/Library/IpmiLibKcs/IpmiLibKcs.inf|   10 +-
>  .../IpmiPlatformHookLib.inf   |6 +-
>  .../Include/Guid/PchRcVariable.h  |6 +
>  .../Include/Guid/SetupVariable.h  |   15 +-
>  .../Intel/PurleyOpenBoardPkg/OpenBoardPkg.dec |1 +
>  .../Bus/Pci/PciBusDxe/ComponentName.c |  170 +
>  .../Bus/Pci/PciBusDxe/ComponentName.h |  146 +
>  .../MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c   |  460 ++
>  .../MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |  396 ++
>  .../Bus/Pci/PciBusDxe/PciBusDxe.inf   |  112 +
>  .../Bus/Pci/PciBusDxe/PciBusDxe.uni   |   16 +
>  .../Bus/Pci/PciBusDxe/PciBusDxeExtra.uni  |   14 +
>  .../Bus/Pci/PciBusDxe/PciCommand.c|  267 +
>  .../Bus/Pci/PciBusDxe/PciCommand.h|  232 +
>  .../Bus/Pci/PciBusDxe/PciDeviceSupport.c  | 1056 +++
>  .../Bus/Pci/PciBusDxe/PciDeviceSupport.h  |  266 +
>  .../Bus/Pci/PciBusDxe/PciDriverOverride.c |  188 +
>  .../Bus/Pci/PciBusDxe/PciDriverOverride.h |   83 +
>  .../Bus/Pci/PciBusDxe/PciEnumerator.c | 2210 ++
>  .../Bus/Pci/PciBusDxe/PciEnumerator.h |  515 ++
>  .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  | 2885 
> .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h  |  480 ++
>  .../Bus/Pci/PciBusDxe/PciHotPlugSupport.c |  484 ++
>  .../Bus/Pci/PciBusDxe/PciHotPlugSupport.h |  205 +
>  .../MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c| 2087 ++
>  .../MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h|  660 ++
>  

Re: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP) support

[Yao, Jiewen]

Hi Brijesh
Thanks for the patient.
Most of my comment focus on the *common* part, and *interface* between SEV and 
common code.
I will leave you to decide the detailed SEV specific implementation.


Patch-04:
Can we use consistent naming conversion?
We have PcdOvmfSecGhcbPageTableBase, PcdOvmfSecGhcbBase, 
PcdSevLaunchSecretBase. Now we are adding PcdOvmfSnpSecretsBase.
Can we change PcdOvmfSnpSecretsBase to PcdSevSnpSecretsBase?
Or we change PcdSevLaunchSecretBase to PcdOvmfSevLaunchSecretBase?

Patch-05:
Ditto. Naming convention.

Patch-06:
I have recommendation to Min, to separate SEV stuff to a standalone file from 
ResetVectorVtf0.asm.
Intel can add TDX stuff to a standalone file, and make it included by 
ResetVectorVtf0.asm.

I am not sure if you want to do it, or you leave Min to do it.

Patch-07:
Same naming convention issue. See #04 and #05.

Patch-08:
I hope we can move all below code to AmdSev.asm, such as PostPageTableHookSev().
Then the PageTable64.asm can be SEV/TDX agnostic.

I am not sure if you want to do it, or you leave Min to do it.

==
;
; Clear the encryption bit from the GHCB entry
;
mov ecx, (GHCB_BASE & 0x1F_) >> 12
mov [ecx * 8 + GHCB_PT_ADDR + 4], strict dword 0

mov ecx, GHCB_SIZE / 4
xor eax, eax
clearGhcbMemoryLoop:
mov dword[ecx * 4 + GHCB_BASE - 4], eax
loopclearGhcbMemoryLoop

;
; The page table built above cleared the memory encryption mask from the
; GHCB_BASE (aka made it shared). When SEV-SNP is enabled, to maintain
; the security guarantees, the page state transition from private to
; shared must go through the page invalidation steps. Invalidate the
; memory range before loading the page table below.
;
; NOTE: the invalidation must happen after zeroing the GHCB memory. This
;   is because, in the 32-bit mode all the access are considered 
private.
;   The invalidation before the zero'ing will cause a #VC.
;
OneTimeCall  InvalidateGHCBPage
==

Patch-10:
I am not UEFI CPU package maintainer. But I do have a little concern to add 
more PcdXxxIsEnable style PCD, especially when they are mutual exclusive (like 
TDX v.s SEV).
If we follow this pattern, we will have PcdSevEsIsEnabled, PcdSevSnpIsEnabled, 
PcdSevFutureIsEnabled, PcdTdxIsEnabled, PcdTdxFutureIsEnabled, ... that will be 
an endless list.

If possible, I suggest define one PcdConfidentialComputingType - indicate 
Legacy, SEV, TDX.

Patch-12:
Can we move all SEV stuff to a standalone file, such as AmdSev.c?

I am not sure if you want to do it, or you leave Min to do it.

Patch-18:
If we have a standalone AmdSev.c (#12), then we can move the function to that 
file, and only leave a hook call to SEV.

Patch-23:
This is UEFI CPU package update. I am thinking if we can follow same patter to 
move all SEV stuff to a standalone file, such as AmdSev.c, AmdSev.asm.
In the future, we may add TDX stuff as well.

Patch-26:
Same comment as #23. 

Patch-27:
Can we move that function to a standalone AmdSev.c ?

Patch-28:
Would you please describe more on what is ConfidentialComputingBlob ?
Is that generic concept? Or SEV specific thing?
Who is consumer?
What is difference between ConfidentialComputingSecret and 
ConfidentialComputingBlob ? When to use which?

I can understand how TDX use ConfidentialComputingSecret, but how do you expect 
TDX use ConfidentialComputingBlob (if it is a generic concept) ?

Thank you
Yao Jiewen



> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, July 29, 2021 12:38 AM
> To: devel@edk2.groups.io; brijesh.si...@amd.com
> Cc: James Bottomley ; Xu, Min M ;
> Tom Lendacky ; Justen, Jordan L
> ; Ard Biesheuvel ;
> Laszlo Ersek ; Erdem Aktas ;
> Dong, Eric ; Ni, Ray ; Kumar, Rahul1
> ; Kinney, Michael D ;
> Liming Gao ; Liu, Zhiguang
> ; Michael Roth 
> Subject: RE: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging
> (SEV-SNP) support
> 
> Sounds good. Thank you to confirm that.
> 
> I will send my feedback.
> 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Brijesh
> > Singh via groups.io
> > Sent: Wednesday, July 28, 2021 11:22 PM
> > To: Yao, Jiewen ; devel@edk2.groups.io
> > Cc: brijesh.si...@amd.com; James Bottomley ; Xu, Min
> M
> > ; Tom Lendacky ; Justen,
> > Jordan L ; Ard Biesheuvel
> > ; Laszlo Ersek ; Erdem
> Aktas
> > ; Dong, Eric ; Ni, Ray
> > ; Kumar, Rahul1 ; Kinney,
> Michael
> > D ; Liming Gao ;
> Liu,
> > Zhiguang ; Michael Roth 
> > Subject: Re: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested
> Paging
> > (SEV-SNP) support
> >
> > Hi Yao Jiewen,
> >
> > On 7/28/21 3:16 AM, Yao, Jiewen wrote:
> > > Hi Brijesh
> > > I reviewed the patch set. I have some basic questions.
> > > Please help me understand before I post my comment
> > >
> > > If a platform supports SEV-SNP, can we assume SEV-ES is supported?
> >
> > The SEV-SNP depends on SEV and SEV-ES support.
> >
> > The 

Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Wang, Jian J]

Thanks for the RFC. I'm not object to this idea. The only concern from me
is the potential security holes introduced by the changes. According to your
description, it allows 3rd party software to violate memory protection policy.
I'd like to see more explanations on how to avoid it to be exploited.

+Jiewen, what's current process to evaluate the security threat?

Regards,
Jian

> -Original Message-
> From: Taylor Beebe 
> Sent: Friday, July 23, 2021 8:33 AM
> To: devel@edk2.groups.io
> Cc: spbro...@outlook.com; Dong, Eric ; Ni, Ray
> ; Kumar, Rahul1 ;
> mikub...@linux.microsoft.com; Wang, Jian J ; Wu,
> Hao A ; Bi, Dandan ;
> gaolim...@byosoft.com.cn; Dong, Guo ; Ma, Maurice
> ; You, Benjamin 
> Subject: [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings
> 
> Current memory protection settings rely on FixedAtBuild PCD values
> (minus PcdSetNxForStack). Because of this, the memory protection
> configuration interface is fixed in nature. Cases arise in which memory
> protections might need to be adjusted between boots (if platform design
> allows) to avoid disabling a system. For example, platforms might choose
> to allow the user to control their protection policies such as allow
> execution of critical 3rd party software that might violate memory
> protections.
> 
> This RFC seeks your feedback regarding introducing an interface that
> allows dynamic configuration of memory protection settings.
> 
> I would like to propose two options:
> 1. Describing the memory protection setting configuration in a HOB that
> is produced by the platform.
> 2. Introducing a library class (e.g. MemoryProtectionLib) that allows
> abstraction of the memory protection setting configuration data source.
> 
> In addition, I would like to know if the memory protection FixedAtBuild
> PCDs currently in MdeModulePkg can be removed so we can move the
> configuration interface entirely to an option above.
> 
> In any case, I would like the settings to be visible to environments
> such as Standalone MM where dynamic PCDs are not accessible.
> 
> I am seeking your feedback on this proposal in preparation for sending
> an edk2 patch series.
> 
> --
> Taylor Beebe
> Software Engineer @ Microsoft


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78331): https://edk2.groups.io/g/devel/message/78331
Mute This Topic: https://groups.io/mt/84392478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] KabylakeOpenBoardPkg/PeiSerialPortLibSpiFlash: Remove PPI from HOB

[Nate DeSimone]

Pushed: https://github.com/tianocore/edk2-platforms/commit/8c9335e

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, July 9, 2021 9:08 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Benjamin Doron
> 
> Subject: [edk2-platforms][PATCH v1 1/1]
> KabylakeOpenBoardPkg/PeiSerialPortLibSpiFlash: Remove PPI from HOB
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3486
> 
> The PPI pointer should not be cached in a HOB as it could get out of sync with
> the current pointers in the PPI list.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Benjamin Doron 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiS
> erialPortLibSpiFlash.c | 114 +---
>  1 file changed, 48 insertions(+), 66 deletions(-)
> 
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/P
> eiSerialPortLibSpiFlash.c
> b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/P
> eiSerialPortLibSpiFlash.c
> index 0230149a38c4..fc48bdc6fccb 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/P
> eiSerialPortLibSpiFlash.c
> +++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFla
> +++ sh/PeiSerialPortLibSpiFlash.c
> @@ -2,6 +2,7 @@
>Serial I/O Port library implementation for output to SPI flash
> 
>  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +Copyright (c) Microsoft Corporation.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -17,40 +18,23 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> #include 
> 
>  typedef struct {
> -  PCH_SPI_PPI   *PchSpiPpi;
>UINT32CurrentWriteOffset;
>  } SPI_FLASH_DEBUG_CONTEXT;
> 
>  /**
> -  Update reference to the most recent PCH SPI PPI installed
> +  Returns a pointer to the PCH SPI PPI.
> 
> -  @param PeiServices   An indirect pointer to the EFI_PEI_SERVICES table
> published by the PEI Foundation
> -  @param NotifyDescriptor  Address of the notification descriptor data
> structure.
> -  @param Ppi   Address of the PPI that was installed.
> -
> -  @retval EFI_SUCCESS  Successfully update the PCH SPI PPI reference
> -  @retval EFI_NOT_FOUNDAn error occurred locating a required interface
> -  @retval EFI_NOT_SUPPORTED
> +  @return Pointer to PCH_SPI_PPIIf an instance of the PCH SPI PPI is
> found
> +  @return NULL  If an instance of the PCH SPI PPI is not 
> found
> 
>  **/
> -EFI_STATUS
> -EFIAPI
> -SpiPpiNotifyCallback (
> -  IN EFI_PEI_SERVICES   **PeiServices,
> -  IN EFI_PEI_NOTIFY_DESCRIPTOR  *NotifyDescriptor,
> -  IN VOID   *Ppi
> +PCH_SPI_PPI *
> +GetSpiPpi (
> +  VOID
>)
>  {
> -  EFI_STATUSStatus;
> -  EFI_HOB_GUID_TYPE *GuidHob;
> -  PCH_SPI_PPI   *PchSpiPpi;
> -  SPI_FLASH_DEBUG_CONTEXT   *Context;
> -
> -  GuidHob = GetFirstGuidHob ();
> -  if (GuidHob == NULL) {
> -return EFI_NOT_FOUND;
> -  }
> -  Context = GET_GUID_HOB_DATA (GuidHob);
> +  EFI_STATUSStatus;
> +  PCH_SPI_PPI   *PchSpiPpi;
> 
>Status =  PeiServicesLocatePpi (
>,
> @@ -59,27 +43,17 @@ SpiPpiNotifyCallback (
>(VOID **) 
>);
>if (EFI_ERROR (Status)) {
> -return EFI_NOT_FOUND;
> +return NULL;
>}
> 
> -  Context->PchSpiPpi = PchSpiPpi;
> -
> -  return EFI_SUCCESS;
> +  return PchSpiPpi;
>  }
> 
> -EFI_PEI_NOTIFY_DESCRIPTOR mSpiPpiNotifyList[] = {
> -  {
> -(EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> -,
> -SpiPpiNotifyCallback
> -  }
> -};
> -
>  /**
>Common function to write trace data to a chosen debug interface like
>UART Serial device, USB Serial device or Trace Hub device
> 
> -  @param  Buffer   Point of data buffer which need to be writed.
> +  @param  Buffer   Point of data buffer which needs to be written.
>@param  NumberOfBytesNumber of output bytes which are cached in
> Buffer.
> 
>  **/
> @@ -93,6 +67,7 @@ SerialPortWrite (
>EFI_STATUSStatus;
>EFI_HOB_GUID_TYPE *GuidHob;
>SPI_FLASH_DEBUG_CONTEXT   *Context;
> +  PCH_SPI_PPI   *PchSpiPpi;
>UINT32BytesWritten;
>UINT32SourceBufferOffset;
>UINT32NvMessageAreaSize;
> @@ -111,18 +86,22 @@ SerialPortWrite (
>  return 0;
>}
>Context = GET_GUID_HOB_DATA (GuidHob);
> -  if (Context == NULL || Context->PchSpiPpi == NULL || Context-
> >CurrentWriteOffset >= NvMessageAreaSize) {
> +  if (Context == NULL || Context->CurrentWriteOffset >=
> NvMessageAreaSize) {
> +return 0;
> +  }
> +  PchSpiPpi = GetSpiPpi ();
> +  if (PchSpiPpi == NULL) {
>  return 0;
>}
> 
>if ((Context->CurrentWriteOffset + NumberOfBytes) / NvMessageAreaSize
> > 0) {
>

Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] KabylakeOpenBoardPkg/PeiSerialPortLibSpiFlash: Remove PPI from HOB

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, July 9, 2021 9:08 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Benjamin Doron
> 
> Subject: [edk2-platforms][PATCH v1 1/1]
> KabylakeOpenBoardPkg/PeiSerialPortLibSpiFlash: Remove PPI from HOB
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3486
> 
> The PPI pointer should not be cached in a HOB as it could get out of sync with
> the current pointers in the PPI list.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Benjamin Doron 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/PeiS
> erialPortLibSpiFlash.c | 114 +---
>  1 file changed, 48 insertions(+), 66 deletions(-)
> 
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/P
> eiSerialPortLibSpiFlash.c
> b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/P
> eiSerialPortLibSpiFlash.c
> index 0230149a38c4..fc48bdc6fccb 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFlash/P
> eiSerialPortLibSpiFlash.c
> +++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/PeiSerialPortLibSpiFla
> +++ sh/PeiSerialPortLibSpiFlash.c
> @@ -2,6 +2,7 @@
>Serial I/O Port library implementation for output to SPI flash
> 
>  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +Copyright (c) Microsoft Corporation.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -17,40 +18,23 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> #include 
> 
>  typedef struct {
> -  PCH_SPI_PPI   *PchSpiPpi;
>UINT32CurrentWriteOffset;
>  } SPI_FLASH_DEBUG_CONTEXT;
> 
>  /**
> -  Update reference to the most recent PCH SPI PPI installed
> +  Returns a pointer to the PCH SPI PPI.
> 
> -  @param PeiServices   An indirect pointer to the EFI_PEI_SERVICES table
> published by the PEI Foundation
> -  @param NotifyDescriptor  Address of the notification descriptor data
> structure.
> -  @param Ppi   Address of the PPI that was installed.
> -
> -  @retval EFI_SUCCESS  Successfully update the PCH SPI PPI reference
> -  @retval EFI_NOT_FOUNDAn error occurred locating a required interface
> -  @retval EFI_NOT_SUPPORTED
> +  @return Pointer to PCH_SPI_PPIIf an instance of the PCH SPI PPI is
> found
> +  @return NULL  If an instance of the PCH SPI PPI is not 
> found
> 
>  **/
> -EFI_STATUS
> -EFIAPI
> -SpiPpiNotifyCallback (
> -  IN EFI_PEI_SERVICES   **PeiServices,
> -  IN EFI_PEI_NOTIFY_DESCRIPTOR  *NotifyDescriptor,
> -  IN VOID   *Ppi
> +PCH_SPI_PPI *
> +GetSpiPpi (
> +  VOID
>)
>  {
> -  EFI_STATUSStatus;
> -  EFI_HOB_GUID_TYPE *GuidHob;
> -  PCH_SPI_PPI   *PchSpiPpi;
> -  SPI_FLASH_DEBUG_CONTEXT   *Context;
> -
> -  GuidHob = GetFirstGuidHob ();
> -  if (GuidHob == NULL) {
> -return EFI_NOT_FOUND;
> -  }
> -  Context = GET_GUID_HOB_DATA (GuidHob);
> +  EFI_STATUSStatus;
> +  PCH_SPI_PPI   *PchSpiPpi;
> 
>Status =  PeiServicesLocatePpi (
>,
> @@ -59,27 +43,17 @@ SpiPpiNotifyCallback (
>(VOID **) 
>);
>if (EFI_ERROR (Status)) {
> -return EFI_NOT_FOUND;
> +return NULL;
>}
> 
> -  Context->PchSpiPpi = PchSpiPpi;
> -
> -  return EFI_SUCCESS;
> +  return PchSpiPpi;
>  }
> 
> -EFI_PEI_NOTIFY_DESCRIPTOR mSpiPpiNotifyList[] = {
> -  {
> -(EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> -,
> -SpiPpiNotifyCallback
> -  }
> -};
> -
>  /**
>Common function to write trace data to a chosen debug interface like
>UART Serial device, USB Serial device or Trace Hub device
> 
> -  @param  Buffer   Point of data buffer which need to be writed.
> +  @param  Buffer   Point of data buffer which needs to be written.
>@param  NumberOfBytesNumber of output bytes which are cached in
> Buffer.
> 
>  **/
> @@ -93,6 +67,7 @@ SerialPortWrite (
>EFI_STATUSStatus;
>EFI_HOB_GUID_TYPE *GuidHob;
>SPI_FLASH_DEBUG_CONTEXT   *Context;
> +  PCH_SPI_PPI   *PchSpiPpi;
>UINT32BytesWritten;
>UINT32SourceBufferOffset;
>UINT32NvMessageAreaSize;
> @@ -111,18 +86,22 @@ SerialPortWrite (
>  return 0;
>}
>Context = GET_GUID_HOB_DATA (GuidHob);
> -  if (Context == NULL || Context->PchSpiPpi == NULL || Context-
> >CurrentWriteOffset >= NvMessageAreaSize) {
> +  if (Context == NULL || Context->CurrentWriteOffset >=
> NvMessageAreaSize) {
> +return 0;
> +  }
> +  PchSpiPpi = GetSpiPpi ();
> +  if (PchSpiPpi == NULL) {
>  return 0;
>}
> 
>if ((Context->CurrentWriteOffset + NumberOfBytes) / NvMessageAreaSize
> > 0) {
>  LinearOffset = (UINT32) 

Re: [edk2-devel] [edk2-non-osi] [PATCH] ASpeed : ASpeedGopBinPkg : Add X64 ASpeedAst2500Gop UEFI Driver

[Nate DeSimone]

Pushed: https://github.com/tianocore/edk2-non-osi/commit/7c28b7d

> -Original Message-
> From: manickavasakam karpagavinayagam 
> Sent: Wednesday, June 16, 2021 2:51 PM
> To: devel@edk2.groups.io
> Cc: Oram, Isaac W ; Desimone, Nathaniel L
> ; fel...@ami.com; DOPPALAPUDI,
> HARIKRISHNA ; Jha, Manish ;
> Bobroff, Zachary ; KARPAGAVINAYAGAM,
> MANICKAVASAKAM 
> Subject: [edk2-non-osi] [PATCH] ASpeed : ASpeedGopBinPkg : Add X64
> ASpeedAst2500Gop UEFI Driver
> 
> Add X64 ASpeedAst2500Gop UEFI Driver
> ---
>  .../ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf |   4 
>  .../ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi| Bin 0 -> 36928 bytes
>  2 files changed, 4 insertions(+)
>  create mode 100644
> Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi
> 
> diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> index b3cee45..b563f76 100644
> --- a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> +++ b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> @@ -3,6 +3,7 @@
>  #
> 
>  #  Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
> 
>  #  Copyright (c) 2020, ASPEED Technology Inc. All rights reserved.
> 
> +#  Copyright (c) 2021, American Megatrends International LLC.
> 
>  #
> 
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #
> 
> @@ -17,3 +18,6 @@
> 
> 
>  [Binaries.AArch64]
> 
>PE32|AArch64/ASpeedAst2500Gop.efi|*
> 
> +
> 
> +[Binaries.X64]
> 
> +  PE32|X64/ASpeedAst2500Gop.efi|*
> 
> diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi
> b/Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi
> new file mode 100644
> index
> ..07d9de0fe5241bf26d516f3522
> a930880a57f5c5
> GIT binary patch
> literal 36928
> zcmeIbeS8$v^*=tF-H;^-nMH#Q5@nT*Mjj*()Ih-
> Ogk6}GU5SKfT0u8LLQ;8%$u198
> zba4~S?zon=+G; NC6ds5A5%K?#%3NLh#dX
> zKfgb|ukWiXleu&5x#ym9?z!ild*{y8^{ V
> z+=hCNGZ!dXzBG=bOZ%CTpljgIx;}}QH8Ar6&!!8&2LpG0pX2VMi~z^w4~Fn>!
> mjny
> zuJ)j;A2O4iBzvm7MApo4_17-
> 0@zfx_;c`6RoxD@N_Oo(ax0deIb6h8Q)$SUc?pBT~
> zzjn1ku#of{0!+Q1hu2iQbj2b?cG7_l2y{>VSwT+>EU*}F6aB}`Vqn-W9^yDrIxI?O
> z#nxTkOG394i=konuH`sqD7_Ll`KLDnA#m9e!fSoUdkNsr0v@WI3dCCoV>Mw&
> Gu>h!
> z-NCRr8P?ATtD+28;|Ob>f>jNy;uNfJ-A`B(fmMK%Jf30gle59JC@ruQiT)ktJGbv~
> zO7A)Xw;LUSO4F_2-
> 0JWzI>Cvd^v!4kM_{Jx3=Oj*3CQ1<5M+)C&|dI5SAjl3x4^I(
> z1-
> (ZMjTk}@Dg7s{ETe*<4RhcYUoYw?tLJ6#;1gRr*UWQDohb3lYL1ik$~qTQ
> zk0#8}uySJk9)e5Tf%rWIvB${}A1B0H(Plt=5ouWjB5J-
> 2HG@Io*IvA zjmSh&3^^^;30{beu?icPfrbb^)+pq!C-O@b^4}ryQNTs;0qs>ld)7O)@7c3Qly-=L
> zYLggf%%hfXbV`mwXUJ+4r7uM3 uS1%Vs
> zHcOFB+ARib7IUcblqj`Wd?;!!?i8i?W;cRKW!a$Mb1;Cr(>IJ1(T?8y{g
> zg0<7n2lAJKJSv-
> m%AC@yLZ`G3OvKllnf|vsLkld84(awhhtzC#NFTrq_AuKO1M@AW
> zs#|Xp<_lHAt-@`hbPO_8ymSIua7ZVlH=I(`KKUPVC269ylW+MiWJqs-
> MS1B>Bo{Hs
> zx3rSdx;UY7eu*=*+UW3KjrM3XiIPhMQ(I~YGkukx<6P2Cm*gt!vRMk5q5@8f
> S=EZv
> zN2J=0gJXv@#2K2C2VE2=51>T(q*#kq7aSEBr|(gw~` zPL
> z$d}%E)NBXe`$zbd!R0h+*V0`@(P^DH+J>j*U_7;Y2HHsluwS2z=03_ A2-d
> zF8cybr}N1c>SLj*>KIREv<=qS(&@cOl-
> >g26Y}A?$PLU~9ZMJei%c6u&{
> zF75^c(99!?AuN;yejU_YN_W{UTdzj8D)M`bt=+O^LK3!%V19HCzU5#
> 2>Gi
> zcDa}1UPP8pehQqUb9@_su$9CL4O@$}oK5ZLUu-
> D>WM)0tVUZY`Q;mLq6}X~jnDxvO
> zF#Ga4qA=|FMFd8Jf$>j~PT`oEZuJcgDFa#E$f7nzQ V89IpF17fKyzUEf6
> z7m9nX6MSFkyu+a-H2f}V*w8IHw5dztLA8l0m(q(-
> +9B<7N%lg`xYI`iCQ7^G6=Ez?
> zd}S!=!p|p4U83}q1p_3c+)*LiDcm6}6c*fh$HJuTFSVc>dn{(^$3+e)!n$x2ZR8!}
> zlmv95*HC4r4-
> `TpPTs|8R%(s%I_hWC@ojJo5^Q8dFA#wK1E7=4X;g9GzJz&`ZNEb>
> z#hGmH7T1+hfAL&~#+i=6F#Hy1qH%hg(Ksta4HHJgngK0UNUiW~R?Qr$aXBSb
> wO)#9
> z zfgB;^(1=qtBrvL#_Bm6P|4T-
> TluwRpfyF9HOD(9xW2uJPi{NOW+Y%U64VZOG=+3v8
> z#L{k;)a{U7;~(pU@DC%W4aOlKCU5TFQGzlwu8M?Gsf-
> SL#E&*rA6q@$*G#To$G4
> zdWb`%InuKgre^@8xf-Xm7e+#aHHQO}9Ss3{G2%eL;Y`5YPO{qFN-
> M{HD!!P@DuFqb
> zM!b?!a$4Mw<#FJO(rqR%|659y_KDK#5Qa%f_U^G_hxov<)h@2he!AKB?
> sg#kU
> z&*-_{-
> )HiC%im}Ae#g;e_z3W(fS4bfCUjX%Tp!2bp4*!NBkZ!~jRr<6k8*mE
> zq8y6OD2KFy=j=4POICxwGsEB8Cj_kK Dw|
> zAnB}U6eQem4{S3Ca-
> ?R7!
> zUi^v$VCii+XBKh;)Y-k+Vu#jIV>dejH;N&{?|=llmx%gT(E?J7|0z5N$_@Rq0N=pi
> zM(ItbG(`UGxp=&|6CJ;Un8DAd#5%A-
> xGoRb<9)D4ggydBZ)$!>zSNSJ==Tu)o^A}?
> z>u#jpC`yNz(9bqP=uVJ>&=a8m`R_Jj?o;%VywZ}URP(zG%_T~Y_M(0 QK&2
> zLw7?5^KYaaPI~P3Bv0gMnw~UMKoy{+sUmtn!DJ&*DE^5F I{qidl
> zsiK*Afz<}OiIQlPS{T)UkP6uVA^`zC6$TG97zycLl7!6|h~Z^(^b$Ky`v
> zRv59 e@Tx$%1o5mkbhf7 z)*K3XhX9%v%MkV5V!)NR^C4y*id%qUmr`4Jl(zUE;t#hNTGQ )Z>)C
> za7rgVqhXNz3bc(HF8I-
> 9ZBPA{lv3a^#8RD
> zY0jGicPB=A)5Jh40UXk-Jg4M!JEhu2Ni;|Y#1M2BGWc*k41r{c^M9%H
> z7~#a
> z)hI_OdlK?~sOI-bK5AHGt(=l-
> gil#E5ZJ%NojUY@%6OvkCWgj(QNK6#XLz7H?!{P5
> z;ZVE+c4 1F@&1g
> z)g!#Z?Liwp$=dEqv)3rRVg?|V?f=r$VM5Bu+xkSwUN3aeG)t7Kdd1TH&3ac>p
> MaRb
> z#JNg8qo=d3);>?J7=KNScZ>SBMEy=N0MvlJ-
> qm{6lkJG_b;S3$^q;%*|1GT}CHS{z
> zz~4k-`WO4+@i=U1OeD 2^F8vdQ_ulEFog{O*(j{uC(i^3cwwW0B^TovoXO#A
> z1(1~oMENp6G3wNZO@KNgy(Sd3XYG*F6?ktrHx<59{-
> hXGA|IN z*e-
> R2rz^DOorDG^J_MQQAEEF$A;Y!Q z4#L3rmcIcAjrY1jH=Pp^KftV< o0Vy
> zg~L@57p3o$D~R+Ov-SgEJr_BOltaI(Jdmr4)nI7w-
> XH|6am!cy7DC|agfU%pk>2z=
> z;0LYeI%Pe-
> 

Re: [edk2-devel] [edk2-non-osi] [PATCH] ASpeed : ASpeedGopBinPkg : Add X64 ASpeedAst2500Gop UEFI Driver

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: manickavasakam karpagavinayagam 
> Sent: Wednesday, June 16, 2021 2:51 PM
> To: devel@edk2.groups.io
> Cc: Oram, Isaac W ; Desimone, Nathaniel L
> ; fel...@ami.com; DOPPALAPUDI,
> HARIKRISHNA ; Jha, Manish ;
> Bobroff, Zachary ; KARPAGAVINAYAGAM,
> MANICKAVASAKAM 
> Subject: [edk2-non-osi] [PATCH] ASpeed : ASpeedGopBinPkg : Add X64
> ASpeedAst2500Gop UEFI Driver
> 
> Add X64 ASpeedAst2500Gop UEFI Driver
> ---
>  .../ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf |   4 
>  .../ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi| Bin 0 -> 36928 bytes
>  2 files changed, 4 insertions(+)
>  create mode 100644
> Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi
> 
> diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> index b3cee45..b563f76 100644
> --- a/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> +++ b/Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf
> @@ -3,6 +3,7 @@
>  #
> 
>  #  Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
> 
>  #  Copyright (c) 2020, ASPEED Technology Inc. All rights reserved.
> 
> +#  Copyright (c) 2021, American Megatrends International LLC.
> 
>  #
> 
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #
> 
> @@ -17,3 +18,6 @@
> 
> 
>  [Binaries.AArch64]
> 
>PE32|AArch64/ASpeedAst2500Gop.efi|*
> 
> +
> 
> +[Binaries.X64]
> 
> +  PE32|X64/ASpeedAst2500Gop.efi|*
> 
> diff --git a/Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi
> b/Drivers/ASpeed/ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi
> new file mode 100644
> index
> ..07d9de0fe5241bf26d516f3522
> a930880a57f5c5
> GIT binary patch
> literal 36928
> zcmeIbeS8$v^*=tF-H;^-nMH#Q5@nT*Mjj*()Ih-
> Ogk6}GU5SKfT0u8LLQ;8%$u198
> zba4~S?zon=+G; NC6ds5A5%K?#%3NLh#dX
> zKfgb|ukWiXleu&5x#ym9?z!ild*{y8^{ V
> z+=hCNGZ!dXzBG=bOZ%CTpljgIx;}}QH8Ar6&!!8&2LpG0pX2VMi~z^w4~Fn>!
> mjny
> zuJ)j;A2O4iBzvm7MApo4_17-
> 0@zfx_;c`6RoxD@N_Oo(ax0deIb6h8Q)$SUc?pBT~
> zzjn1ku#of{0!+Q1hu2iQbj2b?cG7_l2y{>VSwT+>EU*}F6aB}`Vqn-W9^yDrIxI?O
> z#nxTkOG394i=konuH`sqD7_Ll`KLDnA#m9e!fSoUdkNsr0v@WI3dCCoV>Mw&
> Gu>h!
> z-NCRr8P?ATtD+28;|Ob>f>jNy;uNfJ-A`B(fmMK%Jf30gle59JC@ruQiT)ktJGbv~
> zO7A)Xw;LUSO4F_2-
> 0JWzI>Cvd^v!4kM_{Jx3=Oj*3CQ1<5M+)C&|dI5SAjl3x4^I(
> z1-
> (ZMjTk}@Dg7s{ETe*<4RhcYUoYw?tLJ6#;1gRr*UWQDohb3lYL1ik$~qTQ
> zk0#8}uySJk9)e5Tf%rWIvB${}A1B0H(Plt=5ouWjB5J-
> 2HG@Io*IvA zjmSh&3^^^;30{beu?icPfrbb^)+pq!C-O@b^4}ryQNTs;0qs>ld)7O)@7c3Qly-=L
> zYLggf%%hfXbV`mwXUJ+4r7uM3 uS1%Vs
> zHcOFB+ARib7IUcblqj`Wd?;!!?i8i?W;cRKW!a$Mb1;Cr(>IJ1(T?8y{g
> zg0<7n2lAJKJSv-
> m%AC@yLZ`G3OvKllnf|vsLkld84(awhhtzC#NFTrq_AuKO1M@AW
> zs#|Xp<_lHAt-@`hbPO_8ymSIua7ZVlH=I(`KKUPVC269ylW+MiWJqs-
> MS1B>Bo{Hs
> zx3rSdx;UY7eu*=*+UW3KjrM3XiIPhMQ(I~YGkukx<6P2Cm*gt!vRMk5q5@8f
> S=EZv
> zN2J=0gJXv@#2K2C2VE2=51>T(q*#kq7aSEBr|(gw~` zPL
> z$d}%E)NBXe`$zbd!R0h+*V0`@(P^DH+J>j*U_7;Y2HHsluwS2z=03_ A2-d
> zF8cybr}N1c>SLj*>KIREv<=qS(&@cOl-
> >g26Y}A?$PLU~9ZMJei%c6u&{
> zF75^c(99!?AuN;yejU_YN_W{UTdzj8D)M`bt=+O^LK3!%V19HCzU5#
> 2>Gi
> zcDa}1UPP8pehQqUb9@_su$9CL4O@$}oK5ZLUu-
> D>WM)0tVUZY`Q;mLq6}X~jnDxvO
> zF#Ga4qA=|FMFd8Jf$>j~PT`oEZuJcgDFa#E$f7nzQ V89IpF17fKyzUEf6
> z7m9nX6MSFkyu+a-H2f}V*w8IHw5dztLA8l0m(q(-
> +9B<7N%lg`xYI`iCQ7^G6=Ez?
> zd}S!=!p|p4U83}q1p_3c+)*LiDcm6}6c*fh$HJuTFSVc>dn{(^$3+e)!n$x2ZR8!}
> zlmv95*HC4r4-
> `TpPTs|8R%(s%I_hWC@ojJo5^Q8dFA#wK1E7=4X;g9GzJz&`ZNEb>
> z#hGmH7T1+hfAL&~#+i=6F#Hy1qH%hg(Ksta4HHJgngK0UNUiW~R?Qr$aXBSb
> wO)#9
> z zfgB;^(1=qtBrvL#_Bm6P|4T-
> TluwRpfyF9HOD(9xW2uJPi{NOW+Y%U64VZOG=+3v8
> z#L{k;)a{U7;~(pU@DC%W4aOlKCU5TFQGzlwu8M?Gsf-
> SL#E&*rA6q@$*G#To$G4
> zdWb`%InuKgre^@8xf-Xm7e+#aHHQO}9Ss3{G2%eL;Y`5YPO{qFN-
> M{HD!!P@DuFqb
> zM!b?!a$4Mw<#FJO(rqR%|659y_KDK#5Qa%f_U^G_hxov<)h@2he!AKB?
> sg#kU
> z&*-_{-
> )HiC%im}Ae#g;e_z3W(fS4bfCUjX%Tp!2bp4*!NBkZ!~jRr<6k8*mE
> zq8y6OD2KFy=j=4POICxwGsEB8Cj_kK Dw|
> zAnB}U6eQem4{S3Ca-
> ?R7!
> zUi^v$VCii+XBKh;)Y-k+Vu#jIV>dejH;N&{?|=llmx%gT(E?J7|0z5N$_@Rq0N=pi
> zM(ItbG(`UGxp=&|6CJ;Un8DAd#5%A-
> xGoRb<9)D4ggydBZ)$!>zSNSJ==Tu)o^A}?
> z>u#jpC`yNz(9bqP=uVJ>&=a8m`R_Jj?o;%VywZ}URP(zG%_T~Y_M(0 QK&2
> zLw7?5^KYaaPI~P3Bv0gMnw~UMKoy{+sUmtn!DJ&*DE^5F I{qidl
> zsiK*Afz<}OiIQlPS{T)UkP6uVA^`zC6$TG97zycLl7!6|h~Z^(^b$Ky`v
> zRv59 e@Tx$%1o5mkbhf7 z)*K3XhX9%v%MkV5V!)NR^C4y*id%qUmr`4Jl(zUE;t#hNTGQ )Z>)C
> za7rgVqhXNz3bc(HF8I-
> 9ZBPA{lv3a^#8RD
> zY0jGicPB=A)5Jh40UXk-Jg4M!JEhu2Ni;|Y#1M2BGWc*k41r{c^M9%H
> z7~#a
> z)hI_OdlK?~sOI-bK5AHGt(=l-
> gil#E5ZJ%NojUY@%6OvkCWgj(QNK6#XLz7H?!{P5
> z;ZVE+c4 1F@&1g
> z)g!#Z?Liwp$=dEqv)3rRVg?|V?f=r$VM5Bu+xkSwUN3aeG)t7Kdd1TH&3ac>p
> MaRb
> z#JNg8qo=d3);>?J7=KNScZ>SBMEy=N0MvlJ-
> qm{6lkJG_b;S3$^q;%*|1GT}CHS{z
> zz~4k-`WO4+@i=U1OeD 2^F8vdQ_ulEFog{O*(j{uC(i^3cwwW0B^TovoXO#A
> z1(1~oMENp6G3wNZO@KNgy(Sd3XYG*F6?ktrHx<59{-
> hXGA|IN z*e-
> R2rz^DOorDG^J_MQQAEEF$A;Y!Q z4#L3rmcIcAjrY1jH=Pp^KftV< o0Vy
> zg~L@57p3o$D~R+Ov-SgEJr_BOltaI(Jdmr4)nI7w-
> XH|6am!cy7DC|agfU%pk>2z=
> z;0LYeI%Pe-
> rCXF9CMtE2qx!n619d1{5i6i 

Re: [edk2-devel] [PATCH v2 0/3] Move the SEV specific changes in ResetVector in separate file

[Yao, Jiewen]

Pushed.

https://github.com/tianocore/edk2/pull/1842

githash: 
dc485c556d5f5db21debe8de3a45a7564aacbe24..b461d67639f2deced77e9bb967d014b7cfcd75f8


> -Original Message-
> From: Brijesh Singh 
> Sent: Wednesday, July 28, 2021 2:10 AM
> To: devel@edk2.groups.io
> Cc: Brijesh Singh ; James Bottomley
> ; Xu, Min M ; Yao, Jiewen
> ; Tom Lendacky ; Justen,
> Jordan L ; Ard Biesheuvel
> ; Laszlo Ersek ; Erdem Aktas
> 
> Subject: [PATCH v2 0/3] Move the SEV specific changes in ResetVector in
> separate file
> 
> The PageTable64.asm was created to build the initial page table,
> but over the time it grew to include bunch of the SEV specific code
> which does not directly manipulates the pagetable. Before adding more
> to it, let's move all the SEV-specific routines into a separate file.
> 
> The series is taken from SNP RFCv4. And there is no functionality change
> intended. Its just moving the code from one place to another.
> 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> Cc: Erdem Aktas 
> 
> The full branch is available at:
> https://github.com/AMDESE/ovmf/pull/new/refactor-reset-vector
> 
> Changelog:
>  - fix the copyright header in AmdSev.asm
> 
> Brijesh Singh (3):
>   OvmfPkg/ResetVector: move SEV specific code in a separate file
>   OvmfPkg/ResetVector: add the macro to invoke MSR protocol based
> VMGEXIT
>   OvmfPkg/ResetVector: add the macro to request guest termination
> 
>  .../Ia32/{PageTables64.asm => AmdSev.asm} | 297 -
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 391 --
>  OvmfPkg/ResetVector/ResetVector.nasmb |   1 +
>  3 files changed, 92 insertions(+), 597 deletions(-)
>  copy OvmfPkg/ResetVector/Ia32/{PageTables64.asm => AmdSev.asm} (66%)
> 
> --
> 2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78324): https://edk2.groups.io/g/devel/message/78324
Mute This Topic: https://groups.io/mt/84487943/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v4 41/41] TigerlakeSiliconPkg/BasePchSpiCommonLib: Identify flash regions by GUID

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, June 25, 2021 2:21 PM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Desimone,
> Nathaniel L ; Luo, Heng
> 
> Subject: [edk2-platforms][PATCH v4 41/41]
> TigerlakeSiliconPkg/BasePchSpiCommonLib: Identify flash regions by GUID
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3307
> 
> Updates the library to identify flash regions by GUID and internally map the
> GUID entries to values specific to TigerlakeSiliconPkg.
> 
> Cc: Rangasai V Chaganty 
> Cc: Nate DeSimone 
> Cc: Heng Luo 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/LibraryPrivate/BaseSpiCommon
> Lib/SpiCommon.c  | 176 +---
> 
> Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/IncludePrivate/Library/SpiCom
> monLib.h|  16 +-
> 
> Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/LibraryPrivate/BaseSpiCommon
> Lib/BaseSpiCommonLib.inf |  18 +-
>  3 files changed, 177 insertions(+), 33 deletions(-)
> 
> diff --git
> a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/LibraryPrivate/BaseSpiComm
> onLib/SpiCommon.c
> b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/LibraryPrivate/BaseSpiComm
> onLib/SpiCommon.c
> index 954b349e7c8a..5f372a5b58cb 100644
> ---
> a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/LibraryPrivate/BaseSpiComm
> onLib/SpiCommon.c
> +++ b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Spi/LibraryPrivate/BaseS
> +++ piCommonLib/SpiCommon.c
> @@ -2,9 +2,12 @@
>PCH SPI Common Driver implements the SPI Host Controller Compatibility
> Interface.
> 
>Copyright (c) 2021, Intel Corporation. All rights reserved.
> +  Copyright (c) Microsoft Corporation.
> +
>SPDX-License-Identifier: BSD-2-Clause-Patent  **/  #include
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,6 +24,125 @@
>  #include 
>  #include 
> 
> +typedef enum {
> +  FlashRegionDescriptor,
> +  FlashRegionBios,
> +  FlashRegionMe,
> +  FlashRegionGbe,
> +  FlashRegionPlatformData,
> +  FlashRegionDer,
> +  FlashRegionSecondaryBios,
> +  FlashRegionMicrocodePatch,
> +  FlashRegionEc,
> +  FlashRegionDeviceExpansion,
> +  FlashRegionIe,
> +  FlashRegion10GbeA,
> +  FlashRegion10GbeB,
> +  FlashRegionAll = 16,
> +  FlashRegionMax
> +} FLASH_REGION_TYPE;
> +
> +typedef struct {
> +  EFI_GUID*Guid;
> +  FLASH_REGION_TYPE   Type;
> +} FLASH_REGION_MAPPING;
> +
> +FLASH_REGION_MAPPING mFlashRegionTypes[] = {
> +  {
> +,
> +FlashRegionDescriptor
> +  },
> +  {
> +,
> +FlashRegionBios
> +  },
> +  {
> +,
> +FlashRegionMe
> +  },
> +  {
> +,
> +FlashRegionGbe
> +  },
> +  {
> +,
> +FlashRegionPlatformData
> +  },
> +  {
> +,
> +FlashRegionDer
> +  },
> +  {
> +,
> +FlashRegionSecondaryBios
> +  },
> +  {
> +,
> +FlashRegionMicrocodePatch
> +  },
> +  {
> +,
> +FlashRegionEc
> +  },
> +  {
> +,
> +FlashRegionDeviceExpansion
> +  },
> +  {
> +,
> +FlashRegionIe
> +  },
> +  {
> +,
> +FlashRegion10GbeA
> +  },
> +  {
> +,
> +FlashRegion10GbeB
> +  },
> +  {
> +,
> +FlashRegionAll
> +  },
> +  {
> +,
> +FlashRegionMax
> +  }
> +};
> +
> +/**
> +  Returns the type of a flash region given its GUID.
> +
> +  @param[in]FlashRegionGuid   Pointer to the flash region GUID.
> +  @param[out]   FlashRegionType   Pointer to a buffer that will be set to the
> flash region type value.
> +
> +  @retval   EFI_SUCCESS The flash region type was found for 
> the
> given flash region GUID.
> +  @retval   EFI_INVALID_PARAMETER   A pointer argument passed to the
> function is NULL.
> +  @retval   EFI_NOT_FOUND   The flash region type was not found 
> for
> the given flash region GUID.
> +
> +**/
> +EFI_STATUS
> +GetFlashRegionType (
> +  IN EFI_GUID   *FlashRegionGuid,
> +  OUTFLASH_REGION_TYPE  *FlashRegionType
> +  )
> +{
> +  UINTN   Index;
> +
> +  if (FlashRegionGuid == NULL || FlashRegionType == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  for (Index = 0; Index < ARRAY_SIZE (mFlashRegionTypes); Index++) {
> +if (CompareGuid (mFlashRegionTypes[Index].Guid, FlashRegionGuid)) {
> +  *FlashRegionType = mFlashRegionTypes[Index].Type;
> +  return EFI_SUCCESS;
> +}
> +  }
> +
> +  return EFI_NOT_FOUND;
> +}
> +
>  /**
>Initialize an SPI protocol instance.
> 
> @@ -179,7 +301,7 @@ SpiProtocolConstructor (
>ASSERT (SpiInstance->CpuStrapBaseAddr != 0);
> 
>if (SpiInstance->CpuStrapBaseAddr != 0x300) {
> -Status = SpiProtocolFlashRead (&(SpiInstance->SpiProtocol),
> FlashRegionAll, R_FLASH_UMAP1, sizeof (Data32), (UINT8 *) ());
> +Status = SpiProtocolFlashRead (&(SpiInstance->SpiProtocol),
> + , R_FLASH_UMAP1, sizeof (Data32), (UINT8 *)
> + ());
>  ASSERT_EFI_ERROR (Status);
>  Mdtba = (UINT16)(((Data32 & B_FLASH_UMAP1_MDTBA) 

Re: [edk2-devel] [edk2-platforms][PATCH v4 40/41] SimicsIch10Pkg/BasePchSpiCommonLib: Identify flash regions by GUID

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, June 25, 2021 2:21 PM
> To: devel@edk2.groups.io
> Cc: Agyeman, Prince ; Desimone, Nathaniel L
> 
> Subject: [edk2-platforms][PATCH v4 40/41]
> SimicsIch10Pkg/BasePchSpiCommonLib: Identify flash regions by GUID
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3307
> 
> Updates the library to identify flash regions by GUID and internally map the
> GUID entries to values specific to SimicsIch10Pkg.
> 
> Cc: Agyeman Prince 
> Cc: Nate DeSimone 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Silicon/Intel/SimicsIch10Pkg/LibraryPrivate/BasePchSpiCommonLib/SpiCom
> mon.c | 139 
>  Silicon/Intel/SimicsIch10Pkg/IncludePrivate/Library/PchSpiCommonLib.h
> |  20 +--
> 
> Silicon/Intel/SimicsIch10Pkg/LibraryPrivate/BasePchSpiCommonLib/BasePch
> SpiCommonLib.inf |  11 ++
>  3 files changed, 137 insertions(+), 33 deletions(-)
> 
> diff --git
> a/Silicon/Intel/SimicsIch10Pkg/LibraryPrivate/BasePchSpiCommonLib/SpiCo
> mmon.c
> b/Silicon/Intel/SimicsIch10Pkg/LibraryPrivate/BasePchSpiCommonLib/SpiCo
> mmon.c
> index fc2a8be76b6a..04dbd921c091 100644
> ---
> a/Silicon/Intel/SimicsIch10Pkg/LibraryPrivate/BasePchSpiCommonLib/SpiCo
> mmon.c
> +++ b/Silicon/Intel/SimicsIch10Pkg/LibraryPrivate/BasePchSpiCommonLib/Sp
> +++ iCommon.c
> @@ -2,11 +2,13 @@
>PCH SPI Common Driver implements the SPI Host Controller Compatibility
> Interface.
> 
>Copyright (c) 2019 Intel Corporation. All rights reserved. 
> +  Copyright (c) Microsoft Corporation.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent  **/
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -16,6 +18,90 @@
>  #include 
>  #include 
> 
> +typedef enum {
> +  FlashRegionDescriptor,
> +  FlashRegionBios,
> +  FlashRegionMe,
> +  FlashRegionGbe,
> +  FlashRegionPlatformData,
> +  FlashRegionDer,
> +  FlashRegionAll,
> +  FlashRegionMax
> +} FLASH_REGION_TYPE;
> +
> +typedef struct {
> +  EFI_GUID*Guid;
> +  FLASH_REGION_TYPE   Type;
> +} FLASH_REGION_MAPPING;
> +
> +FLASH_REGION_MAPPING mFlashRegionTypes[] = {
> +  {
> +,
> +FlashRegionDescriptor
> +  },
> +  {
> +,
> +FlashRegionBios
> +  },
> +  {
> +,
> +FlashRegionMe
> +  },
> +  {
> +,
> +FlashRegionGbe
> +  },
> +  {
> +,
> +FlashRegionPlatformData
> +  },
> +  {
> +,
> +FlashRegionDer
> +  },
> +  {
> +,
> +FlashRegionAll
> +  },
> +  {
> +,
> +FlashRegionMax
> +  }
> +};
> +
> +/**
> +  Returns the type of a flash region given its GUID.
> +
> +  @param[in]FlashRegionGuid   Pointer to the flash region GUID.
> +  @param[out]   FlashRegionType   Pointer to a buffer that will be set to the
> flash region type value.
> +
> +  @retval   EFI_SUCCESS The flash region type was found for 
> the
> given flash region GUID.
> +  @retval   EFI_INVALID_PARAMETER   A pointer argument passed to the
> function is NULL.
> +  @retval   EFI_NOT_FOUND   The flash region type was not found 
> for
> the given flash region GUID.
> +
> +**/
> +EFI_STATUS
> +GetFlashRegionType (
> +  IN EFI_GUID   *FlashRegionGuid,
> +  OUTFLASH_REGION_TYPE  *FlashRegionType
> +  )
> +{
> +  UINTN   Index;
> +
> +  if (FlashRegionGuid == NULL || FlashRegionType == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  for (Index = 0; Index < ARRAY_SIZE (mFlashRegionTypes); Index++) {
> +if (CompareGuid (mFlashRegionTypes[Index].Guid, FlashRegionGuid)) {
> +  *FlashRegionType = mFlashRegionTypes[Index].Type;
> +  return EFI_SUCCESS;
> +}
> +  }
> +
> +  return EFI_NOT_FOUND;
> +}
> +
>  /**
>Initialize an SPI protocol instance.
> 
> @@ -145,7 +231,7 @@ PchPmTimerStallRuntimeSafe (
>Read data from the flash part.
> 
>@param[in] This Pointer to the PCH_SPI_PROTOCOL instance.
> -  @param[in] FlashRegionType  The Flash Region type for flash cycle which
> is listed in the Descriptor.
> +  @param[in] FlashRegionGuid  The Flash Region GUID for flash cycle
> which corresponds to the type in the descriptor.
>@param[in] Address  The Flash Linear Address must fall within a
> region for which BIOS has access permissions.
>@param[in] ByteCountNumber of bytes in the data portion of the 
> SPI
> cycle.
>@param[out] Buffer  The Pointer to caller-allocated buffer 
> containing
> the dada received.
> @@ -159,7 +245,7 @@ EFI_STATUS
>  EFIAPI
>  SpiProtocolFlashRead (
>IN PCH_SPI_PROTOCOL   *This,
> -  IN FLASH_REGION_TYPE  FlashRegionType,
> +  IN EFI_GUID   *FlashRegionGuid,
>IN UINT32 Address,
>IN UINT32 ByteCount,
>OUTUINT8  *Buffer
> @@ -172,7 +258,7 @@ SpiProtocolFlashRead (
>//
>Status = SendSpiCmd (
>   This,
> - FlashRegionType,

Re: [edk2-devel] [edk2-platforms][PATCH v4 37/41] IntelSiliconPkg: Identify flash regions by GUID

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, June 25, 2021 2:21 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Chaganty, Rangasai V
> ; Desimone, Nathaniel L
> 
> Subject: [edk2-platforms][PATCH v4 37/41] IntelSiliconPkg: Identify flash
> regions by GUID
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3307
> 
> Updates the SPI protocol to identify flash regions by GUID instead of fixed
> values defined in an enum. Packages consuming IntelSiliconPkg are able to
> associate a given GUID with their chosen values based on their SPI flash
> details as implemented in their PCH_SPI_PROTOCOL instance.
> 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Cc: Nate DeSimone 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlashC
> ommonLib.c   |  2 +-
> 
> Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SpiFlashComm
> on.c |  4 +-
>  Silicon/Intel/IntelSiliconPkg/Include/Protocol/Spi.h 
>| 43
> 
> 
> Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlashC
> ommonLib.inf |  3 ++
>  4 files changed, 14 insertions(+), 38 deletions(-)
> 
> diff --git
> a/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlas
> hCommonLib.c
> b/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlas
> hCommonLib.c
> index 7941b8f8720c..2c9c889e7f48 100644
> ---
> a/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlas
> hCommonLib.c
> +++
> b/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiF
> +++ lashCommonLib.c
> @@ -52,7 +52,7 @@ SmmSpiFlashCommonLibConstructor (
>  );
>ASSERT_EFI_ERROR (Status);
> 
> -  mSpiProtocol->GetRegionAddress (mSpiProtocol, FlashRegionBios,
> , );
> +  mSpiProtocol->GetRegionAddress (mSpiProtocol, ,
> + , );
>mBiosOffset = BaseAddr;
>return Status;
>  }
> diff --git
> a/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SpiFlashCom
> mon.c
> b/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SpiFlashCom
> mon.c
> index daebaf8e5e33..62c1d099fc2c 100644
> ---
> a/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SpiFlashCom
> mon.c
> +++ b/Silicon/Intel/IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SpiFlas
> +++ hCommon.c
> @@ -127,7 +127,7 @@ SpiFlashWrite (
>  }
>  Status = mSpiProtocol->FlashWrite (
>   mSpiProtocol,
> - FlashRegionBios,
> + ,
>   (UINT32) Offset,
>   Length,
>   Buffer
> @@ -201,7 +201,7 @@ SpiFlashBlockErase (
> 
>Status = mSpiProtocol->FlashErase (
> mSpiProtocol,
> -   FlashRegionBios,
> +   ,
> (UINT32) Offset,
> (UINT32) RemainingBytes
> );
> diff --git a/Silicon/Intel/IntelSiliconPkg/Include/Protocol/Spi.h
> b/Silicon/Intel/IntelSiliconPkg/Include/Protocol/Spi.h
> index c13dc5a5f5f5..2b09ca1faf02 100644
> --- a/Silicon/Intel/IntelSiliconPkg/Include/Protocol/Spi.h
> +++ b/Silicon/Intel/IntelSiliconPkg/Include/Protocol/Spi.h
> @@ -19,33 +19,6 @@ extern EFI_GUID   gPchSmmSpiProtocolGuid;
>  //
>  typedef struct _PCH_SPI_PROTOCOL  PCH_SPI_PROTOCOL;
> 
> -//
> -// SPI protocol data structures and definitions -//
> -
> -/**
> -  Flash Region Type
> -**/
> -typedef enum {
> -  FlashRegionDescriptor,
> -  FlashRegionBios,
> -  FlashRegionMe,
> -  FlashRegionGbE,
> -  FlashRegionPlatformData,
> -  FlashRegionDer,
> -  FlashRegionSecondaryBios,
> -  FlashRegionuCodePatch,
> -  FlashRegionEC,
> -  FlashRegionDeviceExpansion2,
> -  FlashRegionIE,
> -  FlashRegion10Gbe_A,
> -  FlashRegion10Gbe_B,
> -  FlashRegion13,
> -  FlashRegion14,
> -  FlashRegion15,
> -  FlashRegionAll,
> -  FlashRegionMax
> -} FLASH_REGION_TYPE;
>  //
>  // Protocol member functions
>  //
> @@ -54,7 +27,7 @@ typedef enum {
>Read data from the flash part.
> 
>@param[in] This Pointer to the PCH_SPI_PROTOCOL instance.
> -  @param[in] FlashRegionType  The Flash Region type for flash cycle which
> is listed in the Descriptor.
> +  @param[in] FlashRegionGuid  The Flash Region GUID for flash cycle
> which corresponds to the type in the descriptor.
>@param[in] Address  The Flash Linear Address must fall within a
> region for which BIOS has access permissions.
>@param[in] ByteCountNumber of bytes in the data portion of the 
> SPI
> cycle.
>@param[out] Buffer  The Pointer to caller-allocated buffer 
> containing
> the dada received.
> @@ -68,7 +41,7 @@ typedef
>  EFI_STATUS
>  (EFIAPI *PCH_SPI_FLASH_READ) (
>IN PCH_SPI_PROTOCOL   *This,
> - 

Re: [edk2-devel] [edk2-platforms][PATCH v4 36/41] IntelSiliconPkg: Add flash region GUIDs

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, June 25, 2021 2:21 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Chaganty, Rangasai V
> ; Desimone, Nathaniel L
> 
> Subject: [edk2-platforms][PATCH v4 36/41] IntelSiliconPkg: Add flash region
> GUIDs
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3307
> 
> This change identifies flash regions by GUID instead of fixed values since the
> flash region identifiers are now defined in IntelSiliconPkg and different
> boards may want to associate a flash region identifier with a board/platform
> specific value.
> 
> The flash region GUIDs are intended to provide identifier consistency across
> board implementations improving portability of the code among
> IntelSiliconPkg consumers.
> 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Cc: Nate DeSimone 
> Signed-off-by: Michael Kubacki 
> ---
>  Silicon/Intel/IntelSiliconPkg/Include/Guid/FlashRegion.h | 45
> 
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec| 18 
>  2 files changed, 63 insertions(+)
> 
> diff --git a/Silicon/Intel/IntelSiliconPkg/Include/Guid/FlashRegion.h
> b/Silicon/Intel/IntelSiliconPkg/Include/Guid/FlashRegion.h
> new file mode 100644
> index ..5585ed710ef4
> --- /dev/null
> +++ b/Silicon/Intel/IntelSiliconPkg/Include/Guid/FlashRegion.h
> @@ -0,0 +1,45 @@
> +/** @file
> +
> +  Flash region GUID definitions.
> +
> +  Copyright (c) Microsoft Corporation.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __FLASH_REGION_H__
> +#define __FLASH_REGION_H__
> +
> +#define FLASH_REGION_DESCRIPTOR_GUID{ 0xaf90c5d8, 0xb8d1,
> 0x4cc2, {0xbb, 0xc1, 0xc9, 0xeb, 0x51, 0x2d, 0x2f, 0x82 } }
> +#define FLASH_REGION_BIOS_GUID  { 0x6fe65e44, 0x00fc, 0x4ae7,
> {0xb7, 0x61, 0xb4, 0x8f, 0x17, 0x0f, 0x4d, 0x85 } }
> +#define FLASH_REGION_ME_GUID{ 0xebbfcd3f, 0xe8de, 0x40c1,
> {0x9c, 0xfd, 0xd3, 0x4e, 0x36, 0xdc, 0x0d, 0xe4 } }
> +#define FLASH_REGION_GBE_GUID   { 0x79d11264, 0xed7a, 0x4556,
> {0xaf, 0xeb, 0x4b, 0x23, 0x93, 0x9c, 0x88, 0xe7 } }
> +#define FLASH_REGION_PLATFORM_DATA_GUID { 0x4330a7d5, 0xad54,
> 0x456a, {0x8f, 0xe1, 0xea, 0x4f, 0xa1, 0xbe, 0x58, 0xd0 } }
> +#define FLASH_REGION_DER_GUID   { 0x83014a66, 0xfd0b, 0x4049,
> {0xb3, 0xf7, 0x85, 0x6c, 0x26, 0xbb, 0xb4, 0x34 } }
> +#define FLASH_REGION_SECONDARY_BIOS_GUID{ 0x993382b4, 0x5a43,
> 0x4cb0, {0xba, 0x77, 0x06, 0xb9, 0x16, 0xc5, 0x6a, 0x18 } }
> +#define FLASH_REGION_MICROCODE_PATCH_GUID   { 0x3e97eeeb,
> 0xc5f7, 0x4af6, {0xa8, 0x61, 0x22, 0xfd, 0x8d, 0x8c, 0xa1, 0x84 } }
> +#define FLASH_REGION_EC_GUID{ 0x55a62589, 0x1b0c, 0x43ad,
> {0x91, 0xe2, 0x6f, 0xcc, 0x08, 0xc6, 0x9b, 0x75 } }
> +#define FLASH_REGION_DEVICE_EXPANSION_GUID  { 0x0dc8f30b, 0x472b,
> 0x48cc, {0xbd, 0x22, 0xe2, 0x7c, 0xfe, 0xc2, 0xc3, 0x7e } }
> +#define FLASH_REGION_IE_GUID{ 0xf930a983, 0xb72e, 0x41cc,
> {0x98, 0x1a, 0x2c, 0x60, 0x6b, 0xf5, 0x7e, 0xdb } }
> +#define FLASH_REGION_10GBE_A_GUID   { 0xde09e662, 0x831f,
> 0x4ace, {0x9a, 0x06, 0x31, 0x7c, 0xcd, 0x9c, 0x38, 0x3e } }
> +#define FLASH_REGION_10GBE_B_GUID   { 0x7776d88b, 0x48cb,
> 0x42a4, {0xb5, 0x93, 0x9b, 0x50, 0x9c, 0x8e, 0xd2, 0xae } }
> +#define FLASH_REGION_ALL_GUID   { 0xbabe60dc, 0xf88d, 0x4584,
> {0x9e, 0x54, 0x57, 0x44, 0x4b, 0xe2, 0x6e, 0xf3 } }
> +#define FLASH_REGION_MAX_GUID   { 0x74c2e3c1, 0x8faa, 0x4659,
> {0xa7, 0xbb, 0x87, 0x1f, 0xbb, 0x61, 0xd3, 0xb4 } }
> +
> +extern EFI_GUID gFlashRegionDescriptorGuid; extern EFI_GUID
> +gFlashRegionBiosGuid; extern EFI_GUID gFlashRegionMeGuid; extern
> +EFI_GUID gFlashRegionGbeGuid; extern EFI_GUID
> +gFlashRegionPlatformDataGuid; extern EFI_GUID gFlashRegionDerGuid;
> +extern EFI_GUID gFlashRegionSecondaryBiosGuid; extern EFI_GUID
> +gFlashRegionMicrocodePatchGuid; extern EFI_GUID gFlashRegionEcGuid;
> +extern EFI_GUID gFlashRegionDeviceExpansion2Guid; extern EFI_GUID
> +gFlashRegionIeGuid; extern EFI_GUID gFlashRegion10GbeAGuid; extern
> +EFI_GUID gFlashRegion10GbeBGuid; extern EFI_GUID gFlashRegionAllGuid;
> +extern EFI_GUID gFlashRegionMaxGuid;
> +
> +#endif
> diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> index e71e7b3421cd..c92d5ee64755 100644
> --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> @@ -4,6 +4,7 @@
>  # This package provides common open source Intel silicon modules.
>  #
>  # Copyright (c) 2016 - 2021, Intel Corporation. All rights reserved.
> +# Copyright (c) Microsoft Corporation.
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  #  ## @@ -74,6 +75,23 @@
> [Guids]
>## Include/Guid/MicrocodeShadowInfoHob.h
>gEdkiiMicrocodeStorageTypeFlashGuid = { 0x2cba01b3, 0xd391, 0x4598, {
> 0x8d, 0x89, 0xb7, 0xfc, 

Re: [edk2-devel] [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit assignment

[Chiu, Chasel]

Patch pushed: 69e6a5e160551fdd09ce367e9c97c25d8683a3ac

Thanks,
Chasel



> -Original Message-
> From: Benjamin Doron 
> Sent: Friday, July 23, 2021 10:27 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Liming Gao ;
> Dong, Eric 
> Subject: [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit
> assignment
> 
> In the case where the root bridge's Mem.Limit is the base address of PCIe 
> MMIO,
> subtract one to make a valid end address.
> 
> This fixes an issue where CpuDxe returns "Length(0x5001) is not aligned!"
> when PciHostBridgeDxe attempts to make this range uncacheable.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Signed-off-by: Benjamin Doron 
> ---
> 
> Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBrid
> geLibSimple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBr
> idgeLibSimple.c
> b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBr
> idgeLibSimple.c
> index e231f747019e..0e3fee28b5d1 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBr
> idgeLibSimple.c
> +++ b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/P
> +++ ciHostBridgeLibSimple.c
> @@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
>if (PcdGet32(PcdPciReservedMemLimit) != 0)
> { mRootBridgeTemplate.Mem.Limit = PcdGet32 (PcdPciReservedMemLimit);   }
> else {-mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64
> (PcdPciExpressBaseAddress);+mRootBridgeTemplate.Mem.Limit = (UINT32)
> PcdGet64 (PcdPciExpressBaseAddress) - 1;   }
> mRootBridgeTemplate.MemAbove4G.Base = PcdGet64
> (PcdPciReservedMemAbove4GBBase);--
> 2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78319): https://edk2.groups.io/g/devel/message/78319
Mute This Topic: https://groups.io/mt/84393639/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit assignment

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Benjamin Doron
> Sent: Thursday, July 22, 2021 7:27 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Liming Gao
> ; Dong, Eric 
> Subject: [edk2-devel] [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple:
> Fix Mem.Limit assignment
> 
> In the case where the root bridge's Mem.Limit is the base address of PCIe
> MMIO, subtract one to make a valid end address.
> 
> This fixes an issue where CpuDxe returns "Length(0x5001) is not
> aligned!" when PciHostBridgeDxe attempts to make this range uncacheable.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Signed-off-by: Benjamin Doron 
> ---
> 
> Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostB
> ridgeLibSimple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHos
> tBridgeLibSimple.c
> b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHos
> tBridgeLibSimple.c
> index e231f747019e..0e3fee28b5d1 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHos
> tBridgeLibSimple.c
> +++ b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/P
> +++ ciHostBridgeLibSimple.c
> @@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
>if (PcdGet32(PcdPciReservedMemLimit) != 0) {
> mRootBridgeTemplate.Mem.Limit = PcdGet32 (PcdPciReservedMemLimit);
> } else {-mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64
> (PcdPciExpressBaseAddress);+mRootBridgeTemplate.Mem.Limit =
> (UINT32) PcdGet64 (PcdPciExpressBaseAddress) - 1;   }
> mRootBridgeTemplate.MemAbove4G.Base = PcdGet64
> (PcdPciReservedMemAbove4GBBase);--
> 2.31.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#78112): https://edk2.groups.io/g/devel/message/78112
> Mute This Topic: https://groups.io/mt/84393639/1767664
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [nathaniel.l.desim...@intel.com] -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78318): https://edk2.groups.io/g/devel/message/78318
Mute This Topic: https://groups.io/mt/84393639/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH v1 1/1] Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp

[Chiu, Chasel]

Patch submitted: bee9efb7524dc06799ff65e6e056c7725a54c7e1

Thanks,
Chasel


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Takuto
> Naito
> Sent: Wednesday, July 28, 2021 11:43 PM
> To: devel@edk2.groups.io
> Cc: Takuto Naito ; Oram, Isaac W
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [edk2-devel] [edk2-platforms PATCH v1 1/1]
> Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3511
> 
> The PCD PcdDebugLoadImageMethod, which is consumed by
> PeCoffExtraActionLibDebug.inf is only for the DEBUG build.
> 
> Cc: Isaac Oram 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: Takuto Naito 
> ---
>  Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> index 41dc55a14d..fa41ae923d 100644
> --- a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> +++ b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> @@ -148,7 +148,9 @@
> 
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F# 
> Enable
> asserts, prints, code, clear memory, and deadloops on asserts.
>gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x80200047  #
> Built in messages:  Error, MTRR, info, load, warn, init
> +!if $(TARGET) == "DEBUG"
>gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2
> # This is set to INT3 (0x2) for Simics source level debugging
> +!endif
> 
>gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize|0x0
> --
> 2.25.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78317): https://edk2.groups.io/g/devel/message/78317
Mute This Topic: https://groups.io/mt/84508132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v4 00/41] Consolidate SpiFlashCommonLib instances

[Michael Kubacki]

Sure. These packages were added to edk2-platforms throughout the 
lifetime of this patch series.


Hopefully this is the last rebase...

Regards,
Michael

On 7/28/2021 7:58 PM, Desimone, Nathaniel L wrote:

Hi Michael,

The change content looks good. However, after applying your patch series 
PurleyOpenBoardPkg and WhitleyOpenBoardPkg no longer compile. Can you please 
fix these build errors?

For your reference, these are the tests that I ran:

build_bios.py -p BoardMtOlympus -t VS2015x86 -d
build_bios.py -p WilsonCityRvp -t VS2015x86 -d

Thanks,
Nate


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael
Kubacki
Sent: Friday, June 25, 2021 2:21 PM
To: devel@edk2.groups.io
Cc: Agyeman, Prince ; Chiu, Chasel
; Kethi Reddy, Deepika
; Dong, Eric ; Luo,
Heng ; Jeremy Soller ;
Esakkithevar, Kathappan ; Liming Gao
; Desimone, Nathaniel L
; Chaganty, Rangasai V

Subject: [edk2-devel] [edk2-platforms][PATCH v4 00/41] Consolidate
SpiFlashCommonLib instances

From: Michael Kubacki 

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3307

SpiFlashCommonLib is duplicated in multiple places across the MinPlatform
design in edk2-platforms. I'm planning to build some additional functionality
on top of SpiFlashCommonLib and, ideally, this duplication will be
consolidated into a single instance usable across all current library consumers.

This patch series focuses on consolidating the various SpiFlashCommonLib
instances as agreed upon in https://edk2.groups.io/g/devel/message/71701.

Read the BZ for more general background around this series.

I only have an UpXtreme board on hand so maintainers/reviewers of other
board packages should test these changes on those boards.

V4 changes:
- Assigned new GUID values to the PCH SPI PPI and Protocols to
   differentiate from previous instances. This was done because
   the interface changed to identify SPI flash regions by GUID.

V3 changes:
- Added support to IntelSiliconPkg to identify flash regions by GUID as
   requested in v2 review feedback.
V2 changes:
- Rebased patch series on current edk2-platforms master (32183bdaa91)

Note: Previous patch series only received a couple review comments after
being on the mailing list for over 2 months. Please be respectful of
contributors time and efforts and review in a timely manner.

Cc: Agyeman Prince 
Cc: Chasel Chiu 
Cc: Deepika Kethi Reddy 
Cc: Eric Dong 
Cc: Heng Luo 
Cc: Jeremy Soller 
Cc: Kathappan Esakkithevar 
Cc: Liming Gao 
Cc: Nate DeSimone 
Cc: Rangasai V Chaganty 
Signed-off-by: Michael Kubacki  Michael
Kubacki (41):
   CometlakeOpenBoardPkg: Remove redundant IntelSiliconPkg.dec entry
   WhiskeylakeOpenBoardPkg: Remove redundant IntelSiliconPkg.dec entry
   CometlakeOpenBoardPkg/PeiPolicyUpdateLib: Add missing GUID to INF
   IntelSiliconPkg: Add BIOS area base address and size PCDs
   IntelSiliconPkg: Add microcode FV PCDs
   IntelSiliconPkg: Add PCH SPI PPI
   IntelSiliconPkg: Add PCH SPI Protocol
   IntelSiliconPkg: Add SpiFlashCommonLib
   IntelSiliconPkg: Add SmmSpiFlashCommonLib
   IntelSiliconPkg: Add MM SPI FVB services
   CometlakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   KabylakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   SimicsOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   TigerlakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   WhiskeylakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   CoffeelakeSiliconPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   KabylakeSiliconPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   SimicsIch10Pkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   TigerlakeSiliconPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
   CometlakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
   KabylakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
   SimicsOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
   TigerlakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
   WhiskeylakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
   MinPlatformPkg: Remove SpiFvbService modules
   CoffeelakeSiliconPkg: Remove SmmSpiFlashCommonLib
   KabylakeSiliconPkg: Remove SmmSpiFlashCommonLib
   SimicsIch10Pkg: Remove SmmSpiFlashCommonLib
   TigerlakeOpenBoardPkg: Remove SmmSpiFlashCommonLib
   MinPlatformPkg: Remove SpiFlashCommonLibNull
   KabylakeOpenBoardPkg/PeiSerialPortLibSpiFlash: Add IntelSiliconPkg.dec
   CoffeelakeSiliconPkg: Remove PCH SPI PPI and Protocol from package
   KabylakeSiliconPkg: Remove PCH SPI PPI and Protocol from package
   SimicsIch10Pkg: Remove PCH SPI SMM Protocol from package
   TigerlakeSiliconPkg: Remove PCH SPI PPI and Protocol from package
   IntelSiliconPkg: Add flash region GUIDs
   IntelSiliconPkg: Identify flash regions by GUID
   CoffeelakeSiliconPkg/BasePchSpiCommonLib: Identify flash regions by
 GUID
   KabylakeSiliconPkg: Identify flash regions by GUID
   SimicsIch10Pkg/BasePchSpiCommonLib: Identify flash regions by GUID
   

Re: [edk2-devel] [edk2-platforms][PATCH v4 00/41] Consolidate SpiFlashCommonLib instances

[Nate DeSimone]

Hi Michael,

The change content looks good. However, after applying your patch series 
PurleyOpenBoardPkg and WhitleyOpenBoardPkg no longer compile. Can you please 
fix these build errors?

For your reference, these are the tests that I ran:

build_bios.py -p BoardMtOlympus -t VS2015x86 -d
build_bios.py -p WilsonCityRvp -t VS2015x86 -d

Thanks,
Nate

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Friday, June 25, 2021 2:21 PM
> To: devel@edk2.groups.io
> Cc: Agyeman, Prince ; Chiu, Chasel
> ; Kethi Reddy, Deepika
> ; Dong, Eric ; Luo,
> Heng ; Jeremy Soller ;
> Esakkithevar, Kathappan ; Liming Gao
> ; Desimone, Nathaniel L
> ; Chaganty, Rangasai V
> 
> Subject: [edk2-devel] [edk2-platforms][PATCH v4 00/41] Consolidate
> SpiFlashCommonLib instances
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3307
> 
> SpiFlashCommonLib is duplicated in multiple places across the MinPlatform
> design in edk2-platforms. I'm planning to build some additional functionality
> on top of SpiFlashCommonLib and, ideally, this duplication will be
> consolidated into a single instance usable across all current library 
> consumers.
> 
> This patch series focuses on consolidating the various SpiFlashCommonLib
> instances as agreed upon in https://edk2.groups.io/g/devel/message/71701.
> 
> Read the BZ for more general background around this series.
> 
> I only have an UpXtreme board on hand so maintainers/reviewers of other
> board packages should test these changes on those boards.
> 
> V4 changes:
> - Assigned new GUID values to the PCH SPI PPI and Protocols to
>   differentiate from previous instances. This was done because
>   the interface changed to identify SPI flash regions by GUID.
> 
> V3 changes:
> - Added support to IntelSiliconPkg to identify flash regions by GUID as
>   requested in v2 review feedback.
> V2 changes:
> - Rebased patch series on current edk2-platforms master (32183bdaa91)
> 
> Note: Previous patch series only received a couple review comments after
> being on the mailing list for over 2 months. Please be respectful of
> contributors time and efforts and review in a timely manner.
> 
> Cc: Agyeman Prince 
> Cc: Chasel Chiu 
> Cc: Deepika Kethi Reddy 
> Cc: Eric Dong 
> Cc: Heng Luo 
> Cc: Jeremy Soller 
> Cc: Kathappan Esakkithevar 
> Cc: Liming Gao 
> Cc: Nate DeSimone 
> Cc: Rangasai V Chaganty 
> Signed-off-by: Michael Kubacki  Michael
> Kubacki (41):
>   CometlakeOpenBoardPkg: Remove redundant IntelSiliconPkg.dec entry
>   WhiskeylakeOpenBoardPkg: Remove redundant IntelSiliconPkg.dec entry
>   CometlakeOpenBoardPkg/PeiPolicyUpdateLib: Add missing GUID to INF
>   IntelSiliconPkg: Add BIOS area base address and size PCDs
>   IntelSiliconPkg: Add microcode FV PCDs
>   IntelSiliconPkg: Add PCH SPI PPI
>   IntelSiliconPkg: Add PCH SPI Protocol
>   IntelSiliconPkg: Add SpiFlashCommonLib
>   IntelSiliconPkg: Add SmmSpiFlashCommonLib
>   IntelSiliconPkg: Add MM SPI FVB services
>   CometlakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   KabylakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   SimicsOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   TigerlakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   WhiskeylakeOpenBoardPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   CoffeelakeSiliconPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   KabylakeSiliconPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   SimicsIch10Pkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   TigerlakeSiliconPkg: Use IntelSiliconPkg BIOS area and ucode PCDs
>   CometlakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
>   KabylakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
>   SimicsOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
>   TigerlakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
>   WhiskeylakeOpenBoardPkg: Update SpiFvbService & SpiFlashCommonLib
>   MinPlatformPkg: Remove SpiFvbService modules
>   CoffeelakeSiliconPkg: Remove SmmSpiFlashCommonLib
>   KabylakeSiliconPkg: Remove SmmSpiFlashCommonLib
>   SimicsIch10Pkg: Remove SmmSpiFlashCommonLib
>   TigerlakeOpenBoardPkg: Remove SmmSpiFlashCommonLib
>   MinPlatformPkg: Remove SpiFlashCommonLibNull
>   KabylakeOpenBoardPkg/PeiSerialPortLibSpiFlash: Add IntelSiliconPkg.dec
>   CoffeelakeSiliconPkg: Remove PCH SPI PPI and Protocol from package
>   KabylakeSiliconPkg: Remove PCH SPI PPI and Protocol from package
>   SimicsIch10Pkg: Remove PCH SPI SMM Protocol from package
>   TigerlakeSiliconPkg: Remove PCH SPI PPI and Protocol from package
>   IntelSiliconPkg: Add flash region GUIDs
>   IntelSiliconPkg: Identify flash regions by GUID
>   CoffeelakeSiliconPkg/BasePchSpiCommonLib: Identify flash regions by
> GUID
>   KabylakeSiliconPkg: Identify flash regions by GUID
>   SimicsIch10Pkg/BasePchSpiCommonLib: Identify flash regions by GUID
>   TigerlakeSiliconPkg/BasePchSpiCommonLib: Identify 

Re: [edk2-devel] [edk2-platforms PATCH v1 1/1] Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

Thanks,
Chasel


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Takuto
> Naito
> Sent: Wednesday, July 28, 2021 11:43 PM
> To: devel@edk2.groups.io
> Cc: Takuto Naito ; Oram, Isaac W
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [edk2-devel] [edk2-platforms PATCH v1 1/1]
> Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3511
> 
> The PCD PcdDebugLoadImageMethod, which is consumed by
> PeCoffExtraActionLibDebug.inf is only for the DEBUG build.
> 
> Cc: Isaac Oram 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: Takuto Naito 
> ---
>  Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> index 41dc55a14d..fa41ae923d 100644
> --- a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> +++ b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
> @@ -148,7 +148,9 @@
> 
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F# 
> Enable
> asserts, prints, code, clear memory, and deadloops on asserts.
>gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x80200047  #
> Built in messages:  Error, MTRR, info, load, warn, init
> +!if $(TARGET) == "DEBUG"
>gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2
> # This is set to INT3 (0x2) for Simics source level debugging
> +!endif
> 
>gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize|0x0
> --
> 2.25.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78314): https://edk2.groups.io/g/devel/message/78314
Mute This Topic: https://groups.io/mt/84508132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Yao, Jiewen]

Comment below:

> -Original Message-
> From: Brijesh Singh 
> Sent: Thursday, July 29, 2021 2:59 AM
> 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
> 
> 
> 
> 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.
> >
> > What if some software error, set both TdxEnable and SevEnable at same time?
> > How do you detect such error?
> 
> Hmm, aren't we saying it is a software bug. In that case another bug can
> also mess up the structure header.
[Jiewen] Yes. I treat it as a software implementation bug.
The key thing in software design is to avoid the developer making mistake, help 
debug issues, help maintain the code easily.


> 
> >
> > If some code may check the SEV only, and some code may check TDX only,
> then both code can run. That will be a disaster. The code is hard to maintain 
> and
> hard to debug.
> >
> > Another consideration is: what if someone wants to set the third type?
> > Do we want to reserve the 3rd byte? To indicate the third type? It is not
> scalable.
> >
> > The best software practice it to just define one field as enumeration. So 
> > any
> software can only set Tdx or Sev. The result is consistent, no matter you 
> check
> the SEV at first or TDX at first.
> > If there is 3rd bytes, we just need assign the 3rd value to it, without 
> > impact any
> other field.
> >
> 
> I was trying to see if we can make it work without requiring any changes
> to UefiCpuPkg etc (which uses the EsWorkArea).
[Jiewen] I agree with you.
And I think the priority should be:
1) make a good design following the best practice.
2) minimize the change.

I don’t think two *enable* fields can satisfy #1.
And I am open on how to do #2. (See rest comment below)



> 
> 
> >
> > I think we can add "must zero" in the comment. But it does not mean there 
> > will
> be no error during development.
> >
> > UNION is not a type safe structure. Usually, the consumer of UNION shall
> refer to a common field to know what the type of union is - I treat that as
> header.
> >
> > Since we are defining a common data structure, I think we can do some clean
> up.
> > Or if you have concern to change SEC_SEV_ES_WORK_AREA, we can define a
> new CC WORK_AREA without touching SEV_SEV_ES_WORKING_AREA.
> >
> 
> In your below structure, I assume the SEV or TDX probe will set the Type
> only when it detects that feature is active. But which layer of the
> software is going to set the type to zero to indicate its a legacy guest ?
[Jiewen] Good question.
I expect some initialization function, such as InitCcWorkAreaSev, 
InitCcWorkAreaTdx.
The default value Legacy shall be override in InitCcWorkArea after capability 
check.
PreMainFunctionHookXXX is common patter for all function. It just checks the 
CcWorkArea.



> 
> typedef struct {
>   UINT8HeaderVersion; // 0
>   UINT8HeadLength; // 4
>   UINT8Type; // 0 - legacy, 1 - SEV, 2 - TDX
>   UINT8SubType; // Type specific sub type, if needed.
> } CC_COMMON_WORK_AREA_HEADER;
> 
> i.e In this call sequence:
> 
> OneTimeCall   PreMainFunctionHookSev
> OneTimeCall   PreMainFunctionHookTdx
> 
> 
> 
> The PreMainFunctionHookSev will detect whether SEV is active or not. If
> its active then set the type = MEM_ENCRYPT_SEV; and similarly the Tdx
> hook will set the type=MEM_ENCRYPT_TDX. What if neither TDX or SEV is
> enabled. At this time we will depend on hypervisor to ensure that value
> at that memory is zero.
[Jiewen] I think we just let InitCcWorkAreaSev and InitCcWorkAreaTdx override 
the default value.
InitCcWorkArea{Sev,Tdx}:
// Detect Hardware Capability 
// If discovered, then set Type = {SEV,TDX}
// Else, leave it as is




> 
> Additionally, do you see a need for the HeadLength field in this
> structure ? In asm it is preferred if we can access the actual workarea
> pointer at the fixed location instead of first reading the HeadLength to
> determine how much it need to skip.
[Jiewen] You are right.
Length/Version is NOT absolutely necessary, if the header is simple enough. If 
you think we don’t need them, I am OK to remove them.
I think only "Type" is mandatory, which tells us the category.
I think "SubType" is useful, because we might want to know if it is SEV, or 
SEV-ES, or SEV-SNP, and if it is TDX 1.0, or TDX.future. Please let me know 
your thought.


One question on SEC_SEV_ES_WORK_AREA. Since you have SEV/SEV-ES/SEV-SNP, is 
this SEV_ES_WORK_AREA only for SEV_ES? Or it is also used in SEV (no SEV_ES), 
and SEV_SNP ?
For example, when we see SevEsEnable=0, how do we know it is SEV (no SEV_ES) or 
legacy (no SEV, no SEV_ES)? Or we don’t need care in SEV (no SEV_ES) case.




> 
> 
> > Thank you
> > Yao Jiewen
> >

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Rebecca Cran]

CC'ing the Tianocore stewards.


I've had problems getting a recent patch committed just to make 
edk2-libc work against current edk2 master.


Tianocore stewards: do we need new or additional maintainers for 
edk2-libc, or is there a plan to deprecate it?



The current maintainers are listed as:

StdLib, StdLibPrivateInternalFiles
W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
M: Daryl McDaniel 
M: Jaben Carsey 


--
Rebecca Cran


On 7/28/21 4:25 PM, tim.le...@insyde.com wrote:

I would point out that there was significant work on libc in the past (see 
https://github.com/andreiw/UefiToolsPkg) but never any help to upstream these fixes, 
including making sure that many Linux tools can easily be ported. I myself have used it 
to port several BSD utilities over, but each time there will little nits with the 
existing port and even small patches were returned with "no current maintainer"

In terms of making other projects use libc, I think the other objection was 
that it was never optimized for non-shell usage. Other projects (lie 
https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried to remedy 
this, but never with source checked in. But it allows support under PEI, DXE, 
etc.

Tim

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran
Sent: Wednesday, July 28, 2021 8:34 AM
To: devel@edk2.groups.io; maciej.rab...@linux.intel.com
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

Are you aware of the edk2-libc project at 
https://github.com/tianocore/edk2-libc ?





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78312): https://edk2.groups.io/g/devel/message/78312
Mute This Topic: https://groups.io/mt/84484790/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Tim Lewis]

I would point out that there was significant work on libc in the past (see 
https://github.com/andreiw/UefiToolsPkg) but never any help to upstream these 
fixes, including making sure that many Linux tools can easily be ported. I 
myself have used it to port several BSD utilities over, but each time there 
will little nits with the existing port and even small patches were returned 
with "no current maintainer"

In terms of making other projects use libc, I think the other objection was 
that it was never optimized for non-shell usage. Other projects (lie 
https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried to remedy 
this, but never with source checked in. But it allows support under PEI, DXE, 
etc.

Tim

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran
Sent: Wednesday, July 28, 2021 8:34 AM
To: devel@edk2.groups.io; maciej.rab...@linux.intel.com
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

Are you aware of the edk2-libc project at 
https://github.com/tianocore/edk2-libc ?


-- 
Rebecca Cran


On 7/27/21 9:48 AM, Maciej Rabeda wrote:
> Hi,
>
> I have submitted a new edk2-staging branch named "StdLibPkg".
> https://github.com/tianocore/edk2-staging/tree/StdLibPkg
>
> Branch contains initial implementation of C standard library and 
> intrinsic library for UEFI to smoothen open-source submodule 
> integration (instead of implementing those functions in each new 
> package introducing an external submodule dependent on C stdlib).
>
> More details on the package, its contents and feature scope are placed 
> in that branch, in StdLibPkg/Readme.md file.
> https://github.com/tianocore/edk2-staging/blob/StdLibPkg/StdLibPkg/Readme.md 
>
>
> Feel free to play around. Any and all feedback is welcome.
>
> Thanks,
> Maciej
>
>
> 
>
>








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78311): https://edk2.groups.io/g/devel/message/78311
Mute This Topic: https://groups.io/mt/84484790/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v2 5/6] .mergify: Add Mergify YML pull request rules configuration file

[Michael D Kinney]

The Mergify rules in edk2 repo were recently updated.

Please align with the latest that uses the new Mergify queue feature
along with other improvements.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of PierreGondois
> Sent: Tuesday, July 27, 2021 9:50 AM
> To: devel@edk2.groups.io; Sean Brogan ; Bret 
> Barkelew ; Kinney,
> Michael D ; Liming Gao 
> ; Sami Mujawar 
> Subject: [edk2-devel] [PATCH edk2-platforms v2 5/6] .mergify: Add Mergify YML 
> pull request rules configuration file
> 
> From: Pierre Gondois 
> 
> These files are copies of the files from the tianocore/edk2
> repository. Any modification to the tianocore/edk2 files must be
> reflected on the tianocore/edk2-platforms copies.
> 
> Initial commid-id in the edk2 repository: ab060128768b
> Initial message:
> 
> Add directory for the Mergify YML configuration files that
> provides rules and actions used to process a pull request.
> 
> * Auto commit a PR from EDK II Maintainer with 'push' label
>   set and all CI checks pass
> * Auto close a PR from any developers without 'push' label
>   set and all CI checks pass.
> * Auto close a PR from a non EDK II Maintainer that has
>   the 'push' label set.
> * Post a comment to a PR that has a merge conflict.
>   Submitter can resolved conflicts and reopen the PR.
> * Post a comment to a PR that fails PatchCheck.py
>   Submitter can resolve PatchCheck.py issues and
>   reopen the PR.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3509
> 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Sami Mujawar 
> Signed-off-by: Pierre Gondois 
> ---
>  .mergify/config.yml | 98 +
>  1 file changed, 98 insertions(+)
>  create mode 100644 .mergify/config.yml
> 
> diff --git a/.mergify/config.yml b/.mergify/config.yml
> new file mode 100644
> index ..ee27a4152a75
> --- /dev/null
> +++ b/.mergify/config.yml
> @@ -0,0 +1,98 @@
> +## @file
> +# Mergify YML file that automatically merges a GitHub pull request against
> +# edk2-ci if all of the GitHub branch protections have passed.  It also
> +# contains rules to:
> +# * auto close branches that are not from an EDK II Maintainer
> +# * post a comment on pull requests that have merge conflicts.
> +# * post a comment on pull requests that have PatchCheck.py errors.
> +#
> +# Configuration Notes:
> +# * Update the 'base=edk2-ci' statements with the name of the branch to merge
> +#   pull requests.
> +#
> +# * Update the 'status-failure' statement with the name of the name of the 
> Azure
> +#   Pipelines Build that performs the EDK II Maintainer check.
> +#
> +# * This file must be checked into the 'default' branch of a repo.  Copies
> +#   of this file on other branches of a repo are ignored by Mergify.
> +#
> +# Copyright (c) 2021, Arm Ltd. All rights reserved.
> +# Copyright (c) 2019 - 2020, Intel Corporation. All rights reserved.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +# https://github.com/apps/mergify
> +# https://doc.mergify.io/
> +#
> +##
> +
> +pull_request_rules:
> +
> +  - name: Automatically merge a PR when all required checks pass and 'push' 
> label is present
> +conditions:
> +  - base~=(^master|^stable/)
> +  - label=push
> +  - author=@tianocore/edk-ii-maintainers
> +  - status-success=tianocore.PatchCheck
> +  - status-success=Ubuntu GCC5 PR
> +  - status-success=Windows VS2019 PR
> +actions:
> +  merge:
> +strict: true
> +method: rebase
> +
> +  - name: Automatically close a PR when all required checks pass and 'push' 
> label is not present
> +conditions:
> +  - base~=(^master|^stable/)
> +  - -label=push
> +  - -closed
> +  - status-success=tianocore.PatchCheck
> +  - status-success=Ubuntu GCC5 PR
> +  - status-success=Windows VS2019 PR
> +  - status-success=Ubuntu GCC5 PR (FINISHED)
> +  - status-success=Windows VS2019 PR (FINISHED)
> +actions:
> +  close:
> +message: All checks passed. Auto close personal build.
> +
> +  - name: Post a comment on a PR that can not be merged due to a merge 
> conflict
> +conditions:
> +  - base~=(^master|^stable/)
> +  - conflict
> +actions:
> +  comment:
> +message: PR can not be merged due to conflict.  Please rebase and 
> resubmit
> +
> +  - name: Automatically close a PR that fails the EDK II Maintainers 
> membership check and 'push' label is present
> +conditions:
> +  - base~=(^master|^stable/)
> +  - label=push
> +  - -author=@tianocore/edk-ii-maintainers
> +actions:
> +  close:
> +message: PR submitter is not a member of the Tianocore EDK II 
> Maintainers team
> +
> +  - name: Post a comment on a PR if PatchCheck fails
> +conditions:
> +  - base~=(^master|^stable/)
> +  - status-failure=tianocore.PatchCheck
> +actions:
> +  comment:
> +message: PR can not be 

[edk2-devel] [edk2-platforms][PATCH v2] BoardModulePkg/BoardBdsHookLib: Register UiApp as boot option

[Benjamin Doron]

BootManagerMenuApp is the default PcdBootManagerMenuFile. It allows
choosing a boot device, but system configuration is performed in UiApp.
Therefore, un-comment and fix UiApp boot option registration.

Tested, UiApp can be entered through the new boot option.

Cc: Eric Dong 
Cc: Liming Gao 
Signed-off-by: Benjamin Doron 
---
 Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c | 13 
++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git 
a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c 
b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c
index 87138bdd79ff..2dd0b250d44e 100644
--- a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c
+++ b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c
@@ -361,20 +361,11 @@ RegisterDefaultBootOption (
   if (mBootMenuOptionNumber == LoadOptionNumberUnassigned) {
 DEBUG ((DEBUG_INFO, "BootMenuOptionNumber (%d) should not be same to 
LoadOptionNumberUnassigned(%d).\n", mBootMenuOptionNumber, 
LoadOptionNumberUnassigned));
   }
-#if 0
+
   //
   // Boot Manager Menu
   //
-  EfiInitializeFwVolDevicepathNode (, );
-
-  gBS->HandleProtocol (
- gImageHandle,
- ,
- (VOID **) 
- );
-  DevicePath = AppendDevicePathNode (DevicePathFromHandle 
(LoadedImage->DeviceHandle), (EFI_DEVICE_PATH_PROTOCOL *) );
-#endif
-
+  RegisterFvBootOption (, L"Platform Configuration", (UINTN) -1, 
LOAD_OPTION_ACTIVE, NULL, 0);
 }
 
 /**
-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78309): https://edk2.groups.io/g/devel/message/78309
Mute This Topic: https://groups.io/mt/84469836/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] OvmfPkg: Add build options for 8MB and 16MB X64 OVMF images

[Devon Bautista]

Laszlo,

I apologize for the delay. I've been heavily preoccupied in another work
program I am involved in.

On 5/27/21 3:12 AM, Laszlo Ersek wrote:
> On 05/26/21 19:08, Devon Bautista wrote:
>> Currently, the largest volume size for building OVMF images is 4MB. With
>> the growth of the Linuxboot project, maintainers have had to maintain a
>> fork containing this patch which allows larger image sizes in order for
>> Linuxboot developers/users to have enough space to experiment with
>> and test including their own Linux kernel in the DXE section of OVMF
>> firmware. Testing using OVMF is valuable since it allows testing in QEMU
>> and thus does not require any hardware to do so.
>>
>> This patch allows specifying '-D FD_SIZE_8MB' or '-D FD_SIZE_16MB' to
>> the OVMF build script in order to add the ability to build 8MB or 16MB
>> x86_64 (X64) OVMF images, respectively.
>>
>> Signed-off-by: Devon Bautista 
>> ---
>>  OvmfPkg/OvmfPkgDefines.fdf.inc | 34 ++
>>  OvmfPkg/OvmfPkgX64.dsc | 10 +-
>>  OvmfPkg/VarStore.fdf.inc   | 16 
>>  3 files changed, 51 insertions(+), 9 deletions(-)
>>
>> diff --git a/OvmfPkg/OvmfPkgDefines.fdf.inc b/OvmfPkg/OvmfPkgDefines.fdf.inc
>> index 35fd454b97..da37758934 100644
>> --- a/OvmfPkg/OvmfPkgDefines.fdf.inc
>> +++ b/OvmfPkg/OvmfPkgDefines.fdf.inc
>> @@ -66,6 +66,40 @@ DEFINE SECFV_OFFSET  = 0x003CC000
>>  DEFINE SECFV_SIZE= 0x34000
>>  !endif
>>  
>> +!if $(FD_SIZE_IN_KB) == 8192
>> +DEFINE VARS_SIZE = 0x84000
>> +DEFINE VARS_BLOCKS   = 0x84
>> +DEFINE VARS_LIVE_SIZE= 0x4
>> +DEFINE VARS_SPARE_SIZE   = 0x42000
>> +
>> +DEFINE FW_BASE_ADDRESS   = 0xFF80
>> +DEFINE FW_SIZE   = 0x0080
>> +DEFINE FW_BLOCKS = 0x800
>> +DEFINE CODE_BASE_ADDRESS = 0xFF884000
>> +DEFINE CODE_SIZE = 0x0077C000
>> +DEFINE CODE_BLOCKS   = 0x77C
>> +DEFINE FVMAIN_SIZE   = 0x00748000
>> +DEFINE SECFV_OFFSET  = 0x007CC000
>> +DEFINE SECFV_SIZE= 0x34000
>> +!endif
>> +
>> +!if $(FD_SIZE_IN_KB) == 16384
>> +DEFINE VARS_SIZE = 0x84000
>> +DEFINE VARS_BLOCKS   = 0x84
>> +DEFINE VARS_LIVE_SIZE= 0x4
>> +DEFINE VARS_SPARE_SIZE   = 0x42000
>> +
>> +DEFINE FW_BASE_ADDRESS   = 0xFF00
>> +DEFINE FW_SIZE   = 0x0100
>> +DEFINE FW_BLOCKS = 0x1000
>> +DEFINE CODE_BASE_ADDRESS = 0xFF084000
>> +DEFINE CODE_SIZE = 0x00F7C000
>> +DEFINE CODE_BLOCKS   = 0xF7C
>> +DEFINE FVMAIN_SIZE   = 0x00F48000
>> +DEFINE SECFV_OFFSET  = 0x00FCC000
>> +DEFINE SECFV_SIZE= 0x34000
>> +!endif
>> +
>>  SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS)
>>  SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize= $(FW_SIZE)
>>  SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE)
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index 999738dc39..28351e2f56 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -66,11 +66,19 @@
>>  !else
>>  !ifdef $(FD_SIZE_4MB)
>>DEFINE FD_SIZE_IN_KB   = 4096
>> +!else
>> +!ifdef $(FD_SIZE_8MB)
>> +  DEFINE FD_SIZE_IN_KB   = 8192
>> +!else
>> +!ifdef $(FD_SIZE_16MB)
>> +  DEFINE FD_SIZE_IN_KB   = 16384
>>  !else
>>DEFINE FD_SIZE_IN_KB   = 4096
>>  !endif
>>  !endif
>>  !endif
>> +!endif
>> +!endif
>>  
>>  [BuildOptions]
>>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>> @@ -501,7 +509,7 @@
>>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
>>  !endif
>>  !endif
>> -!if $(FD_SIZE_IN_KB) == 4096
>> +!if $(FD_SIZE_IN_KB) == 4096 || $(FD_SIZE_IN_KB) == 8196 || 
>> $(FD_SIZE_IN_KB) == 16384
>>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
>>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
>>  !if $(NETWORK_TLS_ENABLE) == FALSE
>> diff --git a/OvmfPkg/VarStore.fdf.inc b/OvmfPkg/VarStore.fdf.inc
>> index a1e524e393..70db929478 100644
>> --- a/OvmfPkg/VarStore.fdf.inc
>> +++ b/OvmfPkg/VarStore.fdf.inc
>> @@ -11,7 +11,7 @@
>>  !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
>>  0x|0xe000
>>  !endif
>> -!if $(FD_SIZE_IN_KB) == 4096
>> +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || 
>> ($(FD_SIZE_IN_KB) == 16384)
>>  0x|0x0004
>>  !endif
>>  #NV_VARIABLE_STORE
>> @@ -29,7 +29,7 @@ DATA = {
>># FvLength: 0x2
>>0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
>>  !endif
>> -!if $(FD_SIZE_IN_KB) == 4096
>> +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || 
>> ($(FD_SIZE_IN_KB) == 16384)
>># FvLength: 0x84000
>>0x00, 0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00,
>>  !endif
>> @@ -41,7 +41,7 @@ DATA = {
>># CheckSum
>>0x19, 0xF9,
>>  !endif
>> -!if $(FD_SIZE_IN_KB) == 4096
>> +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || 
>> ($(FD_SIZE_IN_KB) == 16384)
>># CheckSum
>>0xAF, 0xB8,
>>  !endif
>> @@ -51,7 +51,7 @@ 

Re: [edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Taylor Beebe]

Note: I'll be accepting feedback on this until Friday after which I will 
submit a patch series.


On 7/22/2021 5:32 PM, Taylor Beebe via groups.io wrote:
Current memory protection settings rely on FixedAtBuild PCD values 
(minus PcdSetNxForStack). Because of this, the memory protection 
configuration interface is fixed in nature. Cases arise in which memory 
protections might need to be adjusted between boots (if platform design 
allows) to avoid disabling a system. For example, platforms might choose 
to allow the user to control their protection policies such as allow 
execution of critical 3rd party software that might violate memory 
protections.


This RFC seeks your feedback regarding introducing an interface that 
allows dynamic configuration of memory protection settings.


I would like to propose two options:
1. Describing the memory protection setting configuration in a HOB that 
is produced by the platform.
2. Introducing a library class (e.g. MemoryProtectionLib) that allows 
abstraction of the memory protection setting configuration data source.


In addition, I would like to know if the memory protection FixedAtBuild 
PCDs currently in MdeModulePkg can be removed so we can move the 
configuration interface entirely to an option above.


In any case, I would like the settings to be visible to environments 
such as Standalone MM where dynamic PCDs are not accessible.


I am seeking your feedback on this proposal in preparation for sending 
an edk2 patch series.




--
Taylor Beebe
Software Engineer @ Microsoft


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78307): https://edk2.groups.io/g/devel/message/78307
Mute This Topic: https://groups.io/mt/84392478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Brijesh Singh via groups.io]

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.

What if some software error, set both TdxEnable and SevEnable at same time?
How do you detect such error?


Hmm, aren't we saying it is a software bug. In that case another bug can 
also mess up the structure header.




If some code may check the SEV only, and some code may check TDX only, then 
both code can run. That will be a disaster. The code is hard to maintain and 
hard to debug.

Another consideration is: what if someone wants to set the third type?
Do we want to reserve the 3rd byte? To indicate the third type? It is not 
scalable.

The best software practice it to just define one field as enumeration. So any 
software can only set Tdx or Sev. The result is consistent, no matter you check 
the SEV at first or TDX at first.
If there is 3rd bytes, we just need assign the 3rd value to it, without impact 
any other field.



I was trying to see if we can make it work without requiring any changes 
to UefiCpuPkg etc (which uses the EsWorkArea).





I think we can add "must zero" in the comment. But it does not mean there will 
be no error during development.

UNION is not a type safe structure. Usually, the consumer of UNION shall refer 
to a common field to know what the type of union is - I treat that as header.

Since we are defining a common data structure, I think we can do some clean up.
Or if you have concern to change SEC_SEV_ES_WORK_AREA, we can define a new CC 
WORK_AREA without touching SEV_SEV_ES_WORKING_AREA.



In your below structure, I assume the SEV or TDX probe will set the Type 
only when it detects that feature is active. But which layer of the 
software is going to set the type to zero to indicate its a legacy guest ?


typedef struct {
UINT8HeaderVersion; // 0
UINT8HeadLength; // 4
UINT8Type; // 0 - legacy, 1 - SEV, 2 - TDX
UINT8SubType; // Type specific sub type, if needed.
} CC_COMMON_WORK_AREA_HEADER;

i.e In this call sequence:

OneTimeCall   PreMainFunctionHookSev
OneTimeCall   PreMainFunctionHookTdx




The PreMainFunctionHookSev will detect whether SEV is active or not. If 
its active then set the type = MEM_ENCRYPT_SEV; and similarly the Tdx 
hook will set the type=MEM_ENCRYPT_TDX. What if neither TDX or SEV is 
enabled. At this time we will depend on hypervisor to ensure that value 
at that memory is zero.


Additionally, do you see a need for the HeadLength field in this 
structure ? In asm it is preferred if we can access the actual workarea 
pointer at the fixed location instead of first reading the HeadLength to 
determine how much it need to skip.




Thank you
Yao Jiewen



-Original Message-
From: devel@edk2.groups.io  On Behalf Of Brijesh
Singh via groups.io
Sent: Wednesday, July 28, 2021 11:59 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 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 struct {
UINT8SevEsEnabled;

// If Es is enabled then this field must be zeroed
UINT8MustBeZero;

UINT8Reserved1[6];

UINT64   RandomData;

UINT64   EncryptionMask;
} SEC_SEV_ES_WORK_AREA;

typedef struct {
// If Tdx is enabled then it must be zeroed
UINT8MustBeZero

UINT8TdxEnabled;

UINT8Reserved2[6];


} TX_WORK_AREA;

typedef union {
SEC_SEV_ES_WORK_AREA SevEsWorkArea;
TDX_WORK_AREATdxWorkArea;
} CC_WORK_AREA;

I am trying to minimize the changes to the existing code. The SEV and
TDX probe logic should ensure that if the feature is detected, then it
must clear the MustBeZero'ed field.

Basically, we already have a 64-bit value reserved in the SevEsWork area
and currently only one byte is used and second byte can be detected for
the TDX. Basically the which encryption technology is active the
definition of the work area will change.

Am I missing something ?

Thanks

On 7/28/21 10:22 AM, Yao, Jiewen wrote:

Hi Brijesh
Thanks!

I think if we want to reuse this, we need rename the data structure.

First, we should use a generic name.

Second, I don’t think it is good idea to define two *enable* fields. Since only

one of them should be enabled, we should use 1 field as enumeration.


Third, we should hide the SEV specific and TDX specific definition in CC

common work area.


If we agree to use a common work area, I recommend below:

typedef struct {
 UINT8HeaderVersion; // 0
 UINT8HeadLength; // 4
 UINT8Type; // 0 - legacy, 1 - SEV, 2 - TDX
 UINT8SubType; // Type specific sub type, if needed.
} CC_COMMON_WORK_AREA_HEADER;

Re: [edk2-devel] [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0

[Chaganty, Rangasai V]

Digant, 
The notation "PATCH 3/3" indicates part 3 of a 3 patch series. 
However since this is a single patch, the subject line could simply indicate 
[PATCH v3]. Something to consider for future reviews. 

Thanks,
Sai

-Original Message-
From: Chaganty, Rangasai V 
Sent: Wednesday, July 28, 2021 10:48 AM
To: Solanki, Digant H ; devel@edk2.groups.io
Cc: Ni, Ray ; S, Ashraf Ali 
Subject: RE: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

Reviewed-by: Sai Chaganty  

-Original Message-
From: Solanki, Digant H 
Sent: Thursday, July 22, 2021 4:47 AM
To: devel@edk2.groups.io
Cc: Solanki, Digant H ; Ni, Ray ; 
Chaganty, Rangasai V ; S, Ashraf Ali 

Subject: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3426

- There are many OpRegion fields obsoleted in MBOX1
- MBOX2 is re-purposed for Backlight related fields for dual LFP.
- Backlight related fields moved to MBOX2 from MBOX3 and some fields are 
obsoleted in MBOX3.

Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Ashraf Ali S 
---
 Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 
+
 1 file changed, 101 insertions(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
new file mode 100644
index 00..c9948ab55f
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion
+++ 30.h
@@ -0,0 +1,101 @@
+/** @file
+  IGD OpRegion definition from Intel Integrated Graphics Device 
+OpRegion
+  Specification based on version 3.0.
+
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef _IGD_OPREGION_3_0_H_
+#define _IGD_OPREGION_3_0_H_
+
+#include "IgdOpRegion.h"
+
+#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5
+
+#pragma pack(1)
+///
+/// OpRegion Mailbox 1 - Public ACPI Methods /// Offset 0x100, Size
+0x100 /// typedef struct {
+  UINT32 DRDY;  ///< Offset 0x100 Driver Readiness
+  UINT32 CSTS;  ///< Offset 0x104 Status
+  UINT32 CEVT;  ///< Offset 0x108 Current Event
+  UINT8  RM11[0x14];///< Offset 0x10C Reserved Must be Zero
+  UINT32 DIDL[8];   ///< Offset 0x120 Supported Display Devices ID List
+  UINT32 CPDL[8];   ///< Offset 0x140 obsolete
+  UINT32 CADL[8];   ///< Offset 0x160 obsolete
+  UINT32 NADL[8];   ///< Offset 0x180 obsolete
+  UINT32 ASLP;  ///< Offset 0x1A0 ASL Sleep Time Out
+  UINT32 TIDX;  ///< Offset 0x1A4 obsolete
+  UINT32 CHPD;  ///< Offset 0x1A8 obsolete
+  UINT32 CLID;  ///< Offset 0x1AC Current Lid State Indicator
+  UINT32 CDCK;  ///< Offset 0x1B0 Current Docking State Indicator
+  UINT32 SXSW;  ///< Offset 0x1B4 obsolete
+  UINT32 EVTS;  ///< Offset 0x1B8 obsolete
+  UINT32 CNOT;  ///< Offset 0x1BC obsolete
+  UINT32 NRDY;  ///< Offset 0x1C0 Driver Status
+  UINT8  DID2[0x1C];///< Offset 0x1C4 Extended Supported Devices ID List 
(DOD)
+  UINT8  CPD2[0x1C];///< Offset 0x1E0 obsolete
+  UINT8  RM12[4];   ///< Offset 0x1FC - 0x1FF Reserved Must be zero
+} IGD_OPREGION_MBOX1_VER_3_0;
+
+///
+/// OpRegion Mailbox 2 - Backlight communication /// Offset 0x200, Size
+0x100 /// typedef struct {
+  UINT32 BCL1;  ///< Offset 0x200 Backlight Brightness for LFP1
+  UINT32 BCL2;  ///< Offset 0x204 Backlight Brightness for LFP2
+  UINT32 CBL1;  ///< Offset 0x208 Current User Brightness Level for 
LFP1
+  UINT32 CBL2;  ///< Offset 0x20C Current User Brightness Level for 
LFP2
+  UINT32 BCM1[0x1E];///< Offset 0x210 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP1
+  UINT32 BCM2[0x1E];///< Offset 0x288 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP2
+} IGD_OPREGION_MBOX2_VER_3_0;
+
+///
+/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support /// 
+Offset 0x300, Size 0x100 /// typedef struct {
+  UINT32 ARDY;  ///< Offset 0x300 obsolete
+  UINT32 ASLC;  ///< Offset 0x304 obsolete
+  UINT32 TCHE;  ///< Offset 0x308 obsolete
+  UINT32 ALSI;  ///< Offset 0x30C obsolete
+  UINT32 BCLP;  ///< Offset 0x310 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 PFIT;  ///< Offset 0x314 obsolete
+  UINT32 CBLV;  ///< Offset 0x318 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT16 BCLM[0x14];///< Offset 0x31C obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 CPFM;  ///< Offset 0x344 obsolete
+  UINT32 EPFM;  ///< Offset 0x348 obsolete
+  UINT8  PLUT[0x4A];///< Offset 0x34C obsolete
+  UINT32 PFMB;  ///< Offset 0x396 obsolete
+  UINT32 CCDV;  ///< Offset 0x39A obsolete
+  

Re: [edk2-devel] [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0

[Chaganty, Rangasai V]

Reviewed-by: Sai Chaganty  

-Original Message-
From: Solanki, Digant H  
Sent: Thursday, July 22, 2021 4:47 AM
To: devel@edk2.groups.io
Cc: Solanki, Digant H ; Ni, Ray ; 
Chaganty, Rangasai V ; S, Ashraf Ali 

Subject: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3426

- There are many OpRegion fields obsoleted in MBOX1
- MBOX2 is re-purposed for Backlight related fields for dual LFP.
- Backlight related fields moved to MBOX2 from MBOX3 and some fields are 
obsoleted in MBOX3.

Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Ashraf Ali S 
---
 Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 
+
 1 file changed, 101 insertions(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
new file mode 100644
index 00..c9948ab55f
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion
+++ 30.h
@@ -0,0 +1,101 @@
+/** @file
+  IGD OpRegion definition from Intel Integrated Graphics Device 
+OpRegion
+  Specification based on version 3.0.
+
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef _IGD_OPREGION_3_0_H_
+#define _IGD_OPREGION_3_0_H_
+
+#include "IgdOpRegion.h"
+
+#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5
+
+#pragma pack(1)
+///
+/// OpRegion Mailbox 1 - Public ACPI Methods /// Offset 0x100, Size 
+0x100 /// typedef struct {
+  UINT32 DRDY;  ///< Offset 0x100 Driver Readiness
+  UINT32 CSTS;  ///< Offset 0x104 Status
+  UINT32 CEVT;  ///< Offset 0x108 Current Event
+  UINT8  RM11[0x14];///< Offset 0x10C Reserved Must be Zero
+  UINT32 DIDL[8];   ///< Offset 0x120 Supported Display Devices ID List
+  UINT32 CPDL[8];   ///< Offset 0x140 obsolete
+  UINT32 CADL[8];   ///< Offset 0x160 obsolete
+  UINT32 NADL[8];   ///< Offset 0x180 obsolete
+  UINT32 ASLP;  ///< Offset 0x1A0 ASL Sleep Time Out
+  UINT32 TIDX;  ///< Offset 0x1A4 obsolete
+  UINT32 CHPD;  ///< Offset 0x1A8 obsolete
+  UINT32 CLID;  ///< Offset 0x1AC Current Lid State Indicator
+  UINT32 CDCK;  ///< Offset 0x1B0 Current Docking State Indicator
+  UINT32 SXSW;  ///< Offset 0x1B4 obsolete
+  UINT32 EVTS;  ///< Offset 0x1B8 obsolete
+  UINT32 CNOT;  ///< Offset 0x1BC obsolete
+  UINT32 NRDY;  ///< Offset 0x1C0 Driver Status
+  UINT8  DID2[0x1C];///< Offset 0x1C4 Extended Supported Devices ID List 
(DOD)
+  UINT8  CPD2[0x1C];///< Offset 0x1E0 obsolete
+  UINT8  RM12[4];   ///< Offset 0x1FC - 0x1FF Reserved Must be zero
+} IGD_OPREGION_MBOX1_VER_3_0;
+
+///
+/// OpRegion Mailbox 2 - Backlight communication /// Offset 0x200, Size 
+0x100 /// typedef struct {
+  UINT32 BCL1;  ///< Offset 0x200 Backlight Brightness for LFP1
+  UINT32 BCL2;  ///< Offset 0x204 Backlight Brightness for LFP2
+  UINT32 CBL1;  ///< Offset 0x208 Current User Brightness Level for 
LFP1
+  UINT32 CBL2;  ///< Offset 0x20C Current User Brightness Level for 
LFP2
+  UINT32 BCM1[0x1E];///< Offset 0x210 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP1
+  UINT32 BCM2[0x1E];///< Offset 0x288 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP2
+} IGD_OPREGION_MBOX2_VER_3_0;
+
+///
+/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support /// 
+Offset 0x300, Size 0x100 /// typedef struct {
+  UINT32 ARDY;  ///< Offset 0x300 obsolete
+  UINT32 ASLC;  ///< Offset 0x304 obsolete
+  UINT32 TCHE;  ///< Offset 0x308 obsolete
+  UINT32 ALSI;  ///< Offset 0x30C obsolete
+  UINT32 BCLP;  ///< Offset 0x310 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 PFIT;  ///< Offset 0x314 obsolete
+  UINT32 CBLV;  ///< Offset 0x318 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT16 BCLM[0x14];///< Offset 0x31C obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 CPFM;  ///< Offset 0x344 obsolete
+  UINT32 EPFM;  ///< Offset 0x348 obsolete
+  UINT8  PLUT[0x4A];///< Offset 0x34C obsolete
+  UINT32 PFMB;  ///< Offset 0x396 obsolete
+  UINT32 CCDV;  ///< Offset 0x39A obsolete
+  UINT32 PCFT;  ///< Offset 0x39E obsolete
+  UINT32 SROT;  ///< Offset 0x3A2 obsolete
+  UINT32 IUER;  ///< Offset 0x3A6 obsolete
+  UINT64 FDSS;  ///< Offset 0x3AA obsolete
+  UINT32 FDSP;  ///< Offset 0x3B2 obsolete
+  UINT32 STAT;  ///< Offset 0x3B6 obsolete
+  UINT64 RVDA;  ///< Offset 0x3BA Physical address of Raw VBT data. 
Added from Spec Version 0.90 to support VBT greater than 6KB.
+  UINT32 RVDS;  ///< 

Re: [edk2-devel] [PATCH v5 00/11] Measured SEV boot with kernel/initrd/cmdline

[Dov Murik]

On 28/07/2021 19:41, Yao, Jiewen wrote:
> For OvmfPkg, reviewed-by: Jiewen Yao 
> For ArmVirtPkg, acked-by: Jiewen Yao 
> 

Thanks Jiewen!

-Dov


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78303): https://edk2.groups.io/g/devel/message/78303
Mute This Topic: https://groups.io/mt/84489195/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V3] NetworkPkg: Add HTTP Additional Event Notifications

[Maciej Rabeda]

Change merged: https://github.com/tianocore/edk2/pull/1840

On 28-Jul-21 15:50, Maciej Rabeda wrote:

Reviewed-by: Maciej Rabeda 

On 28-Jul-21 13:58, Heng Luo wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3496

Add new EDKII_HTTP_CALLBACK_PROTOCOL in NetworkPkg,
Send HTTP Events via EDKII_HTTP_CALLBACK_PROTOCOL
when Dns/ConnectTcp/TlsConnectSession/InitSession
occurs.

Signed-off-by: Heng Luo 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---

  NetworkPkg/HttpDxe/HttpDriver.h    |  3 ++-
  NetworkPkg/HttpDxe/HttpDxe.inf |  3 ++-
  NetworkPkg/HttpDxe/HttpImpl.c  |  4 +++-
  NetworkPkg/HttpDxe/HttpProto.c | 58 
+-

  NetworkPkg/HttpDxe/HttpProto.h | 15 ++-
  NetworkPkg/Include/Protocol/HttpCallback.h | 85 
+

  NetworkPkg/NetworkPkg.dec  |  3 +++
  7 files changed, 166 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h 
b/NetworkPkg/HttpDxe/HttpDriver.h

index 5fe8c5b5e9..b701b80858 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -1,7 +1,7 @@
  /** @file
    The header files of the driver binding and service binding 
protocol for HttpDxe driver.
  -  Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.
+  Copyright (c) 2015 - 2021, Intel Corporation. All rights 
reserved.

    (C) Copyright 2016 Hewlett Packard Enterprise Development LP
      SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -47,6 +47,7 @@
  #include 
  #include 
  #include 
+#include 
    #include 
  //
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf 
b/NetworkPkg/HttpDxe/HttpDxe.inf

index 35fe31af18..23fb9ec394 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  Implementation of EFI HTTP protocol interfaces.
  #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights 
reserved.

  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -65,6 +65,7 @@
    gEfiTlsServiceBindingProtocolGuid    ## 
SOMETIMES_CONSUMES
    gEfiTlsProtocolGuid  ## 
SOMETIMES_CONSUMES
    gEfiTlsConfigurationProtocolGuid ## 
SOMETIMES_CONSUMES
+  gEdkiiHttpCallbackProtocolGuid   ## 
SOMETIMES_CONSUMES

    [Guids]
    gEfiTlsCaCertificateGuid ## 
SOMETIMES_CONSUMES  ## Variable:L"TlsCaCertificate"
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c 
b/NetworkPkg/HttpDxe/HttpImpl.c

index 5a6ecbc9d9..97f15d229f 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -1,7 +1,7 @@
  /** @file
    Implementation of EFI_HTTP_PROTOCOL protocol interfaces.
  -  Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.
+  Copyright (c) 2015 - 2021, Intel Corporation. All rights 
reserved.
    (C) Copyright 2015-2016 Hewlett Packard Enterprise Development 
LP

      SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -527,6 +527,7 @@ EfiHttpRequest (
    } else {
  Status = HttpDns6 (HttpInstance, HostNameStr, 
>RemoteIpv6Addr);

    }
+  HttpNotify (HttpEventDns, Status);
      FreePool (HostNameStr);
    if (EFI_ERROR (Status)) {
@@ -588,6 +589,7 @@ EfiHttpRequest (
   Configure || ReConfigure,
   TlsConfigure
   );
+  HttpNotify (HttpEventInitSession, Status);
    if (EFI_ERROR (Status)) {
  goto Error2;
    }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c 
b/NetworkPkg/HttpDxe/HttpProto.c

index afc7db5a72..affa916bd6 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1,7 +1,7 @@
  /** @file
    Miscellaneous routines for HttpDxe driver.
  -Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.

+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
  SPDX-License-Identifier: BSD-2-Clause-Patent
  @@ -966,6 +966,7 @@ HttpCreateConnection (
  HttpInstance->IsTcp4ConnDone = FALSE;
  HttpInstance->Tcp4ConnToken.CompletionToken.Status = 
EFI_NOT_READY;
  Status = HttpInstance->Tcp4->Connect (HttpInstance->Tcp4, 
>Tcp4ConnToken);

+    HttpNotify (HttpEventConnectTcp, Status);
  if (EFI_ERROR (Status)) {
    DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp4->Connect() = 
%r\n", Status));

    return Status;
@@ -981,6 +982,7 @@ HttpCreateConnection (
  HttpInstance->IsTcp6ConnDone = FALSE;
  HttpInstance->Tcp6ConnToken.CompletionToken.Status = 
EFI_NOT_READY;
  Status = HttpInstance->Tcp6->Connect (HttpInstance->Tcp6, 
>Tcp6ConnToken);

+    HttpNotify (HttpEventConnectTcp, Status);
  if (EFI_ERROR (Status)) {
    DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp6->Connect() = 

Re: [edk2-devel] [Patch V3] NetworkPkg: Making the HTTP IO timeout value programmable with PCD

[Maciej Rabeda]

Change merged: https://github.com/tianocore/edk2/pull/1840

Corrections applied:
1. NetworkPkg.dsc: [PdcsDynamic] -> [PdcsDynamicDefault]
2. NetworkPkg.dsc: PcdHttpTimeout -> PcdHttpIoTimeout

On 28-Jul-21 15:59, Maciej Rabeda wrote:

Reviewed-by: Maciej Rabeda 

On 28-Jul-21 14:16, Heng Luo wrote:

From: Zachary Clark-Williams 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3507

HTTP boot has a default set forced timeout value of 5 seconds
for getting the recovery image from a remote source.
This change allows the HTTP boot flow to get the IO timeout value
from the PcdHttpIoTimeout.
PcdHttpIoTimeout value is set in platform code.

Signed-off-by: Zachary Clark-Williams 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---
  NetworkPkg/HttpBootDxe/HttpBootClient.c | 12 +---
  NetworkPkg/HttpBootDxe/HttpBootClient.h |  7 +--
  NetworkPkg/HttpBootDxe/HttpBootDxe.inf  |  3 ++-
  NetworkPkg/HttpDxe/HttpDxe.inf  |  3 ++-
  NetworkPkg/HttpDxe/HttpImpl.c   | 17 ++---
  NetworkPkg/HttpDxe/HttpProto.h  |  3 +--
  NetworkPkg/NetworkPkg.dec   |  8 
  NetworkPkg/NetworkPkg.dsc   |  3 +++
  NetworkPkg/NetworkPkg.uni   |  8 +++-
  9 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c 
b/NetworkPkg/HttpBootDxe/HttpBootClient.c

index 8f21f7766e..aa0a153019 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -1,7 +1,7 @@
  /** @file
    Implementation of the boot file download function.
  -Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.

+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
  SPDX-License-Identifier: BSD-2-Clause-Patent
  @@ -596,19 +596,25 @@ HttpBootCreateHttpIo (
    HTTP_IO_CONFIG_DATA  ConfigData;
    EFI_STATUS   Status;
    EFI_HANDLE   ImageHandle;
+  UINT32   TimeoutValue;
      ASSERT (Private != NULL);
  +  //
+  // Get HTTP timeout value
+  //
+  TimeoutValue = PcdGet32 (PcdHttpIoTimeout);
+
    ZeroMem (, sizeof (HTTP_IO_CONFIG_DATA));
    if (!Private->UsingIpv6) {
  ConfigData.Config4.HttpVersion    = HttpVersion11;
-    ConfigData.Config4.RequestTimeOut = HTTP_BOOT_REQUEST_TIMEOUT;
+    ConfigData.Config4.RequestTimeOut = TimeoutValue;
  IP4_COPY_ADDRESS (, 
>StationIp.v4);
  IP4_COPY_ADDRESS (, 
>SubnetMask.v4);

  ImageHandle = Private->Ip4Nic->ImageHandle;
    } else {
  ConfigData.Config6.HttpVersion    = HttpVersion11;
-    ConfigData.Config6.RequestTimeOut = HTTP_BOOT_REQUEST_TIMEOUT;
+    ConfigData.Config6.RequestTimeOut = TimeoutValue;
  IP6_COPY_ADDRESS (, 
>StationIp.v6);

  ImageHandle = Private->Ip6Nic->ImageHandle;
    }
diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.h 
b/NetworkPkg/HttpBootDxe/HttpBootClient.h

index 971b2dc800..3a98f0f557 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.h
@@ -1,7 +1,7 @@
  /** @file
    Declaration of the boot file download function.
  -Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.

+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
  SPDX-License-Identifier: BSD-2-Clause-Patent
  @@ -10,12 +10,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
  #ifndef __EFI_HTTP_BOOT_HTTP_H__
  #define __EFI_HTTP_BOOT_HTTP_H__
  -#define HTTP_BOOT_REQUEST_TIMEOUT    5000  // 5 
seconds in uints of millisecond.
-#define HTTP_BOOT_RESPONSE_TIMEOUT   5000  // 5 seconds 
in uints of millisecond.

  #define HTTP_BOOT_BLOCK_SIZE 1500
-
-
-
  #define HTTP_USER_AGENT_EFI_HTTP_BOOT "UefiHttpBoot/1.0"
    //
diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf

index a27a561722..cffa642a4b 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  This modules produce the Load File Protocol for UEFI HTTP boot.
  #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights 
reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights 
reserved.

  #  (C) Copyright 2020 Hewlett-Packard Development Company, L.P.
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -96,6 +96,7 @@
    [Pcd]
    gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections ## CONSUMES
+  gEfiNetworkPkgTokenSpaceGuid.PcdHttpIoTimeout  ## 
CONSUMES

    [UserExtensions.TianoCore."ExtraFiles"]
    HttpBootDxeExtra.uni
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf 
b/NetworkPkg/HttpDxe/HttpDxe.inf

index 35fe31af18..8dd3838793 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  Implementation of EFI HTTP protocol interfaces.
  #
-#  

Re: [edk2-devel] [PATCH v5 00/11] Measured SEV boot with kernel/initrd/cmdline

[Yao, Jiewen]

For OvmfPkg, reviewed-by: Jiewen Yao 
For ArmVirtPkg, acked-by: Jiewen Yao 



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Dov Murik
> Sent: Wednesday, July 28, 2021 3:07 AM
> To: devel@edk2.groups.io
> Cc: Dov Murik ; Tobin Feldman-Fitzthum
> ; Tobin Feldman-Fitzthum ; Jim
> Cadden ; James Bottomley ;
> Hubertus Franke ; Ard Biesheuvel
> ; Justen, Jordan L ;
> Ashish Kalra ; Brijesh Singh ;
> Erdem Aktas ; Yao, Jiewen ;
> Xu, Min M ; Tom Lendacky
> ; Leif Lindholm ; Sami
> Mujawar 
> Subject: [edk2-devel] [PATCH v5 00/11] Measured SEV boot with
> kernel/initrd/cmdline
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> 
> Booting with SEV prevented the loading of kernel, initrd, and kernel
> command-line via QEMU fw_cfg interface because they arrive from the VMM
> which is untrusted in SEV.
> 
> However, in some cases the kernel, initrd, and cmdline are not secret
> but should not be modified by the host.  In such a case, we want to
> verify inside the trusted VM that the kernel, initrd, and cmdline are
> indeed the ones expected by the Guest Owner, and only if that is the
> case go on and boot them up (removing the need for grub inside OVMF in
> that mode).
> 
> This patch series reserves an area in MEMFD (previously the last 1KB of
> the launch secret page) which will contain the hashes of these three
> blobs (kernel, initrd, cmdline), each under its own GUID entry.  This
> tables of hashes is populated by QEMU before launch, and encrypted as
> part of the initial VM memory; this makes sure these hashes are part of
> the SEV measurement (which has to be approved by the Guest Owner for
> secret injection, for example).  Note that populating the hashes table
> requires QEMU support [1].
> 
> OVMF parses the table of hashes populated by QEMU (patch 10), and as it
> reads the fw_cfg blobs from QEMU, it will verify each one against the
> expected hash.  This is all done inside the trusted VM context.  If all
> the hashes are correct, boot of the kernel is allowed to continue.
> 
> Any attempt by QEMU to modify the kernel, initrd, cmdline (including
> dropping one of them), or to modify the OVMF code that verifies those
> hashes, will cause the initial SEV measurement to change and therefore
> will be detectable by the Guest Owner during launch before secret
> injection.
> 
> Relevant part of OVMF serial log during boot with AmdSevX86 build and
> QEMU with -kernel/-initrd/-append:
> 
>   ...
>   BlobVerifierLibSevHashesConstructor: Found injected hashes table in secure
> location
>   Select Item: 0x17
>   Select Item: 0x8
>   FetchBlob: loading 7379328 bytes for "kernel"
>   Select Item: 0x18
>   Select Item: 0x11
>   VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
>   VerifyBlob: Hash comparison succeeded for "kernel"
>   Select Item: 0xB
>   FetchBlob: loading 12483878 bytes for "initrd"
>   Select Item: 0x12
>   VerifyBlob: Found GUID 44BAF731-3A2F-4BD7-9AF1-41E29169781D in table
>   VerifyBlob: Hash comparison succeeded for "initrd"
>   Select Item: 0x14
>   FetchBlob: loading 86 bytes for "cmdline"
>   Select Item: 0x15
>   VerifyBlob: Found GUID 97D02DD8-BD20-4C94-AA78-E7714D36AB2A in table
>   VerifyBlob: Hash comparison succeeded for "cmdline"
>   ...
> 
> The patch series is organized as follows:
> 
> 1: Simple comment fix in adjacent area in the code.
> 2: Use GenericQemuLoadImageLib to gain one location for fw_cfg blob
>fetching.
> 3: Allow the (previously blocked) usage of -kernel in AmdSevX64.
> 4-7:   Add BlobVerifierLib with null implementation and use it in the correct
>location in QemuKernelLoaderFsDxe.
> 8-9:   Reserve memory for hashes table, declare this area in the reset vector.
> 10-11: Add the secure implementation BlobVerifierLibSevHashes and use it in
>AmdSevX64 builds.
> 
> [1] https://lore.kernel.org/qemu-devel/20210624102040.2015280-1-
> dovmu...@linux.ibm.com/
> 
> Code is at
> https://github.com/confidential-containers-demo/edk2/tree/sev-hashes-v5
> 
> v5 changes:
>  - rename the null implementation dir to OvmfPkg/Library/BlobVerifierLibNull
>(note that I didn't remove the R-b tags on these patches; please let me
>know if I should have acted otherwise)
>  - move the SevHashes implementation to
> OvmfPkg/AmdSev/BlobVerifierLibSevHashes
>  - BlobVerifierLib.h: fix #ifndef according to ECC warnings
>  - separate variable declaration and assignment in
>BlobVerifierLibSevHashesConstructor (ECC warning)
> 
> v4: https://edk2.groups.io/g/devel/message/78075
> v4 changes:
>  - BlobVerifierSevHashes (patch 10): more comprehensive overflow tests
>when parsing the SEV hashes table structure
> 
> v3: https://edk2.groups.io/g/devel/message/77955
> v3 changes:
>  - Rename to BlobVerifierLibNull, use decimal INF_VERSION, remove unused
>DebugLib reference, fix doxygen comments, add missing IN attribute
>  - Rename to BlobVerifierLibSevHashes, use decimal INF_VERSION, fix
>

Re: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP) support

[Yao, Jiewen]

Sounds good. Thank you to confirm that.

I will send my feedback.



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Brijesh
> Singh via groups.io
> Sent: Wednesday, July 28, 2021 11:22 PM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: brijesh.si...@amd.com; James Bottomley ; Xu, Min M
> ; Tom Lendacky ; Justen,
> Jordan L ; Ard Biesheuvel
> ; Laszlo Ersek ; Erdem Aktas
> ; Dong, Eric ; Ni, Ray
> ; Kumar, Rahul1 ; Kinney, Michael
> D ; Liming Gao ; Liu,
> Zhiguang ; Michael Roth 
> Subject: Re: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging
> (SEV-SNP) support
> 
> Hi Yao Jiewen,
> 
> On 7/28/21 3:16 AM, Yao, Jiewen wrote:
> > Hi Brijesh
> > I reviewed the patch set. I have some basic questions.
> > Please help me understand before I post my comment
> >
> > If a platform supports SEV-SNP, can we assume SEV-ES is supported?
> 
> The SEV-SNP depends on SEV and SEV-ES support.
> 
> The SEV-ES depends on the SEV support.
> 
> 
> > Or is it a valid case that SecSnp==YES, SevEs==NO?
> Nope.
> 
> >
> > I am trying to understand how many cases we need support.
> > I think we want to support below:
> > ++
> > | SEV | SEV_ES | SEV_SNP |
> > ++
> > |  0  |   0|0|
> > |  1  |   0|0|
> > |  1  |   1|0|
> > |  1  |   1|1|
> > ++
> >
> 
> Yes, the above looks correct.
> 
> >
> > Any other combination we need support? Such as below:
> 
> The below cases are not applicable.
> 
> > ++
> > | SEV | SEV_ES | SEV_SNP |
> > ++
> > |  0  |   1|0|
> > |  0  |   0|1|
> > |  0  |   1|1|
> > |  1  |   0|1|
> > ++
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >> -Original Message-
> >> From: Brijesh Singh 
> >> Sent: Tuesday, June 29, 2021 1:42 AM
> >> To: devel@edk2.groups.io
> >> Cc: James Bottomley ; Xu, Min M
> ;
> >> Yao, Jiewen ; Tom Lendacky
> >> ; Justen, Jordan L ;
> >> Ard Biesheuvel ; Laszlo Ersek
> >> ; Erdem Aktas ; Dong, Eric
> >> ; Ni, Ray ; Kumar, Rahul1
> >> ; Kinney, Michael D
> ;
> >> Liming Gao ; Liu, Zhiguang
> >> ; Michael Roth ; Brijesh
> >> Singh 
> >> Subject: [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP)
> >> support
> >>
> >> BZ:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.
> tianocore.org%2Fshow_bug.cgi%3Fid%3D3275data=04%7C01%7Cbrijesh.
> singh%40amd.com%7C6bbdbdbb0ac8400b53a808d951a00e10%7C3dd8961fe48
> 84e608e11a82d994e183d%7C0%7C0%7C637630571069893367%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000sdata=BqKBPTm4RQFXsekHTH2ktc2YmZMwazn
> 9bZy8G8%2BWSTA%3Dreserved=0
> >>
> >> SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
> >> new hardware-based memory protections. SEV-SNP adds strong memory
> >> integrity
> >> protection to help prevent malicious hypervisor-based attacks like data
> >> replay, memory re-mapping and more in order to create an isolated memory
> >> encryption environment.
> >>
> >> This series provides the basic building blocks to support booting the 
> >> SEV-SNP
> >> VMs, it does not cover all the security enhancement introduced by the SEV-
> SNP
> >> such as interrupt protection.
> >>
> >> Many of the integrity guarantees of SEV-SNP are enforced through a new
> >> structure called the Reverse Map Table (RMP). Adding a new page to SEV-SNP
> >> VM requires a 2-step process. First, the hypervisor assigns a page to the
> >> guest using the new RMPUPDATE instruction. This transitions the page to
> >> guest-invalid. Second, the guest validates the page using the new PVALIDATE
> >> instruction. The SEV-SNP VMs can use the new "Page State Change Request
> >> NAE"
> >> defined in the GHCB specification to ask hypervisor to add or remove page
> >> from the RMP table.
> >>
> >> Each page assigned to the SEV-SNP VM can either be validated or 
> >> unvalidated,
> >> as indicated by the Validated flag in the page's RMP entry. There are two
> >> approaches that can be taken for the page validation: Pre-validation and
> >> Lazy Validation.
> >>
> >> Under pre-validation, the pages are validated prior to first use. And under
> >> lazy validation, pages are validated when first accessed. An access to a
> >> unvalidated page results in a #VC exception, at which time the exception
> >> handler may validate the page. Lazy validation requires careful tracking of
> >> the validated pages to avoid validating the same GPA more than once. The
> >> recently introduced "Unaccepted" memory type can be used to communicate
> >> the
> >> unvalidated memory ranges to the Guest OS.
> >>
> >> At this time we only support the pre-validation. OVMF detects all the
> available
> >> system RAM in the PEI phase. When SEV-SNP is enabled, the memory is
> validated
> >> before it is made available to the EDK2 core.
> >>
> >> 

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

[Yao, Jiewen]

I would say it is NOT the best software practice to define 2 enable fields to 
indicate one type.

What if some software error, set both TdxEnable and SevEnable at same time?
How do you detect such error?

If some code may check the SEV only, and some code may check TDX only, then 
both code can run. That will be a disaster. The code is hard to maintain and 
hard to debug.

Another consideration is: what if someone wants to set the third type?
Do we want to reserve the 3rd byte? To indicate the third type? It is not 
scalable.

The best software practice it to just define one field as enumeration. So any 
software can only set Tdx or Sev. The result is consistent, no matter you check 
the SEV at first or TDX at first.
If there is 3rd bytes, we just need assign the 3rd value to it, without impact 
any other field.


I think we can add "must zero" in the comment. But it does not mean there will 
be no error during development.

UNION is not a type safe structure. Usually, the consumer of UNION shall refer 
to a common field to know what the type of union is - I treat that as header.

Since we are defining a common data structure, I think we can do some clean up.
Or if you have concern to change SEC_SEV_ES_WORK_AREA, we can define a new CC 
WORK_AREA without touching SEV_SEV_ES_WORKING_AREA.

Thank you
Yao Jiewen


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Brijesh
> Singh via groups.io
> Sent: Wednesday, July 28, 2021 11:59 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 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 struct {
>   UINT8SevEsEnabled;
> 
>   // If Es is enabled then this field must be zeroed
>   UINT8MustBeZero;
> 
>   UINT8Reserved1[6];
> 
>   UINT64   RandomData;
> 
>   UINT64   EncryptionMask;
> } SEC_SEV_ES_WORK_AREA;
> 
> typedef struct {
>   // If Tdx is enabled then it must be zeroed
>   UINT8MustBeZero
> 
>   UINT8TdxEnabled;
> 
>   UINT8Reserved2[6];
>   
> 
> } TX_WORK_AREA;
> 
> typedef union {
>   SEC_SEV_ES_WORK_AREA SevEsWorkArea;
>   TDX_WORK_AREATdxWorkArea;
> } CC_WORK_AREA;
> 
> I am trying to minimize the changes to the existing code. The SEV and
> TDX probe logic should ensure that if the feature is detected, then it
> must clear the MustBeZero'ed field.
> 
> Basically, we already have a 64-bit value reserved in the SevEsWork area
> and currently only one byte is used and second byte can be detected for
> the TDX. Basically the which encryption technology is active the
> definition of the work area will change.
> 
> Am I missing something ?
> 
> Thanks
> 
> On 7/28/21 10:22 AM, Yao, Jiewen wrote:
> > Hi Brijesh
> > Thanks!
> >
> > I think if we want to reuse this, we need rename the data structure.
> >
> > First, we should use a generic name.
> >
> > Second, I don’t think it is good idea to define two *enable* fields. Since 
> > only
> one of them should be enabled, we should use 1 field as enumeration.
> >
> > Third, we should hide the SEV specific and TDX specific definition in CC
> common work area.
> >
> > If we agree to use a common work area, I recommend below:
> >
> > typedef struct {
> > UINT8HeaderVersion; // 0
> > UINT8HeadLength; // 4
> > UINT8Type; // 0 - legacy, 1 - SEV, 2 - TDX
> > UINT8SubType; // Type specific sub type, if needed.
> > } CC_COMMON_WORK_AREA_HEADER;
> >
> > typedef struct {
> > CC_COMMON_WORK_AREA_HEADER Header;
> > // reset is valid if Type == 1
> > UINT8Reserved1[4];
> > UINT64   RandomData;
> > UINT64   EncryptionMask;
> > } SEC_SEV_ES_WORK_AREA;
> >
> > typedef struct {
> > CC_COMMON_WORK_AREA_HEADER Header;
> > // reset is valid if Type == 2
> > UINT8TdxSpecific[];  // TBD
> > } TDX_WORK_AREA;
> >
> > Thank you
> > Yao Jiewen
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of Brijesh
> >> Singh via groups.io
> >> Sent: Wednesday, July 28, 2021 10:34 PM
> >> To: Yao, Jiewen ; Xu, 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 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 - 

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

[Brijesh Singh via groups.io]

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 struct {
UINT8SevEsEnabled;

// If Es is enabled then this field must be zeroed
UINT8MustBeZero;

UINT8Reserved1[6];

UINT64   RandomData;

UINT64   EncryptionMask;
} SEC_SEV_ES_WORK_AREA;

typedef struct {
// If Tdx is enabled then it must be zeroed
UINT8MustBeZero

UINT8TdxEnabled;

UINT8Reserved2[6];


} TX_WORK_AREA;

typedef union {
SEC_SEV_ES_WORK_AREA SevEsWorkArea;
TDX_WORK_AREATdxWorkArea;
} CC_WORK_AREA;

I am trying to minimize the changes to the existing code. The SEV and 
TDX probe logic should ensure that if the feature is detected, then it 
must clear the MustBeZero'ed field.


Basically, we already have a 64-bit value reserved in the SevEsWork area 
and currently only one byte is used and second byte can be detected for 
the TDX. Basically the which encryption technology is active the 
definition of the work area will change.


Am I missing something ?

Thanks

On 7/28/21 10:22 AM, Yao, Jiewen wrote:

Hi Brijesh
Thanks!

I think if we want to reuse this, we need rename the data structure.

First, we should use a generic name.

Second, I don’t think it is good idea to define two *enable* fields. Since only 
one of them should be enabled, we should use 1 field as enumeration.

Third, we should hide the SEV specific and TDX specific definition in CC common 
work area.

If we agree to use a common work area, I recommend below:

typedef struct {
UINT8HeaderVersion; // 0
UINT8HeadLength; // 4
UINT8Type; // 0 - legacy, 1 - SEV, 2 - TDX
UINT8SubType; // Type specific sub type, if needed.
} CC_COMMON_WORK_AREA_HEADER;

typedef struct {
CC_COMMON_WORK_AREA_HEADER Header;
// reset is valid if Type == 1
UINT8Reserved1[4];
UINT64   RandomData;
UINT64   EncryptionMask;
} SEC_SEV_ES_WORK_AREA;

typedef struct {
CC_COMMON_WORK_AREA_HEADER Header;
// reset is valid if Type == 2
UINT8TdxSpecific[];  // TBD
} TDX_WORK_AREA;

Thank you
Yao Jiewen


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Brijesh
Singh via groups.io
Sent: Wednesday, July 28, 2021 10:34 PM
To: Yao, Jiewen ; Xu, 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 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 - 4]

4) A new CC common fixed region, such as
dword[CC_COMMON_FLAGS]

5) A fixed region piggyback on existing CC working area, such as
dword[CC_WORKING_AREA]

Hi Brijesh/Min
Any preference?

[CC Indicator Flags]
Proposal: UINT8[4]

Byte [0] Version: 0
byte [1] Length: 4
byte [2] Type:
0: legacy
1: SEV
2: TDX
byte [3] Sub Type:
If Type is 0 (legacy), then
0: legacy
If Type is 1 (SEV), then
0: SEV
1: SEV-ES
2: SEV-SNP
If Type is 2 (TDX), then
0: TDX 1.0

Thank you
Yao Jiewen



-Original Message-
From: Xu, Min M 
Sent: Wednesday, July 28, 2021 2:58 PM
To: Yao, Jiewen 
Cc: Brijesh Singh ; devel@edk2.groups.io; Ard
Biesheuvel ; Justen, Jordan L
; Erdem Aktas ;

James

Bottomley ; Tom Lendacky



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

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 Tdx the memory region should be initialized by host

VMM.


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 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?

I have replied to Brijesh's mail about the concern of the new pattern.

I have some concern in the current pattern:

 OneTimeCall   PreMainFunctionHookSev
 OneTimeCall   PreMainFunctionHookTdx
MainFunction:
 XX
 OneTimeCall   PostMainFunctionHookSev
 OneTimeCall   PostMainFunctionHookTdx

The TEE function need implement a TEE check function (such as IsSev, or

IsTdx).


Tdx call CPUID(0x21) to determine 

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Rebecca Cran]

I think it's mostly been abandoned, and people are expected to use 
native UEFI functions instead. Personally I'd like to see it continue to 
be maintained.



--
Rebecca Cran


On 7/28/21 9:45 AM, Maciej Rabeda wrote:
Naturally. Since it is there, why is it not used for brotli, openssl 
in CryptoPkg or jansson in RedfishPkg?


On 28-Jul-21 17:34, Rebecca Cran wrote:
Are you aware of the edk2-libc project at 
https://github.com/tianocore/edk2-libc ?













-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78296): https://edk2.groups.io/g/devel/message/78296
Mute This Topic: https://groups.io/mt/84484790/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Maciej Rabeda]

Naturally. Since it is there, why is it not used for brotli, openssl in 
CryptoPkg or jansson in RedfishPkg?


On 28-Jul-21 17:34, Rebecca Cran wrote:
Are you aware of the edk2-libc project at 
https://github.com/tianocore/edk2-libc ?







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78295): https://edk2.groups.io/g/devel/message/78295
Mute This Topic: https://groups.io/mt/84484790/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH v1 1/1] Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp

[Takuto Naito]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3511

The PCD PcdDebugLoadImageMethod, which is consumed by
PeCoffExtraActionLibDebug.inf is only for the DEBUG build.

Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Chasel Chiu 
Signed-off-by: Takuto Naito 
---
 Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc 
b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
index 41dc55a14d..fa41ae923d 100644
--- a/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
+++ b/Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc
@@ -148,7 +148,9 @@
 
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F# 
Enable asserts, prints, code, clear memory, and deadloops on asserts.
   gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x80200047  # 
Built in messages:  Error, MTRR, info, load, warn, init
+!if $(TARGET) == "DEBUG"
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2 # This 
is set to INT3 (0x2) for Simics source level debugging
+!endif
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdHwErrStorageSize|0x0
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78294): https://edk2.groups.io/g/devel/message/78294
Mute This Topic: https://groups.io/mt/84508132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH v1 0/1] Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp

[Takuto Naito]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3511

https://github.com/naitaku/edk2-platforms/tree/FixWilsonCityRvpRelease_v1

Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Chasel Chiu 

Takuto Naito (1):
  Platform/Intel/WhitleyOpenBoardPkg: Fix build error of WilsonCityRvp

 Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78293): https://edk2.groups.io/g/devel/message/78293
Mute This Topic: https://groups.io/mt/84508125/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Rebecca Cran]

Are you aware of the edk2-libc project at 
https://github.com/tianocore/edk2-libc ?



--
Rebecca Cran


On 7/27/21 9:48 AM, Maciej Rabeda wrote:

Hi,

I have submitted a new edk2-staging branch named "StdLibPkg".
https://github.com/tianocore/edk2-staging/tree/StdLibPkg

Branch contains initial implementation of C standard library and 
intrinsic library for UEFI to smoothen open-source submodule 
integration (instead of implementing those functions in each new 
package introducing an external submodule dependent on C stdlib).


More details on the package, its contents and feature scope are placed 
in that branch, in StdLibPkg/Readme.md file.
https://github.com/tianocore/edk2-staging/blob/StdLibPkg/StdLibPkg/Readme.md 



Feel free to play around. Any and all feedback is welcome.

Thanks,
Maciej








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78292): https://edk2.groups.io/g/devel/message/78292
Mute This Topic: https://groups.io/mt/84484790/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP) support

[Brijesh Singh via groups.io]

Hi Yao Jiewen,

On 7/28/21 3:16 AM, Yao, Jiewen wrote:

Hi Brijesh
I reviewed the patch set. I have some basic questions.
Please help me understand before I post my comment

If a platform supports SEV-SNP, can we assume SEV-ES is supported?


The SEV-SNP depends on SEV and SEV-ES support.

The SEV-ES depends on the SEV support.



Or is it a valid case that SecSnp==YES, SevEs==NO?

Nope.



I am trying to understand how many cases we need support.
I think we want to support below:
++
| SEV | SEV_ES | SEV_SNP |
++
|  0  |   0|0|
|  1  |   0|0|
|  1  |   1|0|
|  1  |   1|1|
++



Yes, the above looks correct.



Any other combination we need support? Such as below:


The below cases are not applicable.


++
| SEV | SEV_ES | SEV_SNP |
++
|  0  |   1|0|
|  0  |   0|1|
|  0  |   1|1|
|  1  |   0|1|
++


Thank you
Yao Jiewen


-Original Message-
From: Brijesh Singh 
Sent: Tuesday, June 29, 2021 1:42 AM
To: devel@edk2.groups.io
Cc: James Bottomley ; Xu, Min M ;
Yao, Jiewen ; Tom Lendacky
; Justen, Jordan L ;
Ard Biesheuvel ; Laszlo Ersek
; Erdem Aktas ; Dong, Eric
; Ni, Ray ; Kumar, Rahul1
; Kinney, Michael D ;
Liming Gao ; Liu, Zhiguang
; Michael Roth ; Brijesh
Singh 
Subject: [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP)
support

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3275data=04%7C01%7Cbrijesh.singh%40amd.com%7C6bbdbdbb0ac8400b53a808d951a00e10%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637630571069893367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=BqKBPTm4RQFXsekHTH2ktc2YmZMwazn9bZy8G8%2BWSTA%3Dreserved=0

SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
new hardware-based memory protections. SEV-SNP adds strong memory
integrity
protection to help prevent malicious hypervisor-based attacks like data
replay, memory re-mapping and more in order to create an isolated memory
encryption environment.

This series provides the basic building blocks to support booting the SEV-SNP
VMs, it does not cover all the security enhancement introduced by the SEV-SNP
such as interrupt protection.

Many of the integrity guarantees of SEV-SNP are enforced through a new
structure called the Reverse Map Table (RMP). Adding a new page to SEV-SNP
VM requires a 2-step process. First, the hypervisor assigns a page to the
guest using the new RMPUPDATE instruction. This transitions the page to
guest-invalid. Second, the guest validates the page using the new PVALIDATE
instruction. The SEV-SNP VMs can use the new "Page State Change Request
NAE"
defined in the GHCB specification to ask hypervisor to add or remove page
from the RMP table.

Each page assigned to the SEV-SNP VM can either be validated or unvalidated,
as indicated by the Validated flag in the page's RMP entry. There are two
approaches that can be taken for the page validation: Pre-validation and
Lazy Validation.

Under pre-validation, the pages are validated prior to first use. And under
lazy validation, pages are validated when first accessed. An access to a
unvalidated page results in a #VC exception, at which time the exception
handler may validate the page. Lazy validation requires careful tracking of
the validated pages to avoid validating the same GPA more than once. The
recently introduced "Unaccepted" memory type can be used to communicate
the
unvalidated memory ranges to the Guest OS.

At this time we only support the pre-validation. OVMF detects all the available
system RAM in the PEI phase. When SEV-SNP is enabled, the memory is validated
before it is made available to the EDK2 core.

This series does not implements the following SEV-SNP features yet:

* CPUID filtering
* Lazy validation
* Interrupt security

Additional resources
-
SEV-SNP whitepaper
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2FSEV-SNP-strengthening-vm-data=04%7C01%7Cbrijesh.singh%40amd.com%7C6bbdbdbb0ac8400b53a808d951a00e10%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637630571069893367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7p5Ap%2FHMiSXgxxMI35SYWcZaUcx5VjNt1wnpV9kbT6c%3Dreserved=0
isolation-with-integrity-protection-and-more.pdf

APM 2: 

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

[Yao, Jiewen]

Hi Brijesh
Thanks!

I think if we want to reuse this, we need rename the data structure.

First, we should use a generic name.

Second, I don’t think it is good idea to define two *enable* fields. Since only 
one of them should be enabled, we should use 1 field as enumeration.

Third, we should hide the SEV specific and TDX specific definition in CC common 
work area.

If we agree to use a common work area, I recommend below:

typedef struct {
   UINT8HeaderVersion; // 0
   UINT8HeadLength; // 4
   UINT8Type; // 0 - legacy, 1 - SEV, 2 - TDX
   UINT8SubType; // Type specific sub type, if needed.
} CC_COMMON_WORK_AREA_HEADER;

typedef struct {
   CC_COMMON_WORK_AREA_HEADER Header;
   // reset is valid if Type == 1
   UINT8Reserved1[4];
   UINT64   RandomData;
   UINT64   EncryptionMask;
} SEC_SEV_ES_WORK_AREA;

typedef struct {
   CC_COMMON_WORK_AREA_HEADER Header;
   // reset is valid if Type == 2
   UINT8TdxSpecific[];  // TBD
} TDX_WORK_AREA;

Thank you
Yao Jiewen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Brijesh
> Singh via groups.io
> Sent: Wednesday, July 28, 2021 10:34 PM
> To: Yao, Jiewen ; Xu, 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 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 - 4]
> >
> > 4) A new CC common fixed region, such as
> > dword[CC_COMMON_FLAGS]
> >
> > 5) A fixed region piggyback on existing CC working area, such as
> > dword[CC_WORKING_AREA]
> >
> > Hi Brijesh/Min
> > Any preference?
> >
> > [CC Indicator Flags]
> > Proposal: UINT8[4]
> >
> > Byte [0] Version: 0
> > byte [1] Length: 4
> > byte [2] Type:
> > 0: legacy
> > 1: SEV
> > 2: TDX
> > byte [3] Sub Type:
> > If Type is 0 (legacy), then
> > 0: legacy
> > If Type is 1 (SEV), then
> > 0: SEV
> > 1: SEV-ES
> > 2: SEV-SNP
> > If Type is 2 (TDX), then
> > 0: TDX 1.0
> >
> > Thank you
> > Yao Jiewen
> >
> >
> >> -Original Message-
> >> From: Xu, Min M 
> >> Sent: Wednesday, July 28, 2021 2:58 PM
> >> To: Yao, Jiewen 
> >> Cc: Brijesh Singh ; devel@edk2.groups.io; Ard
> >> Biesheuvel ; Justen, Jordan L
> >> ; Erdem Aktas ;
> James
> >> Bottomley ; Tom Lendacky
> 
> >> Subject: RE: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector
> >>
> >> 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 Tdx the memory region should be initialized by 
> >> host
> VMM.
> >>>
> >>> 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 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?
>  I have replied to Brijesh's mail about the concern of the new pattern.
> 
>  I have some concern in the current pattern:
>  
>  OneTimeCall   PreMainFunctionHookSev
>  OneTimeCall   PreMainFunctionHookTdx
>  MainFunction:
>  XX
>  OneTimeCall   PostMainFunctionHookSev
>  OneTimeCall   PostMainFunctionHookTdx
>  
>  The TEE function need implement a TEE check function (such as IsSev, or
> >> IsTdx).
> 
>  Tdx call CPUID(0x21) to determine if it is tdx guest in the very
>  beginning of ResetVector. Then 'TDXG' is set in TDX_WORK_AREA. SEV
> does
> >>> the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to
> 1.
> 
>  After that both TDX and SEV read the above WORK_AREA to check if it is
> TDX
> >>> or SEV or legacy guest.
> 
>  In Tdx the access to SEV_ES_WORK_AREA will trigger error because
> >>> SEV_ES_WORK_AREA is *NOT* initialized by host VMM.
>  In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error
> too.
> 
>  I am wondering if TDX and SEV can use the same memory region (for
> >> example,
> >>> TEE_WORK_AREA) as the work area?
>  So that this work area is guaranteed to be initialized in both TDX and
>  SEV. Structure 

Re: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to Tpm2HierarchyChangeAuth

[Stefan Berger]

I now filed this bug:

https://bugzilla.tianocore.org/show_bug.cgi?id=3510

    Stefan


On 7/28/21 10:38 AM, Michael Kubacki wrote:

The main commit of the series Bret mentioned (in edk2-platforms) is here:

https://github.com/tianocore/edk2-platforms/commit/bfabeef4c9a63374784bd19f18a869aa2769e011 



Regards,
Michael

On 7/27/2021 12:25 PM, Yao, Jiewen wrote:

Oops. Sorry for late response.

The code is NOT in EDKII, but EDKII-platform as example. 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg 
 



We allow a platform having its own implementation. That is why it is 
NOT in EDKII.


Thank you

Yao Jiewen

*From:* devel@edk2.groups.io  *On Behalf Of 
*Bret Barkelew via groups.io

*Sent:* Wednesday, July 28, 2021 12:11 AM
*To:* devel@edk2.groups.io; stef...@linux.ibm.com; Yao, Jiewen 
; Jeremiah Cox ; Michael 
Kubacki 

*Cc:* Marc-André Lureau 
*Subject:* Re: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to 
Tpm2HierarchyChangeAuth


Adding @Jeremiah …

Jeremiah, weren’t you or @Michael 
 shopping this change to 
MinPlatform?


- Bret

*From: *Stefan Berger via groups.io 


*Sent: *Monday, July 26, 2021 7:48 AM
*To: *Yao, Jiewen ; devel@edk2.groups.io 


*Cc: *Marc-André Lureau 
*Subject: *[EXTERNAL] [edk2-devel] Missing TPM 2 related call to 
Tpm2HierarchyChangeAuth


Hello!

    The TPM 2 code in EDK2 is missing an important call to
Tpm2HierarchyChangeAuth for the platform hierarchy. We have to set the
password of that hierarchy and discard the password. See also specs
section 11:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fwp-content%2Fuploads%2FTCG_PCClient_PFP_r1p05_v22_02dec2020.pdfdata=04%7C01%7Cbret.barkelew%40microsoft.com%7Cf2a2262eee2c44b3760c08d95044601a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629077356686202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=N7VQIw87rHqUAFQ54TvhNwcsPFEwJzdZQ9JZrmX1S4E%3Dreserved=0 
 



"Platform Firmware MUST protect access to the Platform Hierarchy and
prevent access to the platform hierarchy by
non-manufacturer-controlled components.  "

I was wondering where we could put that call so it's invoked after the
user has possibly interacted with the menu and before passing control to
the next stage such as boot loader.

Regards,

    Stefan















-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78289): https://edk2.groups.io/g/devel/message/78289
Mute This Topic: https://groups.io/mt/84485285/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to Tpm2HierarchyChangeAuth

[Michael Kubacki]

The main commit of the series Bret mentioned (in edk2-platforms) is here:

https://github.com/tianocore/edk2-platforms/commit/bfabeef4c9a63374784bd19f18a869aa2769e011

Regards,
Michael

On 7/27/2021 12:25 PM, Yao, Jiewen wrote:

Oops. Sorry for late response.

The code is NOT in EDKII, but EDKII-platform as example. 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg 



We allow a platform having its own implementation. That is why it is NOT 
in EDKII.


Thank you

Yao Jiewen

*From:* devel@edk2.groups.io  *On Behalf Of *Bret 
Barkelew via groups.io

*Sent:* Wednesday, July 28, 2021 12:11 AM
*To:* devel@edk2.groups.io; stef...@linux.ibm.com; Yao, Jiewen 
; Jeremiah Cox ; Michael 
Kubacki 

*Cc:* Marc-André Lureau 
*Subject:* Re: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to 
Tpm2HierarchyChangeAuth


Adding @Jeremiah …

Jeremiah, weren’t you or @Michael  
shopping this change to MinPlatform?


- Bret

*From: *Stefan Berger via groups.io 
*Sent: *Monday, July 26, 2021 7:48 AM
*To: *Yao, Jiewen ; devel@edk2.groups.io 


*Cc: *Marc-André Lureau 
*Subject: *[EXTERNAL] [edk2-devel] Missing TPM 2 related call to 
Tpm2HierarchyChangeAuth


Hello!

    The TPM 2 code in EDK2 is missing an important call to
Tpm2HierarchyChangeAuth for the platform hierarchy. We have to set the
password of that hierarchy and discard the password. See also specs
section 11:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fwp-content%2Fuploads%2FTCG_PCClient_PFP_r1p05_v22_02dec2020.pdfdata=04%7C01%7Cbret.barkelew%40microsoft.com%7Cf2a2262eee2c44b3760c08d95044601a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629077356686202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=N7VQIw87rHqUAFQ54TvhNwcsPFEwJzdZQ9JZrmX1S4E%3Dreserved=0 



"Platform Firmware MUST protect access to the Platform Hierarchy and
prevent access to the platform hierarchy by
non-manufacturer-controlled components.  "

I was wondering where we could put that call so it's invoked after the
user has possibly interacted with the menu and before passing control to
the next stage such as boot loader.

Regards,

    Stefan









-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78288): https://edk2.groups.io/g/devel/message/78288
Mute This Topic: https://groups.io/mt/84485285/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Brijesh Singh via groups.io]

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 - 4]

4) A new CC common fixed region, such as
dword[CC_COMMON_FLAGS]

5) A fixed region piggyback on existing CC working area, such as
dword[CC_WORKING_AREA]

Hi Brijesh/Min
Any preference?

[CC Indicator Flags]
Proposal: UINT8[4]

Byte [0] Version: 0
byte [1] Length: 4
byte [2] Type:
0: legacy
1: SEV
2: TDX
byte [3] Sub Type:
If Type is 0 (legacy), then
0: legacy
If Type is 1 (SEV), then
0: SEV
1: SEV-ES
2: SEV-SNP
If Type is 2 (TDX), then
0: TDX 1.0

Thank you
Yao Jiewen



-Original Message-
From: Xu, Min M 
Sent: Wednesday, July 28, 2021 2:58 PM
To: Yao, Jiewen 
Cc: Brijesh Singh ; devel@edk2.groups.io; Ard
Biesheuvel ; Justen, Jordan L
; Erdem Aktas ; James
Bottomley ; Tom Lendacky 
Subject: RE: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector

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 Tdx the memory region should be initialized by host 
VMM.


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 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?

I have replied to Brijesh's mail about the concern of the new pattern.

I have some concern in the current pattern:

OneTimeCall   PreMainFunctionHookSev
OneTimeCall   PreMainFunctionHookTdx
MainFunction:
XX
OneTimeCall   PostMainFunctionHookSev
OneTimeCall   PostMainFunctionHookTdx

The TEE function need implement a TEE check function (such as IsSev, or

IsTdx).


Tdx call CPUID(0x21) to determine if it is tdx guest in the very
beginning of ResetVector. Then 'TDXG' is set in TDX_WORK_AREA. SEV does

the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to 1.


After that both TDX and SEV read the above WORK_AREA to check if it is TDX

or SEV or legacy guest.


In Tdx the access to SEV_ES_WORK_AREA will trigger error because

SEV_ES_WORK_AREA is *NOT* initialized by host VMM.

In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error too.

I am wondering if TDX and SEV can use the same memory region (for

example,

TEE_WORK_AREA) as the work area?

So that this work area is guaranteed to be initialized in both TDX and
SEV. Structure of the TEE_WORK_AREA may look like this:
  typedef struct {
  UINT8  Flag[4]; 'TDXG' or 'SEVG' or all-0
  UINT8  Others[];
  } TEE_WORK_AREA;




Are we reserving a new page for the TDX_WORK_AREA ? I am wondering why 
can't we use the SEV_ES_WORK_AREA instead of wasting space in the MEMFD.


The SEV_ES_WORK_AREA layout looks like this:

typedef struct _SEC_SEV_ES_WORK_AREA {
  UINT8SevEsEnabled;
  UINT8Reserved1[7];

  UINT64   RandomData;

  UINT64   EncryptionMask;
} SEC_SEV_ES_WORK_AREA;

There is reserved bit after the SevEsEnabled and one byte can be used 
for the TdxEnabled;


typedef struct _SEC_SEV_ES_WORK_AREA {
  UINT8SevEsEnabled;
  UINT8TdxEnabled;
  UINT8Reserved2[6];

  UINT64   RandomData;

  UINT64   EncryptionMask;
} SEC_SEV_ES_WORK_AREA;

The SEV_ES_WORK_AREA can be treated as a TEE_WORK_AREA and we can be 
pull out from MemEncrypSevLib.h to CcWorkAreaLib.h and rename the 
structure (if needed).


Both the SEV-SNP and TEE host-VMM accepts the TEE_WORK_AREA before 
booting the guest to ensure that its safe to access the memory without 
going through the accept/validation process.


In case of the TDX, the reset vector code sets the TdxEnabled on the 
entry. In case of the SEV, the workarea is valid from SEC to PEI phase 
only and it gets reused for other purposes. The PEI phase set the Pcd's
(such as SevEsEnabled or SevEnabled etc) so that Dxe or other EDK2 core 
does not need to know anything about the workarea and they simply can 
read the PCDs.


-Brijesh


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78287): https://edk2.groups.io/g/devel/message/78287
Mute This Topic: https://groups.io/mt/84476064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V3] NetworkPkg: Making the HTTP IO timeout value programmable with PCD

[Maciej Rabeda]

Reviewed-by: Maciej Rabeda 

On 28-Jul-21 14:16, Heng Luo wrote:

From: Zachary Clark-Williams 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3507

HTTP boot has a default set forced timeout value of 5 seconds
for getting the recovery image from a remote source.
This change allows the HTTP boot flow to get the IO timeout value
from the PcdHttpIoTimeout.
PcdHttpIoTimeout value is set in platform code.

Signed-off-by: Zachary Clark-Williams 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---
  NetworkPkg/HttpBootDxe/HttpBootClient.c | 12 +---
  NetworkPkg/HttpBootDxe/HttpBootClient.h |  7 +--
  NetworkPkg/HttpBootDxe/HttpBootDxe.inf  |  3 ++-
  NetworkPkg/HttpDxe/HttpDxe.inf  |  3 ++-
  NetworkPkg/HttpDxe/HttpImpl.c   | 17 ++---
  NetworkPkg/HttpDxe/HttpProto.h  |  3 +--
  NetworkPkg/NetworkPkg.dec   |  8 
  NetworkPkg/NetworkPkg.dsc   |  3 +++
  NetworkPkg/NetworkPkg.uni   |  8 +++-
  9 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c 
b/NetworkPkg/HttpBootDxe/HttpBootClient.c
index 8f21f7766e..aa0a153019 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -1,7 +1,7 @@
  /** @file
Implementation of the boot file download function.
  
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.

+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
  SPDX-License-Identifier: BSD-2-Clause-Patent
  
@@ -596,19 +596,25 @@ HttpBootCreateHttpIo (

HTTP_IO_CONFIG_DATA  ConfigData;
EFI_STATUS   Status;
EFI_HANDLE   ImageHandle;
+  UINT32   TimeoutValue;
  
ASSERT (Private != NULL);
  
+  //

+  // Get HTTP timeout value
+  //
+  TimeoutValue = PcdGet32 (PcdHttpIoTimeout);
+
ZeroMem (, sizeof (HTTP_IO_CONFIG_DATA));
if (!Private->UsingIpv6) {
  ConfigData.Config4.HttpVersion= HttpVersion11;
-ConfigData.Config4.RequestTimeOut = HTTP_BOOT_REQUEST_TIMEOUT;
+ConfigData.Config4.RequestTimeOut = TimeoutValue;
  IP4_COPY_ADDRESS (, >StationIp.v4);
  IP4_COPY_ADDRESS (, 
>SubnetMask.v4);
  ImageHandle = Private->Ip4Nic->ImageHandle;
} else {
  ConfigData.Config6.HttpVersion= HttpVersion11;
-ConfigData.Config6.RequestTimeOut = HTTP_BOOT_REQUEST_TIMEOUT;
+ConfigData.Config6.RequestTimeOut = TimeoutValue;
  IP6_COPY_ADDRESS (, >StationIp.v6);
  ImageHandle = Private->Ip6Nic->ImageHandle;
}
diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.h 
b/NetworkPkg/HttpBootDxe/HttpBootClient.h
index 971b2dc800..3a98f0f557 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.h
@@ -1,7 +1,7 @@
  /** @file
Declaration of the boot file download function.
  
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.

+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
  SPDX-License-Identifier: BSD-2-Clause-Patent
  
@@ -10,12 +10,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent

  #ifndef __EFI_HTTP_BOOT_HTTP_H__
  #define __EFI_HTTP_BOOT_HTTP_H__
  
-#define HTTP_BOOT_REQUEST_TIMEOUT5000  // 5 seconds in uints of millisecond.

-#define HTTP_BOOT_RESPONSE_TIMEOUT   5000  // 5 seconds in uints 
of millisecond.
  #define HTTP_BOOT_BLOCK_SIZE 1500
-
-
-
  #define HTTP_USER_AGENT_EFI_HTTP_BOOT"UefiHttpBoot/1.0"
  
  //

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
index a27a561722..cffa642a4b 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  This modules produce the Load File Protocol for UEFI HTTP boot.
  #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  #  (C) Copyright 2020 Hewlett-Packard Development Company, L.P.
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -96,6 +96,7 @@
  
  [Pcd]

gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections   ## CONSUMES
+  gEfiNetworkPkgTokenSpaceGuid.PcdHttpIoTimeout  ## CONSUMES
  
  [UserExtensions.TianoCore."ExtraFiles"]

HttpBootDxeExtra.uni
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index 35fe31af18..8dd3838793 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  Implementation of EFI HTTP protocol interfaces.
  #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -73,6 +73,7 @@
  
  

Re: [edk2-devel] [Patch V3] NetworkPkg: Add HTTP Additional Event Notifications

[Maciej Rabeda]

Reviewed-by: Maciej Rabeda 

On 28-Jul-21 13:58, Heng Luo wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3496

Add new EDKII_HTTP_CALLBACK_PROTOCOL in NetworkPkg,
Send HTTP Events via EDKII_HTTP_CALLBACK_PROTOCOL
when Dns/ConnectTcp/TlsConnectSession/InitSession
occurs.

Signed-off-by: Heng Luo 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---

  NetworkPkg/HttpDxe/HttpDriver.h|  3 ++-
  NetworkPkg/HttpDxe/HttpDxe.inf |  3 ++-
  NetworkPkg/HttpDxe/HttpImpl.c  |  4 +++-
  NetworkPkg/HttpDxe/HttpProto.c | 58 
+-
  NetworkPkg/HttpDxe/HttpProto.h | 15 ++-
  NetworkPkg/Include/Protocol/HttpCallback.h | 85 
+
  NetworkPkg/NetworkPkg.dec  |  3 +++
  7 files changed, 166 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 5fe8c5b5e9..b701b80858 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -1,7 +1,7 @@
  /** @file
The header files of the driver binding and service binding protocol for 
HttpDxe driver.
  
-  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.

+  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
(C) Copyright 2016 Hewlett Packard Enterprise Development LP
  
SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -47,6 +47,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  //
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index 35fe31af18..23fb9ec394 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  Implementation of EFI HTTP protocol interfaces.
  #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -65,6 +65,7 @@
gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
+  gEdkiiHttpCallbackProtocolGuid   ## SOMETIMES_CONSUMES
  
  [Guids]

gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES  ## 
Variable:L"TlsCaCertificate"
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 5a6ecbc9d9..97f15d229f 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -1,7 +1,7 @@
  /** @file
Implementation of EFI_HTTP_PROTOCOL protocol interfaces.
  
-  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.

+  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
(C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
  
SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -527,6 +527,7 @@ EfiHttpRequest (
} else {
  Status = HttpDns6 (HttpInstance, HostNameStr, 
>RemoteIpv6Addr);
}
+  HttpNotify (HttpEventDns, Status);
  
FreePool (HostNameStr);

if (EFI_ERROR (Status)) {
@@ -588,6 +589,7 @@ EfiHttpRequest (
   Configure || ReConfigure,
   TlsConfigure
   );
+  HttpNotify (HttpEventInitSession, Status);
if (EFI_ERROR (Status)) {
  goto Error2;
}
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index afc7db5a72..affa916bd6 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1,7 +1,7 @@
  /** @file
Miscellaneous routines for HttpDxe driver.
  
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.

+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
  SPDX-License-Identifier: BSD-2-Clause-Patent
  
@@ -966,6 +966,7 @@ HttpCreateConnection (

  HttpInstance->IsTcp4ConnDone = FALSE;
  HttpInstance->Tcp4ConnToken.CompletionToken.Status = EFI_NOT_READY;
  Status = HttpInstance->Tcp4->Connect (HttpInstance->Tcp4, 
>Tcp4ConnToken);
+HttpNotify (HttpEventConnectTcp, Status);
  if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp4->Connect() = %r\n", 
Status));
return Status;
@@ -981,6 +982,7 @@ HttpCreateConnection (
  HttpInstance->IsTcp6ConnDone = FALSE;
  HttpInstance->Tcp6ConnToken.CompletionToken.Status = EFI_NOT_READY;
  Status = HttpInstance->Tcp6->Connect (HttpInstance->Tcp6, 
>Tcp6ConnToken);
+HttpNotify (HttpEventConnectTcp, Status);
  if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp6->Connect() = %r\n", 
Status));
return Status;
@@ -1277,6 +1279,7 @@ HttpConnectTcp4 (
  }
  
  Status = 

[edk2-devel] [Patch V3] NetworkPkg: Making the HTTP IO timeout value programmable with PCD

[Heng Luo]

From: Zachary Clark-Williams 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3507

HTTP boot has a default set forced timeout value of 5 seconds
for getting the recovery image from a remote source.
This change allows the HTTP boot flow to get the IO timeout value
from the PcdHttpIoTimeout.
PcdHttpIoTimeout value is set in platform code.

Signed-off-by: Zachary Clark-Williams 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---
 NetworkPkg/HttpBootDxe/HttpBootClient.c | 12 +---
 NetworkPkg/HttpBootDxe/HttpBootClient.h |  7 +--
 NetworkPkg/HttpBootDxe/HttpBootDxe.inf  |  3 ++-
 NetworkPkg/HttpDxe/HttpDxe.inf  |  3 ++-
 NetworkPkg/HttpDxe/HttpImpl.c   | 17 ++---
 NetworkPkg/HttpDxe/HttpProto.h  |  3 +--
 NetworkPkg/NetworkPkg.dec   |  8 
 NetworkPkg/NetworkPkg.dsc   |  3 +++
 NetworkPkg/NetworkPkg.uni   |  8 +++-
 9 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c 
b/NetworkPkg/HttpBootDxe/HttpBootClient.c
index 8f21f7766e..aa0a153019 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation of the boot file download function.
 
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -596,19 +596,25 @@ HttpBootCreateHttpIo (
   HTTP_IO_CONFIG_DATA  ConfigData;
   EFI_STATUS   Status;
   EFI_HANDLE   ImageHandle;
+  UINT32   TimeoutValue;
 
   ASSERT (Private != NULL);
 
+  //
+  // Get HTTP timeout value
+  //
+  TimeoutValue = PcdGet32 (PcdHttpIoTimeout);
+
   ZeroMem (, sizeof (HTTP_IO_CONFIG_DATA));
   if (!Private->UsingIpv6) {
 ConfigData.Config4.HttpVersion= HttpVersion11;
-ConfigData.Config4.RequestTimeOut = HTTP_BOOT_REQUEST_TIMEOUT;
+ConfigData.Config4.RequestTimeOut = TimeoutValue;
 IP4_COPY_ADDRESS (, >StationIp.v4);
 IP4_COPY_ADDRESS (, >SubnetMask.v4);
 ImageHandle = Private->Ip4Nic->ImageHandle;
   } else {
 ConfigData.Config6.HttpVersion= HttpVersion11;
-ConfigData.Config6.RequestTimeOut = HTTP_BOOT_REQUEST_TIMEOUT;
+ConfigData.Config6.RequestTimeOut = TimeoutValue;
 IP6_COPY_ADDRESS (, >StationIp.v6);
 ImageHandle = Private->Ip6Nic->ImageHandle;
   }
diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.h 
b/NetworkPkg/HttpBootDxe/HttpBootClient.h
index 971b2dc800..3a98f0f557 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.h
@@ -1,7 +1,7 @@
 /** @file
   Declaration of the boot file download function.
 
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -10,12 +10,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #ifndef __EFI_HTTP_BOOT_HTTP_H__
 #define __EFI_HTTP_BOOT_HTTP_H__
 
-#define HTTP_BOOT_REQUEST_TIMEOUT5000  // 5 seconds in uints 
of millisecond.
-#define HTTP_BOOT_RESPONSE_TIMEOUT   5000  // 5 seconds in uints 
of millisecond.
 #define HTTP_BOOT_BLOCK_SIZE 1500
-
-
-
 #define HTTP_USER_AGENT_EFI_HTTP_BOOT"UefiHttpBoot/1.0"
 
 //
diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
index a27a561722..cffa642a4b 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  This modules produce the Load File Protocol for UEFI HTTP boot.
 #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 #  (C) Copyright 2020 Hewlett-Packard Development Company, L.P.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -96,6 +96,7 @@
 
 [Pcd]
   gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections   ## CONSUMES
+  gEfiNetworkPkgTokenSpaceGuid.PcdHttpIoTimeout  ## CONSUMES
 
 [UserExtensions.TianoCore."ExtraFiles"]
   HttpBootDxeExtra.uni
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index 35fe31af18..8dd3838793 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Implementation of EFI HTTP protocol interfaces.
 #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -73,6 +73,7 @@
 
 [Pcd]
   gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections   ## CONSUMES
+  gEfiNetworkPkgTokenSpaceGuid.PcdHttpIoTimeout  ## 

[edk2-devel] [Patch V3] NetworkPkg: Add HTTP Additional Event Notifications

[Heng Luo]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3496

Add new EDKII_HTTP_CALLBACK_PROTOCOL in NetworkPkg,
Send HTTP Events via EDKII_HTTP_CALLBACK_PROTOCOL
when Dns/ConnectTcp/TlsConnectSession/InitSession
occurs.

Signed-off-by: Heng Luo 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---

 NetworkPkg/HttpDxe/HttpDriver.h|  3 ++-
 NetworkPkg/HttpDxe/HttpDxe.inf |  3 ++-
 NetworkPkg/HttpDxe/HttpImpl.c  |  4 +++-
 NetworkPkg/HttpDxe/HttpProto.c | 58 
+-
 NetworkPkg/HttpDxe/HttpProto.h | 15 ++-
 NetworkPkg/Include/Protocol/HttpCallback.h | 85 
+
 NetworkPkg/NetworkPkg.dec  |  3 +++
 7 files changed, 166 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 5fe8c5b5e9..b701b80858 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -1,7 +1,7 @@
 /** @file
   The header files of the driver binding and service binding protocol for 
HttpDxe driver.
 
-  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 //
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index 35fe31af18..23fb9ec394 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Implementation of EFI HTTP protocol interfaces.
 #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -65,6 +65,7 @@
   gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
   gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
+  gEdkiiHttpCallbackProtocolGuid   ## SOMETIMES_CONSUMES
 
 [Guids]
   gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES  ## 
Variable:L"TlsCaCertificate"
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 5a6ecbc9d9..97f15d229f 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation of EFI_HTTP_PROTOCOL protocol interfaces.
 
-  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
   (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -527,6 +527,7 @@ EfiHttpRequest (
   } else {
 Status = HttpDns6 (HttpInstance, HostNameStr, 
>RemoteIpv6Addr);
   }
+  HttpNotify (HttpEventDns, Status);
 
   FreePool (HostNameStr);
   if (EFI_ERROR (Status)) {
@@ -588,6 +589,7 @@ EfiHttpRequest (
  Configure || ReConfigure,
  TlsConfigure
  );
+  HttpNotify (HttpEventInitSession, Status);
   if (EFI_ERROR (Status)) {
 goto Error2;
   }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index afc7db5a72..affa916bd6 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1,7 +1,7 @@
 /** @file
   Miscellaneous routines for HttpDxe driver.
 
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -966,6 +966,7 @@ HttpCreateConnection (
 HttpInstance->IsTcp4ConnDone = FALSE;
 HttpInstance->Tcp4ConnToken.CompletionToken.Status = EFI_NOT_READY;
 Status = HttpInstance->Tcp4->Connect (HttpInstance->Tcp4, 
>Tcp4ConnToken);
+HttpNotify (HttpEventConnectTcp, Status);
 if (EFI_ERROR (Status)) {
   DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp4->Connect() = %r\n", 
Status));
   return Status;
@@ -981,6 +982,7 @@ HttpCreateConnection (
 HttpInstance->IsTcp6ConnDone = FALSE;
 HttpInstance->Tcp6ConnToken.CompletionToken.Status = EFI_NOT_READY;
 Status = HttpInstance->Tcp6->Connect (HttpInstance->Tcp6, 
>Tcp6ConnToken);
+HttpNotify (HttpEventConnectTcp, Status);
 if (EFI_ERROR (Status)) {
   DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp6->Connect() = %r\n", 
Status));
   return Status;
@@ -1277,6 +1279,7 @@ HttpConnectTcp4 (
 }
 
 Status = TlsConnectSession (HttpInstance, HttpInstance->TimeoutEvent);
+HttpNotify (HttpEventTlsConnectSession, Status);
 
 gBS->SetTimer 

[edk2-devel] [Patch] BaseTools: use shutil.copyfile instead shutil.copy2

[Bob Feng]

In Split tool, the copy file actions only need to
copy file content but not need to copy file metadata.

copy2() copies the file metadata that causes split
unit test failed under edk2-basetools CI environment.

So this patch changes the call of copy2() to copyfile().

Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
---
 BaseTools/Source/Python/Split/Split.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/Split/Split.py 
b/BaseTools/Source/Python/Split/Split.py
index e223a72a94..e70d5c22c4 100644
--- a/BaseTools/Source/Python/Split/Split.py
+++ b/BaseTools/Source/Python/Split/Split.py
@@ -146,18 +146,18 @@ def splitFile(inputfile, position, outputdir=None, 
outputfile1=None, outputfile2
 logger.error("Can't make dir: %s" % outputfolder)
 raise(e)
 
 if position <= 0:
 if outputfile2 != os.path.abspath(inputfile):
-shutil.copy2(os.path.abspath(inputfile), outputfile2)
+shutil.copyfile(os.path.abspath(inputfile), outputfile2)
 with open(outputfile1, "wb") as fout:
 fout.write(b'')
 else:
 inputfilesize = getFileSize(inputfile)
 if position >= inputfilesize:
 if outputfile1 != os.path.abspath(inputfile):
-shutil.copy2(os.path.abspath(inputfile), outputfile1)
+shutil.copyfile(os.path.abspath(inputfile), outputfile1)
 with open(outputfile2, "wb") as fout:
 fout.write(b'')
 else:
 try:
 tempdir = tempfile.mkdtemp()
@@ -169,12 +169,12 @@ def splitFile(inputfile, position, outputdir=None, 
outputfile1=None, outputfile2
 fout1.write(content1)
 
 content2 = fin.read(inputfilesize - position)
 with open(tempfile2, "wb") as fout2:
 fout2.write(content2)
-shutil.copy2(tempfile1, outputfile1)
-shutil.copy2(tempfile2, outputfile2)
+shutil.copyfile(tempfile1, outputfile1)
+shutil.copyfile(tempfile2, outputfile2)
 except Exception as e:
 logger.error("Split file failed")
 raise(e)
 finally:
 if os.path.exists(tempdir):
-- 
2.29.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78282): https://edk2.groups.io/g/devel/message/78282
Mute This Topic: https://groups.io/mt/84503147/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys

[Ard Biesheuvel]

On Wed, 28 Jul 2021 at 12:39, Ard Biesheuvel  wrote:
>
> On Wed, 28 Jul 2021 at 09:44, gaoliming  wrote:
> >
> > Sunny:
> >   Yes. This patch set is ready to be merged.
> >
> > Samer:
> >   Would you help merge this patch set?
> >
>
> I can pick it up if you could please create the release notes entry? Thanks.
>

Submitted here:

https://github.com/tianocore/edk2/pull/1839

and failed with some errors. Could someone please diagnose/fix and submit a v7?


> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Sunny Wang
> > > 发送时间: 2021年7月21日 11:41
> > > 收件人: Samer El-Haj-Mahmoud ;
> > > devel@edk2.groups.io; g...@semihalf.com; Ard Biesheuvel
> > > ; gaolim...@byosoft.com.cn; ray...@intel.com
> > > 抄送: l...@nuviainc.com; m...@semihalf.com; upstr...@semihalf.com;
> > > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > > ler...@redhat.com; Sami Mujawar ;
> > > af...@apple.com; jordan.l.jus...@intel.com; rebe...@bsdio.com;
> > > gre...@freebsd.org; Thomas Abraham ;
> > > chasel.c...@intel.com; nathaniel.l.desim...@intel.com;
> > > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> > > Sunny Wang 
> > > 主题: Re: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> > >
> > > Ard, Liming, Ray, Thanks for your review for ArmVirtPkg, ArmPlatformPkg,
> > and
> > > EmulatorPkg patches.
> > >
> > > As for the patch for Intel Platforms below, it is in another series for
> > > edk2-platforms.
> > >  - [edk2-platforms PATCH v6 1/4] Intel Platforms: add
> > > SecureBootVariableLib class resolution
> > > https://edk2.groups.io/g/devel/message/77781
> > >
> > > Therefore, I think this series already got all the necessary Reviewed-By
> > and
> > > Acked-By of all parts and is ready to be pushed now.
> > >
> > > Best Regards,
> > > Sunny Wang
> > >
> > > -Original Message-
> > > From: Samer El-Haj-Mahmoud 
> > > Sent: Friday, July 16, 2021 8:00 PM
> > > To: devel@edk2.groups.io; g...@semihalf.com
> > > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Sunny Wang
> > > ; m...@semihalf.com; upstr...@semihalf.com;
> > > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > > ler...@redhat.com; Sami Mujawar ;
> > > af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> > > rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> > > ; chasel.c...@intel.com;
> > > nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> > > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> > > Samer El-Haj-Mahmoud 
> > > Subject: RE: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> > >
> > > The v6 of this series seems to have all the necessary Reviewed-By (and
> > some
> > > Tested-By) of all parts, except the following platform specific parts.
> > Could we
> > > get help from maintainers to review these please?
> > >
> > > Much appreciated!
> > >
> > > - ArmVirtPkg : https://edk2.groups.io/g/devel/message/2
> > > - ArmPlatformPkg: https://edk2.groups.io/g/devel/message/5
> > > - EmulatorPkg: https://edk2.groups.io/g/devel/message/3
> > > - Intel Platforms (Platform/Intel/QuarkPlatformPkg,
> > > Platform/Intel/MinPlatformPkg, Platform/Intel/Vlv2TbltDevicePkg):
> > > https://edk2.groups.io/g/devel/message/77781
> > >
> > > Thanks,
> > > --Samer
> > >
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of
> > > > Grzegorz Bernacki via groups.io
> > > > Sent: Wednesday, July 14, 2021 8:30 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer
> > > El-Haj-Mahmoud
> > > > ; Sunny Wang
> > > > ; m...@semihalf.com; upstr...@semihalf.com;
> > > > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > > > ler...@redhat.com; Sami Mujawar ;
> > > > af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> > > > rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> > > > ; chasel.c...@intel.com;
> > > > nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> > > > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > > > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com;
> > > > p...@akeo.ie; Grzegorz Bernacki 
> > > > Subject: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> > > >
> > > > This patchset adds support for initialization of default
> > > > Secure Boot variables based on keys content embedded in
> > > > flash binary. This feature is active only if Secure Boot
> > > > is enabled and DEFAULT_KEY is defined. The patchset
> > > > consist also application to enroll keys from default
> > > > variables and secure boot menu change to allow user
> > > > to reset key content to default values.
> > > > Discussion on design can be found at:
> > > > 

Re: [edk2-devel] [edk2-platforms PATCH v2 0/2] Fix some issues on SynQuacer

[Masami Hiramatsu]

2021年7月28日(水) 19:44 Ard Biesheuvel :
>
> On Mon, 26 Jul 2021 at 10:28, Masami Hiramatsu
>  wrote:
> >
> > Hello,
> >
> > Here is the 2nd version of the patches to fix 2 issues on SynQuacer 
> > platform support.
> > I and Sakamoto-san found these issues in edk2-test testcases on SynQuacer
> > DeveloperBox platfrom.
> >
> > Previous version are here;
> >
> > https://edk2.groups.io/g/devel/message/77085
> > https://edk2.groups.io/g/devel/message/77086
> >
> > In this version, I grouped these 2 patches and update patch changelog.
> >
> > [1/2] Fixes OpteeRng driver to check invalid parameter correctly.
> >   Without this fix, edk2-test BBTestGetRNGConformanceTestCheckpoint1
> >   reports an error.
> >
> > [2/2] Fixes Pcf8563RealTimeClockLib to clear unused Nanosecond field.
> >   Without this fix, edk2-test BBTestGetTimeInterfaceTest and
> >   BBTestSetTimeInterfaceTest failed. Moreover, 'date' and 'time'
> >   commands on UEFI shell can not set the time.
> >
> > Thank you,
> >
> > ---
> >
> > Masami Hiramatsu (2):
> >   Silicon/SynQuacer/OpteeRngDxe: Fix invalid parameter check
> >   Silicon/NXP/Pcf8563RealTimeClockLib: Clear Nanosecond field in GetTime
> >
>
> Thank you Masami.
>
> Pushed as 194269223294..c131fed73d37

Thank you Ard!

-- 
Masami Hiramatsu


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78280): https://edk2.groups.io/g/devel/message/78280
Mute This Topic: https://groups.io/mt/84454408/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH v2 0/2] Fix some issues on SynQuacer

[Ard Biesheuvel]

On Mon, 26 Jul 2021 at 10:28, Masami Hiramatsu
 wrote:
>
> Hello,
>
> Here is the 2nd version of the patches to fix 2 issues on SynQuacer platform 
> support.
> I and Sakamoto-san found these issues in edk2-test testcases on SynQuacer
> DeveloperBox platfrom.
>
> Previous version are here;
>
> https://edk2.groups.io/g/devel/message/77085
> https://edk2.groups.io/g/devel/message/77086
>
> In this version, I grouped these 2 patches and update patch changelog.
>
> [1/2] Fixes OpteeRng driver to check invalid parameter correctly.
>   Without this fix, edk2-test BBTestGetRNGConformanceTestCheckpoint1
>   reports an error.
>
> [2/2] Fixes Pcf8563RealTimeClockLib to clear unused Nanosecond field.
>   Without this fix, edk2-test BBTestGetTimeInterfaceTest and
>   BBTestSetTimeInterfaceTest failed. Moreover, 'date' and 'time'
>   commands on UEFI shell can not set the time.
>
> Thank you,
>
> ---
>
> Masami Hiramatsu (2):
>   Silicon/SynQuacer/OpteeRngDxe: Fix invalid parameter check
>   Silicon/NXP/Pcf8563RealTimeClockLib: Clear Nanosecond field in GetTime
>

Thank you Masami.

Pushed as 194269223294..c131fed73d37



>
>  .../Pcf8563RealTimeClockLib.c  |2 ++
>  .../SynQuacer/Drivers/OpteeRngDxe/OpteeRng.c   |5 ++---
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> --
> Masami Hiramatsu 
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78279): https://edk2.groups.io/g/devel/message/78279
Mute This Topic: https://groups.io/mt/84454408/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys

[Ard Biesheuvel]

On Wed, 28 Jul 2021 at 09:44, gaoliming  wrote:
>
> Sunny:
>   Yes. This patch set is ready to be merged.
>
> Samer:
>   Would you help merge this patch set?
>

I can pick it up if you could please create the release notes entry? Thanks.

> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Sunny Wang
> > 发送时间: 2021年7月21日 11:41
> > 收件人: Samer El-Haj-Mahmoud ;
> > devel@edk2.groups.io; g...@semihalf.com; Ard Biesheuvel
> > ; gaolim...@byosoft.com.cn; ray...@intel.com
> > 抄送: l...@nuviainc.com; m...@semihalf.com; upstr...@semihalf.com;
> > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > ler...@redhat.com; Sami Mujawar ;
> > af...@apple.com; jordan.l.jus...@intel.com; rebe...@bsdio.com;
> > gre...@freebsd.org; Thomas Abraham ;
> > chasel.c...@intel.com; nathaniel.l.desim...@intel.com;
> > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> > Sunny Wang 
> > 主题: Re: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> >
> > Ard, Liming, Ray, Thanks for your review for ArmVirtPkg, ArmPlatformPkg,
> and
> > EmulatorPkg patches.
> >
> > As for the patch for Intel Platforms below, it is in another series for
> > edk2-platforms.
> >  - [edk2-platforms PATCH v6 1/4] Intel Platforms: add
> > SecureBootVariableLib class resolution
> > https://edk2.groups.io/g/devel/message/77781
> >
> > Therefore, I think this series already got all the necessary Reviewed-By
> and
> > Acked-By of all parts and is ready to be pushed now.
> >
> > Best Regards,
> > Sunny Wang
> >
> > -Original Message-
> > From: Samer El-Haj-Mahmoud 
> > Sent: Friday, July 16, 2021 8:00 PM
> > To: devel@edk2.groups.io; g...@semihalf.com
> > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Sunny Wang
> > ; m...@semihalf.com; upstr...@semihalf.com;
> > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > ler...@redhat.com; Sami Mujawar ;
> > af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> > rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> > ; chasel.c...@intel.com;
> > nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> > Samer El-Haj-Mahmoud 
> > Subject: RE: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> >
> > The v6 of this series seems to have all the necessary Reviewed-By (and
> some
> > Tested-By) of all parts, except the following platform specific parts.
> Could we
> > get help from maintainers to review these please?
> >
> > Much appreciated!
> >
> > - ArmVirtPkg : https://edk2.groups.io/g/devel/message/2
> > - ArmPlatformPkg: https://edk2.groups.io/g/devel/message/5
> > - EmulatorPkg: https://edk2.groups.io/g/devel/message/3
> > - Intel Platforms (Platform/Intel/QuarkPlatformPkg,
> > Platform/Intel/MinPlatformPkg, Platform/Intel/Vlv2TbltDevicePkg):
> > https://edk2.groups.io/g/devel/message/77781
> >
> > Thanks,
> > --Samer
> >
> >
> >
> >
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of
> > > Grzegorz Bernacki via groups.io
> > > Sent: Wednesday, July 14, 2021 8:30 AM
> > > To: devel@edk2.groups.io
> > > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer
> > El-Haj-Mahmoud
> > > ; Sunny Wang
> > > ; m...@semihalf.com; upstr...@semihalf.com;
> > > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > > ler...@redhat.com; Sami Mujawar ;
> > > af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> > > rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> > > ; chasel.c...@intel.com;
> > > nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> > > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com;
> > > p...@akeo.ie; Grzegorz Bernacki 
> > > Subject: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> > >
> > > This patchset adds support for initialization of default
> > > Secure Boot variables based on keys content embedded in
> > > flash binary. This feature is active only if Secure Boot
> > > is enabled and DEFAULT_KEY is defined. The patchset
> > > consist also application to enroll keys from default
> > > variables and secure boot menu change to allow user
> > > to reset key content to default values.
> > > Discussion on design can be found at:
> > > https://edk2.groups.io/g/rfc/topic/82139806#600
> > >
> > > Built with:
> > > GCC
> > > - RISC-V (U500, U540) [requires fixes in dsc to build]
> > > - Intel (Vlv2TbltDevicePkg (X64/IA32), Quark, MinPlatformPkg,
> > >   EmulatorPkg (X64), Bhyve, OvmfPkg (X64/IA32))
> > > - ARM (Sgi75,SbsaQemu,DeveloperBox, RPi3/RPi4)
> > >
> > > RISC-V, Quark, Vlv2TbltDevicePkg, Bhyve requires additional fixes to be
> > built,
> > > will be post on edk2 maillist later
> > >
> > > 

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

[Min Xu]

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_SEV_ES_WORK_AREA;

In ResetVector SEV flag is recorded in the first byte of SEV_ES_WORK_AREA. In 
SecMain.c this flag is read to determine SEV.

I am thinking whether this memory region can be used by both TDX and SEV. (This 
is option 5)

SEV_ES_WORK_AREA will be added in tdx metadata so that it is initialized by 
host VMM and can be accessed in Tdx guest.
In SEV guest I believe SEV_ES_WORK_AREA can be accessed without any error.
The first 8 bytes of SEV_ES_WORK_AREA can be redefined as [CC Indicator Flags].

> -Original Message-
> From: Yao, Jiewen 
> Sent: Wednesday, July 28, 2021 3:55 PM
> To: Xu, Min M 
> Cc: Brijesh Singh ; devel@edk2.groups.io; Ard
> Biesheuvel ; Justen, Jordan L
> ; Erdem Aktas ;
> James Bottomley ; Tom Lendacky
> 
> Subject: RE: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector
> 
> 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 region piggyback on existing CC working area, such as
> dword[CC_WORKING_AREA]
> 
> Hi Brijesh/Min
> Any preference?
> 
> [CC Indicator Flags]
> Proposal: UINT8[4]
> 
> Byte [0] Version: 0
> byte [1] Length: 4
> byte [2] Type:
>   0: legacy
>   1: SEV
>   2: TDX
> byte [3] Sub Type:
>   If Type is 0 (legacy), then
>   0: legacy
>   If Type is 1 (SEV), then
>   0: SEV
>   1: SEV-ES
>   2: SEV-SNP
>   If Type is 2 (TDX), then
>   0: TDX 1.0
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Xu, Min M 
> > Sent: Wednesday, July 28, 2021 2:58 PM
> > To: Yao, Jiewen 
> > Cc: Brijesh Singh ; devel@edk2.groups.io; Ard
> > Biesheuvel ; Justen, Jordan L
> > ; Erdem Aktas ;
> > James Bottomley ; Tom Lendacky
> > 
> > Subject: RE: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector
> >
> > 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 Tdx the memory region should be initialized by host
> VMM.
> > >
> > > 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 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?
> > > > I have replied to Brijesh's mail about the concern of the new pattern.
> > > >
> > > > I have some concern in the current pattern:
> > > > 
> > > >OneTimeCall   PreMainFunctionHookSev
> > > >OneTimeCall   PreMainFunctionHookTdx
> > > > MainFunction:
> > > >XX
> > > >OneTimeCall   PostMainFunctionHookSev
> > > >OneTimeCall   PostMainFunctionHookTdx
> > > > 
> > > > The TEE function need implement a TEE check function (such as
> > > > IsSev, or
> > IsTdx).
> > > >
> > > > Tdx call CPUID(0x21) to determine if it is tdx guest in the very
> > > > beginning of ResetVector. Then 'TDXG' is set in TDX_WORK_AREA. SEV
> > > > does
> > > the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA
> to 1.
> > > >
> > > > After that both TDX and SEV read the above WORK_AREA to check if
> > > > it is TDX
> > > or SEV or legacy guest.
> > > >
> > > > In Tdx the access to SEV_ES_WORK_AREA will trigger error because
> > > SEV_ES_WORK_AREA is *NOT* initialized by host VMM.
> > > > In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error
> too.
> > > >
> > > > I am wondering if TDX and SEV can use the same memory region (for
> > example,
> > > TEE_WORK_AREA) as the work area?
> > > > So that this work area is guaranteed to be initialized in both TDX
> > > > and SEV. Structure of the TEE_WORK_AREA may look like this:
> > > >  typedef struct {
> > > >  UINT8  Flag[4]; 'TDXG' or 'SEVG' or all-0
> > > >  UINT8  Others[];
> > > >  } TEE_WORK_AREA;
> > > >>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78277): https://edk2.groups.io/g/devel/message/78277
Mute This Topic: 

Re: [edk2-devel] [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP) support

[Yao, Jiewen]

Hi Brijesh
I reviewed the patch set. I have some basic questions.
Please help me understand before I post my comment

If a platform supports SEV-SNP, can we assume SEV-ES is supported?
Or is it a valid case that SecSnp==YES, SevEs==NO?

I am trying to understand how many cases we need support.
I think we want to support below:
++
| SEV | SEV_ES | SEV_SNP |
++
|  0  |   0|0|
|  1  |   0|0|
|  1  |   1|0|
|  1  |   1|1|
++


Any other combination we need support? Such as below:
++
| SEV | SEV_ES | SEV_SNP |
++
|  0  |   1|0|
|  0  |   0|1|
|  0  |   1|1|
|  1  |   0|1|
++


Thank you
Yao Jiewen

> -Original Message-
> From: Brijesh Singh 
> Sent: Tuesday, June 29, 2021 1:42 AM
> To: devel@edk2.groups.io
> Cc: James Bottomley ; Xu, Min M ;
> Yao, Jiewen ; Tom Lendacky
> ; Justen, Jordan L ;
> Ard Biesheuvel ; Laszlo Ersek
> ; Erdem Aktas ; Dong, Eric
> ; Ni, Ray ; Kumar, Rahul1
> ; Kinney, Michael D ;
> Liming Gao ; Liu, Zhiguang
> ; Michael Roth ; Brijesh
> Singh 
> Subject: [RFC PATCH v4 00/27] Add AMD Secure Nested Paging (SEV-SNP)
> support
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
> 
> SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
> new hardware-based memory protections. SEV-SNP adds strong memory
> integrity
> protection to help prevent malicious hypervisor-based attacks like data
> replay, memory re-mapping and more in order to create an isolated memory
> encryption environment.
> 
> This series provides the basic building blocks to support booting the SEV-SNP
> VMs, it does not cover all the security enhancement introduced by the SEV-SNP
> such as interrupt protection.
> 
> Many of the integrity guarantees of SEV-SNP are enforced through a new
> structure called the Reverse Map Table (RMP). Adding a new page to SEV-SNP
> VM requires a 2-step process. First, the hypervisor assigns a page to the
> guest using the new RMPUPDATE instruction. This transitions the page to
> guest-invalid. Second, the guest validates the page using the new PVALIDATE
> instruction. The SEV-SNP VMs can use the new "Page State Change Request
> NAE"
> defined in the GHCB specification to ask hypervisor to add or remove page
> from the RMP table.
> 
> Each page assigned to the SEV-SNP VM can either be validated or unvalidated,
> as indicated by the Validated flag in the page's RMP entry. There are two
> approaches that can be taken for the page validation: Pre-validation and
> Lazy Validation.
> 
> Under pre-validation, the pages are validated prior to first use. And under
> lazy validation, pages are validated when first accessed. An access to a
> unvalidated page results in a #VC exception, at which time the exception
> handler may validate the page. Lazy validation requires careful tracking of
> the validated pages to avoid validating the same GPA more than once. The
> recently introduced "Unaccepted" memory type can be used to communicate
> the
> unvalidated memory ranges to the Guest OS.
> 
> At this time we only support the pre-validation. OVMF detects all the 
> available
> system RAM in the PEI phase. When SEV-SNP is enabled, the memory is validated
> before it is made available to the EDK2 core.
> 
> This series does not implements the following SEV-SNP features yet:
> 
> * CPUID filtering
> * Lazy validation
> * Interrupt security
> 
> Additional resources
> -
> SEV-SNP whitepaper
> https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-
> isolation-with-integrity-protection-and-more.pdf
> 
> APM 2: https://www.amd.com/system/files/TechDocs/24593.pdf (section 15.36)
> 
> The complete source is available at
> https://github.com/AMDESE/ovmf/tree/sev-snp-rfc-4
> 
> GHCB spec:
> https://developer.amd.com/wp-content/resources/56421.pdf
> 
> SEV-SNP firmware specification:
> https://www.amd.com/system/files/TechDocs/56860.pdf
> 
> Brijesh Singh (26):
>   OvmfPkg/ResetVector: move SEV specific code in a separate file
>   OvmfPkg/ResetVector: add the macro to invoke MSR protocol based
> VMGEXIT
>   OvmfPkg/ResetVector: add the macro to request guest termination
>   OvmfPkg: reserve SNP secrets page
>   OvmfPkg: reserve CPUID page for SEV-SNP
>   OvmfPkg/ResetVector: introduce SEV-SNP boot block GUID
>   OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase
>   OvmfPkg/ResetVector: invalidate the GHCB page
>   UefiCpuPkg: Define the SEV-SNP specific dynamic PCDs
>   OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled()
>   OvmfPkg/SecMain: register GHCB gpa for the SEV-SNP guest
>   OvmfPkg/PlatformPei: register GHCB gpa for the SEV-SNP guest
>   OvmfPkg/AmdSevDxe: do not use extended PCI config space
>   OvmfPkg/MemEncryptSevLib: add support to validate system RAM
>   

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

[Yao, Jiewen]

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 region piggyback on existing CC working area, such as
dword[CC_WORKING_AREA]

Hi Brijesh/Min
Any preference?

[CC Indicator Flags]
Proposal: UINT8[4]

Byte [0] Version: 0
byte [1] Length: 4
byte [2] Type:
0: legacy
1: SEV
2: TDX
byte [3] Sub Type: 
If Type is 0 (legacy), then
0: legacy
If Type is 1 (SEV), then
0: SEV
1: SEV-ES
2: SEV-SNP
If Type is 2 (TDX), then
0: TDX 1.0

Thank you
Yao Jiewen


> -Original Message-
> From: Xu, Min M 
> Sent: Wednesday, July 28, 2021 2:58 PM
> To: Yao, Jiewen 
> Cc: Brijesh Singh ; devel@edk2.groups.io; Ard
> Biesheuvel ; Justen, Jordan L
> ; Erdem Aktas ; James
> Bottomley ; Tom Lendacky 
> Subject: RE: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector
> 
> 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 Tdx the memory region should be initialized by host 
> VMM.
> >
> > 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 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?
> > > I have replied to Brijesh's mail about the concern of the new pattern.
> > >
> > > I have some concern in the current pattern:
> > > 
> > >OneTimeCall   PreMainFunctionHookSev
> > >OneTimeCall   PreMainFunctionHookTdx
> > > MainFunction:
> > >XX
> > >OneTimeCall   PostMainFunctionHookSev
> > >OneTimeCall   PostMainFunctionHookTdx
> > > 
> > > The TEE function need implement a TEE check function (such as IsSev, or
> IsTdx).
> > >
> > > Tdx call CPUID(0x21) to determine if it is tdx guest in the very
> > > beginning of ResetVector. Then 'TDXG' is set in TDX_WORK_AREA. SEV does
> > the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to 1.
> > >
> > > After that both TDX and SEV read the above WORK_AREA to check if it is TDX
> > or SEV or legacy guest.
> > >
> > > In Tdx the access to SEV_ES_WORK_AREA will trigger error because
> > SEV_ES_WORK_AREA is *NOT* initialized by host VMM.
> > > In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error too.
> > >
> > > I am wondering if TDX and SEV can use the same memory region (for
> example,
> > TEE_WORK_AREA) as the work area?
> > > So that this work area is guaranteed to be initialized in both TDX and
> > > SEV. Structure of the TEE_WORK_AREA may look like this:
> > >  typedef struct {
> > >  UINT8  Flag[4]; 'TDXG' or 'SEVG' or all-0
> > >  UINT8  Others[];
> > >  } TEE_WORK_AREA;
> > >>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78275): https://edk2.groups.io/g/devel/message/78275
Mute This Topic: https://groups.io/mt/84476064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

回复: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys

[gaoliming]

Sunny:
  Yes. This patch set is ready to be merged. 

Samer:
  Would you help merge this patch set?

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Sunny Wang
> 发送时间: 2021年7月21日 11:41
> 收件人: Samer El-Haj-Mahmoud ;
> devel@edk2.groups.io; g...@semihalf.com; Ard Biesheuvel
> ; gaolim...@byosoft.com.cn; ray...@intel.com
> 抄送: l...@nuviainc.com; m...@semihalf.com; upstr...@semihalf.com;
> jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> ler...@redhat.com; Sami Mujawar ;
> af...@apple.com; jordan.l.jus...@intel.com; rebe...@bsdio.com;
> gre...@freebsd.org; Thomas Abraham ;
> chasel.c...@intel.com; nathaniel.l.desim...@intel.com;
> eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> Sunny Wang 
> 主题: Re: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> 
> Ard, Liming, Ray, Thanks for your review for ArmVirtPkg, ArmPlatformPkg,
and
> EmulatorPkg patches.
> 
> As for the patch for Intel Platforms below, it is in another series for
> edk2-platforms.
>  - [edk2-platforms PATCH v6 1/4] Intel Platforms: add
> SecureBootVariableLib class resolution
> https://edk2.groups.io/g/devel/message/77781
> 
> Therefore, I think this series already got all the necessary Reviewed-By
and
> Acked-By of all parts and is ready to be pushed now.
> 
> Best Regards,
> Sunny Wang
> 
> -Original Message-
> From: Samer El-Haj-Mahmoud 
> Sent: Friday, July 16, 2021 8:00 PM
> To: devel@edk2.groups.io; g...@semihalf.com
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> ler...@redhat.com; Sami Mujawar ;
> af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> ; chasel.c...@intel.com;
> nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> Samer El-Haj-Mahmoud 
> Subject: RE: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> 
> The v6 of this series seems to have all the necessary Reviewed-By (and
some
> Tested-By) of all parts, except the following platform specific parts.
Could we
> get help from maintainers to review these please?
> 
> Much appreciated!
> 
> - ArmVirtPkg : https://edk2.groups.io/g/devel/message/2
> - ArmPlatformPkg: https://edk2.groups.io/g/devel/message/5
> - EmulatorPkg: https://edk2.groups.io/g/devel/message/3
> - Intel Platforms (Platform/Intel/QuarkPlatformPkg,
> Platform/Intel/MinPlatformPkg, Platform/Intel/Vlv2TbltDevicePkg):
> https://edk2.groups.io/g/devel/message/77781
> 
> Thanks,
> --Samer
> 
> 
> 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of
> > Grzegorz Bernacki via groups.io
> > Sent: Wednesday, July 14, 2021 8:30 AM
> > To: devel@edk2.groups.io
> > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer
> El-Haj-Mahmoud
> > ; Sunny Wang
> > ; m...@semihalf.com; upstr...@semihalf.com;
> > jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> > ler...@redhat.com; Sami Mujawar ;
> > af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> > rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> > ; chasel.c...@intel.com;
> > nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> > eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> > yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com;
> > p...@akeo.ie; Grzegorz Bernacki 
> > Subject: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
> >
> > This patchset adds support for initialization of default
> > Secure Boot variables based on keys content embedded in
> > flash binary. This feature is active only if Secure Boot
> > is enabled and DEFAULT_KEY is defined. The patchset
> > consist also application to enroll keys from default
> > variables and secure boot menu change to allow user
> > to reset key content to default values.
> > Discussion on design can be found at:
> > https://edk2.groups.io/g/rfc/topic/82139806#600
> >
> > Built with:
> > GCC
> > - RISC-V (U500, U540) [requires fixes in dsc to build]
> > - Intel (Vlv2TbltDevicePkg (X64/IA32), Quark, MinPlatformPkg,
> >   EmulatorPkg (X64), Bhyve, OvmfPkg (X64/IA32))
> > - ARM (Sgi75,SbsaQemu,DeveloperBox, RPi3/RPi4)
> >
> > RISC-V, Quark, Vlv2TbltDevicePkg, Bhyve requires additional fixes to be
> built,
> > will be post on edk2 maillist later
> >
> > VS2019
> > - Intel (OvmfPkgX64)
> >
> > Test with:
> > GCC5/RPi4
> > VS2019/OvmfX64 (requires changes to enable feature)
> >
> > Tests:
> > 1. Try to enroll key in incorrect format.
> > 2. Enroll with only PKDefault keys specified.
> > 3. Enroll with all keys specified.
> > 4. Enroll when keys are enrolled.
> > 5. Reset keys values.
> > 6. Running signed & 

回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm machines

[gaoliming]

Etienne: 

I check the build log. Two build failure here. Can you update the patch to fix 
them?

1. Two modules are only for AARCH64. They should be specified in 
[Components.AARCH64] in ArmPkg\ArmPkg.dsc
  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
  ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf

2. StandaloneMmCoreEntryPoint library class header file is changed. It should 
also be updated in StandaloneMmPkg\StandaloneMmPkg.dec

ERROR - Library StandaloneMmCoreEntryPoint with path 
Include/Library/AArch64/StandaloneMmCoreEntryPoint.h not found in package 
filesystem
ERROR - Library Header File Include/Library/Arm/StandaloneMmCoreEntryPoint.h 
not declared in package DEC StandaloneMmPkg/StandaloneMmPkg.dec

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Ard
> Biesheuvel
> 发送时间: 2021年7月28日 14:52
> 收件人: Sami Mujawar 
> 抄送: gaoliming ; devel@edk2.groups.io;
> Etienne Carriere ; Achin Gupta
> ; Ard Biesheuvel ;
> Jiewen Yao ; Leif Lindholm ;
> Sughosh Ganu ; nd 
> 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm
> machines
> 
> On Wed, 28 Jul 2021 at 08:41, Sami Mujawar 
> wrote:
> >
> > Hi Liming,
> >
> > I will look into this shortly.
> >
> 
> I submitted it here
> 
> https://github.com/tianocore/edk2/pull/1823
> 
> but it triggered a CI failure that was not immediately obvious to me,
> and I haven't had time yet to dig into it.
> 
> 
> >
> > 
> > From: gaoliming 
> > Sent: Wednesday, 28 July 2021, 7:33 am
> > To: devel@edk2.groups.io; gaolim...@byosoft.com.cn; a...@kernel.org
> > Cc: Sami Mujawar; 'Etienne Carriere'; Achin Gupta; 'Ard Biesheuvel';
> 'Jiewen Yao'; 'Leif Lindholm'; 'Sughosh Ganu'; nd
> > Subject: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> 32bit arm machines
> >
> > Ard and Sami:
> >   Will you help merge this patch set for 202108 stable tag?
> >
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 gaoliming
> > > 发送时间: 2021年7月20日 17:21
> > > 收件人: devel@edk2.groups.io; a...@kernel.org
> > > 抄送: 'Sami Mujawar' ; 'Etienne Carriere'
> > > ; 'Achin Gupta' ;
> 'Ard
> > > Biesheuvel' ; 'Jiewen Yao'
> > > ; 'Leif Lindholm' ; 'Sughosh
> > > Ganu' ; 'nd' 
> > > 主题: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> 32bit
> > > arm machines
> > >
> > > Ard:
> > >   Thanks! I have added this feature into
> > >
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planni
> > > ng.
> > >
> > > Thanks
> > > Liming
> > > > -邮件原件-
> > > > 发件人: devel@edk2.groups.io  代表 Ard
> > > > Biesheuvel
> > > > 发送时间: 2021年7月20日 15:46
> > > > 收件人: edk2-devel-groups-io ; Liming Gao
> > > (Byosoft
> > > > address) 
> > > > 抄送: Sami Mujawar ; Etienne Carriere
> > > > ; Achin Gupta ;
> Ard
> > > > Biesheuvel ; Jiewen Yao
> > > > ; Leif Lindholm ; Sughosh
> > > Ganu
> > > > ; nd 
> > > > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> 32bit
> > > arm
> > > > machines
> > > >
> > > > On Tue, 20 Jul 2021 at 04:01, gaoliming 
> > > wrote:
> > > > >
> > > > > Hi, all
> > > > >   This patch set has passed code review. How about merge it for this
> > > > stable tag edk2 202108?
> > > > >
> > > >
> > > > OK, I will pick these up. Would you mind creating the entry for the
> > > > release notes?
> > > >
> > > >
> > > > > Thanks
> > > > > Liming
> > > > > > -邮件原件-
> > > > > > 发件人: devel@edk2.groups.io  代表
> Sami
> > > > > > Mujawar
> > > > > > 发送时间: 2021年5月19日 17:58
> > > > > > 收件人: Etienne Carriere ;
> > > > > > devel@edk2.groups.io
> > > > > > 抄送: Achin Gupta ; Ard Biesheuvel
> > > > > > ; Jiewen Yao ;
> > > Leif
> > > > > > Lindholm ; Sughosh Ganu
> > > > ;
> > > > > > n...@arm.com
> > > > > > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> > > 32bit
> > > > arm
> > > > > > machines
> > > > > >
> > > > > > Hi Etienn,
> > > > > >
> > > > > > This patch looks good to me.
> > > > > >
> > > > > > Reviewed-by: Sami Mujawar 
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Sami Mujawar
> > > > > >
> > > > > > On 19/05/2021 08:14 AM, Etienne Carriere wrote:
> > > > > > > This change allows to build StandaloneMmPkg components for
> 32bit
> > > > Arm
> > > > > > > StandaloneMm firmware.
> > > > > > >
> > > > > > > This change mainly moves AArch64/ source files to Arm/ side
> directory
> > > > > > > for several components:  StandaloneMmCpu,
> > > > > > StandaloneMmCoreEntryPoint
> > > > > > > and StandaloneMmMemLib. The source file is built for both 32b
> and
> > > 64b
> > > > > > > Arm targets.
> > > > > > >
> > > > > > > Signed-off-by: Etienne Carriere 
> > > > > > > ---
> > > > > > > Changes since v3:
> > > > > > > - Fix BuildOptions.ARM in StandaloneMmPkg.
> > > > > > > - Remove Cc tags.
> > > > > > >
> > > > > > > No change since v2
> > > > > > >
> > > > > > > Changes since v1:
> > > > > > > - ARM_SMC_ID_MM_COMMUNICATE 32b/64b agnostic helper ID
> is
> > > > > > defined
> > > > > > >in ArmStdSmc.h (see 1st commit in this series) 

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

[Min Xu]

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 Tdx the memory region should be initialized by host 
VMM.
> 
> 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 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?
> > I have replied to Brijesh's mail about the concern of the new pattern.
> >
> > I have some concern in the current pattern:
> > 
> >OneTimeCall   PreMainFunctionHookSev
> >OneTimeCall   PreMainFunctionHookTdx
> > MainFunction:
> >XX
> >OneTimeCall   PostMainFunctionHookSev
> >OneTimeCall   PostMainFunctionHookTdx
> > 
> > The TEE function need implement a TEE check function (such as IsSev, or 
> > IsTdx).
> >
> > Tdx call CPUID(0x21) to determine if it is tdx guest in the very
> > beginning of ResetVector. Then 'TDXG' is set in TDX_WORK_AREA. SEV does
> the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to 1.
> >
> > After that both TDX and SEV read the above WORK_AREA to check if it is TDX
> or SEV or legacy guest.
> >
> > In Tdx the access to SEV_ES_WORK_AREA will trigger error because
> SEV_ES_WORK_AREA is *NOT* initialized by host VMM.
> > In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error too.
> >
> > I am wondering if TDX and SEV can use the same memory region (for example,
> TEE_WORK_AREA) as the work area?
> > So that this work area is guaranteed to be initialized in both TDX and
> > SEV. Structure of the TEE_WORK_AREA may look like this:
> >  typedef struct {
> >  UINT8  Flag[4]; 'TDXG' or 'SEVG' or all-0
> >  UINT8  Others[];
> >  } TEE_WORK_AREA;
> >>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78272): https://edk2.groups.io/g/devel/message/78272
Mute This Topic: https://groups.io/mt/84476064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm machines

[Ard Biesheuvel]

On Wed, 28 Jul 2021 at 08:41, Sami Mujawar  wrote:
>
> Hi Liming,
>
> I will look into this shortly.
>

I submitted it here

https://github.com/tianocore/edk2/pull/1823

but it triggered a CI failure that was not immediately obvious to me,
and I haven't had time yet to dig into it.


>
> 
> From: gaoliming 
> Sent: Wednesday, 28 July 2021, 7:33 am
> To: devel@edk2.groups.io; gaolim...@byosoft.com.cn; a...@kernel.org
> Cc: Sami Mujawar; 'Etienne Carriere'; Achin Gupta; 'Ard Biesheuvel'; 'Jiewen 
> Yao'; 'Leif Lindholm'; 'Sughosh Ganu'; nd
> Subject: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm 
> machines
>
> Ard and Sami:
>   Will you help merge this patch set for 202108 stable tag?
>
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 gaoliming
> > 发送时间: 2021年7月20日 17:21
> > 收件人: devel@edk2.groups.io; a...@kernel.org
> > 抄送: 'Sami Mujawar' ; 'Etienne Carriere'
> > ; 'Achin Gupta' ; 'Ard
> > Biesheuvel' ; 'Jiewen Yao'
> > ; 'Leif Lindholm' ; 'Sughosh
> > Ganu' ; 'nd' 
> > 主题: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit
> > arm machines
> >
> > Ard:
> >   Thanks! I have added this feature into
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planni
> > ng.
> >
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Ard
> > > Biesheuvel
> > > 发送时间: 2021年7月20日 15:46
> > > 收件人: edk2-devel-groups-io ; Liming Gao
> > (Byosoft
> > > address) 
> > > 抄送: Sami Mujawar ; Etienne Carriere
> > > ; Achin Gupta ; Ard
> > > Biesheuvel ; Jiewen Yao
> > > ; Leif Lindholm ; Sughosh
> > Ganu
> > > ; nd 
> > > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit
> > arm
> > > machines
> > >
> > > On Tue, 20 Jul 2021 at 04:01, gaoliming 
> > wrote:
> > > >
> > > > Hi, all
> > > >   This patch set has passed code review. How about merge it for this
> > > stable tag edk2 202108?
> > > >
> > >
> > > OK, I will pick these up. Would you mind creating the entry for the
> > > release notes?
> > >
> > >
> > > > Thanks
> > > > Liming
> > > > > -邮件原件-
> > > > > 发件人: devel@edk2.groups.io  代表 Sami
> > > > > Mujawar
> > > > > 发送时间: 2021年5月19日 17:58
> > > > > 收件人: Etienne Carriere ;
> > > > > devel@edk2.groups.io
> > > > > 抄送: Achin Gupta ; Ard Biesheuvel
> > > > > ; Jiewen Yao ;
> > Leif
> > > > > Lindholm ; Sughosh Ganu
> > > ;
> > > > > n...@arm.com
> > > > > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> > 32bit
> > > arm
> > > > > machines
> > > > >
> > > > > Hi Etienn,
> > > > >
> > > > > This patch looks good to me.
> > > > >
> > > > > Reviewed-by: Sami Mujawar 
> > > > >
> > > > > Regards,
> > > > >
> > > > > Sami Mujawar
> > > > >
> > > > > On 19/05/2021 08:14 AM, Etienne Carriere wrote:
> > > > > > This change allows to build StandaloneMmPkg components for 32bit
> > > Arm
> > > > > > StandaloneMm firmware.
> > > > > >
> > > > > > This change mainly moves AArch64/ source files to Arm/ side 
> > > > > > directory
> > > > > > for several components:  StandaloneMmCpu,
> > > > > StandaloneMmCoreEntryPoint
> > > > > > and StandaloneMmMemLib. The source file is built for both 32b and
> > 64b
> > > > > > Arm targets.
> > > > > >
> > > > > > Signed-off-by: Etienne Carriere 
> > > > > > ---
> > > > > > Changes since v3:
> > > > > > - Fix BuildOptions.ARM in StandaloneMmPkg.
> > > > > > - Remove Cc tags.
> > > > > >
> > > > > > No change since v2
> > > > > >
> > > > > > Changes since v1:
> > > > > > - ARM_SMC_ID_MM_COMMUNICATE 32b/64b agnostic helper ID is
> > > > > defined
> > > > > >in ArmStdSmc.h (see 1st commit in this series) instead of being
> > > > > >local to EventHandle.c.
> > > > > > - Fix void occurrence to VOID.
> > > > > > - Fix path in StandaloneMmPkg/StandaloneMmPkg.dsc
> > > > > > ---
> > > > > >   StandaloneMmPkg/Core/StandaloneMmCore.inf
> > > > > |  2 +-
> > > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > > => }/EventHandle.c
> > > > > |  5 +++--
> > > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > > => }/StandaloneMmCpu.c
> > > > > |  2 +-
> > > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > > => }/StandaloneMmCpu.h
> > > > > |  0
> > > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > > => }/StandaloneMmCpu.inf
> > > > > |  0
> > > > > >   StandaloneMmPkg/Include/Library/{AArch64 =>
> > > > > Arm}/StandaloneMmCoreEntryPoint.h
> > > > > |  0
> > > > > >
> > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > > =>
> > > > > Arm}/CreateHobList.c  |  2 +-
> > > > > >
> > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > > =>
> > > > > Arm}/SetPermissions.c |  2 +-
> > > > > >
> > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > > =>
> > > > > Arm}/StandaloneMmCoreEntryPoint.c | 16
> > > > > 
> > > > > >
> > > > >
> > >
> > 

Re: [edk2-devel] [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0

[Digant H Solanki]

Please help review this patch to make it official soon. Thanks..!!

-Original Message-
From: Solanki, Digant H 
Sent: Friday, July 23, 2021 7:25 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Chaganty, Rangasai V 
; S, Ashraf Ali 
Subject: RE: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

Gentle reminder to review this patch pls. Thanks..!!

-Original Message-
From: Solanki, Digant H 
Sent: Thursday, July 22, 2021 5:17 PM
To: devel@edk2.groups.io
Cc: Solanki, Digant H ; Ni, Ray ; 
Chaganty, Rangasai V ; S, Ashraf Ali 

Subject: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD 
OpRegion v3.0

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3426

- There are many OpRegion fields obsoleted in MBOX1
- MBOX2 is re-purposed for Backlight related fields for dual LFP.
- Backlight related fields moved to MBOX2 from MBOX3 and some fields are 
obsoleted in MBOX3.

Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Ashraf Ali S 
---
 Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 
+
 1 file changed, 101 insertions(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
new file mode 100644
index 00..c9948ab55f
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion
+++ 30.h
@@ -0,0 +1,101 @@
+/** @file
+  IGD OpRegion definition from Intel Integrated Graphics Device 
+OpRegion
+  Specification based on version 3.0.
+
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef _IGD_OPREGION_3_0_H_
+#define _IGD_OPREGION_3_0_H_
+
+#include "IgdOpRegion.h"
+
+#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5
+
+#pragma pack(1)
+///
+/// OpRegion Mailbox 1 - Public ACPI Methods /// Offset 0x100, Size
+0x100 /// typedef struct {
+  UINT32 DRDY;  ///< Offset 0x100 Driver Readiness
+  UINT32 CSTS;  ///< Offset 0x104 Status
+  UINT32 CEVT;  ///< Offset 0x108 Current Event
+  UINT8  RM11[0x14];///< Offset 0x10C Reserved Must be Zero
+  UINT32 DIDL[8];   ///< Offset 0x120 Supported Display Devices ID List
+  UINT32 CPDL[8];   ///< Offset 0x140 obsolete
+  UINT32 CADL[8];   ///< Offset 0x160 obsolete
+  UINT32 NADL[8];   ///< Offset 0x180 obsolete
+  UINT32 ASLP;  ///< Offset 0x1A0 ASL Sleep Time Out
+  UINT32 TIDX;  ///< Offset 0x1A4 obsolete
+  UINT32 CHPD;  ///< Offset 0x1A8 obsolete
+  UINT32 CLID;  ///< Offset 0x1AC Current Lid State Indicator
+  UINT32 CDCK;  ///< Offset 0x1B0 Current Docking State Indicator
+  UINT32 SXSW;  ///< Offset 0x1B4 obsolete
+  UINT32 EVTS;  ///< Offset 0x1B8 obsolete
+  UINT32 CNOT;  ///< Offset 0x1BC obsolete
+  UINT32 NRDY;  ///< Offset 0x1C0 Driver Status
+  UINT8  DID2[0x1C];///< Offset 0x1C4 Extended Supported Devices ID List 
(DOD)
+  UINT8  CPD2[0x1C];///< Offset 0x1E0 obsolete
+  UINT8  RM12[4];   ///< Offset 0x1FC - 0x1FF Reserved Must be zero
+} IGD_OPREGION_MBOX1_VER_3_0;
+
+///
+/// OpRegion Mailbox 2 - Backlight communication /// Offset 0x200, Size
+0x100 /// typedef struct {
+  UINT32 BCL1;  ///< Offset 0x200 Backlight Brightness for LFP1
+  UINT32 BCL2;  ///< Offset 0x204 Backlight Brightness for LFP2
+  UINT32 CBL1;  ///< Offset 0x208 Current User Brightness Level for 
LFP1
+  UINT32 CBL2;  ///< Offset 0x20C Current User Brightness Level for 
LFP2
+  UINT32 BCM1[0x1E];///< Offset 0x210 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP1
+  UINT32 BCM2[0x1E];///< Offset 0x288 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP2
+} IGD_OPREGION_MBOX2_VER_3_0;
+
+///
+/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support /// 
+Offset 0x300, Size 0x100 /// typedef struct {
+  UINT32 ARDY;  ///< Offset 0x300 obsolete
+  UINT32 ASLC;  ///< Offset 0x304 obsolete
+  UINT32 TCHE;  ///< Offset 0x308 obsolete
+  UINT32 ALSI;  ///< Offset 0x30C obsolete
+  UINT32 BCLP;  ///< Offset 0x310 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 PFIT;  ///< Offset 0x314 obsolete
+  UINT32 CBLV;  ///< Offset 0x318 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT16 BCLM[0x14];///< Offset 0x31C obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 CPFM;  ///< Offset 0x344 obsolete
+  UINT32 EPFM;  ///< Offset 0x348 obsolete
+  UINT8  PLUT[0x4A];///< Offset 0x34C obsolete
+  UINT32 PFMB;  ///< Offset 0x396 obsolete
+  UINT32 CCDV;  ///< Offset 0x39A obsolete
+  UINT32 PCFT;  ///< Offset 0x39E obsolete
+  UINT32 SROT;  ///< Offset 0x3A2 obsolete
+  UINT32 IUER;  ///< 

Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm machines

[Sami Mujawar]

Hi Liming,

I will look into this shortly.

Regards,

Sami Mujawar


From: gaoliming 
Sent: Wednesday, 28 July 2021, 7:33 am
To: devel@edk2.groups.io; gaolim...@byosoft.com.cn; a...@kernel.org
Cc: Sami Mujawar; 'Etienne Carriere'; Achin Gupta; 'Ard Biesheuvel'; 'Jiewen 
Yao'; 'Leif Lindholm'; 'Sughosh Ganu'; nd
Subject: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm 
machines

Ard and Sami:
  Will you help merge this patch set for 202108 stable tag?

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 gaoliming
> 发送时间: 2021年7月20日 17:21
> 收件人: devel@edk2.groups.io; a...@kernel.org
> 抄送: 'Sami Mujawar' ; 'Etienne Carriere'
> ; 'Achin Gupta' ; 'Ard
> Biesheuvel' ; 'Jiewen Yao'
> ; 'Leif Lindholm' ; 'Sughosh
> Ganu' ; 'nd' 
> 主题: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit
> arm machines
>
> Ard:
>   Thanks! I have added this feature into
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planni
> ng.
>
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Ard
> > Biesheuvel
> > 发送时间: 2021年7月20日 15:46
> > 收件人: edk2-devel-groups-io ; Liming Gao
> (Byosoft
> > address) 
> > 抄送: Sami Mujawar ; Etienne Carriere
> > ; Achin Gupta ; Ard
> > Biesheuvel ; Jiewen Yao
> > ; Leif Lindholm ; Sughosh
> Ganu
> > ; nd 
> > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit
> arm
> > machines
> >
> > On Tue, 20 Jul 2021 at 04:01, gaoliming 
> wrote:
> > >
> > > Hi, all
> > >   This patch set has passed code review. How about merge it for this
> > stable tag edk2 202108?
> > >
> >
> > OK, I will pick these up. Would you mind creating the entry for the
> > release notes?
> >
> >
> > > Thanks
> > > Liming
> > > > -邮件原件-
> > > > 发件人: devel@edk2.groups.io  代表 Sami
> > > > Mujawar
> > > > 发送时间: 2021年5月19日 17:58
> > > > 收件人: Etienne Carriere ;
> > > > devel@edk2.groups.io
> > > > 抄送: Achin Gupta ; Ard Biesheuvel
> > > > ; Jiewen Yao ;
> Leif
> > > > Lindholm ; Sughosh Ganu
> > ;
> > > > n...@arm.com
> > > > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> 32bit
> > arm
> > > > machines
> > > >
> > > > Hi Etienn,
> > > >
> > > > This patch looks good to me.
> > > >
> > > > Reviewed-by: Sami Mujawar 
> > > >
> > > > Regards,
> > > >
> > > > Sami Mujawar
> > > >
> > > > On 19/05/2021 08:14 AM, Etienne Carriere wrote:
> > > > > This change allows to build StandaloneMmPkg components for 32bit
> > Arm
> > > > > StandaloneMm firmware.
> > > > >
> > > > > This change mainly moves AArch64/ source files to Arm/ side directory
> > > > > for several components:  StandaloneMmCpu,
> > > > StandaloneMmCoreEntryPoint
> > > > > and StandaloneMmMemLib. The source file is built for both 32b and
> 64b
> > > > > Arm targets.
> > > > >
> > > > > Signed-off-by: Etienne Carriere 
> > > > > ---
> > > > > Changes since v3:
> > > > > - Fix BuildOptions.ARM in StandaloneMmPkg.
> > > > > - Remove Cc tags.
> > > > >
> > > > > No change since v2
> > > > >
> > > > > Changes since v1:
> > > > > - ARM_SMC_ID_MM_COMMUNICATE 32b/64b agnostic helper ID is
> > > > defined
> > > > >in ArmStdSmc.h (see 1st commit in this series) instead of being
> > > > >local to EventHandle.c.
> > > > > - Fix void occurrence to VOID.
> > > > > - Fix path in StandaloneMmPkg/StandaloneMmPkg.dsc
> > > > > ---
> > > > >   StandaloneMmPkg/Core/StandaloneMmCore.inf
> > > > |  2 +-
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/EventHandle.c
> > > > |  5 +++--
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/StandaloneMmCpu.c
> > > > |  2 +-
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/StandaloneMmCpu.h
> > > > |  0
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/StandaloneMmCpu.inf
> > > > |  0
> > > > >   StandaloneMmPkg/Include/Library/{AArch64 =>
> > > > Arm}/StandaloneMmCoreEntryPoint.h
> > > > |  0
> > > > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > =>
> > > > Arm}/CreateHobList.c  |  2 +-
> > > > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > =>
> > > > Arm}/SetPermissions.c |  2 +-
> > > > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > =>
> > > > Arm}/StandaloneMmCoreEntryPoint.c | 16
> > > > 
> > > > >
> > > >
> >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCor
> > > > eEntryPoint.inf| 14
> > > > +++---
> > > > >   StandaloneMmPkg/Library/StandaloneMmCoreHobLib/{AArch64
> =>
> > > > Arm}/StandaloneMmCoreHobLib.c |
> > 0
> > > > >   StandaloneMmPkg/Library/StandaloneMmCoreHobLib/{AArch64
> =>
> > > > Arm}/StandaloneMmCoreHobLibInternal.c |
> 0
> > > > >
> > > >
> >
> StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreH
> > > 

回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit arm machines

[gaoliming]

Ard and Sami:
  Will you help merge this patch set for 202108 stable tag?

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 gaoliming
> 发送时间: 2021年7月20日 17:21
> 收件人: devel@edk2.groups.io; a...@kernel.org
> 抄送: 'Sami Mujawar' ; 'Etienne Carriere'
> ; 'Achin Gupta' ; 'Ard
> Biesheuvel' ; 'Jiewen Yao'
> ; 'Leif Lindholm' ; 'Sughosh
> Ganu' ; 'nd' 
> 主题: 回复: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit
> arm machines
> 
> Ard:
>   Thanks! I have added this feature into
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planni
> ng.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Ard
> > Biesheuvel
> > 发送时间: 2021年7月20日 15:46
> > 收件人: edk2-devel-groups-io ; Liming Gao
> (Byosoft
> > address) 
> > 抄送: Sami Mujawar ; Etienne Carriere
> > ; Achin Gupta ; Ard
> > Biesheuvel ; Jiewen Yao
> > ; Leif Lindholm ; Sughosh
> Ganu
> > ; nd 
> > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for 32bit
> arm
> > machines
> >
> > On Tue, 20 Jul 2021 at 04:01, gaoliming 
> wrote:
> > >
> > > Hi, all
> > >   This patch set has passed code review. How about merge it for this
> > stable tag edk2 202108?
> > >
> >
> > OK, I will pick these up. Would you mind creating the entry for the
> > release notes?
> >
> >
> > > Thanks
> > > Liming
> > > > -邮件原件-
> > > > 发件人: devel@edk2.groups.io  代表 Sami
> > > > Mujawar
> > > > 发送时间: 2021年5月19日 17:58
> > > > 收件人: Etienne Carriere ;
> > > > devel@edk2.groups.io
> > > > 抄送: Achin Gupta ; Ard Biesheuvel
> > > > ; Jiewen Yao ;
> Leif
> > > > Lindholm ; Sughosh Ganu
> > ;
> > > > n...@arm.com
> > > > 主题: Re: [edk2-devel] [PATCH v4 5/5] StandaloneMmPkg: build for
> 32bit
> > arm
> > > > machines
> > > >
> > > > Hi Etienn,
> > > >
> > > > This patch looks good to me.
> > > >
> > > > Reviewed-by: Sami Mujawar 
> > > >
> > > > Regards,
> > > >
> > > > Sami Mujawar
> > > >
> > > > On 19/05/2021 08:14 AM, Etienne Carriere wrote:
> > > > > This change allows to build StandaloneMmPkg components for 32bit
> > Arm
> > > > > StandaloneMm firmware.
> > > > >
> > > > > This change mainly moves AArch64/ source files to Arm/ side directory
> > > > > for several components:  StandaloneMmCpu,
> > > > StandaloneMmCoreEntryPoint
> > > > > and StandaloneMmMemLib. The source file is built for both 32b and
> 64b
> > > > > Arm targets.
> > > > >
> > > > > Signed-off-by: Etienne Carriere 
> > > > > ---
> > > > > Changes since v3:
> > > > > - Fix BuildOptions.ARM in StandaloneMmPkg.
> > > > > - Remove Cc tags.
> > > > >
> > > > > No change since v2
> > > > >
> > > > > Changes since v1:
> > > > > - ARM_SMC_ID_MM_COMMUNICATE 32b/64b agnostic helper ID is
> > > > defined
> > > > >in ArmStdSmc.h (see 1st commit in this series) instead of being
> > > > >local to EventHandle.c.
> > > > > - Fix void occurrence to VOID.
> > > > > - Fix path in StandaloneMmPkg/StandaloneMmPkg.dsc
> > > > > ---
> > > > >   StandaloneMmPkg/Core/StandaloneMmCore.inf
> > > > |  2 +-
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/EventHandle.c
> > > > |  5 +++--
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/StandaloneMmCpu.c
> > > > |  2 +-
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/StandaloneMmCpu.h
> > > > |  0
> > > > >   StandaloneMmPkg/Drivers/StandaloneMmCpu/{AArch64
> > > > => }/StandaloneMmCpu.inf
> > > > |  0
> > > > >   StandaloneMmPkg/Include/Library/{AArch64 =>
> > > > Arm}/StandaloneMmCoreEntryPoint.h
> > > > |  0
> > > > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > =>
> > > > Arm}/CreateHobList.c  |  2 +-
> > > > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > =>
> > > > Arm}/SetPermissions.c |  2 +-
> > > > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/{AArch64
> > =>
> > > > Arm}/StandaloneMmCoreEntryPoint.c | 16
> > > > 
> > > > >
> > > >
> >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCor
> > > > eEntryPoint.inf| 14
> > > > +++---
> > > > >   StandaloneMmPkg/Library/StandaloneMmCoreHobLib/{AArch64
> =>
> > > > Arm}/StandaloneMmCoreHobLib.c |
> > 0
> > > > >   StandaloneMmPkg/Library/StandaloneMmCoreHobLib/{AArch64
> =>
> > > > Arm}/StandaloneMmCoreHobLibInternal.c |
> 0
> > > > >
> > > >
> >
> StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreH
> > > > obLib.inf|  8
> > 
> > > > >
> > > >
> >
> StandaloneMmPkg/Library/StandaloneMmMemLib/{AArch64/StandaloneMm
> > > > MemLibInternal.c => ArmStandaloneMmMemLibInternal.c} |  9
> > -
> > > > >
> > > >
> >
> StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.i
> > > > nf|  6
> > > > +++---
> > > > >
> > > >
> 

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

[Yao, Jiewen]

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 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?
> I have replied to Brijesh's mail about the concern of the new pattern. 
> 
> I have some concern in the current pattern:
> 
>OneTimeCall   PreMainFunctionHookSev
>OneTimeCall   PreMainFunctionHookTdx
> MainFunction:
>XX
>OneTimeCall   PostMainFunctionHookSev
>OneTimeCall   PostMainFunctionHookTdx
> 
> The TEE function need implement a TEE check function (such as IsSev, or 
> IsTdx). 
> 
> Tdx call CPUID(0x21) to determine if it is tdx guest in the very beginning of 
> ResetVector. Then 'TDXG' is set
> in TDX_WORK_AREA. SEV does the similar work which call CheckSevFeatures to 
> set SEV_ES_WORK_AREA to 1.
> 
> After that both TDX and SEV read the above WORK_AREA to check if it is TDX or 
> SEV or legacy guest.
> 
> In Tdx the access to SEV_ES_WORK_AREA will trigger error because 
> SEV_ES_WORK_AREA is *NOT* initialized by host VMM.
> In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error too.
> 
> I am wondering if TDX and SEV can use the same memory region (for example, 
> TEE_WORK_AREA) as the work area?
> So that this work area is guaranteed to be initialized in both TDX and SEV. 
> Structure of the TEE_WORK_AREA may
> look like this:
>  typedef struct {
>  UINT8  Flag[4]; 'TDXG' or 'SEVG' or all-0
>  UINT8  Others[];
>  } TEE_WORK_AREA;
>> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78267): https://edk2.groups.io/g/devel/message/78267
Mute This Topic: https://groups.io/mt/84476064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH EDK2 v1 0/1] MdeModulePkg/UefiSortLib:Add UefiSortLib unit test

[wenyi,xie via groups.io]

Main Changes :
Adding unit test for UefiSortLib.

Wenyi Xie (1):
  MdeModulePkg/UefiSortLib:Add UefiSortLib unit test

 MdeModulePkg/Test/MdeModulePkgHostTest.dsc|   6 +
 MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf |  32 
 MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c   | 188 

 3 files changed, 226 insertions(+)
 create mode 100644 
MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf
 create mode 100644 
MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c

-- 
2.20.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78266): https://edk2.groups.io/g/devel/message/78266
Mute This Topic: https://groups.io/mt/84499704/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg/UefiSortLib:Add UefiSortLib unit test

[wenyi,xie via groups.io]

Adding unit test for UefiSortLib.

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Wenyi Xie 
---
 MdeModulePkg/Test/MdeModulePkgHostTest.dsc|   6 +
 MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf |  32 
 MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c   | 188 

 3 files changed, 226 insertions(+)

diff --git a/MdeModulePkg/Test/MdeModulePkgHostTest.dsc 
b/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
index 4da4692c8451..c9ec835df65d 100644
--- a/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
+++ b/MdeModulePkg/Test/MdeModulePkgHostTest.dsc
@@ -41,3 +41,9 @@ [Components]
 
   
gEfiMdeModulePkgTokenSpaceGuid.PcdAllowVariablePolicyEnforcementDisable|TRUE
   }
+
+  MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf {
+
+  UefiSortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+  }
diff --git a/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf 
b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf
new file mode 100644
index ..d9dac307934e
--- /dev/null
+++ b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.inf
@@ -0,0 +1,32 @@
+## @file
+# This is a unit test for the UefiSortLib.
+#
+# Copyright (c) Microsoft Corporation.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION = 0x00010017
+  BASE_NAME   = UefiSortLibUnitTest
+  FILE_GUID   = 271337A3-0D79-BA3E-BC03-714E518E3B1B
+  VERSION_STRING  = 1.0
+  MODULE_TYPE = HOST_APPLICATION
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  UefiSortLibUnitTest.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
+
+[LibraryClasses]
+  UnitTestLib
+  DebugLib
+  UefiSortLib
diff --git a/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c 
b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c
new file mode 100644
index ..f2f89daef7ba
--- /dev/null
+++ b/MdeModulePkg/Library/UefiSortLib/UnitTest/UefiSortLibUnitTest.c
@@ -0,0 +1,188 @@
+/** @file
+  Unit tests of the UefiSortLib
+
+  Copyright (C) Huawei Technologies Co., Ltd. All rights reserved
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define UNIT_TEST_APP_NAME"UefiSortLib Unit Tests"
+#define UNIT_TEST_APP_VERSION "1.0"
+
+#define TEST_ARRAY_SIZE_9 9
+
+/**
+  The function is called by PerformQuickSort to compare int values.
+
+  @param[in] LeftThe pointer to first buffer.
+  @param[in] Right   The pointer to second buffer.
+
+  @retval 0  Buffer1 equal to Buffer2.
+  @return <0 Buffer1 is less than Buffer2.
+  @return >0 Buffer1 is greater than Buffer2.
+
+**/
+INTN
+EFIAPI
+TestCompareFunction (
+  IN CONST VOID *Left,
+  IN CONST VOID *Right
+  )
+{
+  if (*(UINT32*)Right > *(UINT32*)Left) {
+return 1;
+  } else if (*(UINT32*)Right < *(UINT32*)Left) {
+return -1;
+  }
+
+  return 0;
+}
+
+/**
+  Unit test for PerformQuickSort () API of the UefiSortLib.
+
+  @param[in]  Context[Optional] An optional parameter that enables:
+ 1) test-case reuse with varied parameters and
+ 2) test-case re-entry for Target tests that need a
+ reboot.  This parameter is a VOID* and it is the
+ responsibility of the test author to ensure that the
+ contents are well understood by all test cases that 
may
+ consume it.
+
+  @retval  UNIT_TEST_PASSED The Unit test has completed and the 
test
+case was successful.
+  @retval  UNIT_TEST_ERROR_TEST_FAILED  A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+EFIAPI
+SortUINT32ArrayShouldSucceed (
+  IN UNIT_TEST_CONTEXT  Context
+  )
+{
+  UINTN TestCount = TEST_ARRAY_SIZE_9;
+  UINT32 TestBuffer[TEST_ARRAY_SIZE_9] = {1, 2, 3, 4, 5, 6, 7 ,8, 9};
+  UINT32 TestResult[TEST_ARRAY_SIZE_9] = {9, 8, 7, 6, 5, 4, 3, 2, 1};
+
+  PerformQuickSort (TestBuffer, TestCount, sizeof (UINT32), 
(SORT_COMPARE)TestCompareFunction);
+  UT_ASSERT_MEM_EQUAL (TestBuffer, TestResult, sizeof (UINT32) * 
TEST_ARRAY_SIZE_9);
+
+  return UNIT_TEST_PASSED;
+}
+
+/**
+  Unit test for StringCompare () API of the UefiSortLib.
+
+  @param[in]  Context[Optional] An optional parameter that enables:
+ 1) test-case reuse with varied parameters and
+ 2) test-case re-entry for