Date   

[edk2-platforms: PATCH v4 1/9] MinPlatformPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.

Chiu, Chasel
 

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

Implementation should search FSP_NON_VOLATILE_STORAGE_HOB2 firstly
and only search FSP_NON_VOLATILE_STORAGE_HOB when former one is not found.

Also added PeiGetLargeVariable () to support the scenarios where the
variable data size is bigger than a single variable size limit. (stored
across multiple variables)

Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
---
Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig=
.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++----------------=
---------------------------------------------
Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c =
| 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++----------
Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/PeiVariableReadLi=
b.c | 4 ++--
Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig=
.inf | 8 ++++++--
Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc =
| 1 +
Platform/Intel/MinPlatformPkg/Include/Library/PeiLib.h =
| 40 +++++++++++++++++++++++++++++++++++-----
Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf =
| 4 +++-
Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec =
| 1 +
8 files changed, 175 insertions(+), 81 deletions(-)

diff --git a/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/Save=
MemoryConfig.c b/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/=
SaveMemoryConfig.c
index 41ed2550bd..820585f676 100644
--- a/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryC=
onfig.c
+++ b/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryC=
onfig.c
@@ -2,7 +2,7 @@
This is the driver that locates the MemoryConfigurationData HOB, if it=0D
exists, and saves the data to nvRAM.=0D
=0D
-Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>=0D
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
=0D
**/=0D
@@ -16,7 +16,9 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include <Guid/GlobalVariable.h>=0D
#include <Library/MemoryAllocationLib.h>=0D
#include <Library/BaseMemoryLib.h>=0D
-#include <Protocol/VariableLock.h>=0D
+#include <Library/LargeVariableReadLib.h>=0D
+#include <Library/LargeVariableWriteLib.h>=0D
+#include <Guid/FspNonVolatileStorageHob2.h>=0D
=0D
/**=0D
This is the standard EFI driver point that detects whether there is a=0D
@@ -40,86 +42,71 @@ SaveMemoryConfigEntryPoint (
VOID *VariableData;=0D
UINTN DataSize;=0D
UINTN BufferSize;=0D
- EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;=0D
+ BOOLEAN DataIsIdentical;=0D
=0D
- DataSize =3D 0;=0D
- VariableData =3D NULL;=0D
- GuidHob =3D NULL;=0D
- HobData =3D NULL;=0D
+ DataSize =3D 0;=0D
+ BufferSize =3D 0;=0D
+ VariableData =3D NULL;=0D
+ GuidHob =3D NULL;=0D
+ HobData =3D NULL;=0D
+ DataIsIdentical =3D FALSE;=0D
=0D
//=0D
// Search for the Memory Configuration GUID HOB. If it is not present, =
then=0D
// there's nothing we can do. It may not exist on the update path.=0D
+ // Firstly check version2 FspNvsHob.=0D
//=0D
- GuidHob =3D GetFirstGuidHob (&gFspNonVolatileStorageHobGuid);=0D
+ GuidHob =3D GetFirstGuidHob (&gFspNonVolatileStorageHob2Guid);=0D
if (GuidHob !=3D NULL) {=0D
- HobData =3D GET_GUID_HOB_DATA (GuidHob);=0D
- DataSize =3D GET_GUID_HOB_DATA_SIZE(GuidHob);=0D
+ HobData =3D (VOID *) (UINTN) ((FSP_NON_VOLATILE_STORAGE_HOB2 *) (UINTN=
) GuidHob)->NvsDataPtr;=0D
+ DataSize =3D (UINTN) ((FSP_NON_VOLATILE_STORAGE_HOB2 *) (UINTN) GuidHo=
b)->NvsDataLength;=0D
+ } else {=0D
+ //=0D
+ // Fall back to version1 FspNvsHob=0D
+ //=0D
+ GuidHob =3D GetFirstGuidHob (&gFspNonVolatileStorageHobGuid);=0D
+ if (GuidHob !=3D NULL) {=0D
+ HobData =3D GET_GUID_HOB_DATA (GuidHob);=0D
+ DataSize =3D GET_GUID_HOB_DATA_SIZE (GuidHob);=0D
+ }=0D
+ }=0D
+=0D
+ if (HobData !=3D NULL) {=0D
+ DEBUG ((DEBUG_INFO, "FspNvsHob.NvsDataLength:%d\n", DataSize));=0D
+ DEBUG ((DEBUG_INFO, "FspNvsHob.NvsDataPtr : 0x%x\n", HobData));=0D
if (DataSize > 0) {=0D
//=0D
- // Use the HOB to save Memory Configuration Data=0D
+ // Check if the presently saved data is identical to the data given =
by MRC/FSP=0D
//=0D
- BufferSize =3D DataSize;=0D
- VariableData =3D AllocatePool (BufferSize);=0D
- if (VariableData =3D=3D NULL) {=0D
- return EFI_UNSUPPORTED;=0D
- }=0D
- Status =3D gRT->GetVariable (=0D
- L"MemoryConfig",=0D
- &gFspNonVolatileStorageHobGuid,=0D
- NULL,=0D
- &BufferSize,=0D
- VariableData=0D
- );=0D
-=0D
+ Status =3D GetLargeVariable (L"FspNvsBuffer", &gFspNvsBufferVariable=
Guid, &BufferSize, NULL);=0D
if (Status =3D=3D EFI_BUFFER_TOO_SMALL) {=0D
- FreePool (VariableData);=0D
- VariableData =3D AllocatePool (BufferSize);=0D
- if (VariableData =3D=3D NULL) {=0D
- return EFI_UNSUPPORTED;=0D
+ if (BufferSize =3D=3D DataSize) {=0D
+ VariableData =3D AllocatePool (BufferSize);=0D
+ if (VariableData !=3D NULL) {=0D
+ Status =3D GetLargeVariable (L"FspNvsBuffer", &gFspNvsBufferVa=
riableGuid, &BufferSize, VariableData);=0D
+ if (!EFI_ERROR (Status) && (BufferSize =3D=3D DataSize) && (0 =
=3D=3D CompareMem (HobData, VariableData, DataSize))) {=0D
+ DataIsIdentical =3D TRUE;=0D
+ }=0D
+ FreePool (VariableData);=0D
+ }=0D
}=0D
-=0D
- Status =3D gRT->GetVariable (=0D
- L"MemoryConfig",=0D
- &gFspNonVolatileStorageHobGuid,=0D
- NULL,=0D
- &BufferSize,=0D
- VariableData=0D
- );=0D
}=0D
+ Status =3D EFI_SUCCESS;=0D
=0D
- if ( (EFI_ERROR(Status)) || BufferSize !=3D DataSize || 0 !=3D Compa=
reMem (HobData, VariableData, DataSize)) {=0D
- Status =3D gRT->SetVariable (=0D
- L"MemoryConfig",=0D
- &gFspNonVolatileStorageHobGuid,=0D
- (EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERV=
ICE_ACCESS),=0D
- DataSize,=0D
- HobData=0D
- );=0D
+ if (!DataIsIdentical) {=0D
+ Status =3D SetLargeVariable (L"FspNvsBuffer", &gFspNvsBufferVariab=
leGuid, TRUE, DataSize, HobData);=0D
ASSERT_EFI_ERROR (Status);=0D
-=0D
- DEBUG((DEBUG_INFO, "Restored Size is 0x%x\n", DataSize));=0D
- }=0D
-=0D
- //=0D
- // Mark MemoryConfig to read-only if the Variable Lock protocol exis=
ts=0D
- //=0D
- Status =3D gBS->LocateProtocol(&gEdkiiVariableLockProtocolGuid, NULL=
, (VOID **)&VariableLock);=0D
- if (!EFI_ERROR(Status)) {=0D
- Status =3D VariableLock->RequestToLock(VariableLock, L"MemoryConfi=
g", &gFspNonVolatileStorageHobGuid);=0D
- ASSERT_EFI_ERROR(Status);=0D
+ DEBUG ((DEBUG_INFO, "Saved size of FSP / MRC Training Data: 0x%x\n=
", DataSize));=0D
+ } else {=0D
+ DEBUG ((DEBUG_INFO, "FSP / MRC Training Data is identical to data =
from last boot, no need to save.\n"));=0D
}=0D
-=0D
- FreePool (VariableData);=0D
- } else {=0D
- DEBUG((DEBUG_INFO, "Memory save size is %d\n", DataSize));=0D
}=0D
} else {=0D
DEBUG((DEBUG_ERROR, "Memory S3 Data HOB was not found\n"));=0D
}=0D
=0D
//=0D
- // This driver does not produce any protocol services, so always unload =
it.=0D
+ // This driver cannot be unloaded because DxeRuntimeVariableWriteLib con=
structor will register ExitBootServices callback.=0D
//=0D
- return EFI_REQUEST_UNLOAD_IMAGE;=0D
+ return EFI_SUCCESS;=0D
}=0D
diff --git a/Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c b/Platfo=
rm/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c
index 96dfd588dc..3f8cf761a7 100644
--- a/Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c
+++ b/Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c
@@ -1,6 +1,6 @@
/** @file=0D
=0D
-Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>=0D
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
=0D
**/=0D
@@ -9,13 +9,17 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include <Library/DebugLib.h>=0D
#include <Library/PeiServicesLib.h>=0D
#include <Library/MemoryAllocationLib.h>=0D
+#include <Library/LargeVariableReadLib.h>=0D
#include <Ppi/ReadOnlyVariable2.h>=0D
=0D
/**=0D
- Returns the status whether get the variable success. The function retrie=
ves =0D
- variable through the ReadOnlyVariable2 PPI GetVariable(). The =0D
- returned buffer is allocated using AllocatePool(). The caller is respon=
sible=0D
- for freeing this buffer with FreePool().=0D
+ Returns the status whether get the variable success. The function retrie=
ves=0D
+ variable through the ReadOnlyVariable2 PPI GetVariable().=0D
+=0D
+ If the *Size is 0, the returned buffer is allocated using AllocatePool()=
.=0D
+ The buffer is not expected to be freed as PEI does not support a FreePoo=
l().=0D
+=0D
+ If the *Size is non-0, this function just uses caller allocated *Value.=
=0D
=0D
If Name is NULL, then ASSERT().=0D
If Guid is NULL, then ASSERT().=0D
@@ -108,6 +112,71 @@ PeiGetVariable (
return Status;=0D
}=0D
=0D
+/**=0D
+ This function returns a "large variable". A large variable is stored acr=
oss multiple=0D
+ UEFI Variables. This function retrieves the multiple UEFI Variables usin=
g=0D
+ ReadOnlyVariable2 PPI GetVariable().=0D
+ The function uses AllocatePages () to allocate the buffer.=0D
+ The caller is responsible for freeing this buffer with FreePages().=0D
+=0D
+ If Name is NULL, then ASSERT().=0D
+ If Guid is NULL, then ASSERT().=0D
+ If Value is NULL, then ASSERT().=0D
+=0D
+ @param[in] Name The pointer to a Null-terminated Unicode string.=0D
+ @param[in] Guid The pointer to an EFI_GUID structure=0D
+ @param[out] Value The buffer point saved the variable info.=0D
+ @param[out] Size The buffer size of the variable.=0D
+=0D
+ @return EFI_OUT_OF_RESOURCES Allocate buffer failed.=0D
+ @return EFI_SUCCESS Find the specified variable.=0D
+ @return Others Errors Return errors from call to gRT->GetVar=
iable.=0D
+=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+PeiGetLargeVariable (=0D
+ IN CHAR16 *Name,=0D
+ IN EFI_GUID *Guid,=0D
+ OUT VOID **Value,=0D
+ OUT UINTN *Size OPTIONAL=0D
+ )=0D
+{=0D
+ EFI_STATUS Status;=0D
+ UINTN VariableSize;=0D
+ VOID *VariableData;=0D
+=0D
+ ASSERT (Name !=3D NULL);=0D
+ ASSERT (Guid !=3D NULL);=0D
+ ASSERT (Value !=3D NULL);=0D
+=0D
+ VariableSize =3D 0;=0D
+ VariableData =3D NULL;=0D
+ Status =3D GetLargeVariable (Name, Guid, &VariableSize, NULL);=0D
+ if (Status =3D=3D EFI_BUFFER_TOO_SMALL) {=0D
+ VariableData =3D AllocatePages (EFI_SIZE_TO_PAGES (VariableSize));=0D
+ if (VariableData =3D=3D NULL) {=0D
+ DEBUG ((DEBUG_ERROR, "Error: Cannot create VariableData, out of memo=
ry!\n"));=0D
+ ASSERT (FALSE);=0D
+ return EFI_OUT_OF_RESOURCES;=0D
+ }=0D
+ Status =3D GetLargeVariable (Name, Guid, &VariableSize, VariableData);=
=0D
+ if (EFI_ERROR (Status)) {=0D
+ DEBUG ((DEBUG_ERROR, "Error: Unable to read UEFI variable Status: %r=
\n", Status));=0D
+ ASSERT_EFI_ERROR (Status);=0D
+ return Status;=0D
+ }=0D
+ if (Value !=3D NULL) {=0D
+ *Value =3D VariableData;=0D
+ }=0D
+ if (Size !=3D NULL) {=0D
+ *Size =3D VariableSize;=0D
+ }=0D
+ return EFI_SUCCESS;=0D
+ }=0D
+ return Status;=0D
+}=0D
+=0D
EFI_PEI_FILE_HANDLE=0D
InternalGetFfsHandleFromAnyFv (=0D
IN CONST EFI_GUID *NameGuid=0D
@@ -139,7 +208,7 @@ InternalGetFfsHandleFromAnyFv (
=0D
/**=0D
Finds the file in any FV and gets file Address and Size=0D
- =0D
+=0D
@param[in] NameGuid File GUID=0D
@param[out] Address Pointer to the File Address=0D
@param[out] Size Pointer to File Size=0D
@@ -162,7 +231,7 @@ PeiGetFfsFromAnyFv (
if (FfsHandle =3D=3D NULL) {=0D
return EFI_NOT_FOUND;=0D
}=0D
- =0D
+=0D
//=0D
// Need get size=0D
//=0D
@@ -185,7 +254,7 @@ PeiGetFfsFromAnyFv (
@param[in] SectionInstance The Instance of Section to be found=0D
@param[out] OutSectionBuffer The section found, including SECTION_HEAD=
ER=0D
@param[out] OutSectionSize The size of section found, including SECT=
ION_HEADER=0D
- =0D
+=0D
@retval EFI_SUCCESS Successfull in reading the section fr=
om FV=0D
**/=0D
EFI_STATUS=0D
@@ -263,7 +332,7 @@ PeiGetSectionFromAnyFv (
EFI_COMMON_SECTION_HEADER *Section;=0D
VOID *FileBuffer;=0D
UINTN FileBufferSize;=0D
- =0D
+=0D
Status =3D PeiGetFfsFromAnyFv (NameGuid, &FileBuffer, &FileBufferSize);=
=0D
if (EFI_ERROR(Status)) {=0D
return Status;=0D
@@ -282,6 +351,6 @@ PeiGetSectionFromAnyFv (
*Size =3D SECTION_SIZE(Section) - sizeof (EFI_COMMON_SECTION_HEADER);=
=0D
*Address =3D (UINT8 *)*Address + sizeof (EFI_COMMON_SECTION_HEADER);=0D
}=0D
- =0D
+=0D
return EFI_SUCCESS;=0D
}=0D
diff --git a/Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/PeiVa=
riableReadLib.c b/Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/=
PeiVariableReadLib.c
index 5eeee12a3c..b7885dd6c2 100644
--- a/Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/PeiVariableR=
eadLib.c
+++ b/Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/PeiVariableR=
eadLib.c
@@ -67,7 +67,7 @@ VarLibGetVariable (
&gEfiPeiReadOnlyVariable2PpiGuid,=0D
0,=0D
NULL,=0D
- &VariablePpi=0D
+ (VOID **) &VariablePpi=0D
);=0D
ASSERT_EFI_ERROR (Status);=0D
if (EFI_ERROR (Status)) {=0D
@@ -134,7 +134,7 @@ VarLibGetNextVariableName (
&gEfiPeiReadOnlyVariable2PpiGuid,=0D
0,=0D
NULL,=0D
- &VariablePpi=0D
+ (VOID **) &VariablePpi=0D
);=0D
ASSERT_EFI_ERROR (Status);=0D
if (EFI_ERROR (Status)) {=0D
diff --git a/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/Save=
MemoryConfig.inf b/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfi=
g/SaveMemoryConfig.inf
index 0c8689a6f6..e2dbd2fb49 100644
--- a/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryC=
onfig.inf
+++ b/Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryC=
onfig.inf
@@ -1,7 +1,7 @@
### @file=0D
# Component information file for SaveMemoryConfig module=0D
#=0D
-# Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>=0D
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>=0D
#=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
@@ -23,11 +23,14 @@
DebugLib=0D
MemoryAllocationLib=0D
BaseMemoryLib=0D
+ LargeVariableReadLib=0D
+ LargeVariableWriteLib=0D
=0D
[Packages]=0D
MdePkg/MdePkg.dec=0D
MdeModulePkg/MdeModulePkg.dec=0D
IntelFsp2Pkg/IntelFsp2Pkg.dec=0D
+ MinPlatformPkg/MinPlatformPkg.dec=0D
=0D
[Sources]=0D
SaveMemoryConfig.c=0D
@@ -35,10 +38,11 @@
[Protocols]=0D
gEfiVariableArchProtocolGuid ## CONSUMES=0D
gEfiVariableWriteArchProtocolGuid ## CONSUMES=0D
- gEdkiiVariableLockProtocolGuid=0D
=0D
[Guids]=0D
gFspNonVolatileStorageHobGuid ## CONSUMES=0D
+ gFspNonVolatileStorageHob2Guid ## CONSUMES=0D
+ gFspNvsBufferVariableGuid ## PRODUCES=0D
=0D
[Depex]=0D
gEfiVariableArchProtocolGuid AND=0D
diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc b/Pla=
tform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
index d3c668d441..c12189bd9a 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
+++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
@@ -41,6 +41,7 @@
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.in=
f=0D
!endif=0D
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf=0D
+ VariableReadLib|MinPlatformPkg/Library/BaseVariableReadLibNull/BaseVaria=
bleReadLibNull.inf=0D
=0D
[LibraryClasses.common.PEI_CORE]=0D
TimerLib|PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf=0D
diff --git a/Platform/Intel/MinPlatformPkg/Include/Library/PeiLib.h b/Platf=
orm/Intel/MinPlatformPkg/Include/Library/PeiLib.h
index d8b1a47c58..eed6502d84 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Library/PeiLib.h
+++ b/Platform/Intel/MinPlatformPkg/Include/Library/PeiLib.h
@@ -1,6 +1,6 @@
/** @file=0D
=0D
-Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>=0D
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
=0D
**/=0D
@@ -11,11 +11,11 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include <PiPei.h>=0D
=0D
/**=0D
- Returns the status whether get the variable success. The function retrie=
ves =0D
+ Returns the status whether get the variable success. The function retrie=
ves=0D
variable through the ReadOnlyVariable2 PPI GetVariable().=0D
=0D
If the *Size is 0, the returned buffer is allocated using AllocatePool()=
.=0D
- The caller is responsible for freeing this buffer with FreePool().=0D
+ The buffer is not expected to be freed as PEI does not support a FreePoo=
l().=0D
=0D
If the *Size is non-0, this function just uses caller allocated *Value.=
=0D
=0D
@@ -38,9 +38,39 @@ PeiGetVariable (
OUT UINTN *Size=0D
);=0D
=0D
+/**=0D
+ This function returns a "large variable". A large variable is stored acr=
oss multiple=0D
+ UEFI Variables. This function retrieves the multiple UEFI Variables usin=
g=0D
+ ReadOnlyVariable2 PPI GetVariable().=0D
+ The function uses AllocatePages () to allocate the buffer.=0D
+ The caller is responsible for freeing this buffer with FreePages().=0D
+=0D
+ If Name is NULL, then ASSERT().=0D
+ If Guid is NULL, then ASSERT().=0D
+ If Value is NULL, then ASSERT().=0D
+=0D
+ @param[in] Name The pointer to a Null-terminated Unicode string.=0D
+ @param[in] Guid The pointer to an EFI_GUID structure=0D
+ @param[out] Value The buffer point saved the variable info.=0D
+ @param[out] Size The buffer size of the variable.=0D
+=0D
+ @return EFI_OUT_OF_RESOURCES Allocate buffer failed.=0D
+ @return EFI_SUCCESS Find the specified variable.=0D
+ @return Others Errors Return errors from call to gRT->GetVar=
iable.=0D
+=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+PeiGetLargeVariable (=0D
+ IN CHAR16 *Name,=0D
+ IN EFI_GUID *Guid,=0D
+ OUT VOID **Value,=0D
+ OUT UINTN *Size OPTIONAL=0D
+ );=0D
+=0D
/**=0D
Finds the file in any FV and gets file Address and Size=0D
- =0D
+=0D
@param[in] NameGuid File GUID=0D
@param[out] Address Pointer to the File Address=0D
@param[out] Size Pointer to File Size=0D
@@ -57,7 +87,7 @@ PeiGetFfsFromAnyFv (
=0D
/**=0D
Finds the section in any FV and gets section Address and Size=0D
- =0D
+=0D
@param[in] NameGuid File GUID=0D
@param[in] SectionType The SectionType of Section to be found=
=0D
@param[in] SectionInstance The Instance of Section to be found=0D
diff --git a/Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf b/Plat=
form/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf
index 7e740172a0..bd57cf7870 100644
--- a/Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf
+++ b/Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf
@@ -1,7 +1,7 @@
## @file=0D
# Component information file for Board Init Test Library=0D
#=0D
-# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.<BR>=0D
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>=0D
#=0D
# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
#=0D
@@ -20,9 +20,11 @@
PeiServicesLib=0D
MemoryAllocationLib=0D
DebugLib=0D
+ LargeVariableReadLib=0D
=0D
[Packages]=0D
MdePkg/MdePkg.dec=0D
+ MinPlatformPkg/MinPlatformPkg.dec=0D
=0D
[Sources]=0D
PeiLib.c=0D
diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec b/Platform/In=
tel/MinPlatformPkg/MinPlatformPkg.dec
index bcb42f0ef9..d6e80a66ce 100644
--- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec
+++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec
@@ -50,6 +50,7 @@
gBdsEventBeforeConsoleAfterTrustedConsoleGuid =3D {0x51e49ff5, 0x28a9, =
0x4159, { 0xac, 0x8a, 0xb8, 0xc4, 0x88, 0xa7, 0xfd, 0xee}}=0D
gBdsEventBeforeConsoleBeforeEndOfDxeGuid =3D {0xfcf26e41, 0xbda6, =
0x4633, { 0xb5, 0x73, 0xd4, 0xb8, 0x0e, 0x6d, 0xd0, 0x78}}=0D
gBdsEventAfterConsoleReadyBeforeBootOptionGuid =3D {0x8eb3d5dc, 0xf4e7, =
0x4b57, { 0xa9, 0xe7, 0x27, 0x39, 0x10, 0xf2, 0x18, 0x9f}}=0D
+ gFspNvsBufferVariableGuid =3D {0x9c7715cd, 0x8d66, =
0x4d2a, { 0x90, 0x0d, 0x01, 0x45, 0x9a, 0x57, 0x59, 0x6b}}=0D
=0D
[LibraryClasses]=0D
=0D
--=20
2.28.0.windows.1


[edk2-platforms: PATCH v4 0/9] MinPlatformPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.

Chiu, Chasel
 

V4:
. Switched to LargeVariableRead(Write)Lib in SaveMemoryConfig driver
. Fixed tailing white space issue in PeiLib.c/.h
. Updated function descriptions for PeiGetVariable() and PeiGetLargeVariable()
. Added VariableReadLib to CorePeiLib.dsc for all platforms
. Fixed white space issue in GalagoPro3/.../PeiFspMiscUpdUpdateLib.c

V3:
Fix another GCC build failure.

V2:
Fix GCC build failures.

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

Implementation should search FSP_NON_VOLATILE_STORAGE_HOB2 firstly
and only search FSP_NON_VOLATILE_STORAGE_HOB when former one is not found.

Also added PeiGetLargeVariable () to support the scenarios where the
variable data size is bigger than a single variable size limit.

Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Heng Luo <heng.luo@intel.com>
Cc: Jeremy Soller <jeremy@system76.com>
Cc: Benjamin Doron <benjamin.doron00@gmail.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Deepika Kethi Reddy <deepika.kethi.reddy@intel.com>
Cc: Kathappan Esakkithevar <kathappan.esakkithevar@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>

Chasel Chiu (9):
MinPlatformPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.
CometlakeOpenBoardPkg: Use same variable name for FspNvsHob.
KabylakeOpenBoardPkg/AspireVn7Dash572G:Use same variable name for
FspNvsHob
KabylakeOpenBoardPkg/GalagoPro3: Use same variable name for FspNvsHob.
KabylakeOpenBoardPkg/KabylakeRvp3: Use same variable name for
FspNvsHob.
TigerlakeOpenBoardPkg: Use same variable name for FspNvsHob.
WhiskeylakeOpenBoardPkg: Use same variable name for FspNvsHob.
WhitleyOpenBoardPkg: Support FSP 2.3 FSP_NON_VOLATILE_STORAGE_HOB2.
WhitleySiliconPkg: Use same variable name for FspNvsHob.

Platform/Intel/CometlakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 63 ++++++++++++++-------------------------------------------------
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 24 ++++++++++--------------
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c | 23 +++++++++--------------
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 25 +++++++++++--------------
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 25 ++++++++++---------------
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c | 23 +++++++++--------------
Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------
Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
Platform/Intel/MinPlatformPkg/Library/PeiVariableReadLib/PeiVariableReadLib.c | 4 ++--
Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiFspPolicyInitLib/PeiFspPolicyInitLib.c | 21 ++++++++++++++++++---
Platform/Intel/WhiskeylakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 63 ++++++++++++---------------------------------------------------
Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiFspMiscUpdUpdateLib.c | 63 ++++++++++++---------------------------------------------------
Platform/Intel/WhitleyOpenBoardPkg/Platform/Dxe/S3NvramSave/S3NvramSave.c | 29 +++++++++++++++++++++++------
Silicon/Intel/WhitleySiliconPkg/Library/FspWrapperPlatformLib/FspWrapperPlatformLib.c | 35 +++++++++--------------------------
Platform/Intel/CometlakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 7 ++++---
Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf | 2 +-
Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf | 2 +-
Platform/Intel/MinPlatformPkg/FspWrapper/SaveMemoryConfig/SaveMemoryConfig.inf | 8 ++++++--
Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc | 1 +
Platform/Intel/MinPlatformPkg/Include/Library/PeiLib.h | 40 +++++++++++++++++++++++++++++++++++-----
Platform/Intel/MinPlatformPkg/Library/PeiLib/PeiLib.inf | 4 +++-
Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec | 1 +
Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiFspPolicyInitLib/PeiFspPolicyInitLib.inf | 1 +
Platform/Intel/WhiskeylakeOpenBoardPkg/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 5 ++---
Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/FspWrapper/Library/PeiSiliconPolicyUpdateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf | 4 ++--
Platform/Intel/WhiskeylakeOpenBoardPkg/UpXtreme/Include/Fdf/FlashMapInclude.fdf | 18 +++++++++---------
Platform/Intel/WhitleyOpenBoardPkg/Platform/Dxe/S3NvramSave/S3NvramSave.inf | 4 +++-
Platform/Intel/WhitleyOpenBoardPkg/PlatformPkg.dsc | 1 +
Silicon/Intel/WhitleySiliconPkg/Library/FspWrapperPlatformLib/FspWrapperPlatformLib.inf | 3 ++-
32 files changed, 344 insertions(+), 368 deletions(-)

--
2.28.0.windows.1


Re: [PATCH V2 13/28] UefiCpuPkg: Enable Tdx support in MpInitLib

Gerd Hoffmann
 

On Thu, Oct 14, 2021 at 12:27:13AM +0000, Xu, Min M wrote:
On October 12, 2021 6:32 PM, Gerd Hoffman wrote:
Hi,

+ do {
+ AsmCpuid (0, &LargestEax, &Ebx, &Ecx, &Edx);
Again: this should use PCD.
ConfidentialComputing PCD is set in PlatformPei. So any check of this PCD should be after PlatformPei.
Can we move that to the SEC phase?

MpInitLib will be included in CpuMpPei. So if PCD is checked in MpInitLib, then we must assume CpuMpPei is called after PlatformPei.
In current OVMF, CpuMpPei is called after PlatforPei. But I am not sure if it is always the case. Can we have such assumption?
Based on above consideration, CPUID is used to probe if it is Tdx guest.
Not sure. There are no explicit depex dependencies, so I suspect the
initialization order could change.

take care,
Gerd


Re: [PATCH] OvmfPkg/BhyveBhfPkg: install bhyve's ACPI tables

Peter Grehan
 

I've requested in the past that you do this so I'll request again: please
discuss these changes on the freebsd-virtualization list before sending
patches outside of the project.
I'd suggest to add the list to the bhyve section of Maintainers.txt
then.
Yep, that's fair enough.

later,

Peter.


Re: [PATCH] OvmfPkg/BhyveBhfPkg: install bhyve's ACPI tables

Gerd Hoffmann
 

Hi,

I've requested in the past that you do this so I'll request again: please
discuss these changes on the freebsd-virtualization list before sending
patches outside of the project.
I'd suggest to add the list to the bhyve section of Maintainers.txt
then.

take care,
Gerd


Re: [PATCH] OvmfPkg/BhyveBhfPkg: install bhyve's ACPI tables

Peter Grehan
 

It's much easier to create configuration dependend ACPI tables for > bhyve than for OVMF. For this reason, don't use the statically>
created ACPI tables provided by OVMF. Instead use the dynamically> created ACPI tables of bhyve. If bhyve provides no ACPI tables or> we are unable to detect those, fall back to OVMF tables.
This looks fine though bhyve will need to generate MCFG to get to full parity.

I've requested in the past that you do this so I'll request again: please discuss these changes on the freebsd-virtualization list before sending patches outside of the project.

Acked-by: Peter Grehan <grehan@freebsd.org>

later,

Peter.


Re: [PATCH V2 0/3] Introduce TdProtocol into EDK2

Min Xu
 

On October 12, 2021 11:27 PM, Sami Mujawar wrote:
Hi Min,

Thank you for this patch.

I think it would greatly help if the EFI_TD_PROTOCOL is changed to something
more architecture neutral. As I understand, this patch series is removing the
dependency on TPM for measurement and is instead providing a lightweight
interface for extending measurements for Confidential Compute Architecture
(CCA) guests.

Considering this, it would be good to generalise EFI_TD_PROTOCOL as a
Confidential Compute Architecture Measurement (CCAM) protocol.
In fact, your v2 series demonstrates this need with the introduction of
MEASURE_BOOT_PROTOCOLS in "[PATCH V2 2/3] SecurityPkg: Support
TdProtocol in DxeTpm2MeasureBootLib
[https://edk2.groups.io/g/devel/message/81651]".

As it stands, I feel most of the code can be reused/common. Some interfaces
may need to use an architecture specific library, and some configuration
options would need to be defined using PCDs.

Kindly let me know your thoughts.
Thanks for your comments. Let me first discuss your feedback with our architecture. We will reply to your proposal a bit later.

Thanks.
Min


Re: [PATCH V2 06/28] MdePkg: Update BaseIoLibIntrinsicSev to support Tdx

Gerd Hoffmann
 

Hi,

Calling CPUID should not be needed, we have a new fancy
ConfidentialComputing PCD for that now.
The gUefiCpuPkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr is defined in UefiCpuPkg. While BaseIoLibIntrinsicSev is in MdePkg.
If the ConfidentialComputing PCD is used, then UefiCpuPkg has to be included in BaseIoLibIntrinsicSev.inf.
I check all the *.inf under MdePkg but no one *.inf include UefiCpuPkg.
I am not sure if UefiCpuPkg can be included in BaseIoLibIntrinsicSev.inf.
Hmm, I guess we should move the pcd then so it cam be used more widely.
Confidential computing has an impact beyond just cpu, it's also memory,
io and more.

Maybe that's something to cleanup for amd (Brijesh?) beforehand, so the
structure is there already and the tdx patches just need to add the "case tdx:"
bits.
Tdx patches can first use above structure. AMD can update it later. Either way is ok.
That'll work too, I don't care much about the ordering.

take care,
Gerd


Re: [PATCH V2 05/28] MdePkg: Add TdxLib to wrap Tdx operations

Gerd Hoffmann
 

Hi,

+UINT8 *mExtendBufferAddress = NULL;
+TDX_EXTEND_BUFFER mExtendBuffer;
+
+/**
+ TD.RTMR.EXTEND requires 64B-aligned guest physical address of
+ 48B-extension data. In runtime we walk thru the Buffer to find
+ out a 64B-aligned start address.
Can't you just use __attribute__((aligned(64))) for that?
In the PoC of TDVF I had thought about it. But at last I gave up such solution. The reasons are:
1) OVMF/TDVF supports both GCC and VS2019 tool chain. __attribute__((aligned(64))) is for GCC. Its counterpart of VS2019 Tool chain is __declspec(align(x)).
2) There is the limitation of /ALIGN:32 in the build scripts which means aligned 64 exceeds the /ALIGN 32, unless /ALIGN is updated to 64.
That's why the current solution is used.
MdePkg/Include/Base.h has a bunch of ALIGN_* macros to do the math for
you, which should simplify this alot. I'd suggest to also drop the
mExtendBufferAddress and the function calculating it. Just use the
macro instead when needed.

take care,
Gerd


Re: [PATCH V2 28/28] OvmfPkg: Add LocalApicTimerDxe

Min Xu
 

On October 12, 2021 9:02 PM, Gerd Hoffmann wrote:
On Tue, Oct 05, 2021 at 11:39:39AM +0800, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429

TDX guest supports LocalApicTimer. But in current OvmfPkg the
supported timer is 8254TimerDxe. So
gUefiOvmfPkgTokenSpaceGuid.PcdTimerSelector
is introduced to select the running Timer. The Timer driver will check
the TimerSelector in its entry point. The default Timer is 8254.
Hmm.

We already have a local apic timer implementation (XenTimerDxe). Works fine
with kvm, microvm already uses that. See commit 76602f45dcd9
("OvmfPkg/Microvm: use XenTimerDxe (lapic timer)").

So, first I'd suggest to just use that (maybe rename the thing to avoid confusion
as it isn't really Xen specific).
Thanks for reminder. Let me first do some more investigation about the XenTimerDxe. It will be better to use an existing lapic timer than introducing a new one.

Next question is whenever there is a need for a runtime switch. I doubt it is
possible to create a virtual machine without lapic, so switching ovmf from 8254
(aka pit) to lapic unconditionally should work fine.
Quick smoke test (patch below) shows no obvious problems.
Let me do some more investigation.
Thanks.
Min


Re: [PATCH] OvmfPkg/Bhyve: Use QemuFwCfg over BhyveFwCtl

Gerd Hoffmann
 

On Wed, Oct 13, 2021 at 11:26:23AM +0200, Corvin Köhne wrote:
From: Corvin Köhne <CorvinK@beckhoff.com>

QemuFwCfg is more powerful and has more use cases than BhyveFwCtl. Try
to use QemuFwCfg in first place. If that fails, fall back to
BhyveFwCtl.
Does bhyve implement the qemu fwcfg interface?

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

take care,
Gerd


Re: [PATCH] OvmfPkg/BhyveBhfPkg: install bhyve's ACPI tables

Gerd Hoffmann
 

Hi,

+#define BHYVE_ACPI_PHYSICAL_ADDRESS ((UINTN)0x000F2400)
+#define BHYVE_BIOS_PHYSICAL_END ((UINTN)0x00100000)
+ //
+ // Detect the RSDP
+ //
+ for (RsdpAddress = BHYVE_ACPI_PHYSICAL_ADDRESS;
+ RsdpAddress < BHYVE_BIOS_PHYSICAL_END;
+ RsdpAddress += 0x10) {
+ Rsdp = NUMERIC_VALUE_AS_POINTER (
+ EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER,
+ RsdpAddress
+ );
+ if (Rsdp->Signature != EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER_SIGNATURE) {
+ continue;
+ }
So bhyve copies the tables to guest memory and ovmf searches for them,
correct?

The commit message should (briefly) describe how the tables are passed
from the host to the guest.

The code looks sane to me, so with a more verbose commit message:
Acked-by: Gerd Hoffmann <kraxel@redhat.com>

take care,
Gerd


Re: [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Rebecca Cran
 

Pushed as 2ebe49ccd34cfd59bac32216b71334d371b3fa44.

Sorry, I forgot to add my "Acked-by" to the commit before pushing.


Acked-by: Rebecca Cran <rebecca@bsdio.com>

On 10/13/21 10:48 PM, Jayaprakash Nevara wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3638

This change is to add IA32 support into py3 EFI package
creation batch script. Enhanced the script take Architecture
as an additional parameter. With this the script can be used
to create deployable Python 3.6.8 EFI package from X64 and IA32 builds
as required by the user

Cc: Rebecca Cran <rebecca@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
---
.../Python-3.6.8/create_python368_pkg.bat | 62 ++++++++++++-------
1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
index 6bbdbd9..b48f83e 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
+++ b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
@@ -2,47 +2,63 @@
set TOOL_CHAIN_TAG=%1
set TARGET=%2
-set OUT_FOLDER=%3
+set ARCH=%3
+set OUT_FOLDER=%4
if "%TOOL_CHAIN_TAG%"=="" goto usage
if "%TARGET%"=="" goto usage
+if "%ARCH%"=="" goto usage
if "%OUT_FOLDER%"=="" goto usage
goto continue
:usage
echo.
+echo Batch Script to create Python EFI Package.
echo.
+echo Invalid command line arguments passed, please see the below usage instructions
echo.
-echo Creates Python EFI Package.
-echo.
-echo "Usage: %0 <ToolChain> <Target> <OutFolder>"
-echo.
-echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
-echo Target = one of RELEASE, DEBUG
-echo OutFolder = Target folder where package needs to create
-echo.
+echo "Usage: %0 <ToolChain> <Target> <Architecture> <OutFolder>"
echo.
+echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
+echo Target = one of RELEASE, DEBUG
+echo Architecture = one of IA32, X64
+echo OutFolder = Output directory for creating the package
echo.
goto :eof
:continue
cd ..\..\..\..\
-IF NOT EXIST Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi goto error
-mkdir %OUT_FOLDER%\EFI\Tools
-xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y
-mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
-mkdir %OUT_FOLDER%\EFI\StdLib\etc
-xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
-xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
-goto all_done
-
-:error
-echo Failed to Create Python 3.6.8 Package, Python368.efi is not available on build location Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\
+if not exist Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi (
+ goto error
+)
+if not exist %OUT_FOLDER%\EFI\Tools (
+ mkdir %OUT_FOLDER%\EFI\Tools
+)
+xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y
-:all_done
-exit /b %ec%
-
+if not exist %OUT_FOLDER%\EFI\StdLib\lib\python36.8 (
+ mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
+)
+if not exist %OUT_FOLDER%\EFI\StdLib\etc (
+ mkdir %OUT_FOLDER%\EFI\StdLib\etc
+)
+xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
+xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
+echo.
+if not x%OUT_FOLDER::=%==x%OUT_FOLDER% (
+ echo Python EFI package available at %OUT_FOLDER%
+) else (
+ echo Python EFI package available at %CD%\%OUT_FOLDER%
+)
+goto all_done
+:error
+echo Failed to Create Python EFI Package
+echo Python368.efi is not available at Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\
+echo Follow the instructions in Py368ReadMe.txt to build Python interpreter
+echo Then use this script to create a Python EFI package
+:all_done
+exit /b %ERRORLEVEL%


Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal

Ashish Singhal
 

Hello Jeff,

Thanks for the reference you provided of the change made by you. Leveraging a similar change resolves the problem 90 percent for me as I do not get the ISR interrupted for the most part because of another timer interrupt. However, even with your change, during the ISR there are few instructions during which IRQ is enabled and we may be interrupted by a timer interrupt during that time unless I am understanding it wrong.

Thanks
Ashish


From: fanjianfeng@... <fanjianfeng@...>
Sent: Tuesday, October 12, 2021 8:32 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Ashish Singhal <ashishsingha@...>; Marc Zyngier <maz@...>; Ard Biesheuvel <ardb@...>; Shanker Donthineni <sdonthineni@...>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Leif Lindholm <leif@...>
Subject: Re: Re: [edk2-devel] [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
 
External email: Use caution opening links or attachments

OVMF did a similare change on Time Driver, please refer to https://github.com/tianocore/edk2/commit/239b50a863704f7960525799eda82de061c7c458 

I do not think this will be apply for ArmPkg/TimerDxe. 

If one real issue happened on platform, it seems that interrupt was reenabled by reigstered timer event functions.

Jeff
 
Date: 2021-10-12 23:38
Subject: Re: [edk2-devel] [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
+ Shaker

Get Outlook for iOS

From: Ashish Singhal <ashishsingha@...>
Sent: Tuesday, October 12, 2021 8:56:58 AM
To: Marc Zyngier <maz@...>; Ard Biesheuvel <ardb@...>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@...>; Ard Biesheuvel <ardb+tianocore@...>
Subject: Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
 
Marc,

In the document ARM062-1010708621-30 (AArch64 Programmer's Guides Generic Timer), towards the end of section 3.4 it says: "When writing an interrupt handler for the timers, it is important that software clears the interrupt before deactivating the interrupt in the GIC. Otherwise, the GIC will re-signal the same interrupt again."

My change was in accordance with this. We only clear the interrupt when we update the compare value but were signaling EOI before that going against the guidance in the document.

Thanks
Ashish

From: Marc Zyngier <maz@...>
Sent: Tuesday, October 12, 2021 2:57 AM
To: Ard Biesheuvel <ardb@...>; Ashish Singhal <ashishsingha@...>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@...>; Ard Biesheuvel <ardb+tianocore@...>
Subject: Re: [PATCH v2] ArmPkg/TimerDxe: Delay End Of Interrupt Signal
 
External email: Use caution opening links or attachments


On Mon, 11 Oct 2021 23:24:38 +0100,
Ard Biesheuvel <ardb@...> wrote:
>
> (+ Marc)
>
> On Mon, 11 Oct 2021 at 23:40, Ashish Singhal <ashishsingha@...> wrote:
> >
> > In an interrupt handler for the timers, it is important that
> > software clears the interrupt before deactivating the interrupt
> > in the GIC. Otherwise the GIC will re-signal the same interrupt
> > again.
> >
> > Signed-off-by: Ashish Singhal <ashishsingha@...>
>
> Please don't spam us with almost identical versions of the same patch
> without even documenting what the difference is.
>
>
> > ---
> >  ArmPkg/Drivers/TimerDxe/TimerDxe.c | 9 +++++----
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> > index 0370620fae..46e5bbf287 100644
> > --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> > +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c
> > @@ -300,10 +300,6 @@ TimerInterruptHandler (
> >    //
> >    OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL);
> >
> > -  // Signal end of interrupt early to help avoid losing subsequent ticks
> > -  // from long duration handlers
> > -  gInterrupt->EndOfInterrupt (gInterrupt, Source);
> > -
> >    // Check if the timer interrupt is active
> >    if ((ArmGenericTimerGetTimerCtrlReg () ) & ARM_ARCH_TIMER_ISTATUS) {
> >
> > @@ -335,6 +331,11 @@ TimerInterruptHandler (
> >      ArmInstructionSynchronizationBarrier ();
> >    }
> >
> > +  // In an interrupt handler for the timers, it is important that software clears the interrupt
> > +  // before deactivating the interrupt in the GIC. Otherwise the GIC will re-signal the same
> > +  // interrupt again.
> > +  gInterrupt->EndOfInterrupt (gInterrupt, Source);
> > +
> >    gBS->RestoreTPL (OriginalTPL);
> >  }
> >

This isn't a requirement if you haven't re-enabled interrupts in
PSTATE (and the TPL being raised seems to indicate that interrupts are
actively masked here).

The timer is a level interrupt, and lowering the level takes time. If
your GIC implementation is good, it will notice that the lowering of
the level quickly, before you can reach the point where you re-enable
interrupts. If it is slow (or badly emulated if this is actually done
in a hypervisor), you'll get a spurious interrupt.

In any case, moving the EOI around doesn't make things any better. You
are just moving the goal post, without additional guarantees that the
level has been retired.

As a consequence, I don't think this patch makes much sense.

        M.

--
Without deviation from the norm, progress is not possible.


[edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Jayaprakash, N
 

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

This change is to add IA32 support into py3 EFI package
creation batch script. Enhanced the script take Architecture
as an additional parameter. With this the script can be used
to create deployable Python 3.6.8 EFI package from X64 and IA32 builds
as required by the user

Cc: Rebecca Cran <rebecca@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com>
---
.../Python-3.6.8/create_python368_pkg.bat | 62 ++++++++++++-------
1 file changed, 39 insertions(+), 23 deletions(-)

diff --git a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
index 6bbdbd9..b48f83e 100644
--- a/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
+++ b/AppPkg/Applications/Python/Python-3.6.8/create_python368_pkg.bat
@@ -2,47 +2,63 @@

set TOOL_CHAIN_TAG=%1
set TARGET=%2
-set OUT_FOLDER=%3
+set ARCH=%3
+set OUT_FOLDER=%4
if "%TOOL_CHAIN_TAG%"=="" goto usage
if "%TARGET%"=="" goto usage
+if "%ARCH%"=="" goto usage
if "%OUT_FOLDER%"=="" goto usage
goto continue

:usage
echo.
+echo Batch Script to create Python EFI Package.
echo.
+echo Invalid command line arguments passed, please see the below usage instructions
echo.
-echo Creates Python EFI Package.
-echo.
-echo "Usage: %0 <ToolChain> <Target> <OutFolder>"
-echo.
-echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
-echo Target = one of RELEASE, DEBUG
-echo OutFolder = Target folder where package needs to create
-echo.
+echo "Usage: %0 <ToolChain> <Target> <Architecture> <OutFolder>"
echo.
+echo ToolChain = one of VS2013x86, VS2015x86, VS2017, VS2019
+echo Target = one of RELEASE, DEBUG
+echo Architecture = one of IA32, X64
+echo OutFolder = Output directory for creating the package
echo.

goto :eof

:continue
cd ..\..\..\..\
-IF NOT EXIST Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi goto error
-mkdir %OUT_FOLDER%\EFI\Tools
-xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y
-mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
-mkdir %OUT_FOLDER%\EFI\StdLib\etc
-xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
-xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
-goto all_done
-
-:error
-echo Failed to Create Python 3.6.8 Package, Python368.efi is not available on build location Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\X64\
+if not exist Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi (
+ goto error
+)

+if not exist %OUT_FOLDER%\EFI\Tools (
+ mkdir %OUT_FOLDER%\EFI\Tools
+)
+xcopy Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\Python368.efi %OUT_FOLDER%\EFI\Tools\ /y

-:all_done
-exit /b %ec%
-
+if not exist %OUT_FOLDER%\EFI\StdLib\lib\python36.8 (
+ mkdir %OUT_FOLDER%\EFI\StdLib\lib\python36.8
+)
+if not exist %OUT_FOLDER%\EFI\StdLib\etc (
+ mkdir %OUT_FOLDER%\EFI\StdLib\etc
+)
+xcopy AppPkg\Applications\Python\Python-3.6.8\Lib\* %OUT_FOLDER%\EFI\StdLib\lib\python36.8\ /Y /S /I
+xcopy StdLib\Efi\StdLib\etc\* %OUT_FOLDER%\EFI\StdLib\etc\ /Y /S /I
+echo.

+if not x%OUT_FOLDER::=%==x%OUT_FOLDER% (
+ echo Python EFI package available at %OUT_FOLDER%
+) else (
+ echo Python EFI package available at %CD%\%OUT_FOLDER%
+)
+goto all_done

+:error
+echo Failed to Create Python EFI Package
+echo Python368.efi is not available at Build\AppPkg\%TARGET%_%TOOL_CHAIN_TAG%\%ARCH%\
+echo Follow the instructions in Py368ReadMe.txt to build Python interpreter
+echo Then use this script to create a Python EFI package

+:all_done
+exit /b %ERRORLEVEL%
--
2.32.0.windows.2


[edk2-libc Patch v2 0/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Jayaprakash, N
 

Jayaprakash Nevara (1):
AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3
package creation batch script

.../Python-3.6.8/create_python368_pkg.bat | 62 ++++++++++++-------
1 file changed, 39 insertions(+), 23 deletions(-)


TianoCore Community Meeting Minutes - October 2021

Soumya Guptha
 

TianoCore Community Meeting

October 7, 2021

 

Events

UEFI Plugfest:

No new updates since last month.

Past AR review from September –

o       Community Action: provide input to Dick Wilkins Dick_Wilkins@...<mailto:Dick_Wilkins@...> on these questions -

*       Is your company interested in sponsoring?

*       Are you willing to pay for the conference?

 

Community Response - Community thinks that it’s useful to have a face to face event.

Paying for the conference maybe fine for those that need to pay for hotel and flight.

Aligning with UEFI plugfest is beneficial for the TianoCore design/technical roadmap discussions and for the TianoCore community to come together. 

 

 

Stable Tag updates:

Stable tag 202111 is collecting features.

Soft freeze on Nov 8th.

Community Action: please send your feature requests ahead of time to Liming.

 

 

Stewards Download:

  1. Inclusive language: Stewards discussed TianoCore to follow inclusive language and layout the guidelines. Community manager will drive further conversations with stewards and community in the upcoming weeks.
  2. Discussion around Uncrustify tool.  

Reduces code review time and provides consistent code base when having to recode so you don’t see mixed styles in diff parts of the tree.

Community action – review the code style and provide feedback if you like it or not and what changes would you like to see.

EDK2 C coding style is not identical to Uncrustify. Should we change EDK2 style?

Please follow the discussion here - https://edk2.groups.io/g/devel/topic/progress_on_getting/84932137?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,84932137,previd=1633659901428425771,nextid=1633620778663080075&previd=1633659901428425771&nextid=1633620778663080075

  1. Felix had sent RFC on static analysis on EDK2 but no feedback from the community. Community to send feedback to Felix.

Please follow the discussion here - https://edk2.groups.io/g/rfc/topic/rfc_static_analysis_in_edk2/85318202?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,85318202,previd=1633604560724866953,nextid=1619704994055247213&previd=1633604560724866953&nextid=1619704994055247213

  1. Spam on Bugzilla (Mike Kinney) – we need to change the configuration of TianoCore Bugzilla. We have been handling so far by disabling those spammers and these emails remain in our mailing list.

a.       Mike has handled it by changing the permissions disabling for people to create accounts to avoid the spam. 

Open: What process should we follow?

AR: Mike and Liming will follow up in the email on the TianoCore Bugzilla account creation process and post it. wiki pages need to be updated as well.

 

Opens:

  1. Update from Soumya Guptha: Lynn Teng from Intel will be acting as Community manager and picking up community management responsibilities starting this month. Please extend your support to Lynn Teng. Soumya Guptha will be stepping away from the Community management during this time.
  2. Update from Nate Desimone –Intel® Xeon Scalable Processors, Ice Lake and Cooper Lake min platform has been released.
  3. OCP Global Summit: Scheduled on Nov 9-10, 2021. This year is a hybrid model – both in-person and online, held in San Jose, California, US.

OCP summit schedule here - https://2021ocpglobal.fnvirtual.app/a/schedule

Check out these sessions –

1)      Wed, November 10, 2:15pm - 2:30pm | SJCC - Concourse Level - 210BF FSP and MinPlatform for Sapphire Rapids Intel® Xeon® Scalable Processors by Nate Desimone and Isaac Oram (Intel).

2)      Wed, November 10, 4:15pm - 4:30pm | SJCC - Concourse Level - 210BF Enabling Runtime RAS on Xeon OCP Platforms Using Intel FSP and Coreboot by Ruth Li

 

 

Regards,

Soumya Guptha

TianoCore Community Manager

 


Re: [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Rebecca Cran
 

Sorry for the delay.

I can't see the copy of the patch you sent out: could you send it again, this time marking it as v2 please? Since it's sent out via email there's no problem with duplicates.


--

Rebecca Cran

On 10/3/21 6:35 PM, Jayaprakash, N wrote:
Hi Rebecca / Mike,

Could you look into this?

Regards,
JP

-----Original Message-----
From: Jayaprakash, N
Sent: 24 September 2021 13:34
To: devel@edk2.groups.io; rebecca@nuviainc.com
Cc: Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Apologies, I have already shared the patch.
I will take this input for future patches.

Regards,
JP

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
Sent: 24 September 2021 00:02
To: Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

Sorry I don't see it. Could you re-send it with "PATCH v2" in the subject line (by passing -v2 to "git format-patch") if you didn't already please?


--
Rebecca Cran


On 9/22/21 10:22 PM, Jayaprakash, N wrote:
Thank you Rebecca.
I have submitted the updated patch for review.

Regards,
JP

-----Original Message-----
From: Rebecca Cran <rebecca@nuviainc.com>
Sent: 23 September 2021 06:59
To: Jayaprakash, N <n.jayaprakash@intel.com>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] AppPkg/Applications/Python/Python3.6.8: add IA32 support for py3 package creation batch script

You should be able to use the same branch.



[PATCH v1 1/1] StandaloneMmPkg: To support CLANGPDB build

Jiyang Yang
 

the flag "-fpie" is passed for all builds with a GCC family toolchain,
including CLANGPDB, but CLANGPDB does not support this flag, it will
report "clang: error: unsupported option '-fpie' for target
'x86_64-unknown-windows-gnu'". So we add the CLANGPDB option "-fno-pie"
later to overwrite it.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Cc: Marvin Häuser <mhaeuser@posteo.de>
Cc: Steven Shi <steven.shi@intel.com>
Signed-off-by: Jiyang Yang <jiyangx.yang@intel.com>
---
StandaloneMmPkg/Core/StandaloneMmCore.inf | 2 ++
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 1 +
2 files changed, 3 insertions(+)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index 56042b7b39f4..3213142523f4 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -79,3 +79,5 @@
[BuildOptions]
GCC:*_*_*_CC_FLAGS = -fpie
GCC:*_*_*_DLINK_FLAGS = -Wl,-z,text,-Bsymbolic,-pie
+ CLANGPDB:*_*_*_CC_FLAGS = -fno-pie
+ CLANGPDB:*_*_*_DLINK_FLAGS =
diff --git a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
index 1762586cfa02..ef69e07d2c07 100644
--- a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
+++ b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
@@ -56,3 +56,4 @@

[BuildOptions]
GCC:*_*_*_CC_FLAGS = -fpie
+ CLANGPDB:*_*_*_CC_FLAGS = -fno-pie
--
2.26.2.windows.1


[PATCH v1 0/1] StandaloneMmPkg: To support CLANGPDB build

Jiyang Yang
 

the flag "-fpie" is passed for all builds with a GCC family toolchain,
including CLANGPDB, but CLANGPDB does not support this flag, it will
report "clang: error: unsupported option '-fpie' for target
'x86_64-unknown-windows-gnu'". So we add the CLANGPDB option "-fno-pie"
later to overwrite it.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Cc: Marvin Häuser <mhaeuser@posteo.de>
Cc: Steven Shi <steven.shi@intel.com>
Signed-off-by: Jiyang Yang <jiyangx.yang@intel.com>

Jiyang Yang (1):
StandaloneMmPkg/StandaloneMmCoreEntryPoint: To support CLANGPDB build

StandaloneMmPkg/Core/StandaloneMmCore.inf | 2 ++
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 1 +
2 files changed, 3 insertions(+)


--
2.26.2.windows.1

3761 - 3780 of 85635