[edk2-devel] [PATCH 6/6] UefiCpuPkg: Avoid assuming only one smmbasehob

[duntan]

Modify the gSmmBaseHobGuid consumption code to
remove the asuumption that there is only one
gSmmBaseHobGuid. If the CPU number is big enough,
there will be more than one SmmBaseHob in the
HOB list.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 142 
++
 1 file changed, 130 insertions(+), 12 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index d8d488b253..36fa5e779a 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -586,6 +586,130 @@ SmmReadyToLockEventNotify (
   return EFI_SUCCESS;
 }
 
+/**
+  Function to compare 2 SMM_BASE_HOB_DATA pointer based on ProcessorIndex.
+
+  @param[in] Buffer1pointer to SMM_BASE_HOB_DATA poiner to compare
+  @param[in] Buffer2pointer to second SMM_BASE_HOB_DATA pointer to 
compare
+
+  @retval 0 Buffer1 equal to Buffer2
+  @retval <0Buffer1 is less than Buffer2
+  @retval >0Buffer1 is greater than Buffer2
+**/
+INTN
+EFIAPI
+SmBaseHobCompare (
+  IN  CONST VOID  *Buffer1,
+  IN  CONST VOID  *Buffer2
+  )
+{
+  if ((*(SMM_BASE_HOB_DATA **)Buffer1)->ProcessorIndex > (*(SMM_BASE_HOB_DATA 
**)Buffer2)->ProcessorIndex) {
+return 1;
+  } else if ((*(SMM_BASE_HOB_DATA **)Buffer1)->ProcessorIndex < 
(*(SMM_BASE_HOB_DATA **)Buffer2)->ProcessorIndex) {
+return -1;
+  }
+
+  return 0;
+}
+
+/**
+  Extract SmBase for all CPU from SmmBase HOB.
+
+  @param[in]  FirstSmmBaseGuidHobPointer to First SmmBaseGuidHob.
+  @param[in]  MaxNumberOfCpusMax NumberOfCpus.
+  @param[out] SmBaseBufferPointerPointer to SmBase buffer pointer.
+
+  @retval EFI_SUCCESSSuccessfully extract SmBase for all CPU 
from SmmBase HOB.
+  @retval RETURN_BUFFER_TOO_SMALLFail to allocate memory.
+**/
+EFI_STATUS
+GetSmBaseFromSmmBaseHob (
+  IN  EFI_HOB_GUID_TYPE  *FirstSmmBaseGuidHob,
+  IN  UINTN  MaxNumberOfCpus,
+  OUT UINTN  **SmBaseBufferPointer
+  )
+{
+  UINTN  HobCount;
+  EFI_HOB_GUID_TYPE  *GuidHob;
+  SMM_BASE_HOB_DATA  *SmmBaseHobData;
+  UINTN  NumberOfProcessors;
+  SMM_BASE_HOB_DATA  **SmBaseHobPointerBuffer;
+  UINTN  *SmBaseBuffer;
+  UINTN  Index;
+  UINTN  SortBuffer;
+  UINTN  ProcessorIndex;
+  UINT64 PrevProcessorIndex;
+
+  SmmBaseHobData = NULL;
+  Index  = 0;
+  ProcessorIndex = 0;
+  PrevProcessorIndex = 0;
+  HobCount   = 0;
+  NumberOfProcessors = 0;
+  GuidHob= FirstSmmBaseGuidHob;
+
+  while (GuidHob != NULL) {
+HobCount++;
+SmmBaseHobData  = GET_GUID_HOB_DATA (GuidHob);
+NumberOfProcessors += SmmBaseHobData->NumberOfProcessors;
+GuidHob = GetNextGuidHob (, GET_NEXT_HOB 
(GuidHob));
+  }
+
+  ASSERT (NumberOfProcessors == MaxNumberOfCpus);
+
+  SmBaseHobPointerBuffer = AllocatePool (sizeof (SMM_BASE_HOB_DATA *) * 
HobCount);
+  ASSERT (SmBaseHobPointerBuffer != NULL);
+  if (SmBaseHobPointerBuffer == NULL) {
+return EFI_BUFFER_TOO_SMALL;
+  }
+
+  //
+  // Record each SmmBaseHob pointer in the SmBaseHobPointerBuffer.
+  //
+  GuidHob = FirstSmmBaseGuidHob;
+  ASSERT (GuidHob != NULL);
+  while (Index < HobCount) {
+SmBaseHobPointerBuffer[Index++] = GET_GUID_HOB_DATA (GuidHob);
+GuidHob = GetNextGuidHob (, 
GET_NEXT_HOB (GuidHob));
+  }
+
+  SmBaseBuffer = (UINTN *)AllocatePool (sizeof (UINTN) * (MaxNumberOfCpus));
+  ASSERT (SmBaseBuffer != NULL);
+  if (SmBaseBuffer == NULL) {
+return EFI_BUFFER_TOO_SMALL;
+  }
+
+  QuickSort (SmBaseHobPointerBuffer, HobCount, sizeof (SMM_BASE_HOB_DATA *), 
(BASE_SORT_COMPARE)SmBaseHobCompare, );
+  for (Index = 0; Index < HobCount; Index++) {
+//
+// Make sure no overlap and no gap in the CPU range covered by each HOB
+//
+ASSERT (SmBaseHobPointerBuffer[Index]->ProcessorIndex == 
PrevProcessorIndex);
+
+//
+// Cache each SmBase in order.
+//
+if (sizeof (UINTN) == sizeof (UINT64)) {
+  CopyMem (
+SmBaseBuffer + PrevProcessorIndex,
+[Index]->SmBase,
+sizeof (UINT64) * SmBaseHobPointerBuffer[Index]->NumberOfProcessors
+);
+} else {
+  for (ProcessorIndex = 0; ProcessorIndex < 
SmBaseHobPointerBuffer[Index]->NumberOfProcessors; ProcessorIndex++) {
+SmBaseBuffer[PrevProcessorIndex + ProcessorIndex] = 
(UINTN)SmBaseHobPointerBuffer[Index]->SmBase[ProcessorIndex];
+  }
+}
+
+PrevProcessorIndex += SmBaseHobPointerBuffer[Index]->NumberOfProcessors;
+  }
+
+  FreePool (SmBaseHobPointerBuffer);
+
+  *SmBaseBufferPointer = SmBaseBuffer;
+  return EFI_SUCCESS;
+}
+
 /**
   

[edk2-devel] [PATCH 5/6] UefiCpuPkg: Cache core type in MpInfo2 HOB

[duntan]

Cache core type in MpInfo2 HOB by CpuMpPei module.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.c | 59 
+--
 UefiCpuPkg/CpuMpPei/CpuMpPei.h |  2 ++
 2 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
index 4d80d52799..8f6863f4d9 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
@@ -541,6 +541,30 @@ InitializeMpExceptionStackSwitchHandlers (
   FreePages (SwitchStackData, EFI_SIZE_TO_PAGES (NumberOfProcessors * sizeof 
(EXCEPTION_STACK_SWITCH_CONTEXT)));
 }
 
+/**
+  Get CPU core type.
+
+  @param[in, out] Buffer  Argument of the procedure.
+**/
+VOID
+EFIAPI
+GetProcessorCoreType (
+  IN OUT VOID  *Buffer
+  )
+{
+  EFI_STATUS   Status;
+  UINT8*CoreType;
+  CPUID_NATIVE_MODEL_ID_AND_CORE_TYPE_EAX  NativeModelIdAndCoreTypeEax;
+  UINTNProcessorIndex;
+
+  Status = MpInitLibWhoAmI ();
+  ASSERT_EFI_ERROR (Status);
+
+  CoreType = (UINT8 *)Buffer;
+  AsmCpuidEx (CPUID_HYBRID_INFORMATION, CPUID_HYBRID_INFORMATION_MAIN_LEAF, 
, NULL, NULL, NULL);
+  CoreType[ProcessorIndex] = (UINT8)NativeModelIdAndCoreTypeEax.Bits.CoreType;
+}
+
 /**
   Create gMpInformationHobGuid2.
 **/
@@ -558,13 +582,36 @@ BuildMpInformationHob (
   MP_INFORMATION2_HOB_DATA  *MpInformation2HobData;
   MP_INFORMATION2_ENTRY *MpInformation2Entry;
   UINTN Index;
+  UINT8 *CoreType;
+  UINT32CpuidMaxInput;
+  UINTN Pages;
 
   ProcessorIndex= 0;
   MpInformation2HobData = NULL;
   MpInformation2Entry   = NULL;
+  CoreType  = NULL;
+  Pages = 0;
 
   Status = MpInitLibGetNumberOfProcessors (, 
);
   ASSERT_EFI_ERROR (Status);
+
+  //
+  // Get Processors CoreType
+  //
+  AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
+  if (CpuidMaxInput >= CPUID_HYBRID_INFORMATION) {
+Pages= EFI_SIZE_TO_PAGES (sizeof (UINT8) * NumberOfProcessors);
+CoreType = AllocatePages (Pages);
+ASSERT (CoreType != NULL);
+
+Status = MpInitLibStartupAllCPUs (
+   GetProcessorCoreType,
+   0,
+   (VOID *)CoreType
+   );
+ASSERT_EFI_ERROR (Status);
+  }
+
   MaxProcessorsPerHob = ((MAX_UINT16 & 7) - sizeof (EFI_HOB_GUID_TYPE) - 
sizeof (MP_INFORMATION2_HOB_DATA)) / sizeof (MP_INFORMATION2_ENTRY);
   NumberOfProcessorsInHob = MaxProcessorsPerHob;
 
@@ -597,12 +644,16 @@ BuildMpInformationHob (
   NULL
   );
   ASSERT_EFI_ERROR (Status);
+
+  MpInformation2Entry->CoreType = (CoreType != NULL) ? CoreType[Index + 
ProcessorIndex] : 0;
+
   DEBUG ((
 DEBUG_INFO,
-"ProcessorIndex = %x, ProcessorId = %lx, StatusFlag = %x\n",
+"ProcessorIndex = %x, ProcessorId = %lx, StatusFlag = %x, CoreType = 
%x\n",
 Index + ProcessorIndex,
 MpInformation2Entry->ProcessorInfo.ProcessorId,
-MpInformation2Entry->ProcessorInfo.StatusFlag
+MpInformation2Entry->ProcessorInfo.StatusFlag,
+MpInformation2Entry->CoreType
 ));
   DEBUG ((
 DEBUG_INFO,
@@ -625,6 +676,10 @@ BuildMpInformationHob (
 
 ProcessorIndex += NumberOfProcessorsInHob;
   }
+
+  if (CoreType != NULL) {
+FreePages (CoreType, Pages);
+  }
 }
 
 /**
diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
index a40fd2c077..e7d07ffd64 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
@@ -32,6 +32,8 @@
 
 #include 
 
+#include 
+
 extern EFI_PEI_PPI_DESCRIPTOR  mPeiCpuMpPpiDesc;
 
 /**
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 4/6] UefiCpuPkg: Add a new field in MpInfo2 HOB

[duntan]

Add new field CoreType in gMpInformationHobGuid2

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/Include/Guid/MpInformation2.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/UefiCpuPkg/Include/Guid/MpInformation2.h 
b/UefiCpuPkg/Include/Guid/MpInformation2.h
index 4164ce1c30..cb654d6f05 100644
--- a/UefiCpuPkg/Include/Guid/MpInformation2.h
+++ b/UefiCpuPkg/Include/Guid/MpInformation2.h
@@ -29,6 +29,8 @@
 
 typedef struct {
   EFI_PROCESSOR_INFORMATIONProcessorInfo;
+  UINT8CoreType;
+  UINT8Reserved[7];
   //
   // Add more fields in future
   //
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 3/6] UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe

[duntan]

Consume MpInfo2Hob in PiSmmCpuDxe driver to get
NumberOfProcessors, MaxNumberOfCpus and
EFI_PROCESSOR_INFORMATION for all CPU from the
MpInformation2 HOB.
This can avoid calling MP service.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 209 
++---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
 3 files changed, 171 insertions(+), 48 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index 1d022a7051..d8d488b253 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -586,6 +586,152 @@ SmmReadyToLockEventNotify (
   return EFI_SUCCESS;
 }
 
+/**
+  Function to compare 2 MP_INFORMATION2_HOB_DATA pointer based on 
ProcessorIndex.
+
+  @param[in] Buffer1pointer to MP_INFORMATION2_HOB_DATA poiner to 
compare
+  @param[in] Buffer2pointer to second MP_INFORMATION2_HOB_DATA 
pointer to compare
+
+  @retval 0 Buffer1 equal to Buffer2
+  @retval <0Buffer1 is less than Buffer2
+  @retval >0Buffer1 is greater than Buffer2
+**/
+INTN
+EFIAPI
+MpInformation2HobCompare (
+  IN  CONST VOID  *Buffer1,
+  IN  CONST VOID  *Buffer2
+  )
+{
+  if ((*(MP_INFORMATION2_HOB_DATA **)Buffer1)->ProcessorIndex > 
(*(MP_INFORMATION2_HOB_DATA **)Buffer2)->ProcessorIndex) {
+return 1;
+  } else if ((*(MP_INFORMATION2_HOB_DATA **)Buffer1)->ProcessorIndex < 
(*(MP_INFORMATION2_HOB_DATA **)Buffer2)->ProcessorIndex) {
+return -1;
+  }
+
+  return 0;
+}
+
+/**
+  Extract NumberOfCpus, MaxNumberOfCpus and EFI_PROCESSOR_INFORMATION for all 
CPU from MpInformation2 HOB.
+
+  @param[out] NumberOfCpus   Pointer to NumberOfCpus.
+  @param[out] MaxNumberOfCpusPointer to MaxNumberOfCpus.
+  @param[out] ProcessorInfoPointer   Pointer to EFI_PROCESSOR_INFORMATION 
buffer pointer.
+
+  @retval EFI_SUCCESSSuccessfully extract information from 
MpInformation2 HOB.
+  @retval RETURN_BUFFER_TOO_SMALLFail to allocate memory.
+**/
+EFI_STATUS
+GetMpInfoFromMpInfo2Hob (
+  OUT UINTN  *NumberOfCpus,
+  OUT UINTN  *MaxNumberOfCpus,
+  OUT EFI_PROCESSOR_INFORMATION  **ProcessorInfoPointer
+  )
+{
+  EFI_HOB_GUID_TYPE  *GuidHob;
+  EFI_HOB_GUID_TYPE  *FirstMpInfor2Hob;
+  MP_INFORMATION2_HOB_DATA   *MpInformation2HobData;
+  UINTN  CpuCount;
+  UINTN  HobCount;
+  UINTN  Index;
+  MP_INFORMATION2_HOB_DATA   **MpInfomation2Buffer;
+  UINTN  SortBuffer;
+  UINTN  ProcessorIndex;
+  UINT64 PrevProcessorIndex;
+  MP_INFORMATION2_ENTRY  *MpInformation2Entry;
+  EFI_PROCESSOR_INFORMATION  *ProcessorInfo;
+
+  GuidHob   = NULL;
+  MpInformation2HobData = NULL;
+  FirstMpInfor2Hob  = NULL;
+  MpInfomation2Buffer   = NULL;
+  CpuCount  = 0;
+  Index = 0;
+  HobCount  = 0;
+  PrevProcessorIndex= 0;
+
+  FirstMpInfor2Hob = GetFirstGuidHob ();
+  ASSERT (FirstMpInfor2Hob != NULL);
+  GuidHob = FirstMpInfor2Hob;
+  while (GuidHob != NULL) {
+MpInformation2HobData = GET_GUID_HOB_DATA (GuidHob);
+
+//
+// This is the last MpInformationHob in the HOB list.
+//
+if (MpInformation2HobData->NumberOfProcessors == 0) {
+  ASSERT (HobCount != 0);
+  break;
+}
+
+HobCount++;
+CpuCount += MpInformation2HobData->NumberOfProcessors;
+GuidHob   = GetNextGuidHob (, GET_NEXT_HOB 
(GuidHob));
+  }
+
+  ASSERT (CpuCount <= PcdGet32 (PcdCpuMaxLogicalProcessorNumber));
+  *NumberOfCpus = CpuCount;
+
+  //
+  // If support CPU hot plug, we need to allocate resources for possibly 
hot-added processors
+  //
+  if (FeaturePcdGet (PcdCpuHotPlugSupport)) {
+*MaxNumberOfCpus = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
+  } else {
+*MaxNumberOfCpus = CpuCount;
+  }
+
+  MpInfomation2Buffer = AllocatePool (sizeof (MP_INFORMATION2_HOB_DATA *) * 
HobCount);
+  ASSERT (MpInfomation2Buffer != NULL);
+  if (MpInfomation2Buffer == NULL) {
+return EFI_BUFFER_TOO_SMALL;
+  }
+
+  //
+  // Record each MpInformation2Hob pointer in the MpInfomation2Buffer.
+  //
+  GuidHob = FirstMpInfor2Hob;
+  ASSERT (GuidHob != NULL);
+  while (Index < HobCount) {
+MpInfomation2Buffer[Index++] = GET_GUID_HOB_DATA (GuidHob);
+GuidHob  = GetNextGuidHob (, 
GET_NEXT_HOB (GuidHob));
+  }
+
+  ProcessorInfo = (EFI_PROCESSOR_INFORMATION *)AllocatePool (sizeof 
(EFI_PROCESSOR_INFORMATION) * (*MaxNumberOfCpus));
+  

[edk2-devel] [PATCH 2/6] UefiCpuPkg: Build MpInfo2HOB in CpuMpPei

[duntan]

Build MpInfo2HOB in CpuMpPei module so that later
PiSmmCpuDxe or other StandaloneMm module can consume
the HOB.
Since there might be more one gMpInformationHobGuid2
in HOB list, CpuMpPei create a gMpInformationHobGuid2
with 0 value NumberOfProcessors field in the end of the
process to indicate it's the last MP_INFORMATION2_HOB.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 91 
+++
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |  4 +++-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |  3 ++-
 3 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
index b504bea3cf..4d80d52799 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
@@ -541,6 +541,92 @@ InitializeMpExceptionStackSwitchHandlers (
   FreePages (SwitchStackData, EFI_SIZE_TO_PAGES (NumberOfProcessors * sizeof 
(EXCEPTION_STACK_SWITCH_CONTEXT)));
 }
 
+/**
+  Create gMpInformationHobGuid2.
+**/
+VOID
+BuildMpInformationHob (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  UINTN ProcessorIndex;
+  UINTN NumberOfProcessors;
+  UINTN NumberOfEnabledProcessors;
+  UINTN NumberOfProcessorsInHob;
+  UINTN MaxProcessorsPerHob;
+  MP_INFORMATION2_HOB_DATA  *MpInformation2HobData;
+  MP_INFORMATION2_ENTRY *MpInformation2Entry;
+  UINTN Index;
+
+  ProcessorIndex= 0;
+  MpInformation2HobData = NULL;
+  MpInformation2Entry   = NULL;
+
+  Status = MpInitLibGetNumberOfProcessors (, 
);
+  ASSERT_EFI_ERROR (Status);
+  MaxProcessorsPerHob = ((MAX_UINT16 & 7) - sizeof (EFI_HOB_GUID_TYPE) - 
sizeof (MP_INFORMATION2_HOB_DATA)) / sizeof (MP_INFORMATION2_ENTRY);
+  NumberOfProcessorsInHob = MaxProcessorsPerHob;
+
+  //
+  // Create MP_INFORMATION2_HOB. when the max HobLength 0xFFF8 is not enough, 
there
+  // will be a MP_INFORMATION2_HOB series in the HOB list.
+  // In the HOB list, there is a gMpInformationHobGuid2 with 0 value 
NumberOfProcessors
+  // fields to indicate it's the last MP_INFORMATION2_HOB.
+  //
+  while (NumberOfProcessorsInHob != 0) {
+NumberOfProcessorsInHob = MIN (NumberOfProcessors - ProcessorIndex, 
MaxProcessorsPerHob);
+MpInformation2HobData   = BuildGuidHob (
+,
+sizeof (MP_INFORMATION2_HOB_DATA) + sizeof 
(MP_INFORMATION2_ENTRY) * NumberOfProcessorsInHob
+);
+ASSERT (MpInformation2HobData != NULL);
+
+MpInformation2HobData->Version= MP_INFORMATION2_HOB_REVISION;
+MpInformation2HobData->ProcessorIndex = ProcessorIndex;
+MpInformation2HobData->NumberOfProcessors = 
(UINT16)NumberOfProcessorsInHob;
+MpInformation2HobData->EntrySize  = sizeof (MP_INFORMATION2_ENTRY);
+
+DEBUG ((DEBUG_INFO, "BuildMpInformationHob\n"));
+
+for (Index = 0; Index < NumberOfProcessorsInHob; Index++) {
+  MpInformation2Entry = GET_MP_INFORMATION_ENTRY (MpInformation2HobData, 
Index);
+  Status  = MpInitLibGetProcessorInfo (
+  (Index + ProcessorIndex) | 
CPU_V2_EXTENDED_TOPOLOGY,
+  >ProcessorInfo,
+  NULL
+  );
+  ASSERT_EFI_ERROR (Status);
+  DEBUG ((
+DEBUG_INFO,
+"ProcessorIndex = %x, ProcessorId = %lx, StatusFlag = %x\n",
+Index + ProcessorIndex,
+MpInformation2Entry->ProcessorInfo.ProcessorId,
+MpInformation2Entry->ProcessorInfo.StatusFlag
+));
+  DEBUG ((
+DEBUG_INFO,
+"Location (Package/Core/Thread) = %d/%d/%d\n",
+MpInformation2Entry->ProcessorInfo.Location.Package,
+MpInformation2Entry->ProcessorInfo.Location.Core,
+MpInformation2Entry->ProcessorInfo.Location.Thread
+));
+  DEBUG ((
+DEBUG_INFO,
+"Location2 (Package/Die/Tile/Module/Core/Thread) = 
%d/%d/%d/%d/%d/%d\n",
+
MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Package,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Die,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Tile,
+
MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Module,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Core,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Thread
+));
+}
+
+ProcessorIndex += NumberOfProcessorsInHob;
+  }
+}
+
 /**
   Initializes MP and exceptions handlers.
 
@@ -602,6 +688,11 @@ InitializeCpuMpWorker (
   Status = PeiServicesInstallPpi (mPeiCpuMpPpiList);
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Create gMpInformationHobGuid2
+  //
+  

[edk2-devel] [PATCH 1/6] UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg

[duntan]

Create gMpInformationHobGuid2 in UefiCpuPkg.

Currently, there is a gMpInformationHobGuid defined,
created and consumed only in StandaloneMmPkg. The HOB
contains the EFI_PROCESSOR_INFORMATION structure for
each CPU and the number of processors. This is the same
as the information that PiSmmCpuDxeSmm uses MpService
Protocol to get.

This new gMpInformationHobGuid2 also contains the
NumberOfProcessors and the EFI_PROCESSOR_INFORMATION
for each CPU. Also the HOB is extended to support the
case that the maximum HOB length is not enough for all
CPU. So there might be more than one HOB instance in the
HOB list. Each HOB describes the corresponding CPU index
range.

The plan is to create gMpInformationHob2Guid in CpuMpPei
module(implemented in next commit). Then PiSmmCpuDxeSmm
and other MM_STANDALONE modules can consume the hob. This
can avoid calling MpService Protocol in PiSmmCpuDxeSmm.
Also the issue that one gMpInformationHobGuid might be not
enough when CPU number is 1~2000 or bigger can be solved.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/Include/Guid/MpInformation2.h | 56 

 UefiCpuPkg/UefiCpuPkg.dec|  3 +++
 2 files changed, 59 insertions(+)

diff --git a/UefiCpuPkg/Include/Guid/MpInformation2.h 
b/UefiCpuPkg/Include/Guid/MpInformation2.h
new file mode 100644
index 00..4164ce1c30
--- /dev/null
+++ b/UefiCpuPkg/Include/Guid/MpInformation2.h
@@ -0,0 +1,56 @@
+/** @file
+  EFI MP information protocol provides a lightweight MP_SERVICES_PROTOCOL.
+
+  MP information protocol only provides static information of MP processor.
+
+  If SwitchBSP or Enable/DisableAP in MP service is called between the HOB
+  production and HOB consumption, EFI_PROCESSOR_INFORMATION.StatusFlag and
+  NumberOfEnabledProcessors fields in this HOB may be invalidated.
+
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MP_INFORMATION2_H_
+#define MP_INFORMATION2_H_
+
+#include 
+#include 
+#include 
+
+#define MP_INFORMATION2_HOB_REVISION  1
+
+#define MP_INFORMATION2_GUID \
+  { \
+0x417a7f64, 0xf4e9, 0x4b32, {0x84, 0x6a, 0x5c, 0xc4, 0xd8, 0x62, 0x18, 
0x79}  \
+  }
+
+typedef struct {
+  EFI_PROCESSOR_INFORMATIONProcessorInfo;
+  //
+  // Add more fields in future
+  //
+} MP_INFORMATION2_ENTRY;
+
+typedef struct {
+  UINT16   NumberOfProcessors;
+  UINT16   EntrySize;
+  UINT8Version;
+  UINT8Reserved[3];
+  UINT64   ProcessorIndex;
+  MP_INFORMATION2_ENTRYMpInformation[0];
+} MP_INFORMATION2_HOB_DATA;
+
+//
+// Producer of MP_INFORMATION2_HOB_DATA should assign sizeof 
(MP_INFORMATION2_ENTRY) to MP_INFORMATION2_HOB_DATA.EntrySize
+// Consumer of MP_INFORMATION2_HOB_DATA should use below macro or similar 
logic to get the individual entry
+// as the entry structure might be updated to include more information.
+//
+#define GET_MP_INFORMATION_ENTRY(MpInfoHobData, Index) \
+(MP_INFORMATION2_ENTRY *)((UINTN)&((MP_INFORMATION2_HOB_DATA 
*)(MpInfoHobData))->MpInformation + (MpInfoHobData)->EntrySize * Index)
+
+extern EFI_GUID  gMpInformationHobGuid2;
+
+#endif
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 0b5431dbf7..61bd34ef17 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -85,6 +85,9 @@
   ## Include/Guid/SmmBaseHob.h
   gSmmBaseHobGuid  = { 0xc2217ba7, 0x03bb, 0x4f63, {0xa6, 0x47, 0x7c, 
0x25, 0xc5, 0xfc, 0x9d, 0x73 }}
 
+  ## Include/Guid/MpInformation2.h
+  gMpInformationHobGuid2 = { 0x417a7f64, 0xf4e9, 0x4b32, {0x84, 0x6a, 
0x5c, 0xc4, 0xd8, 0x62, 0x18, 0x79 }}
+
 [Protocols]
   ## Include/Protocol/SmmCpuService.h
   gEfiSmmCpuServiceProtocolGuid   = { 0x1d202cab, 0xc8ab, 0x4d5c, { 0x94, 
0xf7, 0x3c, 0xfc, 0xc0, 0xd3, 0xd3, 0x35 }}
-- 
2.31.1.windows.1



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

[edk2-devel] [PATCH 0/6] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

[duntan]

Create and consume gMpInformationHobGuid2 in UefiCpuPkg in this patch series.

Currently, there is a gMpInformationHobGuid defined, created and consumed only 
in StandaloneMmPkg.
The HOB contains the EFI_PROCESSOR_INFORMATION structure for each CPU and the 
number of processors.
This is the same as the information that PiSmmCpuDxeSmm uses MpService Protocol 
to get.

This new gMpInformationHobGuid2 also contains the NumberOfProcessors and the 
EFI_PROCESSOR_INFORMATION for each CPU. 
lso the HOB is extended to support the case that the maximum HOB length is not 
enough for all CPU.
So there might be more than one HOB instance in the HOB list. Each HOB 
describes the corresponding CPU index range.

The plan is to create gMpInformationHob2Guid in CpuMpPei module. Then 
PiSmmCpuDxeSmm and other MM_STANDALONE modules can consume the hob.
This can avoid calling MpService Protocol in PiSmmCpuDxeSmm. Also the issue 
that one gMpInformationHobGuid might be not enough when CPU number is 1~2000 or 
bigger can be solved.

Also the code to extracting information from gSmmBaseHobGuid is modified to 
remove the assumption that there is only one HOB instance of gSmmBaseHobGuid.

Dun Tan (6):
  UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg
  UefiCpuPkg: Build MpInfo2HOB in CpuMpPei
  UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe
  UefiCpuPkg: Add a new field in MpInfo2 HOB
  UefiCpuPkg: Cache core type in MpInfo2 HOB
  UefiCpuPkg: Avoid assuming only one smmbasehob

 UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 146 
++
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   6 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   3 ++-
 UefiCpuPkg/Include/Guid/MpInformation2.h |  58 
++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 351 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
 UefiCpuPkg/UefiCpuPkg.dec|   3 +++
 8 files changed, 515 insertions(+), 62 deletions(-)
 create mode 100644 UefiCpuPkg/Include/Guid/MpInformation2.h

-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112062): https://edk2.groups.io/g/devel/message/112062
Mute This Topic: https://groups.io/mt/102987136/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] MinPlatformPkg: Remove PeiDxeTpmPlatformHierarchyLib

[Chiu, Chasel]

Patch pushed: 
https://github.com/tianocore/edk2-platforms/commit/f446fff05003f69a4396b2ec375301ecb5f63a2a

Thanks,
Chasel


> -Original Message-
> From: Chiang, Chris 
> Sent: Monday, December 4, 2023 12:51 AM
> To: devel@edk2.groups.io
> Cc: Chiang, Chris ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Gao, Liming ;
> Dong, Eric 
> Subject: [PATCH v1] MinPlatformPkg: Remove PeiDxeTpmPlatformHierarchyLib
> 
> From: Chiang-Chris 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4612
> 
> Remove PeiDxeTpmPlatformHierarchyLib in Tcg/Library
> Signed-off-by: Chiang-Chris 
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Eric Dong 
> ---
>  Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> |   2 +-
>  Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> |   2 +-
>  Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> |   1 -
> 
> Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/Pei
> DxeTpmPlatformHierarchyLib.c   | 266 
> 
> Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/Pei
> DxeTpmPlatformHierarchyLib.inf |  45 
>  5 files changed, 2 insertions(+), 314 deletions(-)
> 
> diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> index 260f3b94c5..b469938823 100644
> --- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> +++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> @@ -66,7 +66,7 @@
> 
> Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
> 
> 
> 
>  [LibraryClasses.common.DXE_DRIVER]
> 
> -
> TpmPlatformHierarchyLib|MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierar
> chyLib/PeiDxeTpmPlatformHierarchyLib.inf
> 
> +
> TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.inf
> 
> 
> 
>  [LibraryClasses.common.DXE_SMM_DRIVER]
> 
> 
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableL
> ib.inf
> 
> diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> index 595f0ee490..7afbb2900f 100644
> --- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> +++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> @@ -52,7 +52,7 @@
> 
> Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRoute
> rPei.inf
> 
> 
> HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRout
> erPei.inf
> 
> 
> Tcg2PhysicalPresenceLib|SecurityPkg/Library/PeiTcg2PhysicalPresenceLib/PeiTcg
> 2PhysicalPresenceLib.inf
> 
> -
> TpmPlatformHierarchyLib|MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierar
> chyLib/PeiDxeTpmPlatformHierarchyLib.inf
> 
> +
> TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.inf
> 
> 
> 
> 
> FspMeasurementLib|IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/Ba
> seFspMeasurementLib.inf
> 
> 
> FspWrapperPlatformMultiPhaseLib|IntelFsp2WrapperPkg/Library/BaseFspWrapp
> erPlatformMultiPhaseLibNull/BaseFspWrapperPlatformMultiPhaseLibNull.inf
> 
> diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> index 087fa48dd0..ee5d211128 100644
> --- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> +++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> @@ -203,7 +203,6 @@
>MinPlatformPkg/Test/TestPointStubDxe/TestPointStubDxe.inf
> 
>MinPlatformPkg/Test/TestPointDumpApp/TestPointDumpApp.inf
> 
> 
> 
> -
> MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatfor
> mHierarchyLib.inf
> 
>MinPlatformPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf
> 
>MinPlatformPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.inf
> 
> 
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.c
> b/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.c
> deleted file mode 100644
> index 9812ab99ab..00
> ---
> a/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.c
> +++ /dev/null
> @@ -1,266 +0,0 @@
> -/** @file
> 
> -TPM Platform Hierarchy configuration library.
> 
> -
> 
> -This library provides functions for customizing the TPM's Platform 
> Hierarchy
> 
> -Authorization Value (platformAuth) and Platform Hierarchy Authorization
> 
> -Policy (platformPolicy) can be defined through this function.
> 
> -
> 
> -Copyright (c) 2019, Intel Corporation. All rights reserved.
> 
> -Copyright (c) Microsoft Corporation.
> 
> -SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> -
> 
> -@par Specification Reference:
> 
> -https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-
> guidance/
> 
> -**/
> 
> -
> 
> -#include 
> 
> -
> 
> -#include 
> 
> -#include 
> 
> 

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, December 5, 2023 #cal-reminder

[Group Notification]

*Reminder: TianoCore Bug Triage - APAC / NAMO*

*When:*
Tuesday, December 5, 2023
6:30pm to 7:30pm
(UTC-08:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d

*Organizer:* Liming Gao gaolim...@byosoft.com.cn ( 
gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2108595 )

*Description:*

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions ( 
https://conf.intel.com/teams/?conf=1160620940=teams=conf.intel.com=test_call
 )

*Or call in (audio only)*

+1 916-245-6934,,77463821# ( tel:+19162456934,,77463821# ) United States, 
Sacramento

Phone Conference ID: 774 638 21#

Find a local number ( 
https://dialin.teams.microsoft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821
 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e=46c98d88-e344-4ed4-8496-4ed7712e255d=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2=0=en-US
 )


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

Re: [edk2-devel] [PATCH V3 0/9] Refine BMC USB NIC discovery and Redfish service enablement

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

That's fine Mike, I will just create a PR and update it with your Acked-by.

Abner

> -Original Message-
> From: Mike Maslenkin 
> Sent: Monday, December 4, 2023 6:59 PM
> To: devel@edk2.groups.io; Chang, Abner 
> Cc: Nickle Wang ; Igor Kulchytskyy 
> Subject: Re: [edk2-devel] [PATCH V3 0/9] Refine BMC USB NIC discovery and
> Redfish service enablement
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Hi Abner,
>
> You can add my Acked-by to each commit, if it won't take to much time
> for resending series, etc.
>
> Regards,
> Mike
>
>
> On Mon, Dec 4, 2023 at 12:08 PM Chang, Abner via groups.io
>  wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Hi Mike, would you like to having you Acked-by on each commit?
> >
> > Abner
> >
> > > -Original Message-
> > > From: Mike Maslenkin 
> > > Sent: Monday, December 4, 2023 3:18 PM
> > > To: Chang, Abner 
> > > Cc: devel@edk2.groups.io; Nickle Wang ; Igor
> > > Kulchytskyy 
> > > Subject: Re: [PATCH V3 0/9] Refine BMC USB NIC discovery and Redfish
> > > service enablement
> > >
> > > Caution: This message originated from an External Source. Use proper
> caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > On Mon, Nov 27, 2023 at 8:31 AM  wrote:
> > > >
> > > > From: Abner Chang 
> > > >
> > > > In V3: Address Mike's comments to V2.
> > > >
> > > > In V2: Send additional two patches those are missed
> > > >in V1.
> > > >
> > > > This patch set updates the algorithm of BMC USB
> > > > NIC discovery and fixes some bugs.
> > > >
> > > > - Add a new protocol to trigger the notification
> > > >   of Redfish Host Interface readiness.
> > > >   This fixes the issue Redfish config handler driver
> > > >   acquires Redfish service before Redfish Host
> > > >   Interface is published.
> > > > - Add more error debug messages.
> > > > - Address some minor issues
> > > >
> > > > Signed-off-by: Abner Chang 
> > > > Cc: Nickle Wang 
> > > > Cc: Igor Kulchytskyy 
> > > > Cc: Mike Maslenkin 
> > > >
> > > > Abner Chang (9):
> > > >   RedfishPkg/BmcUsbNicLib: Update BMC USB NIC searching algorithm
> > > >   RedfishPkg/RedfishHostInterfaceDxe: Add Redfish HI readiness
> > > > notification
> > > >   RedfishPkg/RedfishConfigHandler: Use Redfish HI readiness notification
> > > >   RedfishPkg/RedfishConfigHandler: Correct the prototype of callback
> > > > function
> > > >   RedfishPkg/RedfishDiscovery: Add more debug message
> > > >   RedfishPkg/RedfishDiscovery: Refine SMBIOS 42h code
> > > >   RedfishPkg/HostInterfaceBmcUsbNic: Fix incorrect reference of MAC
> > > > address pointer
> > > >   RedfishPkg/HostInterfaceBmcUsbNic: Fix incorrect HI protocol record
> > > > size
> > > >   RedfishPkg/HostInterfaceBmcUsbNic: Fix potential memory corruption
> > > > issue
> > > >
> > > >  RedfishPkg/RedfishPkg.dec |   3 +
> > > >  .../RedfishConfigHandlerDriver.inf|   9 +-
> > > >  .../RedfishHostInterfaceDxe.inf   |   3 +-
> > > >  .../RedfishDiscoverInternal.h |   2 +
> > > >  .../PlatformHostInterfaceBmcUsbNicLib.c   | 196 --
> > > >  .../RedfishConfigHandlerDriver.c  | 170 +--
> > > >  .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   |  23 ++
> > > >  .../RedfishSmbiosHostInterface.c  |  20 +-
> > > >  .../RedfishHostInterfaceDxe.c |  18 ++
> > > >  9 files changed, 315 insertions(+), 129 deletions(-)
> > > >
> > > > --
> > > > 2.37.1.windows.1
> > > >
> > >
> > > Looks good to me.
> > > Thank you.
> > >
> > > Regards,
> > > Mike
> >
> >
> > 
> >
> >


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

[edk2-devel] Updated Event: TianoCore edk2-test Bug Triage Meeting #cal-invite

[Group Notification]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20230407T050750Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Repeat:39460
UID:uhga.1631071627369023388.p...@groups.io
DTSTAMP:20231205T014140Z
ORGANIZER;CN=Edhaya Chandran:mailto:edhaya.chand...@arm.com
DTSTART;TZID=Asia/Shanghai:20220901T22
DTEND;TZID=Asia/Shanghai:20220901T23
RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=1TH
SUMMARY:TianoCore edk2-test Bug Triage Meeting
LOCATION:https://armltd.zoom.us/j/94348061758?pwd=Q3RDeFA5K2JFaU5jdWUxc1F
 naGdyUT09=addon
SEQUENCE:7580
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

[edk2-devel] UEFI reserving pages of memory in low memory

[Paul, Bill via groups.io]

Hello:

I have a question which might not be applicable to the stock Tianocore 
codebase, but I'm hoping maybe someone here might recognize what I'm asking 
about and could give me some pointers.

I have A Board (tm) with Intel Raptor Lake CPU and a UEFI 2.7-based firmware 
implementation on it. Out of the box, if I go to the UEFI shell and run the 
memmap command, I can see there is a gap in the available RAM starting at the 
2MB mark. That is, I see this:

Available  0010-001F 0100 000F
Available  00201000-339A6FFF 000337A6 000F

Near the end of the output, I also see this:

Reserved   0020-00200FFF 0001 

The implication is that the UEFI firmware has, for some reason, decided to 
reserve the page of memory at 0x20 for some nefarious purpose.

As it happens, this is extremely inconvenient for my purposes. In the past 
I've seen where the OVMF UEFI images for Intel will try to reserve a block at 
the 8MB mark for stashing things during S3 hibernation mode, and I've been 
able to work around that by using the -global ICH9-LPC.disable_s3=1 command 
line flag with QEMU.

But in this case, I have no idea why the firmware is reserving this page. There 
are ACPI_NVS and ACPI_Reclaim ranges too, but they are further up in RAM and 
not a concern for me.

The only clue I have is that if I dump the page at 0x20 from the shell 
using the mem command, I see that it contains the string 'TERR' at the start, 
and a few numbers within the first 32 bytes, and the rest is all zeroes. This 
suggests some sort of anchor string, but I don't know what it means.

Can anybody think of what this reserved page is for, and if maybe the firmware 
setup menu might offer me a way to turn off whatever feature is reserving it? 
(For the record, there is an option to disable S3 sleep support and I did try 
turning that off, but it made no difference.)

Thanks in advance.

-Bill

-- 
=
-Bill Paul(510) 749-2329 | VxWorks Software Architect,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=




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

[edk2-devel] [PATCH v1] MinPlatformPkg: Remove PeiDxeTpmPlatformHierarchyLib

[chris . chiang]

From: Chiang-Chris 

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

Remove PeiDxeTpmPlatformHierarchyLib in Tcg/Library
Signed-off-by: Chiang-Chris 

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Eric Dong 
---
 Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc   
   |   2 +-
 Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc   
   |   2 +-
 Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc   
   |   1 -
 
Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
   | 266 
 
Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 |  45 
 5 files changed, 2 insertions(+), 314 deletions(-)

diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc 
b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
index 260f3b94c5..b469938823 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
+++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
@@ -66,7 +66,7 @@
   Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
 
 [LibraryClasses.common.DXE_DRIVER]
-  
TpmPlatformHierarchyLib|MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
+  
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 
 [LibraryClasses.common.DXE_SMM_DRIVER]
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc 
b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
index 595f0ee490..7afbb2900f 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
+++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
@@ -52,7 +52,7 @@
   
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterPei.inf
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
   
Tcg2PhysicalPresenceLib|SecurityPkg/Library/PeiTcg2PhysicalPresenceLib/PeiTcg2PhysicalPresenceLib.inf
-  
TpmPlatformHierarchyLib|MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
+  
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 
   
FspMeasurementLib|IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/BaseFspMeasurementLib.inf
   
FspWrapperPlatformMultiPhaseLib|IntelFsp2WrapperPkg/Library/BaseFspWrapperPlatformMultiPhaseLibNull/BaseFspWrapperPlatformMultiPhaseLibNull.inf
diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc 
b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
index 087fa48dd0..ee5d211128 100644
--- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
+++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
@@ -203,7 +203,6 @@
   MinPlatformPkg/Test/TestPointStubDxe/TestPointStubDxe.inf
   MinPlatformPkg/Test/TestPointDumpApp/TestPointDumpApp.inf
 
-  
MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
   MinPlatformPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf
   MinPlatformPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.inf
 
diff --git 
a/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
 
b/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
deleted file mode 100644
index 9812ab99ab..00
--- 
a/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
+++ /dev/null
@@ -1,266 +0,0 @@
-/** @file
-TPM Platform Hierarchy configuration library.
-
-This library provides functions for customizing the TPM's Platform 
Hierarchy
-Authorization Value (platformAuth) and Platform Hierarchy Authorization
-Policy (platformPolicy) can be defined through this function.
-
-Copyright (c) 2019, Intel Corporation. All rights reserved.
-Copyright (c) Microsoft Corporation.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-@par Specification Reference:
-
https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
-**/
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-//
-// The authorization value may be no larger than the digest produced by the 
hash
-//   algorithm used for context integrity.
-//
-#define  MAX_NEW_AUTHORIZATION_SIZE SHA512_DIGEST_SIZE
-
-UINT16   mAuthSize;
-
-/**
-  Generate high-quality entropy source through RDRAND.
-
-  @param[in]   LengthSize of the buffer, in bytes, to fill with.
-  @param[out]  Entropy   Pointer to the buffer to store the entropy data.
-
-  @retval EFI_SUCCESSEntropy generation succeeded.
-  @retval EFI_NOT_READY  Failed to 

Re: [edk2-devel] [PATCH v1] MinPlatformPkg: Remove PeiDxeTpmPlatformHierarchyLib

[Rodrigo Gonzalez del Cueto]

Reviewed-by: Rodrigo Gonzalez del Cueto 


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

[edk2-devel] Now: Tools, CI, Code base construction meeting series - Monday, December 4, 2023 #cal-notice

[Group Notification]

*Tools, CI, Code base construction meeting series*

*When:*
Monday, December 4, 2023
4:30pm to 5:30pm
(UTC-08:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2108598 )

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


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

[edk2-devel] Event: Tools, CI, Code base construction meeting series - Monday, December 4, 2023 #cal-reminder

[Group Notification]

*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Monday, December 4, 2023
4:30pm to 5:30pm
(UTC-08:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2108598 )

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


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

Re: [edk2-devel] [PATCH v2] PcAtChipsetPkg: Fix AcpiTimerLib incompatibility with XhciDxe

[Nate DeSimone]

> -Original Message-

> From: Pedro Falcato 

> Sent: Monday, December 4, 2023 11:59 AM

> To: devel@edk2.groups.io; Desimone, Nathaniel L

> 

> Cc: Ni, Ray ; Kinney, Michael D

> 

> Subject: Re: [edk2-devel] [PATCH v2] PcAtChipsetPkg: Fix AcpiTimerLib

> incompatibility with XhciDxe

>

> On Mon, Dec 4, 2023 at 6:48 PM Nate DeSimone

> mailto:nathaniel.l.desim...@intel.com>> wrote:

> >

> > The DXE & MM standalone variant of AcpiTimerLib defines a global named

> > mPerformanceCounterFrequency. A global with an identical name is also

> > present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c

> >

> > Since XhciDxe has a dependency on TimerLib, this can cause link errors

> > due to the same symbol being defined twice if the platform DSC chooses

> > to use AcpiTimerLib as the TimerLib implementation for any given

> > platform.

> >

> > To resolve this, I have changed made the definition of

> > mPerformanceCounterFrequency to static and renamed it to

> > mAcpiTimerLibTscFrequency. Since this variable is not used outside of

> > the DxeStandaloneMmAcpiTimerLib.c compilation unit, there is no reason

> > to have it exported as a global.

> >

> > Cc: Ray Ni mailto:ray...@intel.com>>

> > Cc: Michael D Kinney 
> > mailto:michael.d.kin...@intel.com>>

> > Signed-off-by: Nate DeSimone 
> > mailto:nathaniel.l.desim...@intel.com>>

> > ---

> >  .../AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c | 18

> > +-

> >  1 file changed, 9 insertions(+), 9 deletions(-)

> >

> > diff --git

> > a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c

> > b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c

> > index 16ac48938f..ccceb8a649 100644

> > ---

> > a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c

> > +++

> b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.

> > +++ c

> > @@ -1,7 +1,7 @@

> >  /** @file

> >ACPI Timer implements one instance of Timer Library.

> >

> > -  Copyright (c) 2013 - 2018, Intel Corporation. All rights

> > reserved.

> > +  Copyright (c) 2013 - 2023, Intel Corporation. All rights

> > + reserved.

> >SPDX-License-Identifier: BSD-2-Clause-Patent

> >

> >  **/

> > @@ -11,6 +11,11 @@

> >  #include 

> >  #include 

> >

> > +//

> > +// Cached performance counter frequency // static UINT64

> > +mAcpiTimerLibTscFrequency = 0;

>

> I'd say you don't need to rename it if it's a static variable. Now the 
> identifier is

> 2x longer with no additional relevant information.



This is in response to Mike K's feedback: 
https://edk2.groups.io/g/devel/message/111966



>

> Aren't we supposed to use STATIC vs static, CONST vs const, etc? Annoyingly

> :/



Apparently not. Honestly, I lose track of what the current coding style is 
sometimes too.



>

> --

> Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112052): https://edk2.groups.io/g/devel/message/112052
Mute This Topic: https://groups.io/mt/102976788/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] PcAtChipsetPkg: Fix AcpiTimerLib incompatibility with XhciDxe

[Pedro Falcato]

On Mon, Dec 4, 2023 at 6:48 PM Nate DeSimone
 wrote:
>
> The DXE & MM standalone variant of AcpiTimerLib defines a global
> named mPerformanceCounterFrequency. A global with an identical
> name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
>
> Since XhciDxe has a dependency on TimerLib, this can cause link
> errors due to the same symbol being defined twice if the platform
> DSC chooses to use AcpiTimerLib as the TimerLib implementation for
> any given platform.
>
> To resolve this, I have changed made the definition of
> mPerformanceCounterFrequency to static and renamed it to
> mAcpiTimerLibTscFrequency. Since this variable is not used outside
> of the DxeStandaloneMmAcpiTimerLib.c compilation unit, there is no
> reason to have it exported as a global.
>
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Signed-off-by: Nate DeSimone 
> ---
>  .../AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git 
> a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c 
> b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> index 16ac48938f..ccceb8a649 100644
> --- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> +++ b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> @@ -1,7 +1,7 @@
>  /** @file
>ACPI Timer implements one instance of Timer Library.
>
> -  Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2013 - 2023, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
> @@ -11,6 +11,11 @@
>  #include 
>  #include 
>
> +//
> +// Cached performance counter frequency
> +//
> +static UINT64 mAcpiTimerLibTscFrequency = 0;

I'd say you don't need to rename it if it's a static variable. Now the
identifier is 2x longer with no additional relevant information.

Aren't we supposed to use STATIC vs static, CONST vs const, etc? Annoyingly :/

-- 
Pedro


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

[edk2-devel] [PATCH v2] MdeModulePkg/Bus: Fix XhciDxe Linker Issues

[Nate DeSimone]

The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c

Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.

To resolve this, I noted that some of the globals in Xhci.c are not
used outside of the Xhci.c compilation unit:

- mPerformanceCounterStartValue
- mPerformanceCounterEndValue
- mPerformanceCounterFrequency
- mPerformanceCounterValuesCached

I have changed the definition for all of these to static and added
an Xhci prefix. Since they are not used outside of the Xhci.c
compilation unit, there is no reason to have them exported as
globals.

Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Nate DeSimone 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 32 ++---
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 7a2e32a9dd..f4e61d223c 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -2,7 +2,7 @@
   The XHCI controller driver.
 
 (C) Copyright 2023 Hewlett Packard Enterprise Development LP
-Copyright (c) 2011 - 2022, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2023, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -86,10 +86,10 @@ EFI_USB2_HC_PROTOCOL  gXhciUsb2HcTemplate = {
   0x0
 };
 
-UINT64   mPerformanceCounterStartValue;
-UINT64   mPerformanceCounterEndValue;
-UINT64   mPerformanceCounterFrequency;
-BOOLEAN  mPerformanceCounterValuesCached = FALSE;
+static UINT64   mXhciPerformanceCounterStartValue;
+static UINT64   mXhciPerformanceCounterEndValue;
+static UINT64   mXhciPerformanceCounterFrequency;
+static BOOLEAN  mXhciPerformanceCounterValuesCached = FALSE;
 
 /**
   Retrieves the capability of root hub ports.
@@ -2318,17 +2318,17 @@ XhcConvertTimeToTicks (
   UINTN   Shift;
 
   // Cache the return values to avoid repeated calls to 
GetPerformanceCounterProperties ()
-  if (!mPerformanceCounterValuesCached) {
-mPerformanceCounterFrequency = GetPerformanceCounterProperties (
- ,
- 
- );
+  if (!mXhciPerformanceCounterValuesCached) {
+mXhciPerformanceCounterFrequency = GetPerformanceCounterProperties (
+ ,
+ 
+ );
 
-mPerformanceCounterValuesCached = TRUE;
+mXhciPerformanceCounterValuesCached = TRUE;
   }
 
   // Prevent returning a tick value of 0, unless Time is already 0
-  if (0 == mPerformanceCounterFrequency) {
+  if (0 == mXhciPerformanceCounterFrequency) {
 return Time;
   }
 
@@ -2342,7 +2342,7 @@ XhcConvertTimeToTicks (
   //
   Ticks = MultU64x64 (
 DivU64x64Remainder (
-  mPerformanceCounterFrequency,
+  mXhciPerformanceCounterFrequency,
   Divisor,
   
   ),
@@ -2384,12 +2384,12 @@ XhcGetElapsedTicks (
   //
   // Determine if the counter is counting up or down
   //
-  if (mPerformanceCounterStartValue < mPerformanceCounterEndValue) {
+  if (mXhciPerformanceCounterStartValue < mXhciPerformanceCounterEndValue) {
 //
 // Counter counts upwards, check for an overflow condition
 //
 if (*PreviousTick > CurrentTick) {
-  Delta = (mPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
+  Delta = (mXhciPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
 } else {
   Delta = CurrentTick - *PreviousTick;
 }
@@ -2398,7 +2398,7 @@ XhcGetElapsedTicks (
 // Counter counts downwards, check for an underflow condition
 //
 if (*PreviousTick < CurrentTick) {
-  Delta = (mPerformanceCounterStartValue - CurrentTick) + *PreviousTick;
+  Delta = (mXhciPerformanceCounterStartValue - CurrentTick) + 
*PreviousTick;
 } else {
   Delta = *PreviousTick - CurrentTick;
 }
-- 
2.39.2.windows.1



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

[edk2-devel] [PATCH v2] PcAtChipsetPkg: Fix AcpiTimerLib incompatibility with XhciDxe

[Nate DeSimone]

The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c

Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.

To resolve this, I have changed made the definition of
mPerformanceCounterFrequency to static and renamed it to
mAcpiTimerLibTscFrequency. Since this variable is not used outside
of the DxeStandaloneMmAcpiTimerLib.c compilation unit, there is no
reason to have it exported as a global.

Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Nate DeSimone 
---
 .../AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c 
b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
index 16ac48938f..ccceb8a649 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI Timer implements one instance of Timer Library.
 
-  Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2023, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -11,6 +11,11 @@
 #include 
 #include 
 
+//
+// Cached performance counter frequency
+//
+static UINT64 mAcpiTimerLibTscFrequency = 0;
+
 extern GUID  mFrequencyHobGuid;
 
 /**
@@ -48,11 +53,6 @@ InternalCalculateTscFrequency (
   VOID
   );
 
-//
-// Cached performance counter frequency
-//
-UINT64  mPerformanceCounterFrequency = 0;
-
 /**
   Internal function to retrieves the 64-bit frequency in Hz.
 
@@ -66,7 +66,7 @@ InternalGetPerformanceCounterFrequency (
   VOID
   )
 {
-  return mPerformanceCounterFrequency;
+  return mAcpiTimerLibTscFrequency;
 }
 
 /**
@@ -92,9 +92,9 @@ CommonAcpiTimerLibConstructor (
   //
   GuidHob = GetFirstGuidHob ();
   if (GuidHob != NULL) {
-mPerformanceCounterFrequency = *(UINT64 *)GET_GUID_HOB_DATA (GuidHob);
+mAcpiTimerLibTscFrequency = *(UINT64 *)GET_GUID_HOB_DATA (GuidHob);
   } else {
-mPerformanceCounterFrequency = InternalCalculateTscFrequency ();
+mAcpiTimerLibTscFrequency = InternalCalculateTscFrequency ();
   }
 
   return EFI_SUCCESS;
-- 
2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112050): https://edk2.groups.io/g/devel/message/112050
Mute This Topic: https://groups.io/mt/102976788/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] MinPlatformPkg: Remove PeiDxeTpmPlatformHierarchyLib

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

Thanks,
Chasel



> -Original Message-
> From: Chiang, Chris 
> Sent: Monday, December 4, 2023 12:51 AM
> To: devel@edk2.groups.io
> Cc: Chiang, Chris ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Gao, Liming ;
> Dong, Eric 
> Subject: [PATCH v1] MinPlatformPkg: Remove PeiDxeTpmPlatformHierarchyLib
> 
> From: Chiang-Chris 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4612
> 
> Remove PeiDxeTpmPlatformHierarchyLib in Tcg/Library
> Signed-off-by: Chiang-Chris 
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Eric Dong 
> ---
>  Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> |   2 +-
>  Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> |   2 +-
>  Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> |   1 -
> 
> Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/Pei
> DxeTpmPlatformHierarchyLib.c   | 266 
> 
> Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/Pei
> DxeTpmPlatformHierarchyLib.inf |  45 
>  5 files changed, 2 insertions(+), 314 deletions(-)
> 
> diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> index 260f3b94c5..b469938823 100644
> --- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> +++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> @@ -66,7 +66,7 @@
> 
> Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
> 
> 
> 
>  [LibraryClasses.common.DXE_DRIVER]
> 
> -
> TpmPlatformHierarchyLib|MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierar
> chyLib/PeiDxeTpmPlatformHierarchyLib.inf
> 
> +
> TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.inf
> 
> 
> 
>  [LibraryClasses.common.DXE_SMM_DRIVER]
> 
> 
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableL
> ib.inf
> 
> diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> index 595f0ee490..7afbb2900f 100644
> --- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> +++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CorePeiLib.dsc
> @@ -52,7 +52,7 @@
> 
> Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRoute
> rPei.inf
> 
> 
> HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRout
> erPei.inf
> 
> 
> Tcg2PhysicalPresenceLib|SecurityPkg/Library/PeiTcg2PhysicalPresenceLib/PeiTcg
> 2PhysicalPresenceLib.inf
> 
> -
> TpmPlatformHierarchyLib|MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierar
> chyLib/PeiDxeTpmPlatformHierarchyLib.inf
> 
> +
> TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.inf
> 
> 
> 
> 
> FspMeasurementLib|IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/Ba
> seFspMeasurementLib.inf
> 
> 
> FspWrapperPlatformMultiPhaseLib|IntelFsp2WrapperPkg/Library/BaseFspWrapp
> erPlatformMultiPhaseLibNull/BaseFspWrapperPlatformMultiPhaseLibNull.inf
> 
> diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> index 087fa48dd0..ee5d211128 100644
> --- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> +++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dsc
> @@ -203,7 +203,6 @@
>MinPlatformPkg/Test/TestPointStubDxe/TestPointStubDxe.inf
> 
>MinPlatformPkg/Test/TestPointDumpApp/TestPointDumpApp.inf
> 
> 
> 
> -
> MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatfor
> mHierarchyLib.inf
> 
>MinPlatformPkg/Tcg/Tcg2PlatformPei/Tcg2PlatformPei.inf
> 
>MinPlatformPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.inf
> 
> 
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.c
> b/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.c
> deleted file mode 100644
> index 9812ab99ab..00
> ---
> a/Platform/Intel/MinPlatformPkg/Tcg/Library/PeiDxeTpmPlatformHierarchyLib/P
> eiDxeTpmPlatformHierarchyLib.c
> +++ /dev/null
> @@ -1,266 +0,0 @@
> -/** @file
> 
> -TPM Platform Hierarchy configuration library.
> 
> -
> 
> -This library provides functions for customizing the TPM's Platform 
> Hierarchy
> 
> -Authorization Value (platformAuth) and Platform Hierarchy Authorization
> 
> -Policy (platformPolicy) can be defined through this function.
> 
> -
> 
> -Copyright (c) 2019, Intel Corporation. All rights reserved.
> 
> -Copyright (c) Microsoft Corporation.
> 
> -SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> -
> 
> -@par Specification Reference:
> 
> -https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-
> guidance/
> 
> -**/
> 
> -
> 
> -#include 
> 
> -
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> 

Re: [edk2-devel] [edk2-redfish-client][PATCH v2] RedfishClientPkg/RedfishFeatureUtilityLib: validate string array

[Igor Kulchytskyy via groups.io]

Reviewed-by: Igor Kulchytskyy 
Regards,
Igor

-Original Message-
From: Nickle Wang 
Sent: Monday, December 4, 2023 4:41 AM
To: devel@edk2.groups.io
Cc: Abner Chang ; Igor Kulchytskyy ; Nick 
Ramirez 
Subject: [EXTERNAL] [edk2-redfish-client][PATCH v2] 
RedfishClientPkg/RedfishFeatureUtilityLib: validate string array


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

Add function ValidateRedfishStringArrayValues to validate Redfish
request for string array type. There is case that user request
invalid string array and feature driver can not find corresponding
HII option.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 .../Library/RedfishFeatureUtilityLib.h|  28 +++
 .../RedfishFeatureUtilityLib.c| 187 ++
 2 files changed, 172 insertions(+), 43 deletions(-)

diff --git a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h 
b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
index 6347585c..24f0ad24 100644
--- a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
+++ b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
@@ -990,4 +990,32 @@ GetPendingSettings (
   OUT EFI_STRING*SettingUri
   );

+/**
+  This function goes through Head and StringArray to check below:
+  1) Check and see if value in Redfish string array can be found in HII
+  configuration string array. This is to see if there is any invalid
+  values from Redfish.
+  2) Check and see if size of Head is the same as ArraySize.
+  3) Check and see if value in Redfish string array are all the same as the one
+  from HII configuration.
+
+  @param[in]  Head  The head of string array.
+  @param[in]  StringArray   Input string array.
+  @param[in]  ArraySize The size of StringArray.
+  @param[out] ValueChanged  TRUE when The order of Head is not the same as the 
order of StringArray.
+FALSE when Head and StringArray are identical.
+
+  @retval  EFI_INVALID_PARAMETER  Input parameter is NULL or ArraySize is 0.
+  @retval  EFI_NOT_FOUND  The element in Head cannot be found in 
StringArray. This is invalid request.
+  @retval  EFI_BAD_BUFFER_SIZEThe size of Head is not the same as the size 
of StringArray. This is invalid request.
+
+**/
+EFI_STATUS
+ValidateRedfishStringArrayValues (
+  IN RedfishCS_char_Array  *Head,
+  IN CHAR8 **StringArray,
+  IN UINTN ArraySize,
+  OUT BOOLEAN  *ValueChanged
+  );
+
 #endif
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 6652539c..07033488 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -866,6 +866,7 @@ ApplyFeatureSettingsStringArrayType (
   EDKII_REDFISH_VALUE   RedfishValue;
   UINTN Index;
   RedfishCS_char_Array  *Buffer;
+  BOOLEAN   ValueChanged;

   if (IS_EMPTY_STRING (Schema) || IS_EMPTY_STRING (Version) || IS_EMPTY_STRING 
(ConfigureLang) || (ArrayHead == NULL)) {
 return EFI_INVALID_PARAMETER;
@@ -886,61 +887,69 @@ ApplyFeatureSettingsStringArrayType (
   }

   //
-  // If there is no change in array, do nothing
+  // Validate input string array from BMC to see:
+  // 1) String array from BMC is valid or not.
+  // 2) If there is no change in array, do nothing.
   //
-  if (!CompareRedfishStringArrayValues (ArrayHead, 
RedfishValue.Value.StringArray, RedfishValue.ArrayCount)) {
-//
-// Apply settings from redfish
-//
-DEBUG ((DEBUG_MANAGEABILITY, "%a: %a.%a apply %s for array\n", __func__, 
Schema, Version, ConfigureLang));
-FreeArrayTypeRedfishValue ();
-
-//
-// Convert array from RedfishCS_char_Array to EDKII_REDFISH_VALUE
-//
-RedfishValue.ArrayCount = 0;
-Buffer  = ArrayHead;
-while (Buffer != NULL) {
-  RedfishValue.ArrayCount += 1;
-  Buffer   = Buffer->Next;
-}
+  Status = ValidateRedfishStringArrayValues (ArrayHead, 
RedfishValue.Value.StringArray, RedfishValue.ArrayCount, );
+  if (!EFI_ERROR (Status)) {
+if (ValueChanged) {
+  //
+  // Apply settings from redfish
+  //
+  DEBUG ((DEBUG_MANAGEABILITY, "%a: %a.%a apply %s for array\n", __func__, 
Schema, Version, ConfigureLang));
+  FreeArrayTypeRedfishValue ();

-//
-// Allocate pool for new values
-//
-RedfishValue.Value.StringArray = AllocatePool (RedfishValue.ArrayCount 
*sizeof (CHAR8 *));
-if (RedfishValue.Value.StringArray == NULL) {
-  ASSERT (FALSE);
-  return EFI_OUT_OF_RESOURCES;
-}
+  //
+  // Convert array from RedfishCS_char_Array to EDKII_REDFISH_VALUE
+  //
+

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Ard Biesheuvel]

On Mon, 4 Dec 2023 at 15:52, Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > > That way you at least you know who you trust. Just remove shim. Have a 
> > > > look
> > > > at how Amazon Linux 2023 did it [2] :))
>
> > > You are in the luxurious position to run your own distro on your own
> > > platform, which makes this totally easy.
>
> > Sure, we're cheating a bit on x86. But for ARM, the same story holds true
> > for RH as well. There are a solid number of ARM systems that implement UEFI
> > Secure Boot today - and none of them (that I'm aware of) provision a
> > Microsoft 3rd party key.
>
> Didn't got my hands on any such arm system.
>
> How do you enroll the keys on those systems?
>
> Do they offer the option to read the 'db' keys from files on distro boot
> media?  Or do they expect the distro boot loader (or installer) to enroll
> keys and enable secure boot (which is supported by systemd-boot I think)?
>
> > In fact, for virtual machines you're in the exact same position as EC2: If
> > virt-install only provisions Red Hat Secure Boot keys by default when you
> > install Fedora or RHEL guests, you've already increased your guests'
> > security posture significantly.
>
> Well, no.  One problem is install media, where you really have only
> one entry point (EFI/BOOT/BOOT${ARCH}.EFI) which must work under all
> circumstances.  Which must be shim with microsoft signature (and ideally
> distro signature too) on x64.
>
> When booting cloud images and the platform allowing for
> 'bring-your-own-varstore', then yes, it is simpler and doable.
>
> > > The RH bootloader team considers shim.efi being an essential part of the
> > > boot chain (to the point that the distro grub.efi throws errors with
> > > secure boot being enabled and shim.efi missing), and on x86 bare metal
> > > it actually is essential because hardware usually ships with only the
> > > microsoft certificate enrolled.
>
> > See above, the key (in your case) is to not treat ARM and x86 identical. And
> > yes, the (downstream) shim patches for grub break normal grub secure boot
> > support. But that's a bug - not a feature :).
>
> I'm with you on that.  Unfortunately the boot loader team is not.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2108083
>
> tl;dr: You can't boot Fedora in secure boot mode without microsoft keys
> today.  grub.efi refuses to work without shim.efi, and shim.efi exists
> only in a microsoft-signed version (which differed from rhel were a
> second, redhat-signed shim binary exists).
>
> Oh, and the above applies to x86 only.  On arm fedora shim.efi is not
> signed and grub.efi is signed with the (public) redhat test keys.
>

So what is holding Fedora back from providing a fixed shim binary if
it doesn't need to be signed by Microsoft? And also, the only
problematic binary in the boot chain appears to be fbaa64.efi - that
one could be fixed as well, by using 4k aligned executable sections.

To be honest (and I know I am preaching to the choir here), the more i
learn about this, the less I am inclined to make *any* accommodations
whatsoever, given that the boot loader team obviously does not give a
shit about their crappy boot chain.


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

[edk2-devel] Tianocore edk2-test bug triage meeting

[G Edhaya Chandran]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:India Standard Time
BEGIN:STANDARD
DTSTART:16010101T00
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T00
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=G Edhaya Chandran:mailto:edhaya.chand...@arm.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=devel@edk2
 .groups.io:mailto:devel@edk2.groups.io
DESCRIPTION;LANGUAGE=en-US:New Series\n\nTianocore edk2-test bug triage mee
 ting\n\nAgenda:\n\n• Discussion on the progress of t
 he BZ tickets dispositioned in the previous meeting.\n
   Bug List (tianocore.org)\n\n
 • Dispositioning the new BZ tickets\n\n•  
Specific agenda items from the community members\n\n\n\n\n\n Ed
 haya Chandran G is inviting you to a scheduled Zoom meeting.\n\nJoin Zoom 
 Meeting\nhttps://armltd.zoom.us/j/94348061758?pwd=Q3RDeFA5K2JFaU5jdWUxc1Fn
 aGdyUT09=addon\n\nMeeting ID: 943 4806 1758\nPasscode: 277536\n\n---\
 n\nOne tap mobile\n+16465189805\,\,94348061758#\,\,\,\,*277536# US (New Yo
 rk)\n+13462487799\,\,94348061758#\,\,\,\,*277536# US (Houston)\n\n---\n\nD
 ial by your location\n• +1 646 518 9805 US (New York)\n• +1 346 248 77
 99 US (Houston)\n• +1 408 638 0968 US (San Jose)\n\nMeeting ID: 943 4806
  1758\nPasscode: 277536\n\nFind your local number: https://armltd.zoom.us/
 u/a03gYNyxT\n\n---\n\nJoin by SIP\n• 94348061...@zoomcrc.com\n\n---\n\nJoin by H.323\n• 162.255.37.11 (US West)\
 n• 162.255.36.11 (US East)\n• 115.114.131.7 (India Mumbai)\n• 115.11
 4.115.7 (India Hyderabad)\n• 213.19.144.110 (Amsterdam Netherlands)\n•
  213.244.140.110 (Germany)\n• 103.122.166.55 (Australia Sydney)\n• 103
 .122.167.55 (Australia Melbourne)\n• 209.9.211.110 (Hong Kong SAR)\n• 
 149.137.40.110 (Singapore)\n• 64.211.144.160 (Brazil)\n• 69.174.57.160
  (Canada Toronto)\n• 65.39.152.160 (Canada Vancouver)\n• 207.226.132.1
 10 (Japan Tokyo)\n• 149.137.24.110 (Japan Osaka)\n\nMeeting ID: 943 4806
  1758\nPasscode: 277536\nIMPORTANT NOTICE: The contents of this email and 
 any attachments are confidential and may also be privileged. If you are no
 t the intended recipient\, please notify the sender immediately and do not
  disclose the contents to any other person\, use it for any purpose\, or s
 tore or copy the information in any medium. Thank you.\n
RRULE:FREQ=MONTHLY;UNTIL=20241207T14Z;INTERVAL=1;BYDAY=1TH
UID:04008200E00074C5B7101A82E00880F4B657F226DA01000
 01000C9AE4A4C3B4E0B499A40C31A5D1B4695
SUMMARY;LANGUAGE=en-US:Tianocore edk2-test bug triage meeting
DTSTART;TZID=India Standard Time:20231207T193000
DTEND;TZID=India Standard Time:20231207T203000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20231204T151606Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:https://armltd.zoom.us/j/94348061758?pwd=Q3RDeFA5K2
 JFaU5jdWUxc1FnaGdyUT09=addon
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-1614493721
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-REQUESTEDATTENDANCEMODE:DEFAULT
X-MICROSOFT-LOCATIONS:[ { "DisplayName" : "https://armltd.zoom.us/j/9434806
 1758?pwd=Q3RDeFA5K2JFaU5jdWUxc1FnaGdyUT09=addon"\, "LocationAnnotatio
 n" : ""\, "LocationSource" : 0\, "Unresolved" : false\, "LocationUri" : ""
  } ]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Gerd Hoffmann]

  Hi,

> > > That way you at least you know who you trust. Just remove shim. Have a 
> > > look
> > > at how Amazon Linux 2023 did it [2] :))

> > You are in the luxurious position to run your own distro on your own
> > platform, which makes this totally easy.

> Sure, we're cheating a bit on x86. But for ARM, the same story holds true
> for RH as well. There are a solid number of ARM systems that implement UEFI
> Secure Boot today - and none of them (that I'm aware of) provision a
> Microsoft 3rd party key.

Didn't got my hands on any such arm system.

How do you enroll the keys on those systems?

Do they offer the option to read the 'db' keys from files on distro boot
media?  Or do they expect the distro boot loader (or installer) to enroll
keys and enable secure boot (which is supported by systemd-boot I think)?

> In fact, for virtual machines you're in the exact same position as EC2: If
> virt-install only provisions Red Hat Secure Boot keys by default when you
> install Fedora or RHEL guests, you've already increased your guests'
> security posture significantly.

Well, no.  One problem is install media, where you really have only
one entry point (EFI/BOOT/BOOT${ARCH}.EFI) which must work under all
circumstances.  Which must be shim with microsoft signature (and ideally
distro signature too) on x64.

When booting cloud images and the platform allowing for
'bring-your-own-varstore', then yes, it is simpler and doable.

> > The RH bootloader team considers shim.efi being an essential part of the
> > boot chain (to the point that the distro grub.efi throws errors with
> > secure boot being enabled and shim.efi missing), and on x86 bare metal
> > it actually is essential because hardware usually ships with only the
> > microsoft certificate enrolled.

> See above, the key (in your case) is to not treat ARM and x86 identical. And
> yes, the (downstream) shim patches for grub break normal grub secure boot
> support. But that's a bug - not a feature :).

I'm with you on that.  Unfortunately the boot loader team is not.

https://bugzilla.redhat.com/show_bug.cgi?id=2108083

tl;dr: You can't boot Fedora in secure boot mode without microsoft keys
today.  grub.efi refuses to work without shim.efi, and shim.efi exists
only in a microsoft-signed version (which differed from rhel were a
second, redhat-signed shim binary exists).

Oh, and the above applies to x86 only.  On arm fedora shim.efi is not
signed and grub.efi is signed with the (public) redhat test keys.

> > At least they promised to sign shim with both distro and microsoft keys
> > on the next update, so I have the option to enroll the distro instead of
> > the micosoft keys in 'db' on platforms where this is possible.
> 
> Shim really has no place in a world where you have a distro key enrolled.

Except for https://github.com/rhboot/shim/blob/main/SBAT.md

> Fight the battle please, we'll all be off with an easier boot stack as a
> result :).

Trust me, I had my fair share of battles already, and I still have
multiple open bug reports.

> If there are concerns around tooling differences (like mokutil), let's look
> at how we can unify/simplify the user experience instead.

IMHO it essentially it comes down to standardize a few things.  Most
importantly placing the distro secure boot certificate on some
well-known location on the install media, so tooling like virt-install
can pre-load it into 'db' of the guest it is going to install.
Something similar for cloud images, so OpenStack / EC2 / whatever can do
the same.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112044): https://edk2.groups.io/g/devel/message/112044
Mute This Topic: https://groups.io/mt/102967690/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 1/1] Platform/ARM: Fix the build failure DxeCore

[Sami Mujawar]

Merged as b95395ba400e..3220cb309390

Thanks.

Regards,

Sami Mujawar


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112043): https://edk2.groups.io/g/devel/message/112043
Mute This Topic: https://groups.io/mt/102894400/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 1/1] Platform/ARM: Fix the build failure DxeCore

[Sami Mujawar]

Hi Levi,

Thank you for this patch.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 30/11/2023, 14:29, "levi.yun" mailto:yeoreum@arm.com>> wrote:




The edk2 commit 7284c44951cffd52f1a08367d91b5c63c7bb9c16
introduces a new library ImagePropertiesRecordLib to
consolidate the logic for manipulating the image properties
used to track runtime images and to remove duplicate code.
This library is further linked with DxeCore.


Therefore, add an instance of ImagePropertiesRecordLib to
the ArmVExpress.dsc.inc file so that it is included for Arm
platforms.


Signed-off-by: Levi Yun mailto:yeoreum@arm.com>>
---


Notes:
Patch v2:
- fix the line ending issue.
- add missing edk2 mailing list.


Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 +
1 file changed, 1 insertion(+)


diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 
5e6886b30c8e507939a73b97366e2247a1430cef..9c9e1f79c8869639c01a0f257633dd8a8a686c3b
 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -164,6 +164,7 @@ [LibraryClasses.common]
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf


ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+ 
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf


[LibraryClasses.common.SEC]
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
--
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112042): https://edk2.groups.io/g/devel/message/112042
Mute This Topic: https://groups.io/mt/102894400/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 1/1] Platform/ARM: Fix the build failure DxeCore

[Himanshu Sharma]

Tested for N1SDP.

Tested-by: Himanshu Sharma 


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

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Ard Biesheuvel]

On Mon, 4 Dec 2023 at 13:38, Alexander Graf  wrote:
>
>
> On 04.12.23 13:20, Gerd Hoffmann wrote:
> >Hi,
> >
> >> (hint: You really don't want or need shim on ARM. The only reason for shim
> >> is that on most x86 desktop systems, users will have the MS keys
> >> preinstalled. The MS Secure Boot concept however is terribly broken: Any
> >> compromise of any of the MS signed binaries jeopardizes your boot chain.
> >> You're a lot better off installing *only* your distribution's key material.
> >> That way you at least you know who you trust. Just remove shim. Have a look
> >> at how Amazon Linux 2023 did it [2] :))
> > You are in the luxurious position to run your own distro on your own
> > platform, which makes this totally easy.
>
>
> Sure, we're cheating a bit on x86. But for ARM, the same story holds
> true for RH as well. There are a solid number of ARM systems that
> implement UEFI Secure Boot today - and none of them (that I'm aware of)
> provision a Microsoft 3rd party key. I think we're all better off as
> community if we don't repeat the mistakes we did on x86 on ARM.
>
> In fact, for virtual machines you're in the exact same position as EC2:
> If virt-install only provisions Red Hat Secure Boot keys by default when
> you install Fedora or RHEL guests, you've already increased your guests'
> security posture significantly.
>
> The same applies to RHEL-on-EC2, where you can bring your own db.
>
>
> > The RH bootloader team considers shim.efi being an essential part of the
> > boot chain (to the point that the distro grub.efi throws errors with
> > secure boot being enabled and shim.efi missing), and on x86 bare metal
> > it actually is essential because hardware usually ships with only the
> > microsoft certificate enrolled.
>
>
> See above, the key (in your case) is to not treat ARM and x86 identical.
> And yes, the (downstream) shim patches for grub break normal grub secure
> boot support. But that's a bug - not a feature :).
>
> Once you sorted that bit out, we can start talking about paths to remove
> shim on select x86 environments such as VMs.
>
>
> > At least they promised to sign shim with both distro and microsoft keys
> > on the next update, so I have the option to enroll the distro instead of
> > the micosoft keys in 'db' on platforms where this is possible.
>
>
> Shim really has no place in a world where you have a distro key
> enrolled. Fight the battle please, we'll all be off with an easier boot
> stack as a result :). This bug here alone already shows you why shim is
> a bad idea conceptually. Necessary in an MS dominated world, but still bad.
>
> If there are concerns around tooling differences (like mokutil), let's
> look at how we can unify/simplify the user experience instead.
>

I don't think it helps to go off on a tangent about why shim exists
and why it is so terrible, as I don't think there is actually any
disagreement about that. But now that we are, let me add my 2c as well
:-)

For the patch under discussion here, I think that Gerd's suggestion is
to have both a PCD and a QEMU variable, and use the PCD unless the
variable has a value. I'm on the fence here: I would like to
accommodate users, but adding another control that the distros are
just going to set and forget is just going to make the mess bigger.

What is even worse: arm64 system firmware will have to deal with this
as well, and disable the protocol in order to run distro installers.
And once the tightened MS requirements for NX compat come into effect,
they will have to add another workaround for this as well, and so
we'll probably end up with generations of arm64 hardware with a
'enable memory attributes protocol' option in their BIOS menus. And
guess what the default setting is likely to be?

I am quite disappointed with the complete lack of involvement from the
folks who develop and deploy shim, and instead, third parties (and
users) are the ones chasing me and people like Gerd (who work on QEMU
or EDK2 rather than shim) to clean up the mess.

If the shim developers (or anyone else) can suggest some kind of
heuristic for deciding whether a broken shim is calling into the
protocol, I'd be more than happy to add more code to avoid the need
for a QEMU command line option in the common case. But just turning it
off via a PCD or otherwise is not something I am willing to entertain.


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

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Gerd Hoffmann]

  Hi,

> (hint: You really don't want or need shim on ARM. The only reason for shim
> is that on most x86 desktop systems, users will have the MS keys
> preinstalled. The MS Secure Boot concept however is terribly broken: Any
> compromise of any of the MS signed binaries jeopardizes your boot chain.
> You're a lot better off installing *only* your distribution's key material.
> That way you at least you know who you trust. Just remove shim. Have a look
> at how Amazon Linux 2023 did it [2] :))

You are in the luxurious position to run your own distro on your own
platform, which makes this totally easy.

The RH bootloader team considers shim.efi being an essential part of the
boot chain (to the point that the distro grub.efi throws errors with
secure boot being enabled and shim.efi missing), and on x86 bare metal
it actually is essential because hardware usually ships with only the
microsoft certificate enrolled.

At least they promised to sign shim with both distro and microsoft keys
on the next update, so I have the option to enroll the distro instead of
the micosoft keys in 'db' on platforms where this is possible.

take care,
  Gerd



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

回复: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized FV Migration Information

[gaoliming via groups.io]

Fan:
  I add my comment below. 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Wang Fan
> 发送时间: 2023年12月4日 18:31
> 收件人: Ni, Ray ; devel@edk2.groups.io; Gao, Liming
> ; Kinney, Michael D
> 
> 抄送: Jiang, Guomin 
> 主题: Re: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized
> FV Migration Information
> 
> Thank you Ray and Liming, for your comments.
> 
> Ray,
> 
> There's something to clarify on this HOB usage. In this patch, when this
> Migration feature PCD is set to TRUE, the PeiCore will only migrate FVs which
> are recorded by ToMigrateFvInfo hob (each FV should publish their own
> ToMigrateFvInfo hob in this flow), and check MigrationFlags to decide also
> copy raw data or not. If no ToMigrateFvInfo hobs published, it will go into 
> the
> legacy flow to migrate all FVs for backward compatibility.
> 
> Agree on your suggestion on the flag name change to
> "FLAGS_BUILD_MIGRATED_FV_INFO", I will update in V4 patch. But I think a
> little different on your listed approaches: I prefer to refine the hob usage 
> to
> include all ToMigrateFvInfo data in one hob (rather than each FV publish their
> own) and a field "MigrateAll" in this hob for those platforms who have no
> performance concern. In future, if we want to retire Migration feature PCD,
> we just need replace "check PCD TRUE or FALSE" with "check Hob exists or
> not". What do you think this way?
> 
> Liming,
> 
> For your question "RAW_DATA_COPY is for measure boot to make sure PCR0
> have the same value on the different boot.", we have
> gEfiPeiFirmwareVolumeInfoMeasurementExcludedPpiGuid to skip FV
> measurement when boot guard already measured these FVs. So I'm thinking
> it's valid to assume not all FVs need copy raw data for measurement.

[Liming] If so, please highlight this usage in comments that 
gEfiPeiFirmwareVolumeInfoMeasurementExcludedPpiGuid
must be configured if FV RAW_DATA_COPY is not set.

Thanks
Liming
> 
> For your another question "If RemoveFvHobsInTemporaryMemory () does
> nothing now.", it's true from my investigation.
> 
> Best Regards
> Fan
> 
> -Original Message-
> From: Ni, Ray 
> Sent: Friday, December 1, 2023 11:06 AM
> To: devel@edk2.groups.io; Gao, Liming ; Wang,
> Fan ; Kinney, Michael D
> 
> Cc: Jiang, Guomin ; Bi, Dandan
> 
> Subject: RE: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support
> customized FV Migration Information
> 
> When PcdMigrateTemporaryRamFirmwareVolumes is TRUE, FV in flash
> (cached in code cache) is copied to physical memory and all C global pointers
> (PPIs, GUIDs) are fixed up.
> But TCG needs to measure the original FV contents, so the original FV is saved
> into MigratedFvInfo HOB when the FV migration is done.
> 
> Now we are going to add a new ToMigrate HOB to tell something.
> 
> Initially without reading the patch, I thought the HOB is to tell which FV 
> needs
> to be migrated.
> But what the patch does is: migration is always done when PCD is true. The
> only thing that's skipped is not to save the original FV contents, then the
> MigratedFvInfo HOB is not produced as well.
> More strangely, if a FV is listed in "ToMigrate" HOB with flag 0, it's the 
> same as
> the "ToMigrate" HOB does not exist.
> 
> It's a bit confusing, in my opinion.
> 
> There are several approaches:
> 1. Do not add "ToMigrate" HOB. Instead, avoid saving the whole original FV
> content, only save the delta that TCG driver uses the new FV content and the
> delta to calculate the HASH. The save of delta should not impact the
> performance very much.
> 
> 2. Abandon the PCD, and update today's logic to follow the new "ToMigrate"
> HOB to perform migration. A new flag tells whether the original FV content
> needs to be saved.
> 
> 3. Keep the PCD. If "ToMigrate" HOB does not exist, follow PCD. If "ToMigrate"
> HOB exists, follow the HOB and ignores the PCD. HOB takes higher priority.
> It's still backward compatible and allows edk2 to gradually retire that PCD.
> (Having multiple interfaces controlling one behavior is always confusing.)
> 3.1 The flag name in the patch is "*SKIP*". I prefer we reverse the meaning of
> the flag, meaning when the flag is set, FV original content is saved. The flag
> name can be "FLAGS_BUILD_MIGRATED_FV_INFO" which directly maps to
> the behavior the flag controls. I agree "MigratedFvInfo" name is confusing but
> at least we avoid adding another confusing "SKIP_FV_RAW_DATA_COPY" flag.
> 
> 
> 
> Thanks,
> Ray
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of
> > gaoliming via groups.io
> > Sent: Friday, December 1, 2023 9:01 AM
> > To: devel@edk2.groups.io; Wang, Fan ; Kinney,
> > Michael D 
> > Cc: Jiang, Guomin ; Bi, Dandan
> > 
> > Subject: 回复: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support
> > customized FV Migration Information
> >
> > Fan:
> >   I add my comment below.
> >
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Wang
> Fan
> > > 发送时间: 2023年10月27日 16:24
> > > 收件人: Kinney, Michael D ;
> > > devel@edk2.groups.io
> > > 

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Gerd Hoffmann]

On Mon, Dec 04, 2023 at 11:57:43AM +0100, Ard Biesheuvel wrote:
> On Mon, Dec 4, 2023 at 11:53 AM Gerd Hoffmann  wrote:
> >
> > > So let's introduce a QEMU command line option to indicate that the
> > > protocol should not be exposed at all.
> > >
> > >   -fw_cfg opt/org.tianocore/DisableMemAttrProtocol,string=y
> >
> > Can we name this 'MemAttrProtocol={y,n}' so it works both ways (enabling
> > and disabling) without double negative?
> >
> 
> Sure, but with the same behavior, right?
> 
> =y means it will get installed
> =n means it will get installed and uninstalled again
> 
> > The fedora distro builds have the protocol disabled, and I'll keep it
> > that way until we finally have fixed shim.efi builds.  Having the option
> > to enable this would be nice though.
> >
> 
> So how did you disable the protocol? That part is not upstream afaik.

Yes, right now it's a fedora-specific patch.  Which I'd drop in favor of
this patch, or a slightly modified version of it.

> We can disable the protocol via this method but how would you set it
> to =n by default?

if (Status != EFI_SUCCESS) 
// opt/org.tiabocode/MemAttrProtocol not present on the qemu cmdline
MemAttrProtocol = ThisBuildsDefault
}

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112036): https://edk2.groups.io/g/devel/message/112036
Mute This Topic: https://groups.io/mt/102967690/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 0/9] Refine BMC USB NIC discovery and Redfish service enablement

[Mike Maslenkin]

Hi Abner,

You can add my Acked-by to each commit, if it won't take to much time
for resending series, etc.

Regards,
Mike


On Mon, Dec 4, 2023 at 12:08 PM Chang, Abner via groups.io
 wrote:
>
> [AMD Official Use Only - General]
>
> Hi Mike, would you like to having you Acked-by on each commit?
>
> Abner
>
> > -Original Message-
> > From: Mike Maslenkin 
> > Sent: Monday, December 4, 2023 3:18 PM
> > To: Chang, Abner 
> > Cc: devel@edk2.groups.io; Nickle Wang ; Igor
> > Kulchytskyy 
> > Subject: Re: [PATCH V3 0/9] Refine BMC USB NIC discovery and Redfish
> > service enablement
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Mon, Nov 27, 2023 at 8:31 AM  wrote:
> > >
> > > From: Abner Chang 
> > >
> > > In V3: Address Mike's comments to V2.
> > >
> > > In V2: Send additional two patches those are missed
> > >in V1.
> > >
> > > This patch set updates the algorithm of BMC USB
> > > NIC discovery and fixes some bugs.
> > >
> > > - Add a new protocol to trigger the notification
> > >   of Redfish Host Interface readiness.
> > >   This fixes the issue Redfish config handler driver
> > >   acquires Redfish service before Redfish Host
> > >   Interface is published.
> > > - Add more error debug messages.
> > > - Address some minor issues
> > >
> > > Signed-off-by: Abner Chang 
> > > Cc: Nickle Wang 
> > > Cc: Igor Kulchytskyy 
> > > Cc: Mike Maslenkin 
> > >
> > > Abner Chang (9):
> > >   RedfishPkg/BmcUsbNicLib: Update BMC USB NIC searching algorithm
> > >   RedfishPkg/RedfishHostInterfaceDxe: Add Redfish HI readiness
> > > notification
> > >   RedfishPkg/RedfishConfigHandler: Use Redfish HI readiness notification
> > >   RedfishPkg/RedfishConfigHandler: Correct the prototype of callback
> > > function
> > >   RedfishPkg/RedfishDiscovery: Add more debug message
> > >   RedfishPkg/RedfishDiscovery: Refine SMBIOS 42h code
> > >   RedfishPkg/HostInterfaceBmcUsbNic: Fix incorrect reference of MAC
> > > address pointer
> > >   RedfishPkg/HostInterfaceBmcUsbNic: Fix incorrect HI protocol record
> > > size
> > >   RedfishPkg/HostInterfaceBmcUsbNic: Fix potential memory corruption
> > > issue
> > >
> > >  RedfishPkg/RedfishPkg.dec |   3 +
> > >  .../RedfishConfigHandlerDriver.inf|   9 +-
> > >  .../RedfishHostInterfaceDxe.inf   |   3 +-
> > >  .../RedfishDiscoverInternal.h |   2 +
> > >  .../PlatformHostInterfaceBmcUsbNicLib.c   | 196 --
> > >  .../RedfishConfigHandlerDriver.c  | 170 +--
> > >  .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   |  23 ++
> > >  .../RedfishSmbiosHostInterface.c  |  20 +-
> > >  .../RedfishHostInterfaceDxe.c |  18 ++
> > >  9 files changed, 315 insertions(+), 129 deletions(-)
> > >
> > > --
> > > 2.37.1.windows.1
> > >
> >
> > Looks good to me.
> > Thank you.
> >
> > Regards,
> > Mike
>
>
> 
>
>


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

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Ard Biesheuvel]

On Mon, Dec 4, 2023 at 11:53 AM Gerd Hoffmann  wrote:
>
> > So let's introduce a QEMU command line option to indicate that the
> > protocol should not be exposed at all.
> >
> >   -fw_cfg opt/org.tianocore/DisableMemAttrProtocol,string=y
>
> Can we name this 'MemAttrProtocol={y,n}' so it works both ways (enabling
> and disabling) without double negative?
>

Sure, but with the same behavior, right?

=y means it will get installed
=n means it will get installed and uninstalled again

> The fedora distro builds have the protocol disabled, and I'll keep it
> that way until we finally have fixed shim.efi builds.  Having the option
> to enable this would be nice though.
>

So how did you disable the protocol? That part is not upstream afaik.

We can disable the protocol via this method but how would you set it
to =n by default?


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

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Ard Biesheuvel]

On Mon, Dec 4, 2023 at 11:45 AM Alexander Graf  wrote:
>
>
> On 04.12.23 10:52, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel 
> >
> > Shim's PE loader uses the EFI memory attributes protocol in a way that
> > results in an immediate crash when invoking the loaded image unless the
> > base and size of its executable segment are both aligned to 4k.
> >
> > If this is not the case, it will strip the executable permissions from
> > the memory allocation, but fail to add them back for the executable
> > region, resulting in non-executable code. Unfortunately, the PE loader
> > does not even bother invoking the protocol in this case (as it notices
> > the misalignment), making it very hard for system firmware to work
> > around this by attempting to infer the intent of the caller.
> >
> > So let's introduce a QEMU command line option to indicate that the
> > protocol should not be exposed at all.
> >
> >-fw_cfg opt/org.tianocore/DisableMemAttrProtocol,string=y
> >
> > Cc: L�szl� �rsek 
> > Cc: Gerd Hoffmann 
> > Cc: Oliver Steffen 
> > Cc: Alexander Graf 
> > Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
> > Signed-off-by: Ard Biesheuvel 
>
>
> Could you please add a PCD value that allows us to set the default to
> disabled? I believe we want to have at least an interim phase where we
> allow the "old" behavior by default, without modification of QEMU
> command line issuing components.
>

The old behavior is a working combination of firmware and QEMU. The
problem manifests itself now that QEMU is updating its bundled
firmware image.

So if the override needs to be on by default, QEMU can take care of that itself.

> I'm happy to leave the default to the new behavior upstream, but with
> the PCD value, distributions like homebrew can easily unblock themselves
> from updating to the latest edk2 without touching every single
> downstream user of QEMU.
>

edk2 is not a homebrew package. QEMU is, and it bundles the firmware.
So the right place to handle this is QEMU, and this patch gives them
an opportunity to do so without the need to fork the edk2 source code.

Adding a PCD is not going to help - we tried that 7+ years ago with
the default memory permissions on LoaderCode vs LoaderData, and the
distros simply ignored the upstream GRUB changes and kept carrying
their own hacks.

I think having an override like the one I am proposing here is as far
as I am willing to go in terms of disabling security features to
accommodate crap software like shim.



> (hint: You really don't want or need shim on ARM. The only reason for
> shim is that on most x86 desktop systems, users will have the MS keys
> preinstalled. The MS Secure Boot concept however is terribly broken: Any
> compromise of any of the MS signed binaries jeopardizes your boot chain.
> You're a lot better off installing *only* your distribution's key
> material. That way you at least you know who you trust. Just remove
> shim. Have a look at how Amazon Linux 2023 did it [2] :))
>

I have been saying the same thing since 2013, which is when I
implemented secure boot support in Tianocore for AArch64.

The distros want shim, and claim they know what they are doing - who
am I to challenge that.


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

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Gerd Hoffmann]

> So let's introduce a QEMU command line option to indicate that the
> protocol should not be exposed at all.
> 
>   -fw_cfg opt/org.tianocore/DisableMemAttrProtocol,string=y

Can we name this 'MemAttrProtocol={y,n}' so it works both ways (enabling
and disabling) without double negative?

The fedora distro builds have the protocol disabled, and I'll keep it
that way until we finally have fixed shim.efi builds.  Having the option
to enable this would be nice though.

take care,
  Gerd



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

[edk2-devel] Transition from DxeIpl to DxeCoreLoad

[Alireza Banejad]

Hello everyone,
I am building the wilsonCity Rvp From the whitleyLake package inside
edk2-platforms. unfortunately i wasn't able to get the debug running
even though I tried everything but that isn't my problem right now
since I use POST codes on each part of code and check to see if the
codes are displayed on the motherboard. my main problem is I put a
post code right before dxeipl to see if it reaches this point:
IoWrite8(0x80,0x7b);
Status = TempPtr.DxeIpl->Entry (
TempPtr.DxeIpl,
,
PrivateData.HobList
);
and so the motherboard shows me 0x7b but it doen't go inside the
DxeloadCore function since I put a Post code at the very beginning of
this function and its still stuck on the 0x7b code:
EFI_STATUS
EFIAPI
DxeLoadCore (
IN CONST EFI_DXE_IPL_PPI *This,
IN EFI_PEI_SERVICES **PeiServices,
IN EFI_PEI_HOB_POINTERS HobList
)
{
...
//
// if in S3 Resume, restore configure
//
IoWrite8(0x80,0x3a);
BootMode = GetBootModeHob ();
IoWrite8(0x80,0x22);
...
 I dont have any better debug approaches to check the stack or
registers that is why i can only send POST codes as evidence that
execution has reached to that point. I dont know why it doesn't
execute the DxeLoadCore properly and I assume the CPU halts since it
just stays stuck on the previous post code from before calling DxeIpl
(I mean 0x7b). I also checked if any arguments being passed to
TempPtr.DxeIpl->Entry are NULL but it seemed none were NULL.
Thanks,
Alireza


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112030): https://edk2.groups.io/g/devel/message/112030
Mute This Topic: https://groups.io/mt/102968005/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 1/1] MdeModulePkg: Support customized FV Migration Information

[Wang Fan]

Thank you Ray and Liming, for your comments.

Ray, 

There's something to clarify on this HOB usage. In this patch, when this 
Migration feature PCD is set to TRUE, the PeiCore will only migrate FVs which 
are recorded by ToMigrateFvInfo hob (each FV should publish their own 
ToMigrateFvInfo hob in this flow), and check MigrationFlags to decide also copy 
raw data or not. If no ToMigrateFvInfo hobs published, it will go into the 
legacy flow to migrate all FVs for backward compatibility.

Agree on your suggestion on the flag name change to 
"FLAGS_BUILD_MIGRATED_FV_INFO", I will update in V4 patch. But I think a little 
different on your listed approaches: I prefer to refine the hob usage to 
include all ToMigrateFvInfo data in one hob (rather than each FV publish their 
own) and a field "MigrateAll" in this hob for those platforms who have no 
performance concern. In future, if we want to retire Migration feature PCD, we 
just need replace "check PCD TRUE or FALSE" with "check Hob exists or not". 
What do you think this way?

Liming,

For your question "RAW_DATA_COPY is for measure boot to make sure PCR0 have the 
same value on the different boot.", we have 
gEfiPeiFirmwareVolumeInfoMeasurementExcludedPpiGuid to skip FV measurement when 
boot guard already measured these FVs. So I'm thinking it's valid to assume not 
all FVs need copy raw data for measurement.
 
For your another question "If RemoveFvHobsInTemporaryMemory () does nothing 
now.", it's true from my investigation.

Best Regards
Fan

-Original Message-
From: Ni, Ray  
Sent: Friday, December 1, 2023 11:06 AM
To: devel@edk2.groups.io; Gao, Liming ; Wang, Fan 
; Kinney, Michael D 
Cc: Jiang, Guomin ; Bi, Dandan 
Subject: RE: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized FV 
Migration Information

When PcdMigrateTemporaryRamFirmwareVolumes is TRUE, FV in flash (cached in code 
cache) is copied to physical memory and all C global pointers (PPIs, GUIDs) are 
fixed up.
But TCG needs to measure the original FV contents, so the original FV is saved 
into MigratedFvInfo HOB when the FV migration is done.

Now we are going to add a new ToMigrate HOB to tell something.

Initially without reading the patch, I thought the HOB is to tell which FV 
needs to be migrated.
But what the patch does is: migration is always done when PCD is true. The only 
thing that's skipped is not to save the original FV contents, then the 
MigratedFvInfo HOB is not produced as well.
More strangely, if a FV is listed in "ToMigrate" HOB with flag 0, it's the same 
as the "ToMigrate" HOB does not exist.

It's a bit confusing, in my opinion.

There are several approaches:
1. Do not add "ToMigrate" HOB. Instead, avoid saving the whole original FV 
content, only save the delta that TCG driver uses the new FV content and the 
delta to calculate the HASH. The save of delta should not impact the 
performance very much.

2. Abandon the PCD, and update today's logic to follow the new "ToMigrate" HOB 
to perform migration. A new flag tells whether the original FV content needs to 
be saved.

3. Keep the PCD. If "ToMigrate" HOB does not exist, follow PCD. If "ToMigrate" 
HOB exists, follow the HOB and ignores the PCD. HOB takes higher priority. It's 
still backward compatible and allows edk2 to gradually retire that PCD. (Having 
multiple interfaces controlling one behavior is always confusing.)
3.1 The flag name in the patch is "*SKIP*". I prefer we reverse the meaning of 
the flag, meaning when the flag is set, FV original content is saved. The flag 
name can be "FLAGS_BUILD_MIGRATED_FV_INFO" which directly maps to the behavior 
the flag controls. I agree "MigratedFvInfo" name is confusing but at least we 
avoid adding another confusing "SKIP_FV_RAW_DATA_COPY" flag.



Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of 
> gaoliming via groups.io
> Sent: Friday, December 1, 2023 9:01 AM
> To: devel@edk2.groups.io; Wang, Fan ; Kinney, 
> Michael D 
> Cc: Jiang, Guomin ; Bi, Dandan 
> 
> Subject: 回复: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support 
> customized FV Migration Information
> 
> Fan:
>   I add my comment below.
> 
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Wang Fan
> > 发送时间: 2023年10月27日 16:24
> > 收件人: Kinney, Michael D ; 
> > devel@edk2.groups.io
> > 抄送: Gao, Liming ; Jiang, Guomin 
> > ; Bi, Dandan 
> > 主题: Re: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support
> customized
> > FV Migration Information
> >
> > Hi Mike
> >
> > Thank you for your feedback.
> >
> > I have updated the patch to v3:
> > https://edk2.groups.io/g/devel/message/110197
> >
> > Pull Request: https://github.com/tianocore/edk2/pull/4970
> >
> > Based on V2, this update includes changes:
> > - Add more descriptions for "gEdkiiToMigrateFvInfoGuid" PPI usages 
> > and background, but still keep the name.
> > - Update "FvOrgBase" to "FvTemporaryRamBase" in 
> > EDKII_TO_MIGRATE_FV_INFO.
> > - Remove flag "FLAGS_SKIP_FV_MIGRATION", since it's not 

Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Ard Biesheuvel]

On Mon, 4 Dec 2023 at 10:52, Ard Biesheuvel  wrote:
>
> From: Ard Biesheuvel 
>
> Shim's PE loader uses the EFI memory attributes protocol in a way that
> results in an immediate crash when invoking the loaded image unless the
> base and size of its executable segment are both aligned to 4k.
>
> If this is not the case, it will strip the executable permissions from
> the memory allocation, but fail to add them back for the executable
> region, resulting in non-executable code. Unfortunately, the PE loader
> does not even bother invoking the protocol in this case (as it notices
> the misalignment), making it very hard for system firmware to work
> around this by attempting to infer the intent of the caller.
>
> So let's introduce a QEMU command line option to indicate that the
> protocol should not be exposed at all.
>
>   -fw_cfg opt/org.tianocore/DisableMemAttrProtocol,string=y
>
> Cc: L�szl� �rsek 

Apologies for the alphabet soup. The Google internal mailer appears to
have changed the content transfer encoding from 8bit to qp because it
spotted a long line (??)


> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Alexander Graf 
> Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  2 +
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 56 
> 
>  2 files changed, 58 insertions(+)
>
> diff --git 
> a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 997eb1a4429f..facd81a5d036 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -46,6 +46,7 @@ [LibraryClasses]
>PcdLib
>
>PlatformBmPrintScLib
>
>QemuBootOrderLib
>
> +  QemuFwCfgSimpleParserLib
>
>QemuLoadImageLib
>
>ReportStatusCodeLib
>
>TpmPlatformHierarchyLib
>
> @@ -73,5 +74,6 @@ [Guids]
>  [Protocols]
>
>gEfiFirmwareVolume2ProtocolGuid
>
>gEfiGraphicsOutputProtocolGuid
>
> +  gEfiMemoryAttributeProtocolGuid
>
>gEfiPciRootBridgeIoProtocolGuid
>
>gVirtioDeviceProtocolGuid
>
> diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 85c01351b09d..e17899100e4a 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
>
>  #include 
>
> +#include 
>
>  #include 
>
>  #include 
>
>  #include 
>
> @@ -,6 +1112,49 @@ PlatformBootManagerBeforeConsole (
>FilterAndProcess (, IsVirtioPciSerial, 
> SetupVirtioSerial);
>
>  }
>
>
>
> +/**
>
> +  Uninstall the EFI memory attribute protocol if it exists.
>
> +**/
>
> +STATIC
>
> +VOID
>
> +UninstallEfiMemoryAttributesProtocol (
>
> +  VOID
>
> +  )
>
> +{
>
> +  EFI_STATUS  Status;
>
> +  EFI_HANDLE  Handle;
>
> +  UINTN   Size;
>
> +  VOID*MemoryAttributeProtocol;
>
> +
>
> +  Size   = sizeof (Handle);
>
> +  Status = gBS->LocateHandle (
>
> +  ByProtocol,
>
> +  ,
>
> +  NULL,
>
> +  ,
>
> +  
>
> +  );
>
> +
>
> +  if (EFI_ERROR (Status)) {
>
> +ASSERT (Status == EFI_NOT_FOUND);
>
> +return;
>
> +  }
>
> +
>
> +  Status = gBS->HandleProtocol (
>
> +  Handle,
>
> +  ,
>
> +  
>
> +  );
>
> +  ASSERT_EFI_ERROR (Status);
>
> +
>
> +  Status = gBS->UninstallProtocolInterface (
>
> +  Handle,
>
> +  ,
>
> +  MemoryAttributeProtocol
>
> +  );
>
> +  ASSERT_EFI_ERROR (Status);
>
> +}
>
> +
>
>  /**
>
>Do the platform specific action after the console is ready
>
>Possible things that can be done in PlatformBootManagerAfterConsole:
>
> @@ -1129,12 +1173,24 @@ PlatformBootManagerAfterConsole (
>)
>
>  {
>
>RETURN_STATUS  Status;
>
> +  BOOLEANFwCfgBool;
>
>
>
>//
>
>// Show the splash screen.
>
>//
>
>BootLogoEnableLogo ();
>
>
>
> +  //
>
> +  // Work around shim's terminally broken use of the EFI memory attributes
>
> +  // protocol, by just uninstalling it when requested on the QEMU command 
> line.
>
> +  //
>
> +  Status = QemuFwCfgParseBool (
>
> + "opt/org.tianocore/DisableMemAttrProtocol",
>
> + );
>
> +  if (!RETURN_ERROR (Status) && FwCfgBool) {
>
> +UninstallEfiMemoryAttributesProtocol ();
>
> +  }
>
> +
>
>//
>
>// Process QEMU's -kernel command line option. The kernel booted this way
>
>// will receive ACPI tables: in PlatformBootManagerBeforeConsole(), we
>
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent 

[edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled

[Ard Biesheuvel]

From: Ard Biesheuvel 

Shim's PE loader uses the EFI memory attributes protocol in a way that
results in an immediate crash when invoking the loaded image unless the
base and size of its executable segment are both aligned to 4k.

If this is not the case, it will strip the executable permissions from
the memory allocation, but fail to add them back for the executable
region, resulting in non-executable code. Unfortunately, the PE loader
does not even bother invoking the protocol in this case (as it notices
the misalignment), making it very hard for system firmware to work
around this by attempting to infer the intent of the caller.

So let's introduce a QEMU command line option to indicate that the
protocol should not be exposed at all.

  -fw_cfg opt/org.tianocore/DisableMemAttrProtocol,string=y

Cc: L�szl� �rsek 
Cc: Gerd Hoffmann 
Cc: Oliver Steffen 
Cc: Alexander Graf 
Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  2 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 56 

 2 files changed, 58 insertions(+)

diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 997eb1a4429f..facd81a5d036 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -46,6 +46,7 @@ [LibraryClasses]
   PcdLib

   PlatformBmPrintScLib

   QemuBootOrderLib

+  QemuFwCfgSimpleParserLib

   QemuLoadImageLib

   ReportStatusCodeLib

   TpmPlatformHierarchyLib

@@ -73,5 +74,6 @@ [Guids]
 [Protocols]

   gEfiFirmwareVolume2ProtocolGuid

   gEfiGraphicsOutputProtocolGuid

+  gEfiMemoryAttributeProtocolGuid

   gEfiPciRootBridgeIoProtocolGuid

   gVirtioDeviceProtocolGuid

diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 85c01351b09d..e17899100e4a 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -16,6 +16,7 @@
 #include 

 #include 

 #include 

+#include 

 #include 

 #include 

 #include 

@@ -,6 +1112,49 @@ PlatformBootManagerBeforeConsole (
   FilterAndProcess (, IsVirtioPciSerial, 
SetupVirtioSerial);

 }

 

+/**

+  Uninstall the EFI memory attribute protocol if it exists.

+**/

+STATIC

+VOID

+UninstallEfiMemoryAttributesProtocol (

+  VOID

+  )

+{

+  EFI_STATUS  Status;

+  EFI_HANDLE  Handle;

+  UINTN   Size;

+  VOID*MemoryAttributeProtocol;

+

+  Size   = sizeof (Handle);

+  Status = gBS->LocateHandle (

+  ByProtocol,

+  ,

+  NULL,

+  ,

+  

+  );

+

+  if (EFI_ERROR (Status)) {

+ASSERT (Status == EFI_NOT_FOUND);

+return;

+  }

+

+  Status = gBS->HandleProtocol (

+  Handle,

+  ,

+  

+  );

+  ASSERT_EFI_ERROR (Status);

+

+  Status = gBS->UninstallProtocolInterface (

+  Handle,

+  ,

+  MemoryAttributeProtocol

+  );

+  ASSERT_EFI_ERROR (Status);

+}

+

 /**

   Do the platform specific action after the console is ready

   Possible things that can be done in PlatformBootManagerAfterConsole:

@@ -1129,12 +1173,24 @@ PlatformBootManagerAfterConsole (
   )

 {

   RETURN_STATUS  Status;

+  BOOLEANFwCfgBool;

 

   //

   // Show the splash screen.

   //

   BootLogoEnableLogo ();

 

+  //

+  // Work around shim's terminally broken use of the EFI memory attributes

+  // protocol, by just uninstalling it when requested on the QEMU command line.

+  //

+  Status = QemuFwCfgParseBool (

+ "opt/org.tianocore/DisableMemAttrProtocol",

+ );

+  if (!RETURN_ERROR (Status) && FwCfgBool) {

+UninstallEfiMemoryAttributesProtocol ();

+  }

+

   //

   // Process QEMU's -kernel command line option. The kernel booted this way

   // will receive ACPI tables: in PlatformBootManagerBeforeConsole(), we

--
2.43.0.rc2.451.g8631bc7472-goog



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

Re: [edk2-devel] [edk2-redfish-client][PATCH] RedfishClientPkg/RedfishFeatureUtilityLib: validate string array

[Nickle Wang via groups.io]

Hi Igor,

Sorry for my delay response. Having three checks in 
ValidateRedfishStringArrayValues is complicate to me so I took some time to 
verify it on my system.

> Maybe their functionality can be combined in ValidateRedfishStringArrayValues?
> Some additional an out parameter from that function can indicate If there is 
> no
> change in array.

This is good idea! I update ValidateRedfishStringArrayValues in version 2 patch 
file here: https://edk2.groups.io/g/devel/message/112025  PR: 
https://github.com/tianocore/edk2-redfish-client/pull/58 Please help me to 
check them if you have time.

Thanks,
Nickle

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Thursday, November 9, 2023 11:11 PM
> To: Nickle Wang ; devel@edk2.groups.io
> Cc: Abner Chang ; Nick Ramirez
> 
> Subject: RE: [EXTERNAL] [edk2-redfish-client][PATCH]
> RedfishClientPkg/RedfishFeatureUtilityLib: validate string array
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Nickle,
> I noticed one typo. See below the text.
> 
> And I have a question regarding newly introduced
> ValidateRedfishStringArrayValues function.
> You use that function to check if value in Redfish string array can be found 
> in HII
> configuration string array.
> And you still call CompareRedfishStringArrayValues function. Both iterate 
> through
> ArrayHead and RedfishValue.Value.StringArray.
> Maybe their functionality can be combined in ValidateRedfishStringArrayValues?
> Some additional an out parameter from that function can indicate If there is 
> no
> change in array.
> What do you think?
> Thank you,
> Igor
> 
> 
> -Original Message-
> From: Nickle Wang 
> Sent: Wednesday, November 8, 2023 2:25 AM
> To: devel@edk2.groups.io
> Cc: Abner Chang ; Igor Kulchytskyy ;
> Nick Ramirez 
> Subject: [EXTERNAL] [edk2-redfish-client][PATCH]
> RedfishClientPkg/RedfishFeatureUtilityLib: validate string array
> 
> 
> **CAUTION: The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.**
> 
> - Add function to validate Redfish request for string array type. There is 
> case that
> user request invalid string array and feature driver can not find 
> corresponding HII
> option.
> - Fix typo.
> 
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> Cc: Nick Ramirez 
> ---
>  .../Library/RedfishFeatureUtilityLib.h|  56 +--
>  .../RedfishFeatureUtilityLib.c| 156 +-
>  2 files changed, 154 insertions(+), 58 deletions(-)
> 
> diff --git a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
> b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
> index e2f728b2..440c4b68 100644
> --- a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
> +++ b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
> @@ -22,7 +22,7 @@
> 
>Read redfish resource by given resource URI.
> 
> -  @param[in]  Service   Redfish srvice instacne to make query.
> +  @param[in]  Service   Redfish service instance to make query.
>@param[in]  ResourceUri   Target resource URI.
>@param[out] Response  HTTP response from redfish service.
> 
> @@ -47,7 +47,7 @@ GetResourceByUri (
>@param[out] ArraySignatureClose   String to the close of array 
> signature.
> 
>@retval EFI_SUCCESSIndex is found.
> -  @retval EFI_NOT_FOUND  The non-array configure language string 
> is
> retured.
> +  @retval EFI_NOT_FOUND  The non-array configure language string 
> is
> returned.
>@retval EFI_INVALID_PARAMETER  The format of input ConfigureLang is
> wrong.
>@retval Others Errors occur.
> 
> @@ -118,10 +118,10 @@ GetNumberOfRedpathNodes (
> 
>@param[in]  NodeString The node string to parse.
>@param[in]  Index  Index of the node.
> -  @param[out] EndOfNodePtr   Pointer to receive the poitner to
> +  @param[out] EndOfNodePtr   Pointer to receive the pointer to
>   the last character of node string.
> 
> -  @retval EFI_STRING the begining of the node string.
> +  @retval EFI_STRING the beginning of the node string.
> 
>  **/
>  EFI_STRING
> @@ -140,7 +140,7 @@ GetRedpathNodeByIndex (
>@param[out] Index The array index number.
> 
>@retval EFI_SUCCESSIndex is found.
> -  @retval EFI_NOT_FOUND  The non-array configure language string 
> is
> retured.
> +  @retval EFI_NOT_FOUND  The non-array configure language string 
> is
> returned.
>@retval EFI_INVALID_PARAMETER  The format of input ConfigureLang is
> wrong.
>@retval Others Errors occur.
> 
> @@ -188,7 +188,7 @@ DestroyConfiglanguageList (
> 
>@param[in]  DestConfigLangPointer to the node's configure language
> string.
> 

[edk2-devel] [edk2-redfish-client][PATCH v2] RedfishClientPkg/RedfishFeatureUtilityLib: validate string array

[Nickle Wang via groups.io]

Add function ValidateRedfishStringArrayValues to validate Redfish
request for string array type. There is case that user request
invalid string array and feature driver can not find corresponding
HII option.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 .../Library/RedfishFeatureUtilityLib.h|  28 +++
 .../RedfishFeatureUtilityLib.c| 187 ++
 2 files changed, 172 insertions(+), 43 deletions(-)

diff --git a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h 
b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
index 6347585c..24f0ad24 100644
--- a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
+++ b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
@@ -990,4 +990,32 @@ GetPendingSettings (
   OUT EFI_STRING*SettingUri
   );
 
+/**
+  This function goes through Head and StringArray to check below:
+  1) Check and see if value in Redfish string array can be found in HII
+  configuration string array. This is to see if there is any invalid
+  values from Redfish.
+  2) Check and see if size of Head is the same as ArraySize.
+  3) Check and see if value in Redfish string array are all the same as the one
+  from HII configuration.
+
+  @param[in]  Head  The head of string array.
+  @param[in]  StringArray   Input string array.
+  @param[in]  ArraySize The size of StringArray.
+  @param[out] ValueChanged  TRUE when The order of Head is not the same as the 
order of StringArray.
+FALSE when Head and StringArray are identical.
+
+  @retval  EFI_INVALID_PARAMETER  Input parameter is NULL or ArraySize is 0.
+  @retval  EFI_NOT_FOUND  The element in Head cannot be found in 
StringArray. This is invalid request.
+  @retval  EFI_BAD_BUFFER_SIZEThe size of Head is not the same as the size 
of StringArray. This is invalid request.
+
+**/
+EFI_STATUS
+ValidateRedfishStringArrayValues (
+  IN RedfishCS_char_Array  *Head,
+  IN CHAR8 **StringArray,
+  IN UINTN ArraySize,
+  OUT BOOLEAN  *ValueChanged
+  );
+
 #endif
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 6652539c..07033488 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -866,6 +866,7 @@ ApplyFeatureSettingsStringArrayType (
   EDKII_REDFISH_VALUE   RedfishValue;
   UINTN Index;
   RedfishCS_char_Array  *Buffer;
+  BOOLEAN   ValueChanged;
 
   if (IS_EMPTY_STRING (Schema) || IS_EMPTY_STRING (Version) || IS_EMPTY_STRING 
(ConfigureLang) || (ArrayHead == NULL)) {
 return EFI_INVALID_PARAMETER;
@@ -886,61 +887,69 @@ ApplyFeatureSettingsStringArrayType (
   }
 
   //
-  // If there is no change in array, do nothing
+  // Validate input string array from BMC to see:
+  // 1) String array from BMC is valid or not.
+  // 2) If there is no change in array, do nothing.
   //
-  if (!CompareRedfishStringArrayValues (ArrayHead, 
RedfishValue.Value.StringArray, RedfishValue.ArrayCount)) {
-//
-// Apply settings from redfish
-//
-DEBUG ((DEBUG_MANAGEABILITY, "%a: %a.%a apply %s for array\n", __func__, 
Schema, Version, ConfigureLang));
-FreeArrayTypeRedfishValue ();
-
-//
-// Convert array from RedfishCS_char_Array to EDKII_REDFISH_VALUE
-//
-RedfishValue.ArrayCount = 0;
-Buffer  = ArrayHead;
-while (Buffer != NULL) {
-  RedfishValue.ArrayCount += 1;
-  Buffer   = Buffer->Next;
-}
+  Status = ValidateRedfishStringArrayValues (ArrayHead, 
RedfishValue.Value.StringArray, RedfishValue.ArrayCount, );
+  if (!EFI_ERROR (Status)) {
+if (ValueChanged) {
+  //
+  // Apply settings from redfish
+  //
+  DEBUG ((DEBUG_MANAGEABILITY, "%a: %a.%a apply %s for array\n", __func__, 
Schema, Version, ConfigureLang));
+  FreeArrayTypeRedfishValue ();
 
-//
-// Allocate pool for new values
-//
-RedfishValue.Value.StringArray = AllocatePool (RedfishValue.ArrayCount 
*sizeof (CHAR8 *));
-if (RedfishValue.Value.StringArray == NULL) {
-  ASSERT (FALSE);
-  return EFI_OUT_OF_RESOURCES;
-}
+  //
+  // Convert array from RedfishCS_char_Array to EDKII_REDFISH_VALUE
+  //
+  RedfishValue.ArrayCount = 0;
+  Buffer  = ArrayHead;
+  while (Buffer != NULL) {
+RedfishValue.ArrayCount += 1;
+Buffer   = Buffer->Next;
+  }
 
-Buffer = ArrayHead;
-Index  = 0;
-while (Buffer != NULL) {
-  RedfishValue.Value.StringArray[Index] = AllocateCopyPool (AsciiStrSize 
(Buffer->ArrayValue), Buffer->ArrayValue);
-  if (RedfishValue.Value.StringArray[Index] == NULL) {
+  //
+   

Re: [edk2-devel] [PATCH V3 0/9] Refine BMC USB NIC discovery and Redfish service enablement

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Hi Mike, would you like to having you Acked-by on each commit?

Abner

> -Original Message-
> From: Mike Maslenkin 
> Sent: Monday, December 4, 2023 3:18 PM
> To: Chang, Abner 
> Cc: devel@edk2.groups.io; Nickle Wang ; Igor
> Kulchytskyy 
> Subject: Re: [PATCH V3 0/9] Refine BMC USB NIC discovery and Redfish
> service enablement
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, Nov 27, 2023 at 8:31 AM  wrote:
> >
> > From: Abner Chang 
> >
> > In V3: Address Mike's comments to V2.
> >
> > In V2: Send additional two patches those are missed
> >in V1.
> >
> > This patch set updates the algorithm of BMC USB
> > NIC discovery and fixes some bugs.
> >
> > - Add a new protocol to trigger the notification
> >   of Redfish Host Interface readiness.
> >   This fixes the issue Redfish config handler driver
> >   acquires Redfish service before Redfish Host
> >   Interface is published.
> > - Add more error debug messages.
> > - Address some minor issues
> >
> > Signed-off-by: Abner Chang 
> > Cc: Nickle Wang 
> > Cc: Igor Kulchytskyy 
> > Cc: Mike Maslenkin 
> >
> > Abner Chang (9):
> >   RedfishPkg/BmcUsbNicLib: Update BMC USB NIC searching algorithm
> >   RedfishPkg/RedfishHostInterfaceDxe: Add Redfish HI readiness
> > notification
> >   RedfishPkg/RedfishConfigHandler: Use Redfish HI readiness notification
> >   RedfishPkg/RedfishConfigHandler: Correct the prototype of callback
> > function
> >   RedfishPkg/RedfishDiscovery: Add more debug message
> >   RedfishPkg/RedfishDiscovery: Refine SMBIOS 42h code
> >   RedfishPkg/HostInterfaceBmcUsbNic: Fix incorrect reference of MAC
> > address pointer
> >   RedfishPkg/HostInterfaceBmcUsbNic: Fix incorrect HI protocol record
> > size
> >   RedfishPkg/HostInterfaceBmcUsbNic: Fix potential memory corruption
> > issue
> >
> >  RedfishPkg/RedfishPkg.dec |   3 +
> >  .../RedfishConfigHandlerDriver.inf|   9 +-
> >  .../RedfishHostInterfaceDxe.inf   |   3 +-
> >  .../RedfishDiscoverInternal.h |   2 +
> >  .../PlatformHostInterfaceBmcUsbNicLib.c   | 196 --
> >  .../RedfishConfigHandlerDriver.c  | 170 +--
> >  .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   |  23 ++
> >  .../RedfishSmbiosHostInterface.c  |  20 +-
> >  .../RedfishHostInterfaceDxe.c |  18 ++
> >  9 files changed, 315 insertions(+), 129 deletions(-)
> >
> > --
> > 2.37.1.windows.1
> >
>
> Looks good to me.
> Thank you.
>
> Regards,
> Mike


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

[edk2-devel] [PATCH v9 5/5] OvmfPkg/RiscVVirt: Override for RV CPU Features

[Dhaval Sharma]

This PCD provides a way for platform to override any
HW features that are default enabled by previous stages
of FW (like OpenSBI). For the case where previous/prev
stage has disabled the feature, this override is not
useful and its usage should be avoided.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Sunil V L 
Cc: Andrei Warkentin 
Cc: Laszlo Ersek 

Signed-off-by: Dhaval Sharma 
Acked-by: Laszlo Ersek 
Reviewed-by: Andrei Warkentin 
---

Notes:
V8:
- Added RV tag
V7:
- Added RB tag
v6:
- Modify PCD name according to changes made in Baselib implementation
V5:
- Introduce PCD for platform

 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
index fe320525153f..5d66f7fe6ae6 100644
--- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
+++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
@@ -203,6 +203,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 
 [PcdsFixedAtBuild.common]
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|0
-- 
2.39.2



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

[edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Dhaval Sharma]

Use newly defined cache management operations for RISC-V where possible
It builds up on the support added for RISC-V cache management
instructions in BaseLib.
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Laszlo Ersek 

Signed-off-by: Dhaval Sharma 
Acked-by: Laszlo Ersek 
---

Notes:
V9:
- Fixed an issue with Instruction cache invalidation. Use fence.i
  instruction as CMO does not support i-cache operations.
V8:
- Added note to convert PCD into RISC-V feature bitmap pointer
- Modified function names to be more explicit about cache ops
- Added RB tag
V7:
- Added PcdLib
- Restructure DEBUG message based on feedback on V6
- Make naming consistent to CMO, remove all CBO references
- Add ASSERT for not supported functions instead of plain debug message
- Added RB tag
V6:
- Utilize cache management instructions if HW supports it
  This patch is part of restructuring on top of v5

 MdePkg/MdePkg.dec  |   8 +
 MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
 MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 173 

 MdePkg/MdePkg.uni  |   4 +
 4 files changed, 160 insertions(+), 30 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index ac54338089e8..fa92673ff633 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, PcdsPatchableInModule.AARCH64]
   # @Prompt CPU Rng algorithm's GUID.
   
gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
 
+[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
+  #
+  # Configurability to override RISC-V CPU Features
+  # BIT 0 = Cache Management Operations. This bit is relevant only if
+  # previous stage has feature enabled and user wants to disable it.
+  #
+  
gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
+
 [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
   ## This value is used to set the base address of PCI express hierarchy.
   # @Prompt PCI Express Base Address.
diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf 
b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
index 6fd9cbe5f6c9..601a38d6c109 100644
--- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
+++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
@@ -56,3 +56,8 @@ [LibraryClasses]
   BaseLib
   DebugLib
 
+[LibraryClasses.RISCV64]
+  PcdLib
+
+[Pcd.RISCV64]
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
index ac2a3c23a249..cacc38eff4f4 100644
--- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
+++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
@@ -2,6 +2,7 @@
   RISC-V specific functionality for cache.
 
   Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+  Copyright (c) 2023, Rivos Inc. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
@@ -9,10 +10,117 @@
 #include 
 #include 
 #include 
+#include 
+
+//
+// TODO: Grab cache block size and make Cache Management Operation
+// enabling decision based on RISC-V CPU HOB in
+// future when it is available and convert PcdRiscVFeatureOverride
+// PCD to a pointer that contains pointer to bitmap structure
+// which can be operated more elegantly.
+//
+#define RISCV_CACHE_BLOCK_SIZE 64
+#define RISCV_CPU_FEATURE_CMO_BITMASK  0x1
+
+typedef enum {
+  CacheOpClean,
+  CacheOpFlush,
+  CacheOpInvld,
+} CACHE_OP;
+
+/**
+Verify CBOs are supported by this HW
+TODO: Use RISC-V CPU HOB once available.
+
+**/
+STATIC
+BOOLEAN
+RiscVIsCMOEnabled (
+  VOID
+  )
+{
+  // If CMO is disabled in HW, skip Override check
+  // Otherwise this PCD can override settings
+  return ((PcdGet64 (PcdRiscVFeatureOverride) & RISCV_CPU_FEATURE_CMO_BITMASK) 
!= 0);
+}
+
+/**
+  Performs required opeartion on cache lines in the cache coherency domain
+  of the calling CPU. If Address is not aligned on a cache line boundary,
+  then entire cache line containing Address is operated. If Address + Length
+  is not aligned on a cache line boundary, then the entire cache line
+  containing Address + Length -1 is operated.
+  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
+  @param  Address The base address of the cache lines to
+  invalidate.
+  @param  Length  The number of bytes to invalidate from the instruction
+  cache.
+  @param  Op  Type of CMO operation to be performed
+  @return Address.
+
+**/
+STATIC
+VOID
+CacheOpCacheRange (
+  IN VOID  *Address,
+  IN UINTN Length,
+  IN CACHE_OP  

[edk2-devel] [PATCH v9 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Dhaval Sharma]

Implement Cache Management Operations (CMO) defined by
RISC-V spec https://github.com/riscv/riscv-CMOs.

Notes:
1. CMO only supports block based Operations. Meaning cache
   flush/invd/clean Operations are not available for the entire
   range. In that case we fallback on fence.i instructions.
2. Operations are implemented using Opcodes to make them compiler
   independent. binutils 2.39+ compilers support CMO instructions.

Test:
1. Ensured correct instructions are refelecting in asm
2. Qemu implements basic support for CMO operations in that it allwos
   instructions without exceptions. Verified it works properly in
   that sense.
3. SG2042Pkg implements CMO-like instructions. It was verified that
   CpuFlushCpuDataCache works fine. This more of less
   confirms that framework is alright.
4. TODO: Once Silicon is available with exact instructions, we will
   further verify this.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Sunil V L 
Cc: Daniel Schaefer 
Cc: Laszlo Ersek 

Signed-off-by: Dhaval Sharma 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Sunil V L 
Reviewed-by: Jingyu Li 
---

Notes:
v8:
- Add *asm* postfix to cmo functions
- Add reviewed by tags
V7:
- Modify instruction names as per feedback from V6
- Added RB
V6:
- Implement Cache management instructions in Baselib

 MdePkg/Library/BaseLib/BaseLib.inf|  2 +-
 MdePkg/Include/Library/BaseLib.h  | 33 

 MdePkg/Include/RiscV64/RiscVasm.inc   | 19 
+++
 MdePkg/Library/BaseLib/RiscV64/{FlushCache.S => RiscVCacheMgmt.S} | 17 
++
 4 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 03c7b02e828b..53389389448c 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -400,7 +400,7 @@ [Sources.RISCV64]
   RiscV64/RiscVCpuBreakpoint.S  | GCC
   RiscV64/RiscVCpuPause.S   | GCC
   RiscV64/RiscVInterrupt.S  | GCC
-  RiscV64/FlushCache.S  | GCC
+  RiscV64/RiscVCacheMgmt.S  | GCC
   RiscV64/CpuScratch.S  | GCC
   RiscV64/ReadTimer.S   | GCC
   RiscV64/RiscVMmu.S| GCC
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index d80e27285424..47424709cd72 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -226,6 +226,39 @@ RiscVInvalidateDataCacheFenceAsm (
   VOID
   );
 
+/**
+  RISC-V flush cache block. Atomically perform a clean operation
+  followed by an invalidate operation
+
+**/
+VOID
+EFIAPI
+RiscVCpuCacheFlushCmoAsm (
+  IN UINTN
+  );
+
+/**
+Perform a write transfer to another cache or to memory if the
+data in the copy of the cache block have been modified by a store
+operation
+
+**/
+VOID
+EFIAPI
+RiscVCpuCacheCleanCmoAsm (
+  IN UINTN
+  );
+
+/**
+Deallocate the copy of the cache block
+
+**/
+VOID
+EFIAPI
+RiscVCpuCacheInvalCmoAsm (
+  IN UINTN
+  );
+
 #endif // defined (MDE_CPU_RISCV64)
 
 #if defined (MDE_CPU_LOONGARCH64)
diff --git a/MdePkg/Include/RiscV64/RiscVasm.inc 
b/MdePkg/Include/RiscV64/RiscVasm.inc
new file mode 100644
index ..29de7358855c
--- /dev/null
+++ b/MdePkg/Include/RiscV64/RiscVasm.inc
@@ -0,0 +1,19 @@
+/*
+ *
+ * RISC-V cache operation encoding.
+ * Copyright (c) 2023, Rivos Inc. All rights reserved.
+ * SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ */
+
+.macro RISCVCMOFLUSH
+.word 0x25200f
+.endm
+
+.macro RISCVCMOINVALIDATE
+.word 0x05200f
+.endm
+
+.macro RISCVCMOCLEAN
+.word 0x15200f
+.endm
diff --git a/MdePkg/Library/BaseLib/RiscV64/FlushCache.S 
b/MdePkg/Library/BaseLib/RiscV64/RiscVCacheMgmt.S
similarity index 56%
rename from MdePkg/Library/BaseLib/RiscV64/FlushCache.S
rename to MdePkg/Library/BaseLib/RiscV64/RiscVCacheMgmt.S
index 8cfb85097996..4752aa72d95e 100644
--- a/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
+++ b/MdePkg/Library/BaseLib/RiscV64/RiscVCacheMgmt.S
@@ -3,10 +3,12 @@
 // RISC-V cache operation.
 //
 // Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+// Copyright (c) 2023, Rivos Inc. All rights reserved.
 //
 // SPDX-License-Identifier: BSD-2-Clause-Patent
 //
 
//--
+.include "RiscVasm.inc"
 
 .align 3
 ASM_GLOBAL ASM_PFX(RiscVInvalidateInstCacheFenceAsm)
@@ -19,3 +21,18 @@ ASM_PFX(RiscVInvalidateInstCacheFenceAsm):
 ASM_PFX(RiscVInvalidateDataCacheFenceAsm):
 fence
 ret
+
+ASM_GLOBAL ASM_PFX (RiscVCpuCacheFlushCmoAsm)
+ASM_PFX (RiscVCpuCacheFlushCmoAsm):
+RISCVCMOFLUSH
+ret
+
+ASM_GLOBAL ASM_PFX (RiscVCpuCacheCleanCmoAsm)
+ASM_PFX (RiscVCpuCacheCleanCmoAsm):
+RISCVCMOCLEAN
+ret
+
+ASM_GLOBAL ASM_PFX (RiscVCpuCacheInvalCmoAsm)
+ASM_PFX (RiscVCpuCacheInvalCmoAsm):
+RISCVCMOINVALIDATE
+ret
-- 

[edk2-devel] [PATCH v9 2/5] MdePkg: Rename Cache Management Function To Clarify Fence Based Op

[Dhaval Sharma]

There are different ways to manage cache on RISC-V Processors.
One way is to use fence instruction. Another way is to use CPU
specific cache management operation instructions ratified as
per RISC-V ISA specifications to be introduced in future
patches. Current method is fence instruction based, rename the
function accordingly to add that clarity.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Sunil V L 
Cc: Daniel Schaefer 
Cc: Laszlo Ersek 

Signed-off-by: Dhaval Sharma 
Reviewed-by: Laszlo Ersek 
---

Notes:
V8:
- Update function name to udpate *asm* in the end
V7:
- Add RB tag
V6:
- As part of restructuring, adding cache instruction differentiation
  in function naming

 MdePkg/Include/Library/BaseLib.h| 4 ++--
 MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c | 4 ++--
 MdePkg/Library/BaseLib/RiscV64/FlushCache.S | 8 
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 7142bbfa42f2..d80e27285424 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -212,7 +212,7 @@ RiscVClearPendingTimerInterrupt (
 **/
 VOID
 EFIAPI
-RiscVInvalidateInstCacheAsm (
+RiscVInvalidateInstCacheFenceAsm (
   VOID
   );
 
@@ -222,7 +222,7 @@ RiscVInvalidateInstCacheAsm (
 **/
 VOID
 EFIAPI
-RiscVInvalidateDataCacheAsm (
+RiscVInvalidateDataCacheFenceAsm (
   VOID
   );
 
diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
index d5efcf49a4bf..ac2a3c23a249 100644
--- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
+++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
@@ -21,7 +21,7 @@ InvalidateInstructionCache (
   VOID
   )
 {
-  RiscVInvalidateInstCacheAsm ();
+  RiscVInvalidateInstCacheFenceAsm ();
 }
 
 /**
@@ -193,7 +193,7 @@ InvalidateDataCache (
   VOID
   )
 {
-  RiscVInvalidateDataCacheAsm ();
+  RiscVInvalidateDataCacheFenceAsm ();
 }
 
 /**
diff --git a/MdePkg/Library/BaseLib/RiscV64/FlushCache.S 
b/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
index 7c10fdd268af..8cfb85097996 100644
--- a/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
+++ b/MdePkg/Library/BaseLib/RiscV64/FlushCache.S
@@ -9,13 +9,13 @@
 
//--
 
 .align 3
-ASM_GLOBAL ASM_PFX(RiscVInvalidateInstCacheAsm)
-ASM_GLOBAL ASM_PFX(RiscVInvalidateDataCacheAsm)
+ASM_GLOBAL ASM_PFX(RiscVInvalidateInstCacheFenceAsm)
+ASM_GLOBAL ASM_PFX(RiscVInvalidateDataCacheFenceAsm)
 
-ASM_PFX(RiscVInvalidateInstCacheAsm):
+ASM_PFX(RiscVInvalidateInstCacheFenceAsm):
 fence.i
 ret
 
-ASM_PFX(RiscVInvalidateDataCacheAsm):
+ASM_PFX(RiscVInvalidateDataCacheFenceAsm):
 fence
 ret
-- 
2.39.2



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

[edk2-devel] [PATCH v9 1/5] MdePkg: Move RISC-V Cache Management Declarations Into BaseLib

[Dhaval Sharma]

The declarations for cache Management functions belong to BaseLib
instead of instance source file. This helps with further restructuring
of cache management code for RISC-V.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Laszlo Ersek 

Signed-off-by: Dhaval Sharma 
Reviewed-by: Laszlo Ersek 
---

Notes:
V7:
- Added RB tag
V6:
- Move cache management function declaration in baselib where it belongs

 MdePkg/Include/Library/BaseLib.h| 20 
 MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c | 20 
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 5d7067ee854e..7142bbfa42f2 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -206,6 +206,26 @@ RiscVClearPendingTimerInterrupt (
   VOID
   );
 
+/**
+  RISC-V invalidate instruction cache.
+
+**/
+VOID
+EFIAPI
+RiscVInvalidateInstCacheAsm (
+  VOID
+  );
+
+/**
+  RISC-V invalidate data cache.
+
+**/
+VOID
+EFIAPI
+RiscVInvalidateDataCacheAsm (
+  VOID
+  );
+
 #endif // defined (MDE_CPU_RISCV64)
 
 #if defined (MDE_CPU_LOONGARCH64)
diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
index d08fb9f193ca..d5efcf49a4bf 100644
--- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
+++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
@@ -10,26 +10,6 @@
 #include 
 #include 
 
-/**
-  RISC-V invalidate instruction cache.
-
-**/
-VOID
-EFIAPI
-RiscVInvalidateInstCacheAsm (
-  VOID
-  );
-
-/**
-  RISC-V invalidate data cache.
-
-**/
-VOID
-EFIAPI
-RiscVInvalidateDataCacheAsm (
-  VOID
-  );
-
 /**
   Invalidates the entire instruction cache in cache coherency domain of the
   calling CPU.
-- 
2.39.2



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

[edk2-devel] [PATCH v9 0/5] Cache Management Operations Support For RISC-V

[Dhaval Sharma]

Implementing code to support Cache Management Operations (CMO) defined by
RISC-V CMO instructions.https://github.com/riscv/riscv-CMOs
This is a re-write of original series v5.
The patchset contains 5 patches- created based on V5 feedback.
1. Restructuring of existing code and move instruction declarations into BaseLib
2. Renaming existing functions to denote type of instruction used to maanage 
cache.
   This is useful for further patches where more cache management instructions 
are added.
3. Add the new cache maintenance operations to BaseLib, including the
 new assembly instruction encodings.
4. Update BaseCacheMaintenanceLib (utilizing the new BaseLib primitives)
5. Add platform level PCD to allow overriding of RISC-V features.

Code Link: https://github.com/tianocore/edk2/pull/5103

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Sunil V L 
Cc: Andrei Warkentin 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Daniel Schaefer 


Dhaval (5):
  MdePkg: Move RISC-V Cache Management Declarations Into BaseLib
  MdePkg: Rename Cache Management Function To Clarify Fence Based Op
  MdePkg: Implement RISC-V Cache Management Operations
  MdePkg: Utilize Cache Management Operations Implementation For RISC-V
  OvmfPkg/RiscVVirt: Override for RV CPU Features

 MdePkg/MdePkg.dec  |   8 +
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc|   1 +
 MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
 MdePkg/Library/BaseLib/BaseLib.inf |   2 +-
 MdePkg/Include/Library/BaseLib.h   |  53 ++
 MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 177 
+++-
 MdePkg/Include/RiscV64/RiscVasm.inc|  19 +++
 MdePkg/Library/BaseLib/RiscV64/FlushCache.S|  21 ---
 MdePkg/Library/BaseLib/RiscV64/RiscVCacheMgmt.S|  38 +
 MdePkg/MdePkg.uni  |   4 +
 10 files changed, 264 insertions(+), 64 deletions(-)
 create mode 100644 MdePkg/Include/RiscV64/RiscVasm.inc
 delete mode 100644 MdePkg/Library/BaseLib/RiscV64/FlushCache.S
 create mode 100644 MdePkg/Library/BaseLib/RiscV64/RiscVCacheMgmt.S

-- 
2.39.2



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