[edk2-devel] [PATCH v2 0/1] Add support for generating SRAT tables

[Xiong Yining]

SbsaQemu can configure with numa-related arguments, but OS cannot
identify the numa architecture without SRAT tables. We add supporting
for generating SRAT tables at runtime to solve this issue.

the numa-related information and memory information can be obtained via
SMC calls which is provided on the EDK2 patch "get rid of DeviceTree from 
SbsaQemu" 
https://openfw.io/edk2-devel/20240131132400.3022662-1-xiongyining1...@phytium.com.cn/

when this patch is applied, there is only the first memory node can be 
identified by OS, this is because UEFI only allocates the first memory node 
memory space for SbsaQemu platform. we can use patch "Support multi memory 
nodes"
to solve it.

changes in v2:
- fix the compile error which is caused by redundant "+" in SbsaQemuAcpiDxe.h.

Xiong Yining (1):
  SbsaQemu: AcpiDxe: Create SRAT table at runtime

 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 27 ++
 .../Include/Library/SbsaQemuHardwareInfoLib.h | 11 +++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 92 +++
 .../SbsaQemuHardwareInfoLib.c | 36 
 4 files changed, 166 insertions(+)

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115639): https://edk2.groups.io/g/devel/message/115639
Mute This Topic: https://groups.io/mt/104463804/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] SbsaQemu: AcpiDxe: Create SRAT table at runtime

[Xiong Yining]

Add support to create SRAT(System resource affinity table) for
sbsa platform at runtime.

Signed-off-by: Xiong Yining 
Signed-off-by: Chen Baozi 
Reviewed-by: Marcin Juszkiewicz 

---
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 27 ++
 .../Include/Library/SbsaQemuHardwareInfoLib.h | 11 +++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 92 +++
 .../SbsaQemuHardwareInfoLib.c | 36 
 4 files changed, 166 insertions(+)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
index 7595df4c8a2d..83a085cd86f4 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
@@ -63,4 +63,31 @@ typedef struct {
 
 #define GTDT_WDTIMER_FLAGS  (GTDT_WDTIMER_ACTIVE_HIGH | 
GTDT_WDTIMER_LEVEL_TRIGGERED)
 
+#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(  
   \
+  ProximityDomain, Base, Length, Flags)
   \
+  {
   \
+1,  /* Type */ 
   \
+sizeof (EFI_ACPI_6_4_MEMORY_AFFINITY_STRUCTURE),/* Length */   
   \
+ProximityDomain,/* Proximity Domain */ 
   \
+0,  /* Reserved */ 
   \
+(Base) & 0x,/* Base Address Low */ 
   \
+((Base) >> 32) & 0x ,   /* Base Address High 
*/   \
+(Length) & 0x,  /* Length Low */   
   \
+((Length) >> 32) & 0x,  /* Length High */  
   \
+0,  /* Reserved */ 
   \
+Flags,  /* Flags */
   \
+0   /* Reserved */ 
   \
+  }
+
+#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(
   \
+  ProximityDomain, ACPIProcessorUID, Flags, ClockDomain)   
   \
+  {
   \
+3,  /* Type */ 
   \
+sizeof (EFI_ACPI_6_4_GICC_AFFINITY_STRUCTURE),  /* Length */   
   \
+ProximityDomain,/* Proximity Domain */ 
   \
+ACPIProcessorUID,   /* ACPI Processor UID 
*/  \
+Flags,  /* Flags */
   \
+ClockDomain /* Clock Domain */ 
   \
+  }
+
 #endif
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
index 0b71a3f7e6eb..831efe2e8d1d 100644
--- a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
@@ -70,4 +70,15 @@ SbsaQemuGetMemInfo (
   IN UINTN   MemoryId
   );
 
+/**
+  Get the number of numa node from device tree passed by Qemu.
+
+  @retvalthe number of numa node.
+**/
+UINT64
+SbsaQemuGetNumaNodeCount (
+  VOID
+  );
+
+
 #endif /* SBSA_QEMU_HARDWARE_INFO_ */
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 03f7a34977a0..2685d4b00426 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -682,6 +682,91 @@ AddGtdtTable (
   return Status;
 }
 
+/*
+ * A function that adds the SRAT ACPI table.
+ */
+EFI_STATUS
+AddSratTable (
+  IN EFI_ACPI_TABLE_PROTOCOL   *AcpiTable
+  )
+{
+  EFI_STATUSStatus;
+  UINT8 *New;
+  EFI_PHYSICAL_ADDRESS  PageAddress;
+  UINTN TableHandle;
+  UINT32TableSize;
+  UINT32Index;
+  UINT32NodeId;
+  UINT32NumMemNodes;
+  MemoryInfoMemInfo;
+  UINT32NumCores = PcdGet32 (PcdCoreCount);
+
+  // Initialize SRAT ACPI Header
+  EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_HEADER Header = {
+ SBSAQEMU_ACPI_HEADER 
(EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_SIGNATURE,
+   EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_HEADER,
+   
EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_REVISION),
+  1, 0 };
+
+  NumMemNodes  = SbsaQemuGetMemNodeCount();
+
+  // Calculate the new table size based on the number of cores
+  TableSize = sizeof (EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_HEADER) +
+ 

Re: [edk2-devel] [PATCH 5/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SaveCpuMpData()

[Ni, Ray]

> 
> > +
> > +  if (CpuMpData->ApLoopMode != ApInHltLoop) {
> > +MpHandOff->StartupSignalValue= MP_HAND_OFF_SIGNAL;
> > +MpHandOff->WaitLoopExecutionMode = sizeof (VOID *);
> > +  }
> > +}
> 
> As noted elsewhere, these fields don't belong in the loop (they don't
> belong to MP_HAND_OFF, going forward); the two of them together should
> form a new singleton structure.
> 

I agree the StartupSignalValue and WaitLoopExecutionMode are duplicated fields
if multiple MP_HAND_OFF instances are created.

I am ok to leave them as duplicates in this patch series.



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

[edk2-devel] [PATCH v3 1/1] SbsaQemu: add memory space for the high memory nodes

[Xiong Yining]

To support more memory nodes, we refer to the implement of
"OvmfPkg/Fdt/HighMemDxe" to add memory space for the high memory nodes
except the first one.

Signed-off-by: Xiong Yining 
Signed-off-by: Chen Baozi 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   1 +
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   1 +
 .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf |  45 ++
 .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c   | 134 ++
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
 create mode 100644 
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index bde61651da2e..e48bb8eb0174 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -675,6 +675,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
+  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
 
   #
   # FAT filesystem + GPT/MBR partitioning
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
index 6fcfd25faaeb..b35f42e11aa4 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
@@ -161,6 +161,7 @@ READ_LOCK_STATUS   = TRUE
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
   INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+  INF Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
 
   #
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
new file mode 100644
index ..85bfb722affa
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
@@ -0,0 +1,45 @@
+## @file
+#  High memory node enumeration DXE driver for SbsaQemu
+#
+#  Copyright (c) 2023, Linaro Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = SbsaQemuHighMemDxe
+  FILE_GUID  = 9E749C5E-C282-32F8-7CC3-E5A3DDE15329
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= InitializeHighMemDxe
+
+[Sources]
+  SbsaQemuHighMemDxe.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ArmPkg/ArmPkg.dec
+  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  DxeServicesTableLib
+  PcdLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  SbsaQemuHardwareInfoLib
+
+[Protocols]
+  gEfiCpuArchProtocolGuid ## CONSUMES
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy
+  gArmTokenSpaceGuid.PcdSystemMemoryBase
+
+[Depex]
+  gEfiCpuArchProtocolGuid
diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
new file mode 100644
index ..35ccf8eb942b
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
@@ -0,0 +1,134 @@
+/** @file
+*  High memory node enumeration DXE driver for SbsaQemu
+*  Virtual Machines
+*
+*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+EFI_STATUS
+EFIAPI
+InitializeHighMemDxe (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_CPU_ARCH_PROTOCOL*Cpu;
+  EFI_STATUS   Status;
+  UINT32   NumMemNodes;
+  UINT32   index;
+  UINT64   CurBase;
+  UINT64   CurSize;
+  UINT64   Attributes;
+  MemoryInfo   MemInfo;
+  EFI_GCD_MEMORY_SPACE_DESCRIPTOR  GcdDescriptor;
+
+  Status = gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **)
+  );
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Check for memory node and add the memory spaces except the lowest one
+  //
+  NumMemNodes = SbsaQemuGetMemNodeCount();
+  for (index = 0; index < NumMemNodes; index++){
+MemInfo = SbsaQemuGetMemInfo(index);
+CurBase = MemInfo.AddressBase;
+CurSize = MemInfo.AddressSize;
+
+if (CurBase > PcdGet64 (PcdSystemMemoryBase)) {
+  Status = gDS->GetMemorySpaceDescriptor (CurBase, );
+  if (EFI_ERROR (Status)) {
+DEBUG ((
+  DEBUG_WARN,
+  "%a: Region 0x%lx - 0x%lx not found in the GCD memory 

[edk2-devel] [PATCH v3 0/1] support multi memory nodes

[Xiong Yining]

When SaSbQemu platform is configured with multi memory nodes, like 
numa architecture, os will ignore any memory node in the device tree 
except the first one. The kernel reads UEFI memory map for memory 
information when booting via UEFI. 

However UEFI only allocates the first memory node memory space for 
SbsaQemu platform, in this scenario we can refer to the implement 
of "OvmfPkg/Fdt/HighMemDxe" and use the GCD services to add memory 
spaces for high memory node.

Instead of using FdtClientDxe driver to get the informatin of memory, 
we get the hardware information of memory via SMC calls, which is proposed
on get rid of DeviceTree from SbsaQemu:
https://openfw.io/edk2-devel/20240131132400.3022662-1-xiongyining1...@phytium.com.cn/

Changes in v2:
- get the information of memory via SMC rather than FdtClientDxe.
- add a new driver rather than use HighMemDxe. 

Changes in v3:
- when the memory node is the first one, there is no need to add it.

Xiong Yining (1):
  SbsaQemu: add memory space for the high memory nodes

 Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   3 +-
 Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   1 +
 .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf |  45 ++
 .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c   | 134 ++
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
 create mode 100644 
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c

-- 
2.34.1



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

[edk2-devel] [PATCH v1 2/3] DynamicTablesPkg: Adds ACPI HPET Table generator

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Adds generic ACPI HPET table generator library.
Register/Deregister HPET table.
Update the HPET table during boot as per specification.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
 DynamicTablesPkg/DynamicTables.dsc.inc|   2 +
 DynamicTablesPkg/DynamicTablesPkg.ci.yaml |   3 +-
 DynamicTablesPkg/Include/AcpiTableGenerator.h |   1 +
 .../Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf  |  38 
 .../Library/Acpi/AcpiHpetLib/HpetGenerator.c  | 208 ++
 5 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index 5ec9ffac06..af70785520 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -35,6 +35,7 @@
   # Generators
   #
   DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
+  DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
 
   #
   # Dynamic Table Factory Dxe
@@ -42,6 +43,7 @@
   DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf {
 
   NULL|DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
+  NULL|DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
   }
 
 [Components.ARM, Components.AARCH64]
diff --git a/DynamicTablesPkg/DynamicTablesPkg.ci.yaml 
b/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
index 1ad5540e24..cacdaa1df6 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
+++ b/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
@@ -53,7 +53,8 @@
 "EmbeddedPkg/EmbeddedPkg.dec",
 "DynamicTablesPkg/DynamicTablesPkg.dec",
 "MdeModulePkg/MdeModulePkg.dec",
-"MdePkg/MdePkg.dec"
+"MdePkg/MdePkg.dec",
+"PcAtChipsetPkg/PcAtChipsetPkg.dec"
 ],
 # For host based unit tests
 "AcceptableDependencies-HOST_APPLICATION":[
diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h
index d0eda011c3..18b5f99f47 100644
--- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
+++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
@@ -99,6 +99,7 @@ typedef enum StdAcpiTableId {
   EStdAcpiTableIdSsdtCpuTopology,   ///< SSDT Cpu Topology
   EStdAcpiTableIdSsdtPciExpress,///< SSDT Pci Express Generator
   EStdAcpiTableIdPcct,  ///< PCCT Generator
+  EStdAcpiTableIdHpet,  ///< HPET Generator
   EStdAcpiTableIdMax
 } ESTD_ACPI_TABLE_ID;
 
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf 
b/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
new file mode 100644
index 00..74a1358ffe
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
@@ -0,0 +1,38 @@
+## @file
+#  HPET Table Generator
+#
+#  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 1.27
+  BASE_NAME  = AcpiHpetLib
+  FILE_GUID  = 4E75F653-C356-48B3-B32C-D1B901ECF90A
+  VERSION_STRING = 1.0
+  MODULE_TYPE= DXE_DRIVER
+  LIBRARY_CLASS  = NULL|DXE_DRIVER
+  CONSTRUCTOR= AcpiHpetLibConstructor
+  DESTRUCTOR = AcpiHpetLibDestructor
+
+[Sources]
+  HpetGenerator.c
+
+[Packages]
+  DynamicTablesPkg/DynamicTablesPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  PcAtChipsetPkg/PcAtChipsetPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  IoLib
+  PcdLib
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision
+  gPcAtChipsetPkgTokenSpaceGuid.PcdHpetBaseAddress
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c 
b/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c
new file mode 100644
index 00..e365746556
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c
@@ -0,0 +1,208 @@
+/** @file
+  HPET Table Generator
+
+  Copyright (c) 2017 - 2023, Arm Limited. All rights reserved.
+  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - ACPI 6.5 Specification, Aug 29, 2022
+  - HPET spec, version 1.0a
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** The AcpiHpet is a template EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_TABLE_HEADER
+structure used for generating the HPET Table.
+*/
+STATIC
+EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_TABLE_HEADER  mAcpiHpet = {
+  ACPI_HEADER (
+EFI_ACPI_6_5_HIGH_PRECISION_EVENT_TIMER_TABLE_SIGNATURE,
+EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_TABLE_HEADER,
+

[edk2-devel] [PATCH v1 3/3] DynamicTablesPkg: Adds ACPI WSMT Table generator

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Adds generic ACPI WSMT table generator library.
Register/Deregister WSMT table.
Update the WSMT table during boot as per specification.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
 DynamicTablesPkg/DynamicTables.dsc.inc|   2 +
 DynamicTablesPkg/Include/AcpiTableGenerator.h |   1 +
 .../Include/ArchNameSpaceObjects.h|  10 +
 .../Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf  |  34 +++
 .../Library/Acpi/AcpiWsmtLib/WsmtGenerator.c  | 221 ++
 5 files changed, 268 insertions(+)
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index af70785520..5e66f5cd02 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -36,6 +36,7 @@
   #
   DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
   DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
+  DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
 
   #
   # Dynamic Table Factory Dxe
@@ -44,6 +45,7 @@
 
   NULL|DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
   NULL|DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
+  NULL|DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
   }
 
 [Components.ARM, Components.AARCH64]
diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h
index 18b5f99f47..a32ef46ecb 100644
--- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
+++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
@@ -100,6 +100,7 @@ typedef enum StdAcpiTableId {
   EStdAcpiTableIdSsdtPciExpress,///< SSDT Pci Express Generator
   EStdAcpiTableIdPcct,  ///< PCCT Generator
   EStdAcpiTableIdHpet,  ///< HPET Generator
+  EStdAcpiTableIdWsmt,  ///< WSMT Generator
   EStdAcpiTableIdMax
 } ESTD_ACPI_TABLE_ID;
 
diff --git a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
index b421c4cd29..ad3045dfec 100644
--- a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
@@ -39,6 +39,7 @@ typedef enum ArchObjectID {
   EArchObjFadtArmBootArch,///< 11 - ARM boot arch information
   EArchObjFadtHypervisorVendorId, ///< 12 - Hypervisor vendor identity 
information
   EArchObjFadtMiscInfo,   ///< 13 - Legacy fields; RTC, latency, flush 
stride, etc
+  EArchObjWsmtProtectionFlags,///< 14 - WSMT protection flags
   EArchObjMax
 } E_ARCH_OBJECT_ID;
 
@@ -214,4 +215,13 @@ typedef struct CmArchFadtMiscInfo {
   UINT8 Century;
 } CM_ARCH_FADT_MISC_INFO;
 
+/** A structure that describes the
+protection flags for the WSMT fields information.
+
+ID: EArchObjWsmtProtectionFlags
+*/
+typedef struct CmArchWsmtProtectionFlags {
+  UINT32ProtectionFlags;
+} CM_ARCH_WSMT_PROTECTION_FLAGS;
+
 #endif
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf 
b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
new file mode 100644
index 00..f8683a5005
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
@@ -0,0 +1,34 @@
+## @file
+#  WSMT Table Generator
+#
+#  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 1.27
+  BASE_NAME  = AcpiWsmtLib
+  FILE_GUID  = D6C34086-C914-4F8E-B56A-08329B4D1271
+  VERSION_STRING = 1.0
+  MODULE_TYPE= DXE_DRIVER
+  LIBRARY_CLASS  = NULL|DXE_DRIVER
+  CONSTRUCTOR= AcpiWsmtLibConstructor
+  DESTRUCTOR = AcpiWsmtLibDestructor
+
+[Sources]
+  WsmtGenerator.c
+
+[Packages]
+  DynamicTablesPkg/DynamicTablesPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  PcdLib
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
new file mode 100644
index 00..c102152974
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
@@ -0,0 +1,221 @@
+/** @file
+  WSMT Table Generator
+
+  Copyright (c) 2017 - 2023, Arm Limited. All rights reserved.
+  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - ACPI 6.5 Specification, Aug 29, 2022
+  - WSMT spec, version 1.0, April 18, 2016
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** This macro expands to a function that retrieves the
+protection 

[edk2-devel] [PATCH v1 1/3] DynamicTablesPkg: Adds ACPI FADT Table generator

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Adds generic ACPI FADT table generator library.
Register/Deregister FADT table.
Adds Arch namespace ids.
Update the FADT table during boot as per specification.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
 DynamicTablesPkg/DynamicTables.dsc.inc|  10 +-
 DynamicTablesPkg/DynamicTablesPkg.ci.yaml |   4 +-
 .../Include/ArchNameSpaceObjects.h| 217 ++
 .../Include/ConfigurationManagerObject.h  |   6 +
 .../Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf  |  42 +
 .../Library/Acpi/AcpiFadtLib/FadtGenerator.c  | 737 ++
 .../Library/Acpi/AcpiFadtLib/FadtUpdate.h |  28 +
 .../Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c |  32 +
 8 files changed, 1074 insertions(+), 2 deletions(-)
 create mode 100644 DynamicTablesPkg/Include/ArchNameSpaceObjects.h
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtGenerator.c
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtUpdate.h
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index 19ca62d6a8..5ec9ffac06 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -31,10 +31,18 @@
   DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
 
 [Components.IA32, Components.X64]
+  #
+  # Generators
+  #
+  DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
+
   #
   # Dynamic Table Factory Dxe
   #
-  DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf
+  DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf {
+
+  NULL|DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
+  }
 
 [Components.ARM, Components.AARCH64]
   #
diff --git a/DynamicTablesPkg/DynamicTablesPkg.ci.yaml 
b/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
index 42829f393e..1ad5540e24 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
+++ b/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
@@ -128,7 +128,9 @@
"TABLEEX",
"TNSID",
"Vatos",
-   "WBINVD"
+   "WBINVD",
+   "NAMESPACEID",
+   "aswell"
],   # words to extend to the dictionary for this package
 "IgnoreStandardPaths": [],   # Standard Plugin defined paths that
  # should be ignore
diff --git a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
new file mode 100644
index 00..b421c4cd29
--- /dev/null
+++ b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
@@ -0,0 +1,217 @@
+/** @file
+  ARCH Name space object definations.
+
+  Defines namespace objects which are common across platform.
+  Platform can implements these optional namespace depends on
+  their requirements.
+
+  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+- Std or STD - Standard
+**/
+
+#ifndef ARCH_NAMESPACE_OBJECTS_H_
+#define ARCH_NAMESPACE_OBJECTS_H_
+
+#include 
+#include 
+
+/** The E_ARCH_OBJECT_ID enum describes the Object IDs
+in the ARCH Namespace
+*/
+typedef enum ArchObjectID {
+  EArchObjReserved,   ///<  0 - Reserved
+  EArchObjFadtPreferredPmProfile, ///<  1 - Preferred Power Management Profile 
Info
+  EArchObjFadtSciInterrupt,   ///<  2 - SCI Interrupt information
+  EArchObjFadtSciCmdInfo, ///<  3 - SCI CMD information
+  EArchObjFadtPmBlockInfo,///<  4 - Power management block info
+  EArchObjFadtGpeBlockInfo,   ///<  5 - GPE block info
+  EArchObjFadtXpmBlockInfo,   ///<  6 - 64-bit Power Management block info
+  EArchObjFadtXgpeBlockInfo,  ///<  7 - 64-bit GPE block info
+  EArchObjFadtSleepBlockInfo, ///<  8 - SLEEP block info
+  EArchObjFadtResetBlockInfo, ///<  9 - Reset block info
+  EArchObjFadtFlags,  ///< 10 - FADT flags
+  EArchObjFadtArmBootArch,///< 11 - ARM boot arch information
+  EArchObjFadtHypervisorVendorId, ///< 12 - Hypervisor vendor identity 
information
+  EArchObjFadtMiscInfo,   ///< 13 - Legacy fields; RTC, latency, flush 
stride, etc
+  EArchObjMax
+} E_ARCH_OBJECT_ID;
+
+/** A structure that describes the
+Power Management Profile Information for the Platform.
+
+ID: EArchObjFadtPreferredPmProfile
+*/
+typedef struct CmArchPreferredPmProfile {
+  /** This is the Preferred_PM_Profile field of the FADT Table
+  described in the ACPI Specification
+  */
+  UINT8PreferredPmProfile;
+} CM_ARCH_FADT_PREFERRED_PM_PROFILE;
+
+/** A structure that describes the
+SCI interrupt Information for the Platform.
+
+ID: EArchObjFadtSciInterrupt
+*/
+typedef struct 

[edk2-devel] [PATCH v1 0/3] DynamicTablesPkg: Adds generic FADT, HPET and WSMT table generators

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

PR: https://github.com/tianocore/edk2/pull/5384

Adds new space for ArchNameSpaceObjects.
Adds generic FADT table generator.
Adds generic HPET table generator.
Adds generic WSMT table generator.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Cc: Abdul Lateef Attar 

Abdul Lateef Attar (3):
  DynamicTablesPkg: Adds ACPI FADT Table generator
  DynamicTablesPkg: Adds ACPI HPET Table generator
  DynamicTablesPkg: Adds ACPI WSMT Table generator

 DynamicTablesPkg/DynamicTables.dsc.inc|  14 +-
 DynamicTablesPkg/DynamicTablesPkg.ci.yaml |   7 +-
 DynamicTablesPkg/Include/AcpiTableGenerator.h |   2 +
 .../Include/ArchNameSpaceObjects.h| 227 ++
 .../Include/ConfigurationManagerObject.h  |   6 +
 .../Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf  |  42 +
 .../Library/Acpi/AcpiFadtLib/FadtGenerator.c  | 737 ++
 .../Library/Acpi/AcpiFadtLib/FadtUpdate.h |  28 +
 .../Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c |  32 +
 .../Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf  |  38 +
 .../Library/Acpi/AcpiHpetLib/HpetGenerator.c  | 208 +
 .../Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf  |  34 +
 .../Library/Acpi/AcpiWsmtLib/WsmtGenerator.c  | 221 ++
 13 files changed, 1593 insertions(+), 3 deletions(-)
 create mode 100644 DynamicTablesPkg/Include/ArchNameSpaceObjects.h
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtGenerator.c
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtUpdate.h
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
 create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c

-- 
2.34.1



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

[edk2-devel] [PATCH 5/6] RedfishPkg/RedfishDebugLib: use RedfishHttpLib

[Nickle Wang via groups.io]

Remove RedfishLib and use RedfishHttpLib for debug printing
Redfish response data.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf | 4 ++--
 RedfishPkg/Include/Library/RedfishDebugLib.h   | 2 +-
 RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.c   | 1 +
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf 
b/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf
index 048d27c6dc..d468bb213b 100644
--- a/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf
+++ b/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  INF file for Redfish debug library.
 #
-#  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+#  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -32,7 +32,7 @@
   DebugLib
   JsonLib
   MemoryAllocationLib
-  RedfishLib
+  RedfishHttpLib
   UefiLib
 
 [Depex]
diff --git a/RedfishPkg/Include/Library/RedfishDebugLib.h 
b/RedfishPkg/Include/Library/RedfishDebugLib.h
index 3430cf1d14..ad7a697586 100644
--- a/RedfishPkg/Include/Library/RedfishDebugLib.h
+++ b/RedfishPkg/Include/Library/RedfishDebugLib.h
@@ -11,9 +11,9 @@
 #define REDFISH_DEBUG_LIB_H_
 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 #include 
 
diff --git a/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.c 
b/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.c
index 3728f51213..8b0425b8c3 100644
--- a/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.c
+++ b/RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifndef IS_EMPTY_STRING
-- 
2.34.1



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

[edk2-devel] [PATCH 6/6] RedfishPkg/RedfishCrtLib: fix unresolved external symbol issue

[Nickle Wang via groups.io]

-Fix below compiler error reported in edk2 CI.
ERROR - Linker #2001 from JsonLib.lib(load.obj) : unresolved external
symbol __ftol2
-The file MathFtol.c is copied from IntrinsicLib in CryptoPkg.
-Add MathFtol.c to EccCheck IgnoreFiles.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 .../RedfishCrtLib/RedfishCrtLib.inf   |  7 +++-
 .../RedfishCrtLib/Ia32/MathFtol.c | 37 +++
 RedfishPkg/RedfishPkg.ci.yaml |  2 +
 3 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 RedfishPkg/PrivateLibrary/RedfishCrtLib/Ia32/MathFtol.c

diff --git a/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf 
b/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf
index 6ff5dba75c..3a5e309d1a 100644
--- a/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf
+++ b/RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf
@@ -3,6 +3,7 @@
 #
 # Copyright (c) 2019, Intel Corporation. All rights reserved.
 # (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -23,6 +24,9 @@
 [Sources]
   RedfishCrtLib.c
 
+[Sources.IA32]
+  Ia32/MathFtol.c   | MSFT
+
 [LibraryClasses]
   BaseLib
   SortLib
@@ -35,4 +39,5 @@
   MdeModulePkg/MdeModulePkg.dec
   RedfishPkg/RedfishPkg.dec
 
-
+[BuildOptions]
+  MSFT:*_*_IA32_CC_FLAGS = /GL-
diff --git a/RedfishPkg/PrivateLibrary/RedfishCrtLib/Ia32/MathFtol.c 
b/RedfishPkg/PrivateLibrary/RedfishCrtLib/Ia32/MathFtol.c
new file mode 100644
index 00..adfe249b1d
--- /dev/null
+++ b/RedfishPkg/PrivateLibrary/RedfishCrtLib/Ia32/MathFtol.c
@@ -0,0 +1,37 @@
+/** @file
+  64-bit Math Worker Function.
+  The 32-bit versions of C compiler generate calls to library routines
+  to handle 64-bit math. These functions use non-standard calling conventions.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+/*
+ * Floating point to integer conversion.
+ */
+__declspec(naked) void
+_ftol2 (
+  void
+  )
+{
+  _asm {
+fistp qword ptr [esp-8]
+mov   edx, [esp-4]
+mov   eax, [esp-8]
+ret
+  }
+}
+
+__declspec(naked) void
+_ftol2_sse (
+  void
+  )
+{
+  _asm {
+fistp dword ptr [esp-4]
+mov   eax,[esp-4]
+ret
+  }
+}
diff --git a/RedfishPkg/RedfishPkg.ci.yaml b/RedfishPkg/RedfishPkg.ci.yaml
index 69b6bf39f5..b95e8bfdc7 100644
--- a/RedfishPkg/RedfishPkg.ci.yaml
+++ b/RedfishPkg/RedfishPkg.ci.yaml
@@ -2,6 +2,7 @@
 # CI configuration for NetworkPkg
 #
 # (C) Copyright 2021 Hewlett Packard Enterprise Development LP
+# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 {
@@ -38,6 +39,7 @@
 "PrivateInclude/Crt/string.h",
 "PrivateInclude/Crt/time.h",
 "PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c",
+"PrivateLibrary/RedfishCrtLib/Ia32/MathFtol.c",
 "Include/Library/RedfishCrtLib.h",
 ##
 ## For jansson library open source
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115631): https://edk2.groups.io/g/devel/message/115631
Mute This Topic: https://groups.io/mt/104463409/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] RedfishPkg/RedfishLib: include RedfishServiceData.h

[Nickle Wang via groups.io]

Redfish common structures are moved to RedfishServiceData.h. Remove
them from RedfishLib.h

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishPkg/Include/Library/RedfishLib.h | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/RedfishPkg/Include/Library/RedfishLib.h 
b/RedfishPkg/Include/Library/RedfishLib.h
index 8309a67c76..fb30ff68f6 100644
--- a/RedfishPkg/Include/Library/RedfishLib.h
+++ b/RedfishPkg/Include/Library/RedfishLib.h
@@ -70,6 +70,7 @@
 #ifndef REDFISH_LIB_H_
 #define REDFISH_LIB_H_
 
+#include 
 #include 
 
 #include 
@@ -78,22 +79,6 @@
 #define ODATA_TYPE_NAME_MAX_SIZE  128
 #define ODATA_TYPE_MAX_SIZE   128
 
-///
-/// Library class public defines
-///
-typedef  VOID  *REDFISH_SERVICE;
-typedef  VOID  *REDFISH_PAYLOAD;
-
-///
-/// Library class public structures/unions
-///
-typedef struct {
-  EFI_HTTP_STATUS_CODE*StatusCode;
-  UINTN   HeaderCount;
-  EFI_HTTP_HEADER *Headers;
-  REDFISH_PAYLOAD Payload;
-} REDFISH_RESPONSE;
-
 ///
 /// Odata type-name mapping structure.
 ///
-- 
2.34.1



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

[Nickle Wang via groups.io]

RedfishHttpLib is a wrapper library for Redfish feature drivers to
call Redfish HTTP Protocol easily.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishPkg/RedfishPkg.dec |   5 +
 RedfishPkg/RedfishLibs.dsc.inc|   3 +-
 RedfishPkg/RedfishPkg.dsc |   3 +-
 .../Library/RedfishHttpLib/RedfishHttpLib.inf |  43 ++
 RedfishPkg/Include/Library/RedfishHttpLib.h   | 326 ++
 .../Library/RedfishHttpLib/RedfishHttpLib.c   | 585 ++
 6 files changed, 963 insertions(+), 2 deletions(-)
 create mode 100644 RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
 create mode 100644 RedfishPkg/Include/Library/RedfishHttpLib.h
 create mode 100644 RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.c

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index 114f8d2ad8..1a9c9ed7bc 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -69,6 +69,11 @@
   #
   RedfishPlatformConfigLib|Include/Library/RedfishPlatformConfigLib.h
 
+  ##  @libraryclass  Provides the library functions to access Redfish HTTP
+  #   protocol.
+  #
+  RedfishHttpLib|Include/Library/RedfishHttpLib.h
+
 [LibraryClasses.Common.Private]
   ##  @libraryclass  Provides the private C runtime library functions.
   #   CRT library is currently used by edk2 JsonLib (open source
diff --git a/RedfishPkg/RedfishLibs.dsc.inc b/RedfishPkg/RedfishLibs.dsc.inc
index 5426957da8..55846aaa9d 100644
--- a/RedfishPkg/RedfishLibs.dsc.inc
+++ b/RedfishPkg/RedfishLibs.dsc.inc
@@ -6,7 +6,7 @@
 # of EDKII network library classes.
 #
 # (C) Copyright 2021 Hewlett Packard Enterprise Development LP
-# Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -21,5 +21,6 @@
   
RedfishPlatformCredentialLib|RedfishPkg/Library/RedfishPlatformCredentialIpmiLib/RedfishPlatformCredentialIpmiLib.inf
   HiiUtilityLib|RedfishPkg/Library/HiiUtilityLib/HiiUtilityLib.inf
   
RedfishPlatformConfigLib|RedfishPkg/Library/RedfishPlatformConfigLib/RedfishPlatformConfigLib.inf
+  RedfishHttpLib|RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
 !endif
 
diff --git a/RedfishPkg/RedfishPkg.dsc b/RedfishPkg/RedfishPkg.dsc
index 5849e7cf9e..b0150043a9 100644
--- a/RedfishPkg/RedfishPkg.dsc
+++ b/RedfishPkg/RedfishPkg.dsc
@@ -4,7 +4,7 @@
 # Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
 # (C) Copyright 2021 Hewlett-Packard Enterprise Development LP.
 # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
-# Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -74,5 +74,6 @@
   RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf
   RedfishPkg/Library/HiiUtilityLib/HiiUtilityLib.inf
   RedfishPkg/Library/RedfishPlatformConfigLib/RedfishPlatformConfigLib.inf
+  RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
 
   !include RedfishPkg/Redfish.dsc.inc
diff --git a/RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf 
b/RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
new file mode 100644
index 00..fd53b8c2ed
--- /dev/null
+++ b/RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
@@ -0,0 +1,43 @@
+## @file
+#  Redfish HTTP library is wrapper library for application to call Redfish
+#  HTTP protocol easily.
+#
+#  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = RedfishHttpLib
+  FILE_GUID  = 62855D9B-441B-436B-9CA6-B7FEB7ABF54E
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = RedfishHttpLib| DXE_DRIVER UEFI_DRIVER
+  CONSTRUCTOR= RedfishHttpConstructor
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 EBC
+#
+
+[Sources]
+  RedfishHttpLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  RedfishPkg/RedfishPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  UefiLib
+  UefiBootServicesTableLib
+
+[Protocols]
+  gEdkIIRedfishHttpProtocolGuid   ## CONSUMES ##
+
+[depex]
+  TRUE
+
diff --git a/RedfishPkg/Include/Library/RedfishHttpLib.h 
b/RedfishPkg/Include/Library/RedfishHttpLib.h
new file mode 100644
index 00..b07a46993b
--- /dev/null
+++ b/RedfishPkg/Include/Library/RedfishHttpLib.h
@@ -0,0 +1,326 @@
+/** @file
+  This file defines the Redfish HTTP library interface.
+
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef REDFISH_HTTP_LIB_H_
+#define 

[edk2-devel] [PATCH 2/6] RedfishPkg: implement Redfish HTTP protocol

[Nickle Wang via groups.io]

implement Redfish HTTP protocol driver.

Signed-off-by: Nickle Wang 
Co-authored-by: Igor Kulchytskyy 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishPkg/RedfishPkg.dec |7 +-
 RedfishPkg/RedfishComponents.dsc.inc  |3 +-
 RedfishPkg/RedfishPkg.dsc |2 +
 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf  |   73 +
 RedfishPkg/RedfishHttpDxe/RedfishHttpData.h   |  256 
 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.h|   44 +
 .../RedfishHttpDxe/RedfishHttpOperation.h |   76 +
 RedfishPkg/RedfishHttpDxe/RedfishHttpData.c   |  667 
 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.c| 1344 +
 .../RedfishHttpDxe/RedfishHttpOperation.c |  693 +
 RedfishPkg/Redfish.fdf.inc|3 +-
 11 files changed, 3164 insertions(+), 4 deletions(-)
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpData.h
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.h
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpOperation.h
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpData.c
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.c
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpOperation.c

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index 9b424efdf3..114f8d2ad8 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -157,8 +157,11 @@
   # set to EFI_REST_EX_PROTOCOL.
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout|5000|UINT32|0x1009
-  ## This is used to enable HTTP content encoding on Redfish communication.
-  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishServiceContentEncoding|TRUE|BOOLEAN|0x100A
+  #
+  # This PCD string is introduced for platform developer to set the encoding 
method supported by BMC Redfish.
+  # Currently only "None" and "gzip" are supported.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishServiceContentEncoding|"None"|VOID*|0x100A
   #
   # Use below PCDs to control Redfhs HTTP protocol.
   #
diff --git a/RedfishPkg/RedfishComponents.dsc.inc 
b/RedfishPkg/RedfishComponents.dsc.inc
index 464ffc8606..d6c5b73d7f 100644
--- a/RedfishPkg/RedfishComponents.dsc.inc
+++ b/RedfishPkg/RedfishComponents.dsc.inc
@@ -7,7 +7,7 @@
 # "RedfishDefines.dsc.inc".
 #
 # (C) Copyright 2020-2021 Hewlett Packard Enterprise Development LP
-# Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -28,4 +28,5 @@
   RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
   RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.inf
   MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
+  RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf
 !endif
diff --git a/RedfishPkg/RedfishPkg.dsc b/RedfishPkg/RedfishPkg.dsc
index 25ed193182..5849e7cf9e 100644
--- a/RedfishPkg/RedfishPkg.dsc
+++ b/RedfishPkg/RedfishPkg.dsc
@@ -45,6 +45,8 @@
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   
RedfishPlatformCredentialLib|RedfishPkg/Library/PlatformCredentialLibNull/PlatformCredentialLibNull.inf
   
RedfishContentCodingLib|RedfishPkg/Library/RedfishContentCodingLibNull/RedfishContentCodingLibNull.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
   # NULL instance of IPMI related library.
   IpmiLib|MdeModulePkg/Library/BaseIpmiLibNull/BaseIpmiLibNull.inf
diff --git a/RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf 
b/RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf
new file mode 100644
index 00..c7dfdffacf
--- /dev/null
+++ b/RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf
@@ -0,0 +1,73 @@
+## @file
+#  RedfishHttpDxe is the DXE driver which provides
+#  EdkIIRedfishHttpProtocol to EDK2 Redfish Feature
+#  drivers for HTTP operation.
+#
+#  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001000b
+  BASE_NAME  = RedfishHttpDxe
+  FILE_GUID  = 85ADB2F1-DA93-47D4-AF4F-3D920D9BD2C0
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= RedfishHttpEntryPoint
+  UNLOAD_IMAGE   = RedfishHttpDriverUnload
+
+#
+#  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64 RISCV64
+#
+
+[Sources]
+  RedfishHttpData.c
+  RedfishHttpData.h
+  RedfishHttpDxe.c
+  RedfishHttpDxe.h
+  RedfishHttpOperation.c
+  RedfishHttpOperation.h
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  NetworkPkg/NetworkPkg.dec
+  RedfishPkg/RedfishPkg.dec
+

[edk2-devel] [PATCH 1/6] RedfishPkg: introduce Redfish HTTP protocol

[Nickle Wang via groups.io]

Introduce Redfish HTTP protocol to improve Redfish performance
and communication stability between BIOS and Redfish service.
- Feature drivers often query same Redfish resource multiple
times for different purpose. Implement HTTP cache mechanism to
improve HTTP GET performance. "UseCache" parameter is provided
if application likes to send HTTP GET request to Redfish service
without using cache data.
- This driver will retire stale cache data automatically when
application modify Redfish resource at service side.
- PCD PcdHttpCacheDisabled is used to disable cache mechanism in
this driver for debugging purpose.
- PCD PcdRedfishServiceContentEncoding is used to enable content
encoding while sending data to Redfish service.
- Redfish HTTP protocol also implement retry mechanism to retry
HTTP request when BIOS receive unexpected response from Redfish service.
This function helps BIOS Redfish to finish its job as much as possible.
- PCDs are defined to control how many times BIOS will retry the
request and how many time BIOS will wait between retries.

Signed-off-by: Nickle Wang 
Co-authored-by: Igor Kulchytskyy 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishPkg/RedfishPkg.dec |  24 +-
 .../Protocol/EdkIIRedfishHttpProtocol.h   | 308 ++
 RedfishPkg/Include/RedfishServiceData.h   |  43 +++
 3 files changed, 374 insertions(+), 1 deletion(-)
 create mode 100644 RedfishPkg/Include/Protocol/EdkIIRedfishHttpProtocol.h
 create mode 100644 RedfishPkg/Include/RedfishServiceData.h

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index 3ea9ff3ef7..9b424efdf3 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -4,7 +4,7 @@
 # Copyright (c) 2019, Intel Corporation. All rights reserved.
 # (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 # Copyright (c) 2023, American Megatrends International LLC.
-# Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
@@ -93,6 +93,9 @@
   # Redfish Host Interface ready notification protocol
   gEdkIIRedfishHostInterfaceReadyProtocolGuid = { 0xC3F6D062, 0x3D38, 0x4EA4, 
{ 0x92, 0xB1, 0xE8, 0xF8, 0x02, 0x27, 0x63, 0xDF } }
 
+  ## Include/Protocol/EdkIIRedfishHttpProtocol.h
+  gEdkIIRedfishHttpProtocolGuid = { 0x58a0f47e, 0xf45f, 0x4d44, { 0x89, 0x5b, 
0x2a, 0xfe, 0xb0, 0x80, 0x15, 0xe2 } }
+
 [Guids]
   gEfiRedfishPkgTokenSpaceGuid  = { 0x4fdbccb7, 0xe829, 0x4b4c, { 0x88, 
0x87, 0xb2, 0x3f, 0xd7, 0x25, 0x4b, 0x85 }}
 
@@ -154,3 +157,22 @@
   # set to EFI_REST_EX_PROTOCOL.
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout|5000|UINT32|0x1009
+  ## This is used to enable HTTP content encoding on Redfish communication.
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishServiceContentEncoding|TRUE|BOOLEAN|0x100A
+  #
+  # Use below PCDs to control Redfhs HTTP protocol.
+  #
+  ## The number of retry when HTTP GET request failed. If the value is 0, 
there is no retry enabled.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpGetRetry|0|UINT16|0x100B
+  ## The number of retry when HTTP PUT request failed. If the value is 0, 
there is no retry enabled.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpPutRetry|0|UINT16|0x100C
+  ## The number of retry when HTTP PATCH request failed. If the value is 0, 
there is no retry enabled.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpPatchRetry|0|UINT16|0x100D
+  ## The number of retry when HTTP POST request failed. If the value is 0, 
there is no retry enabled.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpPostRetry|0|UINT16|0x100E
+  ## The number of retry when HTTP DELETE request failed. If the value is 0, 
there is no retry enabled.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpDeleteRetry|0|UINT16|0x100F
+  ## The number of second to wait before driver retry HTTP request. If the 
value is 0, there is no wait before next retry.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpRetryWaitInSecond|1|UINT16|0x1010
+  ## This is used to disable Redfish HTTP cache function and every request 
will be sent to Redfish service.
+  gEfiRedfishPkgTokenSpaceGuid.PcdHttpCacheDisabled|FALSE|BOOLEAN|0x1011
diff --git a/RedfishPkg/Include/Protocol/EdkIIRedfishHttpProtocol.h 
b/RedfishPkg/Include/Protocol/EdkIIRedfishHttpProtocol.h
new file mode 100644
index 00..fef365730d
--- /dev/null
+++ b/RedfishPkg/Include/Protocol/EdkIIRedfishHttpProtocol.h
@@ -0,0 +1,308 @@
+/** @file
+  This file defines the EDKII_REDFISH_HTTP_PROTOCOL interface.
+
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef EDKII_REDFISH_HTTP_PROTOCOL_H_
+#define EDKII_REDFISH_HTTP_PROTOCOL_H_
+
+#include 
+#include 
+#include 
+
+typedef struct _EDKII_REDFISH_HTTP_PROTOCOL EDKII_REDFISH_HTTP_PROTOCOL;
+
+/**
+  This function 

[edk2-devel] [PATCH 0/6] Introduce Redfish http protocol

[Nickle Wang via groups.io]

This patch series introduce Redfish HTTP protocol to RedfishPkg. 
This is to improve Redfish performance and communication stability 
between BIOS and Redfish service. Two big functions are introduced:
1) HTTP cache mechanism is implemented to reduce the number of 
communiocation between BIOS and BMC. 
2) HTTP request retry mechanism is implemented to handle communication 
failure. With retry mechanism, Redfish feature driver can finish its job 
as best as possible.

Several libraries are updated to fix build issues. Pull request is created:
https://github.com/tianocore/edk2/pull/5348

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 

Nickle Wang (6):
  RedfishPkg: introduce Redfish HTTP protocol
  RedfishPkg: implement Redfish HTTP protocol
  RedfishPkg: introduce RedfishHttpLib
  RedfishPkg/RedfishLib: include RedfishServiceData.h
  RedfishPkg/RedfishDebugLib: use RedfishHttpLib
  RedfishPkg/RedfishCrtLib: fix unresolved external symbol issue

 RedfishPkg/RedfishPkg.dec |   32 +-
 RedfishPkg/RedfishComponents.dsc.inc  |3 +-
 RedfishPkg/RedfishLibs.dsc.inc|3 +-
 RedfishPkg/RedfishPkg.dsc |5 +-
 .../RedfishDebugLib/RedfishDebugLib.inf   |4 +-
 .../Library/RedfishHttpLib/RedfishHttpLib.inf |   43 +
 .../RedfishCrtLib/RedfishCrtLib.inf   |7 +-
 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf  |   73 +
 RedfishPkg/Include/Library/RedfishDebugLib.h  |2 +-
 RedfishPkg/Include/Library/RedfishHttpLib.h   |  326 
 RedfishPkg/Include/Library/RedfishLib.h   |   17 +-
 .../Protocol/EdkIIRedfishHttpProtocol.h   |  308 
 RedfishPkg/Include/RedfishServiceData.h   |   43 +
 RedfishPkg/RedfishHttpDxe/RedfishHttpData.h   |  256 
 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.h|   44 +
 .../RedfishHttpDxe/RedfishHttpOperation.h |   76 +
 .../Library/RedfishDebugLib/RedfishDebugLib.c |1 +
 .../Library/RedfishHttpLib/RedfishHttpLib.c   |  585 +++
 .../RedfishCrtLib/Ia32/MathFtol.c |   37 +
 RedfishPkg/RedfishHttpDxe/RedfishHttpData.c   |  667 
 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.c| 1344 +
 .../RedfishHttpDxe/RedfishHttpOperation.c |  693 +
 RedfishPkg/Redfish.fdf.inc|3 +-
 RedfishPkg/RedfishPkg.ci.yaml |2 +
 24 files changed, 4549 insertions(+), 25 deletions(-)
 create mode 100644 RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.inf
 create mode 100644 RedfishPkg/Include/Library/RedfishHttpLib.h
 create mode 100644 RedfishPkg/Include/Protocol/EdkIIRedfishHttpProtocol.h
 create mode 100644 RedfishPkg/Include/RedfishServiceData.h
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpData.h
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.h
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpOperation.h
 create mode 100644 RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.c
 create mode 100644 RedfishPkg/PrivateLibrary/RedfishCrtLib/Ia32/MathFtol.c
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpData.c
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpDxe.c
 create mode 100644 RedfishPkg/RedfishHttpDxe/RedfishHttpOperation.c

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115625): https://edk2.groups.io/g/devel/message/115625
Mute This Topic: https://groups.io/mt/104463401/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 1/4] OvmfPkg/Sec: Setup MTRR early in the boot process.

[Min Xu]

On Monday, February 12, 2024 11:22 PM, Gerd Hoffmann wrote:
> On Thu, Feb 01, 2024 at 10:38:43AM +0100, Gerd Hoffmann wrote:
> >   Hi,
> >
> > > > Can you confirm (a) this patch is OK for
> > > > "OvmfPkg/IntelTdx/Sec/SecMain.c", and (b) this series fixes the slowdown
> you had encountered?
> > > >
> > > > (that's what's left before we can merge this series)
> > > >
> > > We test the patch in TDX and find EXIT_REASON_CR_ACCESS is triggered in
> DXE phase.
> >
> > Hmm.  Sure this caused by this patch series?  For the PEI-less TDX
> > build this series moves the MTRR setup to a different place in SEC.
> > Once the DXE phase started the MTRR configuration should be identical
> > with and without this patch series, and the series also doesn't touch
> > any control register.
> 
> Ping.  Can you double-check please?  Our QE ran a test build with this series
> applied through regression testing (including TDX) and has not found any
> issues.

We double check the patch-set (v3) for both OvmfPkgX64 and IntelTdx. It 
triggered EXIT_REASON_CR_ACCESS in DXE phase when launching a td-guest.
@Gerd, what's the qemu command and test environment your QE run the case? We'd 
like run it in our side.

Thanks
Min


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

[edk2-devel] [PATCH] Pkg-Module: Silicon/Marvell

[Gahan]

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

Bug 4689 - GetInfo() of Adapter Information Protocol
should have a provision for IHV to return no data for
UEFI Spec compliance 2.9 [mantis #1866]

Signed-off-by: Gahan Saraiya 
---
 Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c 
b/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
index 5e463ac932..517b21940d 100644
--- a/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
+++ b/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
@@ -1394,6 +1394,7 @@ Pp2DxeSnpInstall (
 
   @retval EFI_SUCCESSThe InformationType information was 
retrieved.
   @retval EFI_UNSUPPORTEDThe InformationType is not known.
+  @retval EFI_NOT_FOUND  Information is not available for the 
requested information type.
   @retval EFI_DEVICE_ERROR   The device reported an error.
   @retval EFI_OUT_OF_RESOURCES   The request could not be completed due to 
a lack of resources.
   @retval EFI_INVALID_PARAMETER  This is NULL.
-- 
2.39.2.windows.1



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

Re: [edk2-devel] [PATCH] Pkg-Module: OptionRomPkg, MinPlatformPkg, Silicon/Marvell

[Gahan]

Discarding the thread to split in to 3 different review patch.


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

[edk2-devel] [PATCH] Pkg-Module: OptionRomPkg

[Gahan]

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

Bug 4689 - GetInfo() of Adapter Information Protocol
should have a provision for IHV to return no data for
UEFI Spec compliance 2.9 [mantis #1866]

Signed-off-by: Gahan Saraiya 
---
 Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h 
b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
index 31c55a8e11..45c1f41414 100644
--- a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
+++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
@@ -350,23 +350,24 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI 
*PxePtr);
 
   This function returns information of type InformationType from the adapter.
   If an adapter does not support the requested informational type, then
-  EFI_UNSUPPORTED is returned. 
+  EFI_UNSUPPORTED is returned.
 
   @param[in]  This   A pointer to the 
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
   @param[in]  InformationTypeA pointer to an EFI_GUID that defines the 
contents of InformationBlock.
-  @param[out] InforamtionBlock   The service returns a pointer to the 
buffer with the InformationBlock
+  @param[out] InformationBlock   The service returns a pointer to the 
buffer with the InformationBlock
  structure which contains details about 
the data specific to InformationType.
-  @param[out] InforamtionBlockSize   The driver returns the size of the 
InformationBlock in bytes.
+  @param[out] InformationBlockSize   The driver returns the size of the 
InformationBlock in bytes.
 
   @retval EFI_SUCCESSThe InformationType information was 
retrieved.
   @retval EFI_UNSUPPORTEDThe InformationType is not known.
+  @retval EFI_NOT_FOUND  Information is not available for the 
requested information type.
   @retval EFI_DEVICE_ERROR   The device reported an error.
   @retval EFI_OUT_OF_RESOURCES   The request could not be completed due to 
a lack of resources.
-  @retval EFI_INVALID_PARAMETER  This is NULL. 
-  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL. 
+  @retval EFI_INVALID_PARAMETER  This is NULL.
+  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL.
   @retval EFI_INVALID_PARAMETER  InformationBlockSize is NULL.
 
-**/  
+**/
 EFI_STATUS
 EFIAPI
 UndiAipGetInfo (
@@ -396,7 +397,7 @@ UndiAipGetInfo (
   @retval EFI_INVALID_PARAMETER  InformationBlock is NULL.
   @retval EFI_WRITE_PROTECTEDThe InformationType cannot be modified 
using EFI_ADAPTER_INFO_SET_INFO().
 
-**/
+**/
 EFI_STATUS
 EFIAPI
 UndiAipSetInfo (
@@ -427,7 +428,7 @@ UndiAipSetInfo (
   @retval EFI_INVALID_PARAMETER InfoTypesBufferCount is NULL.
   @retval EFI_OUT_OF_RESOURCES  There is not enough pool memory to store 
the results.
 
-**/
+**/
 EFI_STATUS
 EFIAPI
 UndiAipGetSupportedTypes (
-- 
2.39.2.windows.1



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

[edk2-devel] [PATCH] Pkg-Module: MinPlatformPkg

[Gahan]

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

Bug 4689 - GetInfo() of Adapter Information Protocol
should have a provision for IHV to return no data for
UEFI Spec compliance 2.9 [mantis #1866]

Signed-off-by: Gahan Saraiya 
---
 .../Test/Library/TestPointLib/DxeTestPointAip.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c
index a7fe9530cf..fcfef58175 100644
--- a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c
+++ b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c
@@ -12,7 +12,7 @@
 
   This function returns information of type InformationType from the adapter.
   If an adapter does not support the requested informational type, then
-  EFI_UNSUPPORTED is returned. 
+  EFI_UNSUPPORTED is returned.
 
   @param[in]  This   A pointer to the 
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
   @param[in]  InformationTypeA pointer to an EFI_GUID that defines the 
contents of InformationBlock.
@@ -24,8 +24,8 @@
   @retval EFI_UNSUPPORTEDThe InformationType is not known.
   @retval EFI_DEVICE_ERROR   The device reported an error.
   @retval EFI_OUT_OF_RESOURCES   The request could not be completed due to 
a lack of resources.
-  @retval EFI_INVALID_PARAMETER  This is NULL. 
-  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL. 
+  @retval EFI_INVALID_PARAMETER  This is NULL.
+  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL.
   @retval EFI_INVALID_PARAMETER  InformationBlockSize is NULL.
 
 **/
-- 
2.39.2.windows.1



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

Re: [edk2-devel] [PATCH 1/5] UefiCpuPkg/MpInitLib: Add ProcessorIndex argument to GetMpHandOffHob()

[Ni, Ray]

> 
> That will only work if the HOBs are returned in ProcessorIndex order.
> 
> That happens to be the case in my testing; the HOBs are returned in the
> same order they are created by patch #5 of this series.
> 
> Is that behavior guaranteed?  MdePkg/Include/Library/HobLib.h doesn't
> say anything about the ordering.

The HOB item order follows when it's created.
The HOB structure implicitly guarantees it.

I am aware that in a production server UEFI firmware, the number of HOB items 
is huge.
Enumerating the HOB list multiple times is a big cost.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115619): https://edk2.groups.io/g/devel/message/115619
Mute This Topic: https://groups.io/mt/104369841/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 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Check BspIndex first before lock cmpxchg

[Wu, Jiaxin]

> From C11 "5.1.2.4 Multi-threaded executions and data races":
> 
> - paragraph 4: "Two expression evaluations conflict if one of them
> modifies a memory location and the other one reads or modifies the same
> memory location."
> 
> - paragraph 25: "The execution of a program contains a data race if it
> contains two conflicting actions in different threads, at least one of
> which is not atomic, and neither happens before the other. Any such data
> race results in undefined behavior."
> 
> In this case, the outer condition (which reads the volatile UINT32
> object "mSmmMpSyncData->BspIndex") is one access. It is a read access,
> and it is not atomic. The other access is the
> InterlockedCompareExchange32(). It is a read-write access, and it is
> atomic. There is no "happens before" relationship enforced between both
> accesses.
> 
> Therefore, this is a data race: the pre-check on one CPU conflicts with
> the InterlockedCompareExchange32() on another CPU, the pre-check is not
> atomic, and there is no happens-before between them.
> 
> A data race means undefined behavior. In particular, if there is a data
> race, then there are no guarantees of sequential consistency, so the
> observable values in the object could be totally inexplicable.
> 

I think here data race won't cause the undefined behavior:

The read operation in one processor might see the 1) old value (MAX_UINT32) or 
2) the new value (CpuIndex), but both behaviors are explicable:

If case 1, that's ok continue do the lock comxchg since BspIndex hasn't been 
elected.
If case 2, which means another processor has already atomic invalid or write 
the BspIndex, then existing processor absolutely can skip the lock comxchg.

if (mSmmMpSyncData->BspIndex == MAX_UINT32) {
  InterlockedCompareExchange32 (
(UINT32 *)>BspIndex,
MAX_UINT32,
(UINT32)CpuIndex
);
}

> If you consider PiSmmCpuDxeSmm's usage of "volatile" to be "atomic",
> then that would remove the data race; but volatile is not necessarily
> atomic.
> 

I *never* do the assumption: "volatile" is "atomic".
BspIndex is volatile, I think it only can ensure the compiler behavior, not 
processor itself:
1. Compiler will not optimize this variable. All reads and writes to this 
variable will be done directly to memory, not using cached values in registers. 
But it doesn't prevent the CPU from caching that variable in its own internal 
caches.
2. "volatile" can prevent the compiler from optimizing and reordering 
instructions, it can't prevent the processor from reordering instructions, and 
can't guarantee the atomicity of operations. 

For processor reordering, I think Ray explained that reordering won't happen. 

> Since you linked a wikipedia article, I'll link three articles that
> describe a similar (nearly the same) technique called "double-checked
> locking". In the general case, that technique is broken.
> 
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.
> html
> https://en.wikipedia.org/wiki/Double-checked_locking
> https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
> 
> It can be made work in bare-bones C, but it requires explicit fences /
> memory barriers.

Here, the case is different to the above three "Double-checked locking".  Cache 
coherency can make sure the read value for check is only 2 cases as I explained 
above.
The only possible impact is the AP behavior: AP won't pending on lock comxchg, 
while it will continue do the following code logic after if check: for example 
performs the APHandler. But it won't has the negative-impact since it has the 
timeout BSP check in APHandler. And even failure of that, we still has the 
error handling to sync out the existing AP due to don't know the BSP:

  SmmCpuSyncCheckOutCpu (mSmmMpSyncData->SyncContext, CpuIndex);
  return;

Thanks,
Jiaxin


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

[edk2-devel] [PATCH] IntelSiliconPkg/VTd: Reset the one-shot bits before modifing GCMD_REG

[Sheng Wei]

Here is the process of modify GCMD_REG.
  Read GSTS_REG
  Reset the one-shot bits.
  Modify the target comamnd value.
  Write the command value to GCMD_REG.
  Wait until GSTS_REG indicates command is serviced.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Jenny Huang 
Signed-off-by: Sheng Wei 
---
 .../Feature/VTd/IntelVTdCoreDxe/VtdReg.c  | 13 ++
 .../VTd/IntelVTdCorePei/IntelVTdDmar.c|  9 +---
 .../VTd/IntelVTdDmarPei/IntelVTdDmar.c| 43 +-
 .../Feature/VTd/IntelVTdDxe/VtdReg.c  | 44 +--
 .../Feature/VTd/IntelVTdPmrPei/VtdReg.c   |  1 +
 .../IntelVTdPeiDxeLib/IntelVTdPeiDxeLib.c | 12 ++---
 6 files changed, 51 insertions(+), 71 deletions(-)

diff --git a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCoreDxe/VtdReg.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCoreDxe/VtdReg.c
index edeb4b3ff..21e2d5f1b 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCoreDxe/VtdReg.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCoreDxe/VtdReg.c
@@ -112,13 +112,8 @@ PerpareCacheInvalidationInterface (
   // Enable the queued invalidation interface through the Global Command 
Register.
   // When enabled, hardware sets the QIES field in the Global Status Register.
   //
-  Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
-  Reg32 |= B_GMCD_REG_QIE;
-  MmioWrite32 (VtdUnitBaseAddress + R_GCMD_REG, Reg32);
-  DEBUG ((DEBUG_INFO, "Enable Queued Invalidation Interface. GCMD_REG = 
0x%x\n", Reg32));
-  do {
-Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
-  } while ((Reg32 & B_GSTS_REG_QIES) == 0);
+  DEBUG ((DEBUG_INFO, "Enable Queued Invalidation Interface.\n"));
+  VtdLibSetGlobalCommandRegisterBits (VtdUnitBaseAddress, B_GMCD_REG_QIE);
 
   VTdLogAddEvent (VTDLOG_DXE_QUEUED_INVALIDATION, VTD_LOG_QI_ENABLE, 
VtdUnitBaseAddress);
 
@@ -577,7 +572,7 @@ DumpVtdCapRegs (
   IN VTD_CAP_REG *CapReg
   )
 {
-  DEBUG((DEBUG_INFO, "  CapReg   - 0x%x\n", CapReg->Uint64));
+  DEBUG((DEBUG_INFO, "  CapReg   - 0x%lx\n", CapReg->Uint64));
   DEBUG((DEBUG_INFO, "ND - 0x%x\n", CapReg->Bits.ND));
   DEBUG((DEBUG_INFO, "AFL- 0x%x\n", CapReg->Bits.AFL));
   DEBUG((DEBUG_INFO, "RWBF   - 0x%x\n", CapReg->Bits.RWBF));
@@ -737,7 +732,7 @@ DumpVtdIfError (
 if (HasError) {
   REPORT_STATUS_CODE (EFI_ERROR_CODE, PcdGet32 (PcdErrorCodeVTdError));
   DEBUG((DEBUG_INFO, "\n ERROR \n"));
-  DumpVtdRegs (mVtdUnitInformation[Num].VtdUnitBaseAddress);
+  DumpVtdRegs (mVtdUnitInformation[Num].VtdUnitBaseAddress);
   DEBUG((DEBUG_INFO, " ERROR \n\n"));
   //
   // Clear
diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCorePei/IntelVTdDmar.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCorePei/IntelVTdDmar.c
index 93207ba52..549313dbf 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCorePei/IntelVTdDmar.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdCorePei/IntelVTdDmar.c
@@ -120,13 +120,8 @@ PerpareCacheInvalidationInterface (
   // Enable the queued invalidation interface through the Global Command 
Register.
   // When enabled, hardware sets the QIES field in the Global Status Register.
   //
-  Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
-  Reg32 |= B_GMCD_REG_QIE;
-  MmioWrite32 (VtdUnitBaseAddress + R_GCMD_REG, Reg32);
-  DEBUG ((DEBUG_INFO, "Enable Queued Invalidation Interface. GCMD_REG = 
0x%x\n", Reg32));
-  do {
-Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
-  } while ((Reg32 & B_GSTS_REG_QIES) == 0);
+  DEBUG ((DEBUG_INFO, "Enable Queued Invalidation Interface.\n"));
+  VtdLibSetGlobalCommandRegisterBits (VtdUnitBaseAddress, B_GMCD_REG_QIE);
 
   VTdLogAddEvent (VTDLOG_PEI_QUEUED_INVALIDATION, VTD_LOG_QI_ENABLE, 
VtdUnitBaseAddress);
 
diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDmarPei/IntelVTdDmar.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDmarPei/IntelVTdDmar.c
index e1b867973..533fb2b9a 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDmarPei/IntelVTdDmar.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDmarPei/IntelVTdDmar.c
@@ -20,6 +20,18 @@
 #include 
 #include "IntelVTdDmarPei.h"
 
+VOID
+SetGlobalCommandRegisterBits (
+  IN UINTN VtdUnitBaseAddress,
+  IN UINT32BitMask
+  );
+
+VOID
+ClearGlobalCommandRegisterBits (
+  IN UINTN VtdUnitBaseAddress,
+  IN UINT32BitMask
+  );
+
 /**
   Flush VTD page table and context table memory.
 
@@ -58,6 +70,7 @@ FlushWriteBuffer (
 
   if (CapReg.Bits.RWBF != 0) {
 Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
+Reg32 = (Reg32 & 0x96FF);   // Reset the one-shot bits
 MmioWrite32 (VtdUnitBaseAddress + R_GCMD_REG, Reg32 | B_GMCD_REG_WBF);
 do {
   Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
@@ -104,11 +117,7 @@ PerpareCacheInvalidationInterface (
   Reg32 = MmioRead32 (VtdUnitBaseAddress + R_GSTS_REG);
   if ((Reg32 & 

Re: [edk2-devel] [PATCH 1/2] Add maintainers for EaglestreamSiliconBinPkg and EaglestreamOpenBoardBinPkg

[Michael D Kinney]

Hi Nathaniel,

I can not tell which repo these are for.

Can you please indicate the target repo in the subject such as:

[edk2-platforms][Patch x/y] 
[edk2-non-osi][Patch x/y]

I the repo is not specified, then [edk2] is assumed.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Nathaniel Haller
> Sent: Friday, February 16, 2024 5:47 PM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Chiu,
> Chasel 
> Subject: [edk2-devel] [PATCH 1/2] Add maintainers for
> EaglestreamSiliconBinPkg and EaglestreamOpenBoardBinPkg
> 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: Nathaniel Haller 
> ---
>  Maintainers.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 1d5dacb..66ac96d 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -50,6 +50,11 @@ M: Isaac Oram 
>  M: Nate DeSimone 
>  M: Chasel Chiu 
> 
> +Platform/Intel/EaglestreamOpenBoardBinPkg
> +M: Nate DeSimone 
> +M: Chasel Chiu 
> +M: Nathaniel Haller 
> +
>  Platform/Intel/CoffeelakeSiliconBinPkg
>  M: Chasel Chiu 
>  M: Sai Chaganty 
> @@ -88,6 +93,11 @@ Silicon/Intel/WhitleySiliconBinPkg
>  M: Nate DeSimone 
>  M: Isaac W Oram 
> 
> +Silicon/Intel/EaglestreamSiliconBinPkg
> +M: Nate DeSimone 
> +M: Chasel Chiu 
> +M: Nathaniel Haller 
> +
>  Silicon/Intel/QuarkSocBinPkg
>  M: Michael D Kinney 
>  M: Kelly Steele 
> --
> 2.43.0.windows.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 2/2] Update Maintainers for Intel packages

[Michael D Kinney]

Reviewed-by: Michael D Kinney 



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Nathaniel Haller
> Sent: Friday, February 16, 2024 5:48 PM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Chiu,
> Chasel 
> Subject: [edk2-devel] [PATCH 2/2] Update Maintainers for Intel packages
> 
> Update PurleySiliconBinPkg, WhitleyOpenBoardBinPkg, and
> WhitleySiliconBinPkg maintainers.
> 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: Nathaniel Haller 
> ---
>  Maintainers.txt | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 66ac96d..eaf13fd 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -46,9 +46,9 @@ M: Chasel Chiu 
>  M: Nate DeSimone 
> 
>  Platform/Intel/WhitleyOpenBoardBinPkg
> -M: Isaac Oram 
>  M: Nate DeSimone 
>  M: Chasel Chiu 
> +M: Nathaniel Haller 
> 
>  Platform/Intel/EaglestreamOpenBoardBinPkg
>  M: Nate DeSimone 
> @@ -87,11 +87,12 @@ M: Sai Chaganty 
> 
>  Silicon/Intel/PurleySiliconBinPkg
>  M: Nate DeSimone 
> -M: Isaac W Oram 
> +M: Chasel Chiu 
> 
>  Silicon/Intel/WhitleySiliconBinPkg
>  M: Nate DeSimone 
> -M: Isaac W Oram 
> +M: Chasel Chiu 
> +M: Nathaniel Haller 
> 
>  Silicon/Intel/EaglestreamSiliconBinPkg
>  M: Nate DeSimone 
> --
> 2.43.0.windows.1
> 
> 
> 
> 
> 



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

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, February 20, 2024 #cal-reminder

[Group Notification]

*Reminder: TianoCore Bug Triage - APAC / NAMO*

*When:*
Tuesday, February 20, 2024
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=2159759 )

*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 (#115614): https://edk2.groups.io/g/devel/message/115614
Mute This Topic: https://groups.io/mt/104461031/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] The API in BaseCryptLib can't seed the pseudorandom number generator properly

[Li, Yi]

Hi Eddie,

> the API in CryptPkg "RandomSeed()"(X64, in CryptRandTsc.c) always returned 
> false

Does your code run in a XIP environment? Such like PreMemory stage or other 
cases.
The setup of Randlib in OpenSsl 3.0 relies on global variables, so there may be 
an error if the global variables are read-only.

Regards,
Yi


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
Sent: Tuesday, February 20, 2024 9:11 AM
To: devel@edk2.groups.io; ler...@redhat.com; eddie wang 
Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom 
number generator properly

Thanks Laslo and Eddie.

I am just back from Chinese New Year vocation, still checking email.

If you can file a Bugzilla (https://bugzilla.tianocore.org/) with source code 
of your app, that would be very helpful for us to investigate this issue.


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo 
> Ersek
> Sent: Tuesday, February 20, 2024 4:18 AM
> To: eddie wang 
> Cc: devel@edk2.groups.io
> Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the 
> pseudorandom number generator properly
> 
> On 2/17/24 10:17, eddie wang wrote:
> > Hi Laszlo,
> > After digging dipper,  we found that the *EVP_RAND_fetch *in 
> > "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's 
> > meant the DRBG implementation could not be fetched. We also compared 
> > it to the case on Linux, and they could both fetched DRBG 
> > implementation correctly. Is it possible that the opensslLib 3.0.9 
> > caused any compatibility issues with edk2?  Or has anyone else 
> > encountered the same problem with these openssl services?
> 
> Sorry, I can't say.
> 
> If you have a small reproducer UEFI application that works fine when 
> built with edk2-stable202305, but does not work when built against 
> either edk2-stable202308 or current master, then filing a TianoCore BZ
> (regression) seems justified. (AFAICT it was edk2-stable202308 that 
> incorporated the OpenSSL 3.0.9 upgrade, from 1.1.1u.) Attaching the 
> source code of the small repro application to the ticket would likely 
> be helpful.
> 
> Laszlo
> 
> > Laszlo Ersek mailto:ler...@redhat.com>> 於 
> > 2024年2月
> > 15日 週四 下午7:48寫道：
> >
> > On 2/15/24 12:09, eddie wang wrote:
> > > Hi Laszlo,
> > > Thanks for your reply. How can I enable the DEBUGs at RandomSeed()
> > ? Or
> > > any suggesting information that I can provide?
> >
> > Sorry, upon a closer look, I see you had already narrowed it down to
> > RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
> > suggestion would amount to adding DEBUGs to OpenSSL, such as to
> > RAND_seed() in
> > "CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".
> >
> > But, I think you may be able to do just that.
> > "CryptoPkg/Library/Include/CrtLibSupport.h" already includes
> > , and DebugLib is listed under [LibraryClasses] in each
> > instance of OpensslLib. So if you modify your
> > "CryptoPkg/Library/OpensslLib/openssl" submodule directory tree locally,
> > with the following patch:
> >
> > | diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
> > | index 0fcf4fe3bc1e..e5f105268f52 100644
> > | --- a/crypto/rand/rand_lib.c
> > | +++ b/crypto/rand/rand_lib.c
> > | @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
> > |      drbg = RAND_get0_primary(NULL);
> > |      if (drbg != NULL && num > 0)
> > |          EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
> > | +
> > | +    DEBUG ((DEBUG_INFO, "%a: hello\n", __func__));
> > |  }
> > |
> > |  void RAND_add(const void *buf, int num, double randomness)
> >
> > then you should get usable debug messages -- at least it builds for me.
> >
> > Inserting DEBUGs like this (over multiple rounds of testing / narrowing)
> > should lead you to the exact location that is responsible for the
> > initialization failure.
> >
> > You mention you have encountered the problem with a UEFI application.
> > That is relevant for choosing your DebugLib instance. If you already
> > have a function DebugLib instance for your platform (logging to the
> > serial port, for example), then just use that.
> >
> > Otherwise, consider building your UEFI application with a module scope
> > override in the DSC file, one that resolves DebugLib to
> >
> >   MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> >
> > or
> >
> >   MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
> >
> > These will send DEBUG messages to the UEFI console or standard error
> > devices, respectively.
> >
> > hth
> > Laszlo
> >
> > > Laszlo Ersek mailto:ler...@redhat.com>
> > >> 於 2024年2月
> > > 8日 週四 上午5:03寫道：
> > >
> > >     On 2/6/24 08:00, eddie wang wrote:
> > >     > Hi all,
> > >  

Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom number generator properly

[Yao, Jiewen]

Thanks Laslo and Eddie.

I am just back from Chinese New Year vocation, still checking email.

If you can file a Bugzilla (https://bugzilla.tianocore.org/) with source code 
of your app, that would be very helpful for us to investigate this issue.


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Tuesday, February 20, 2024 4:18 AM
> To: eddie wang 
> Cc: devel@edk2.groups.io
> Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom
> number generator properly
> 
> On 2/17/24 10:17, eddie wang wrote:
> > Hi Laszlo,
> > After digging dipper,  we found that the *EVP_RAND_fetch *in
> > "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's
> > meant the DRBG implementation could
> > not be fetched. We also compared it to the case on Linux, and they could
> > both fetched DRBG implementation correctly. Is it possible that the
> > opensslLib 3.0.9 caused any compatibility issues with edk2?  Or has
> > anyone else encountered the same problem with these openssl services?
> 
> Sorry, I can't say.
> 
> If you have a small reproducer UEFI application that works fine when
> built with edk2-stable202305, but does not work when built against
> either edk2-stable202308 or current master, then filing a TianoCore BZ
> (regression) seems justified. (AFAICT it was edk2-stable202308 that
> incorporated the OpenSSL 3.0.9 upgrade, from 1.1.1u.) Attaching the
> source code of the small repro application to the ticket would likely be
> helpful.
> 
> Laszlo
> 
> > Laszlo Ersek mailto:ler...@redhat.com>> 於 2024年2月
> > 15日 週四 下午7:48寫道：
> >
> > On 2/15/24 12:09, eddie wang wrote:
> > > Hi Laszlo,
> > > Thanks for your reply. How can I enable the DEBUGs at RandomSeed()
> > ? Or
> > > any suggesting information that I can provide?
> >
> > Sorry, upon a closer look, I see you had already narrowed it down to
> > RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
> > suggestion would amount to adding DEBUGs to OpenSSL, such as to
> > RAND_seed() in
> > "CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".
> >
> > But, I think you may be able to do just that.
> > "CryptoPkg/Library/Include/CrtLibSupport.h" already includes
> > , and DebugLib is listed under [LibraryClasses] in each
> > instance of OpensslLib. So if you modify your
> > "CryptoPkg/Library/OpensslLib/openssl" submodule directory tree locally,
> > with the following patch:
> >
> > | diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
> > | index 0fcf4fe3bc1e..e5f105268f52 100644
> > | --- a/crypto/rand/rand_lib.c
> > | +++ b/crypto/rand/rand_lib.c
> > | @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
> > |      drbg = RAND_get0_primary(NULL);
> > |      if (drbg != NULL && num > 0)
> > |          EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
> > | +
> > | +    DEBUG ((DEBUG_INFO, "%a: hello\n", __func__));
> > |  }
> > |
> > |  void RAND_add(const void *buf, int num, double randomness)
> >
> > then you should get usable debug messages -- at least it builds for me.
> >
> > Inserting DEBUGs like this (over multiple rounds of testing / narrowing)
> > should lead you to the exact location that is responsible for the
> > initialization failure.
> >
> > You mention you have encountered the problem with a UEFI application.
> > That is relevant for choosing your DebugLib instance. If you already
> > have a function DebugLib instance for your platform (logging to the
> > serial port, for example), then just use that.
> >
> > Otherwise, consider building your UEFI application with a module scope
> > override in the DSC file, one that resolves DebugLib to
> >
> >   MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> >
> > or
> >
> >   MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
> >
> > These will send DEBUG messages to the UEFI console or standard error
> > devices, respectively.
> >
> > hth
> > Laszlo
> >
> > > Laszlo Ersek mailto:ler...@redhat.com>
> > >> 於 2024年2月
> > > 8日 週四 上午5:03寫道：
> > >
> > >     On 2/6/24 08:00, eddie wang wrote:
> > >     > Hi all,
> > >     > We had an UEFI application that used the EDK2(2023/12/05),
> > and  we
> > >     would
> > >     > like to take advantage of the services in BaseCryptLib .However,
> > >     the API
> > >     > in CryptPkg "*RandomSeed()*"(X64, in CryptRandTsc.c) always
> > returned
> > >     > false because of  the pseudorandom number generator set up
> > failed.
> > >     I am
> > >     > not sure this issue is from the *openssl configuration in
> > >     OpensslLib(we
> > >     > use the default configuration)* or is from the *openssl 3.0.9*.
> > >     >
> > >     > Is there 

Re: [edk2-devel] [edk2-redfish-client][PATCH V3] RedfishClientPkg: Readme.md update

[Nickle Wang via groups.io]

Reviewed-by: Nickle Wang 

Regards,
Nickle

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang, Abner
> via groups.io
> Sent: Monday, February 5, 2024 4:36 PM
> To: devel@edk2.groups.io
> Cc: Nickle Wang ; Igor Kulchytskyy 
> Subject: Re: [edk2-devel] [edk2-redfish-client][PATCH V3] RedfishClientPkg:
> Readme.md update
> 
> External email: Use caution opening links or attachments
> 
> 
> [AMD Official Use Only - General]
> 
> Hi Igor and Nickle,
> Sorry for sending out V3 so quick. I forget to add the criteria for HTTP POST 
> and
> DELETE.
> 
> Thanks
> Abner
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Chang,
> > Abner via groups.io
> > Sent: Monday, February 5, 2024 4:34 PM
> > To: devel@edk2.groups.io
> > Cc: Nickle Wang ; Igor Kulchytskyy 
> > Subject: [edk2-devel] [edk2-redfish-client][PATCH V3] RedfishClientPkg:
> > Readme.md update
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > From: Abner Chang 
> >
> > Update Readme file to align with Redfish Client implementation.
> >
> > Signed-off-by: Abner Chang 
> > Cc: Nickle Wang 
> > Cc: Igor Kulchytskyy 
> > ---
> >  RedfishClientPkg/Readme.md | 175
> > +
> >  1 file changed, 160 insertions(+), 15 deletions(-)
> >
> > diff --git a/RedfishClientPkg/Readme.md b/RedfishClientPkg/Readme.md
> > index edef2ec23b..82cb9c8c99 100644
> > --- a/RedfishClientPkg/Readme.md
> > +++ b/RedfishClientPkg/Readme.md
> > @@ -294,7 +294,7 @@ PCD is set to `TRUE`.
> >  The purpose of Redfish feature driver is to do the synchronization
> > job between Redfish service and BIOS. The operation of synchronization
> > can be simply divided into two types:
> >
> >   Provisioning resource
> > -Below is the flow diagram of provisioning platform configuration to
> > Redfish service at Bios resource. With the x-uefi-redfish
> > +Below is the flow diagram of provisioning platform configuration to
> > +Redfish
> > service at BIOS resource. With the x-uefi-redfish  configure language
> > described in above section, Redfish feature driver collect all BIOS
> > attributes from HII database and populated  them to Redfish service.
> >  ![provisioning](https://github.com/tianocore/edk2-redfish-
> > client/blob/main/RedfishClientPkg/Documents/Media/redfish-call-flow-
> > provisioning.svg?raw=true)
> > @@ -311,7 +311,7 @@ job.
> >  Several interfaces defined in EDKII Redfish Resource Config Protocol
> > work together to support Redfish synchronization:
> >  - Identify()
> >- This function is used to check if the given Redfish resource is
> > the one the feature driver wants to manage. A platform
> > -library `RedfishReesourceIdentifyLib` is introduced for platform to
> > implement its own policy to identify Redfish resource.
> > +library `RedfishResourceIdentifyLib` is introduced for platform
> > + to
> > implement its own policy to identify Redfish resource.
> >  - Check()
> >- This function is used to check the attribute status on Redfish
> > service. If all attributes the feature driver manages
> >  are presented in Redfish service, feature driver must provision them 
> > already.
> > Otherwise, Provisioning() will be called @@ -338,19 +338,164 @@ struct
> > _EDKII_REDFISH_RESOURCE_ADDENDUM_PROTOCOL {  };  ```
> >
> > - Redfish service implementation
> > -The idea of Redfish synchronization design is to manage Redfish
> > resource directly by platform firmware. To do this, Redfish
> > -synchronization functions have to work with Redfish service
> > implementation in BMC firmware. This is because the interface -between
> > platform firmware and BMC firmware is not defined in any
> > specification.
> > -Several prerequisites must be satisfied:
> > -- Platform firmware has permission to manage Redfish resource. BMC
> > has ability to tell the difference between platform request
> > -  and out-of-band user. This can normally be done by identifying the
> > bootstrap account in HTTP request. The bootstrap account is
> > -  described in Host Interface specification 1.3.0 section 9.
> > -- The ability to tell if there is an user who changes to Redfish resource 
> > or not.
> > Redfish feature drivers can only be executed at
> > -  POST time. So the modification to BIOS managed resource is an
> > asynchronous operation. Thus, we need below supports in Redfish service:
> > -  - ETAG support in HTTP header.
> > -  - Setting resource support (defined in Redfish specification 1.18
> > section 9.10).
> > -  - Redfish Task support to POST and DELETE operation made by user in
> > Redfish collection resource and Redfish actions.
> > +### Redfish Service Implementation that Incorporates with EDK2
> > +Redfish The idea of Redfish synchronization design is to manage
> > +Redfish resource
> > directly by platform host
> > +firmware. To do this, Redfish synchronization functions 

Re: [edk2-devel] GVT-g VM takes a long time before OVMF splash shown - bisected

[Laszlo Ersek]

Hi,

On 2/19/24 19:18, chriscjsus via groups.io wrote:
> Sorry if this is a duplicate post.  I sent an email to
> devel@edk2.groups.io  before creating an
> account on groups.io.
> 
> This started with edk2-stable202311.  I bisected this to
> 
> first bad commit: [e8aa4c6546ad5b04a1100fa2618e424f58e354f5]
> UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0
> 
> I tried the lastest ovmf git master with same result.  Reverting the
> above commit fixed the issue.
> 
> I am running Arch linux with kernel 6.7.4.

This should be resolved by Gerd's patch set

  [edk2-devel] [PATCH v3 0/4] OvmfPkg/Sec: Setup MTRR early in the boot process.
  https://edk2.groups.io/g/devel/message/114781
  https://openfw.io/edk2-devel/20240130130441.772484-1-kra...@redhat.com/

The first commit in the patch set explains the issue.

(IIUC, we're waiting on Min's confirmation wrt. TDX, under patch v3 1/4, before 
the v3 set can be merged.)

Laszlo



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

[edk2-devel] [PATCH] Pkg-Module: OptionRomPkg, MinPlatformPkg, Silicon/Marvell

[Gahan Saraiya]

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

Bug 4689 - GetInfo() of Adapter Information Protocol
should have a provision for IHV to return no data for
UEFI Spec compliance 2.9 [mantis #1866]

Signed-off-by: Gahan Saraiya 
---
 Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h| 17 +
 .../Test/Library/TestPointLib/DxeTestPointAip.c |  7 ---
 Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c |  1 +
 3 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h 
b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
index 31c55a8e11..45c1f41414 100644
--- a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
+++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
@@ -350,23 +350,24 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI 
*PxePtr);
 
   This function returns information of type InformationType from the adapter.
   If an adapter does not support the requested informational type, then
-  EFI_UNSUPPORTED is returned. 
+  EFI_UNSUPPORTED is returned.
 
   @param[in]  This   A pointer to the 
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
   @param[in]  InformationTypeA pointer to an EFI_GUID that defines the 
contents of InformationBlock.
-  @param[out] InforamtionBlock   The service returns a pointer to the 
buffer with the InformationBlock
+  @param[out] InformationBlock   The service returns a pointer to the 
buffer with the InformationBlock
  structure which contains details about 
the data specific to InformationType.
-  @param[out] InforamtionBlockSize   The driver returns the size of the 
InformationBlock in bytes.
+  @param[out] InformationBlockSize   The driver returns the size of the 
InformationBlock in bytes.
 
   @retval EFI_SUCCESSThe InformationType information was 
retrieved.
   @retval EFI_UNSUPPORTEDThe InformationType is not known.
+  @retval EFI_NOT_FOUND  Information is not available for the 
requested information type.
   @retval EFI_DEVICE_ERROR   The device reported an error.
   @retval EFI_OUT_OF_RESOURCES   The request could not be completed due to 
a lack of resources.
-  @retval EFI_INVALID_PARAMETER  This is NULL. 
-  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL. 
+  @retval EFI_INVALID_PARAMETER  This is NULL.
+  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL.
   @retval EFI_INVALID_PARAMETER  InformationBlockSize is NULL.
 
-**/  
+**/
 EFI_STATUS
 EFIAPI
 UndiAipGetInfo (
@@ -396,7 +397,7 @@ UndiAipGetInfo (
   @retval EFI_INVALID_PARAMETER  InformationBlock is NULL.
   @retval EFI_WRITE_PROTECTEDThe InformationType cannot be modified 
using EFI_ADAPTER_INFO_SET_INFO().
 
-**/
+**/
 EFI_STATUS
 EFIAPI
 UndiAipSetInfo (
@@ -427,7 +428,7 @@ UndiAipSetInfo (
   @retval EFI_INVALID_PARAMETER InfoTypesBufferCount is NULL.
   @retval EFI_OUT_OF_RESOURCES  There is not enough pool memory to store 
the results.
 
-**/
+**/
 EFI_STATUS
 EFIAPI
 UndiAipGetSupportedTypes (
diff --git 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c
index a7fe9530cf..95d8c02b5a 100644
--- a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c
+++ b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointLib/DxeTestPointAip.c
@@ -12,7 +12,7 @@
 
   This function returns information of type InformationType from the adapter.
   If an adapter does not support the requested informational type, then
-  EFI_UNSUPPORTED is returned. 
+  EFI_UNSUPPORTED is returned.
 
   @param[in]  This   A pointer to the 
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
   @param[in]  InformationTypeA pointer to an EFI_GUID that defines the 
contents of InformationBlock.
@@ -22,10 +22,11 @@
 
   @retval EFI_SUCCESSThe InformationType information was 
retrieved.
   @retval EFI_UNSUPPORTEDThe InformationType is not known.
+  @retval EFI_NOT_FOUND  Information is not available for the 
requested information type.
   @retval EFI_DEVICE_ERROR   The device reported an error.
   @retval EFI_OUT_OF_RESOURCES   The request could not be completed due to 
a lack of resources.
-  @retval EFI_INVALID_PARAMETER  This is NULL. 
-  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL. 
+  @retval EFI_INVALID_PARAMETER  This is NULL.
+  @retval EFI_INVALID_PARAMETER  InformationBlock is NULL.
   @retval EFI_INVALID_PARAMETER  InformationBlockSize is NULL.
 
 **/
diff --git a/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c 
b/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
index 5e463ac932..517b21940d 100644
--- a/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
+++ b/Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
@@ -1394,6 +1394,7 @@ Pp2DxeSnpInstall (
 
   

[edk2-devel] [PATCH 2/2] Update Maintainers for Intel packages

[Nathaniel Haller]

Update PurleySiliconBinPkg, WhitleyOpenBoardBinPkg, and
WhitleySiliconBinPkg maintainers.

Cc: Nate DeSimone 
Cc: Chasel Chiu 
Signed-off-by: Nathaniel Haller 
---
 Maintainers.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 66ac96d..eaf13fd 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -46,9 +46,9 @@ M: Chasel Chiu 
 M: Nate DeSimone 
 
 Platform/Intel/WhitleyOpenBoardBinPkg
-M: Isaac Oram 
 M: Nate DeSimone 
 M: Chasel Chiu 
+M: Nathaniel Haller 
 
 Platform/Intel/EaglestreamOpenBoardBinPkg
 M: Nate DeSimone 
@@ -87,11 +87,12 @@ M: Sai Chaganty 
 
 Silicon/Intel/PurleySiliconBinPkg
 M: Nate DeSimone 
-M: Isaac W Oram 
+M: Chasel Chiu 
 
 Silicon/Intel/WhitleySiliconBinPkg
 M: Nate DeSimone 
-M: Isaac W Oram 
+M: Chasel Chiu 
+M: Nathaniel Haller 
 
 Silicon/Intel/EaglestreamSiliconBinPkg
 M: Nate DeSimone 
-- 
2.43.0.windows.1



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

[edk2-devel] GVT-g VM takes a long time before OVMF splash shown - bisected

[chriscjsus via groups.io]

Sorry if this is a duplicate post.  I sent an email to devel@edk2.groups.io 
before creating an account on groups.io.

This started with edk2-stable202311.  I bisected this to

first bad commit: [e8aa4c6546ad5b04a1100fa2618e424f58e354f5] 
UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

I tried the lastest ovmf git master with same result.  Reverting the above 
commit fixed the issue.

I am running Arch linux with kernel 6.7.4.


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

[edk2-devel] GVT-g VM takes a long time before OVMF splash shown - bisected

[Chris Stinson via groups.io]

This started with edk2-stable202311.  I bisected this to

# first bad commit: [e8aa4c6546ad5b04a1100fa2618e424f58e354f5] 
UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0


I tried the lastest ovmf git master with same result.  Reverting the 
above commit fixed the issue.


I'm running Arch linux with kernel 6.7.4.



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

[edk2-devel] [PATCH 1/2] Add maintainers for EaglestreamSiliconBinPkg and EaglestreamOpenBoardBinPkg

[Nathaniel Haller]

Cc: Nate DeSimone 
Cc: Chasel Chiu 
Signed-off-by: Nathaniel Haller 
---
 Maintainers.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 1d5dacb..66ac96d 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -50,6 +50,11 @@ M: Isaac Oram 
 M: Nate DeSimone 
 M: Chasel Chiu 
 
+Platform/Intel/EaglestreamOpenBoardBinPkg
+M: Nate DeSimone 
+M: Chasel Chiu 
+M: Nathaniel Haller 
+
 Platform/Intel/CoffeelakeSiliconBinPkg
 M: Chasel Chiu 
 M: Sai Chaganty 
@@ -88,6 +93,11 @@ Silicon/Intel/WhitleySiliconBinPkg
 M: Nate DeSimone 
 M: Isaac W Oram 
 
+Silicon/Intel/EaglestreamSiliconBinPkg
+M: Nate DeSimone 
+M: Chasel Chiu 
+M: Nathaniel Haller 
+
 Silicon/Intel/QuarkSocBinPkg
 M: Michael D Kinney 
 M: Kelly Steele 
-- 
2.43.0.windows.1



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

[edk2-devel] [PATCH 0/2] Intel maintainers updates

[Nathaniel Haller]

Adding maintainers for new Intel packages, EaglestreamSiliconBinPkg and
EaglestreamOpenBoardBinPkg, then replacing Isaac W Oram from the
Intel package maintainers lists.

Nathaniel Haller (2):
  Add maintainers for EaglestreamSiliconBinPkg and
EaglestreamOpenBoardBinPkg
  Update Maintainers for Intel packages

 Maintainers.txt | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

-- 
2.43.0.windows.1



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

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/NvmExpressDxe: use format "0x%lx" for UINT64 values.

[Laszlo Ersek]

On 2/16/24 22:26, Mike Maslenkin wrote:
> Signed-off-by: Mike Maslenkin 
> Cc: Ray Ni 
> ---
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> index dfa3653d6a5e..069da12a9b1b 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
> @@ -288,9 +288,9 @@ EnumerateNvmeDevNamespace (
>  // Dump NvmExpress Identify Namespace Data
>  //
>  DEBUG ((DEBUG_INFO, " == NVME IDENTIFY NAMESPACE [%d] DATA ==\n", 
> NamespaceId));
> -DEBUG ((DEBUG_INFO, "NSZE: 0x%x\n", NamespaceData->Nsze));
> -DEBUG ((DEBUG_INFO, "NCAP: 0x%x\n", NamespaceData->Ncap));
> -DEBUG ((DEBUG_INFO, "NUSE: 0x%x\n", NamespaceData->Nuse));
> +DEBUG ((DEBUG_INFO, "NSZE: 0x%lx\n", NamespaceData->Nsze));
> +DEBUG ((DEBUG_INFO, "NCAP: 0x%lx\n", NamespaceData->Ncap));
> +DEBUG ((DEBUG_INFO, "NUSE: 0x%lx\n", NamespaceData->Nuse));
>  DEBUG ((DEBUG_INFO, "LBAF0.LBADS : 0x%x\n", 
> (NamespaceData->LbaFormat[0].Lbads)));
>  
>  //

series
Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115601): https://edk2.groups.io/g/devel/message/115601
Mute This Topic: https://groups.io/mt/104401877/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-libc 1/1] StdLib: Remove the 'register' keyword from public interfaces

[Laszlo Ersek]

On 2/16/24 22:46, Pedro Falcato wrote:
> ISO C interfaces do not have the 'register' keyword, so this is
> technically non-compliant and other consumers of C headers (such as C++)
> will error out when seeing this keyword.
> 
> This should not affect anything, functionality-wise or ABI-wise.
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Cc: pawel.karczew...@solidigm.com
> Signed-off-by: Pedro Falcato 
> ---
> 
> This should fix your problem. Pawel, can you check?
> 
>  StdLib/Include/stdlib.h   |  8 
>  StdLib/Include/string.h   |  6 +++---
>  StdLib/LibC/StdLib/Environs.c |  4 ++--
>  StdLib/LibC/String/strsep.c   | 10 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/StdLib/Include/stdlib.h b/StdLib/Include/stdlib.h
> index d9b39d46..42810c86e65a 100644
> --- a/StdLib/Include/stdlib.h
> +++ b/StdLib/Include/stdlib.h
> @@ -33,8 +33,8 @@
>  voidexit(int status) __noreturn;
>  void_Exit   (int status) __noreturn;
>  char   *getenv  (const char *name);
> -int setenv  (register const char * name,
> - register const char * value, int rewrite);
> +int setenv  (const char * name,
> + const char * value, int rewrite);
>  int system  (const char *string);
>  
>    Integer arithmetic functions
> @@ -279,8 +279,8 @@ char   *getenv(const char *name);
>  **/
>  int
>  setenv (
> -  register const char * name,
> -  register const char * value,
> +  const char * name,
> +  const char * value,
>int rewrite
>);
>  
> diff --git a/StdLib/Include/string.h b/StdLib/Include/string.h
> index 0c809441e830..6acd274b848d 100644
> --- a/StdLib/Include/string.h
> +++ b/StdLib/Include/string.h
> @@ -71,7 +71,7 @@
>int   strncasecmp (const char *s1, const char *s2, size_t n);
>size_tstrlcpy (char *destination, const char *source, size_t 
> size);
>size_tstrlcat (char *destination, const char *source, size_t 
> size);
> -  char *strsep  (register char **stringp, register const char 
> *delim);
> +  char *strsep  (char **stringp, const char *delim);
>  @endverbatim
>  
>  Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
> @@ -484,8 +484,8 @@ size_t  strlcat(char *destination, const char *source, 
> size_t size);
>   */
>  char *
>  strsep(
> -  register char **stringp,
> -  register const char *delim
> +  char **stringp,
> +  const char *delim
>);
>  
>  __END_DECLS
> diff --git a/StdLib/LibC/StdLib/Environs.c b/StdLib/LibC/StdLib/Environs.c
> index e8cfd6d9f400..ad16444ce89c 100644
> --- a/StdLib/LibC/StdLib/Environs.c
> +++ b/StdLib/LibC/StdLib/Environs.c
> @@ -209,8 +209,8 @@ char   *getenv(const char *name)
>  **/
>  int
>  setenv (
> -  register const char * name,
> -  register const char * value,
> +  const char * name,
> +  const char * value,
>int rewrite
>)
>  {
> diff --git a/StdLib/LibC/String/strsep.c b/StdLib/LibC/String/strsep.c
> index 234b0cabd689..d250ff781658 100644
> --- a/StdLib/LibC/String/strsep.c
> +++ b/StdLib/LibC/String/strsep.c
> @@ -53,13 +53,13 @@ static char sccsid[] = "@(#)strsep.c  8.1 (Berkeley) 
> 6/4/93";
>   */
>  char *
>  strsep(
> -  register char **stringp,
> -  register const char *delim
> +  char **stringp,
> +  const char *delim
>)
>  {
> -  register char *s;
> -  register const char *spanp;
> -  register int c, sc;
> +  char *s;
> +  const char *spanp;
> +  int c, sc;
>char *tok;
>  
>if ((s = *stringp) == NULL)

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom number generator properly

[Laszlo Ersek]

On 2/17/24 10:17, eddie wang wrote:
> Hi Laszlo,
> After digging dipper,  we found that the *EVP_RAND_fetch *in
> "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's
> meant the DRBG implementation could 
> not be fetched. We also compared it to the case on Linux, and they could
> both fetched DRBG implementation correctly. Is it possible that the
> opensslLib 3.0.9 caused any compatibility issues with edk2?  Or has
> anyone else encountered the same problem with these openssl services?

Sorry, I can't say.

If you have a small reproducer UEFI application that works fine when
built with edk2-stable202305, but does not work when built against
either edk2-stable202308 or current master, then filing a TianoCore BZ
(regression) seems justified. (AFAICT it was edk2-stable202308 that
incorporated the OpenSSL 3.0.9 upgrade, from 1.1.1u.) Attaching the
source code of the small repro application to the ticket would likely be
helpful.

Laszlo

> Laszlo Ersek mailto:ler...@redhat.com>> 於 2024年2月
> 15日 週四 下午7:48寫道：
> 
> On 2/15/24 12:09, eddie wang wrote:
> > Hi Laszlo,
> > Thanks for your reply. How can I enable the DEBUGs at RandomSeed()
> ? Or
> > any suggesting information that I can provide?
> 
> Sorry, upon a closer look, I see you had already narrowed it down to
> RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
> suggestion would amount to adding DEBUGs to OpenSSL, such as to
> RAND_seed() in
> "CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".
> 
> But, I think you may be able to do just that.
> "CryptoPkg/Library/Include/CrtLibSupport.h" already includes
> , and DebugLib is listed under [LibraryClasses] in each
> instance of OpensslLib. So if you modify your
> "CryptoPkg/Library/OpensslLib/openssl" submodule directory tree locally,
> with the following patch:
> 
> | diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
> | index 0fcf4fe3bc1e..e5f105268f52 100644
> | --- a/crypto/rand/rand_lib.c
> | +++ b/crypto/rand/rand_lib.c
> | @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
> |      drbg = RAND_get0_primary(NULL);
> |      if (drbg != NULL && num > 0)
> |          EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
> | +
> | +    DEBUG ((DEBUG_INFO, "%a: hello\n", __func__));
> |  }
> |
> |  void RAND_add(const void *buf, int num, double randomness)
> 
> then you should get usable debug messages -- at least it builds for me.
> 
> Inserting DEBUGs like this (over multiple rounds of testing / narrowing)
> should lead you to the exact location that is responsible for the
> initialization failure.
> 
> You mention you have encountered the problem with a UEFI application.
> That is relevant for choosing your DebugLib instance. If you already
> have a function DebugLib instance for your platform (logging to the
> serial port, for example), then just use that.
> 
> Otherwise, consider building your UEFI application with a module scope
> override in the DSC file, one that resolves DebugLib to
> 
>   MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> 
> or
> 
>   MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
> 
> These will send DEBUG messages to the UEFI console or standard error
> devices, respectively.
> 
> hth
> Laszlo
> 
> > Laszlo Ersek mailto:ler...@redhat.com>
> >> 於 2024年2月
> > 8日 週四 上午5:03寫道：
> >
> >     On 2/6/24 08:00, eddie wang wrote:
> >     > Hi all,
> >     > We had an UEFI application that used the EDK2(2023/12/05),
> and  we
> >     would
> >     > like to take advantage of the services in BaseCryptLib .However,
> >     the API
> >     > in CryptPkg "*RandomSeed()*"(X64, in CryptRandTsc.c) always
> returned
> >     > false because of  the pseudorandom number generator set up
> failed.
> >     I am
> >     > not sure this issue is from the *openssl configuration in
> >     OpensslLib(we
> >     > use the default configuration)* or is from the *openssl 3.0.9*.
> >     >
> >     > Is there any comments about this issue?
> >
> >     Can you narrow it down by inserting DEBUGs starting at
> RandomSeed()
> >     [CryptoPkg/Library/BaseCryptLib/Rand/CryptRandTsc.c], and then
> digging
> >     down as necessary?
> >
> >     Laszlo
> >
> >
> >
> >     
> >
> >
> 



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

Re: [edk2-devel] [edk2-platforms PATCH 5/6] LoongArchQemuPkg: fix SEC ProcessLibraryConstructorList() prototype

[Laszlo Ersek]

On 2/19/24 03:21, Chao Li wrote:
> Hi Laszlo,
> 
> I have tested:
> 
> 1. Follow edk2 series patch 3 changes to
> BaseTools/Source/Python/AutoGen/GenC.py.
> 
> 2. Follow edk2-platforms series patch 5 changes to
> edk2-platforms/Platform/Loongson/LoongArchQemuPkg/Sec/SecMain.c.
> 
> After the changes, I have built and tested, and it works fine.
> 
> 
> BTW, you can get the LoongArch cross-toolchain in two ways:
> 
> 1. Download it from LoongArch cross-toolchain website, URL:
> https://github.com/loongson/build-tools, the last release date is Aug 8,
> 2023.
> 
> 2. Use the Fedora39 docker or virt-machin(X64), and install the
> LoongArch cross-toolchain from rpm source.
> 
> 
> Build-tested-by: Chao Li 
> 
> Reviewed-by: Chao Li 

Thanks -- in fact I've remembered since that, at an earlier time, I've
already used a LoongArch toolchain in a Fedora VM, with a virtio filesystem.

Laszlo

> 
> 
> Thanks,
> Chao
> On 2024/2/7 09:09, Laszlo Ersek wrote:
>> The current declaration of, and call to, SEC
>> ProcessLibraryConstructorList() in LoongArchQemuPkg matches the PEIM entry
>> point parameter list. Fix the call, and rely on AutoGen for the
>> declaration.
>>
>> Untested (have no cross-toolchain installed for LOONGARCH64).
>>
>> Cc: Bibo Mao 
>> Cc: Chao Li 
>> Cc: Xianglai li 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  Platform/Loongson/LoongArchQemuPkg/Sec/SecMain.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/Platform/Loongson/LoongArchQemuPkg/Sec/SecMain.c 
>> b/Platform/Loongson/LoongArchQemuPkg/Sec/SecMain.c
>> index 3f1998c48c12..50d898859a99 100644
>> --- a/Platform/Loongson/LoongArchQemuPkg/Sec/SecMain.c
>> +++ b/Platform/Loongson/LoongArchQemuPkg/Sec/SecMain.c
>> @@ -9,7 +9,6 @@
>>  
>>  #include 
>>  
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -378,7 +377,7 @@ SecCoreStartupWithStack (
>>  
>>DEBUG ((DEBUG_INFO, "Entering C environment\n"));
>>  
>> -  ProcessLibraryConstructorList (NULL, NULL);
>> +  ProcessLibraryConstructorList ();
>>  
>>DEBUG ((DEBUG_INFO,
>>  "SecCoreStartupWithStack (0x%lx, 0x%lx)\n",
>>
>>
>>
>> 
>>
>>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115598): https://edk2.groups.io/g/devel/message/115598
Mute This Topic: https://groups.io/mt/104210907/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 12/12] OvmfPkg: only add shell to FV in case secure boot is disabled

[Laszlo Ersek]

On 2/19/24 11:21, Gerd Hoffmann wrote:
>>> -!if $(BUILD_SHELL) == TRUE
>>> +!if $(BUILD_SHELL) == TRUE && $(SECURE_BOOT_ENABLE) == FALSE
>>>
>>>  !if $(TOOL_CHAIN_TAG) != "XCODE5"
>>>  !if $(NETWORK_ENABLE) == TRUE
>>
>> This does the job:
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> An alternative could be (perhaps informing the user better):
>>
>>   !if $(BUILD_SHELL) == TRUE
>>   !if $(SECURE_BOOT_ENABLE) == TRUE
>>   !error BUILD_SHELL and SECURE_BOOT_ENABLE conflict
>>   !endif
>>   ...
>>   !endif
> 
> That would break CI.
> 
> Patch 11/12 depends on the shell being built even if not included in the
> firmware image, so it can be copied to the virtual drive used by the
> qemu test.

Ah, understood. We don't conditionalize in the DSC files, only in the FDFs.

Laszlo

> 
>> A repost might be worth your while either way, because some of the
>> patches are identical to their first versions, and Jiewen's v1 Acked-by,
>> from [1], is missing from the unchanged (or trivially rebased) patches
>> in v2.
> 
> Oops, right, went over all individual patches updating them, then forgot
> the Jiewen's ack for the whole series.
> 
> take care,
>   Gerd
> 



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

Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()

[Laszlo Ersek]

On 2/19/24 12:37, Gerd Hoffmann wrote:
>   Hi,
> 
>> (I'm missing the larger picture here -- is this related to the problem
>> -- too many CPUs to fit their infos into a single HOB -- that Pawel
>> worked on for a while?
> 
> Different HOB, but similar underlying problem.
> 
> At least the HOB structure already has the fields needed to allow
> splitting the information into multiple HOBs, even though the current
> code doesn't actually do that (which is fixed by this series).
> 
>> The outer loop is suboptimal, IMO, to just open-coding another HOB scan
>> -- this approach looks quadratic, even though it could be linear. More
>> or less, as proposed, we call GetMpHandOffHob() for each MP_HAND_OFF
>> HOB, which will scan n/2 HOBs on average. (Even if the GUID HOB list is
>> sorted by ProcessorIndex, we'll scan 1 + 2 + 3 +... HOBs.) But if we
>> open-coded GetFirstGuidHob() and GetNextGuidHob() here, then a single
>> scan would suffice.
> 
> Ray raised performance concerns too.
> 
> Does HobLib provides any ordering guarantees?  Specifically in case the
> HOBs are returned in the same order they are created (which implies they
> are sorted by ProcessorIndex because patch #5 creates them in that
> order) this can certainly be optimized.

I don't think there are ordering guarantees, but my larger point in
review is that the order does not matter. I see no reason for addressing
HOBs in increasing processor index order. No loop over the HOBs that
I've seen touched by this patch set seems to depend on the visiting
order of HOBs. So the outer loops that advance with
GetMpHandOffHob(ProcessorIndex) should be rewritable with get-next-GUID-HOB.

Laszlo



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

Re: [edk2-devel] [PATCH 5/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SaveCpuMpData()

[Laszlo Ersek]

On 2/15/24 10:31, Gerd Hoffmann wrote:
> Add support for splitting Hand-Off data into multiple HOBs.  This is
> required for VMs with thousands of CPUs.  The actual CPU count per HOB
> is much smaller (128) for better test coverage.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c | 48 ++---
>  1 file changed, 27 insertions(+), 21 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> index f80e00edcff3..a5710789c8c3 100644
> --- a/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> @@ -126,35 +126,41 @@ SaveCpuMpData (
>IN CPU_MP_DATA  *CpuMpData
>)
>  {
> -  UINT64   Data64;
> -  UINTNIndex;
> -  CPU_INFO_IN_HOB  *CpuInfoInHob;
> -  MP_HAND_OFF  *MpHandOff;
> -  UINTNMpHandOffSize;
> +  STATIC CONST UINT32  CpusPerHob = 128;

This should be a fixed-at-build PCD. Easy to modify on the build command
line, for test coverage, but for production builds, it should be as
large as possible.

In fact, the code should determine how many CPU entries fit in a single
HOB [*], and the PCD should be checked against it:

- PCD == 0: use the maximum
- PCD > maximum: assert
- otherwise: use the PCD as chunking factor

[*] See BuildGuidHob() in "MdePkg/Library/PeiHobLib/HobLib.c":

|   //
|   // Make sure that data length is not too long.
|   //
|   ASSERT (DataLength <= (0xFFF8 - sizeof (EFI_HOB_GUID_TYPE)));

So the max permitted payload size is 0xFFE0 bytes, if I count right.

  CpusPerHob = (0xFFE0 - sizeof (MP_HAND_OFF)) / sizeof (PROCESSOR_HAND_OFF);


> +  UINT64   Data64;
> +  UINT32   Index, HobBase;
> +  CPU_INFO_IN_HOB  *CpuInfoInHob;
> +  MP_HAND_OFF  *MpHandOff;
> +  UINTNMpHandOffSize;
>
>//
>// When APs are in a state that can be waken up by a store operation to a 
> memory address,
>// report the MP_HAND_OFF data for DXE to use.
>//
> -  CpuInfoInHob  = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
> -  MpHandOffSize = sizeof (MP_HAND_OFF) + sizeof (PROCESSOR_HAND_OFF) * 
> CpuMpData->CpuCount;
> -  MpHandOff = (MP_HAND_OFF *)BuildGuidHob (, 
> MpHandOffSize);
> -  ASSERT (MpHandOff != NULL);
> -  ZeroMem (MpHandOff, MpHandOffSize);
> -  MpHandOff->ProcessorIndex = 0;
> +  CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
>
> -  MpHandOff->CpuCount = CpuMpData->CpuCount;
> -  if (CpuMpData->ApLoopMode != ApInHltLoop) {
> -MpHandOff->StartupSignalValue= MP_HAND_OFF_SIGNAL;
> -MpHandOff->WaitLoopExecutionMode = sizeof (VOID *);
> -  }
> +  for (Index = 0; Index < CpuMpData->CpuCount; Index++) {
> +if (Index % CpusPerHob == 0) {
> +  MpHandOffSize = sizeof (MP_HAND_OFF) + sizeof (PROCESSOR_HAND_OFF) * 
> CpusPerHob;

I don't like that the last HOB will only be partially filled in, most of
the time. Especially the max chunking factor -- which strives to create
HOBs that are approximately 64KB in size -- might waste ~32KB on
average, using a flat multiplication like the above.

How about:

  UINT32  FreeInHob;
  PROCESSOR_HAND_OFF  *Info;

  FreeInHob = 0;
  for (Index = 0; Index < CpuMpData->CpuCount; Index++) {
if (FreeInHob == 0) {
  FreeInHob = MIN (CpusPerHob, CpuMpData->CpuCount - Index);
  MpHandOffSize = sizeof *MpHandOff + FreeInHob * sizeof *Info;
  MpHandOff = BuildGuidHob (, MpHandOffSize);
  ASSERT (MpHandOff != NULL);
  ZeroMem (MpHandOff, MpHandOffSize);
  MpHandOff->ProcessorIndex = Index;
  MpHandOff->CpuCount   = FreeInHob;
  Info  = MpHandOff->Info;
}

Info->ApicId = CpuInfoInHob[Index].ApicId;
Info->Health = CpuInfoInHob[Index].Health;
if (CpuMpData->ApLoopMode != ApInHltLoop) {
  Info->StartupSignalAddress= 
(UINT64)(UINTN)CpuMpData->CpuData[Index].StartupApSignal;
  Info->StartupProcedureAddress = 
(UINT64)(UINTN)>CpuData[Index].ApFunction;
}

Info++;
FreeInHob--;
  }

And then "HobBase" becomes superfluous. (Well, having a HobBase that
carries information between iterations of the loop, versus an Info
pointer, is conceptually the same; it's just that the Info pointer
allows for shorter expressions.)

The UINTN -> UINT32 type change for Index looks fine, however.

> +  MpHandOff = (MP_HAND_OFF *)BuildGuidHob (, 
> MpHandOffSize);
> +  ASSERT (MpHandOff != NULL);
> +  ZeroMem (MpHandOff, MpHandOffSize);
>
> -  for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -MpHandOff->Info[Index].ApicId = CpuInfoInHob[Index].ApicId;
> -MpHandOff->Info[Index].Health = CpuInfoInHob[Index].Health;
> +  HobBase   = Index;
> +  MpHandOff->ProcessorIndex = HobBase;
> +  MpHandOff->CpuCount   = MIN (CpuMpData->CpuCount - HobBase, 
> CpusPerHob);

Yes, the MIN() here is my key point, but I think we should also let it
control 

Re: [edk2-devel] [PATCH 4/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to MpInitLibInitialize

[Laszlo Ersek]

On 2/15/24 10:31, Gerd Hoffmann wrote:
> Loop over all MP_HAND_OFF HOBs instead of expecting a single HOB
> covering all CPUs in the system.
> 
> Add a new HaveMpHandOff variable to track whenever MP_HAND_OFF HOBs are
> present, using the MpHandOff pointer for that does not work because the
> variable will be NULL after looping over all HOBs.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 54 +++-
>  1 file changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 35f47d3b1289..1547b7e74a1a 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -2023,6 +2023,7 @@ MpInitLibInitialize (
>)
>  {
>MP_HAND_OFF  *MpHandOff;
> +  BOOLEAN  HaveMpHandOff;
>CPU_INFO_IN_HOB  *CpuInfoInHob;
>UINT32   MaxLogicalProcessorNumber;
>UINT32   ApStackSize;
> @@ -2035,17 +2036,29 @@ MpInitLibInitialize (
>CPU_MP_DATA  *CpuMpData;
>UINT8ApLoopMode;
>UINT8*MonitorBuffer;
> -  UINTNIndex;
> +  UINTNIndex, HobIndex;
>UINTNApResetVectorSizeBelow1Mb;
>UINTNApResetVectorSizeAbove1Mb;
>UINTNBackupBufferAddr;
>UINTNApIdtBase;
>  
> -  MpHandOff = GetMpHandOffHob (0);
> -  if (MpHandOff == NULL) {
> +  MaxLogicalProcessorNumber = 0;
> +  HaveMpHandOff = FALSE;
> +
> +  while ((MpHandOff = GetMpHandOffHob (MaxLogicalProcessorNumber)) != 0) {
> +DEBUG ((
> +  DEBUG_INFO,
> +  "%a: ProcessorIndex=%u CpuCount=%u\n",
> +  __func__,
> +  MpHandOff->ProcessorIndex,
> +  MpHandOff->CpuCount
> +  ));
> +MaxLogicalProcessorNumber += MpHandOff->CpuCount;
> +HaveMpHandOff  = TRUE;
> +  }
> +
> +  if (!HaveMpHandOff) {
>  MaxLogicalProcessorNumber = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
> -  } else {
> -MaxLogicalProcessorNumber = MpHandOff->CpuCount;
>}
>  
>ASSERT (MaxLogicalProcessorNumber != 0);

How about:

- just looping over the GUID HOBs, summing their CpuCount fields,

- replacing the HaveMpHandOff variable with the sum being nonzero, after
the loop

(One extra assertion, on top, could be: while iterating over the GUID
HOB list, also perform a maximum search for (MpHandOff->ProcessorIndex +
MpHandOff->CpuCount), and after the loop, check that the maximum found
like this equals the sum of CpuCount fields. But this is really an extra.)

In other words -- again, I don't see any need for going through the HOBs
in a particular order, just for summing their CpuCount fields.


> @@ -2189,7 +2202,7 @@ MpInitLibInitialize (
>//
>ProgramVirtualWireMode ();
>  
> -  if (MpHandOff == NULL) {
> +  if (!HaveMpHandOff) {
>  if (MaxLogicalProcessorNumber > 1) {
>//
>// Wakeup all APs and calculate the processor count in system
> @@ -2205,19 +2218,26 @@ MpInitLibInitialize (
>AmdSevUpdateCpuMpData (CpuMpData);
>  }

Hm, okay, considering this code, I do agree we need the "HaveMpHandOff"
variable. Because, at this point, MaxLogicalProcessorNumber will be
nonzero, regardless of how we calculated it it.

>  
> -CpuMpData->CpuCount  = MpHandOff->CpuCount;
> +CpuMpData->CpuCount  = MaxLogicalProcessorNumber;
>  CpuMpData->BspNumber = GetBspNumber ();
>  CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
> -for (Index = 0; Index < CpuMpData->CpuCount; Index++) {

This original code here is a bit confused. Namely, after briefly
auditing MpInitLibInitialize(), it seems like "Index" should always have
been UINT32; making it UINTN is a confusing and unneeded generality.
(But, if you disagree with my claim, please say so.)

And the new variable HobIndex should be UINT32 too.

> -  InitializeSpinLock (>CpuData[Index].ApLock);
> -  CpuMpData->CpuData[Index].CpuHealthy = (MpHandOff->Info[Index].Health 
> == 0) ? TRUE : FALSE;

Comment on the pre-patch code:

  Predicate ? TRUE : FALSE

is poor style.

> -  CpuMpData->CpuData[Index].ApFunction = 0;
> -  CpuInfoInHob[Index].InitialApicId= MpHandOff->Info[Index].ApicId;
> -  CpuInfoInHob[Index].ApTopOfStack = CpuMpData->Buffer + (Index + 1) 
> * CpuMpData->CpuApStackSize;
> -  CpuInfoInHob[Index].ApicId   = MpHandOff->Info[Index].ApicId;
> -  CpuInfoInHob[Index].Health   = MpHandOff->Info[Index].Health;
> +for (MpHandOff = GetMpHandOffHob (0);
> + MpHandOff != NULL;
> + MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex + 
> MpHandOff->CpuCount))
> +{
> +  for (HobIndex = 0; HobIndex < MpHandOff->CpuCount; HobIndex++) {
> +Index = MpHandOff->ProcessorIndex + HobIndex;
> +

Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()

[Gerd Hoffmann]

  Hi,

> (I'm missing the larger picture here -- is this related to the problem
> -- too many CPUs to fit their infos into a single HOB -- that Pawel
> worked on for a while?

Different HOB, but similar underlying problem.

At least the HOB structure already has the fields needed to allow
splitting the information into multiple HOBs, even though the current
code doesn't actually do that (which is fixed by this series).

> The outer loop is suboptimal, IMO, to just open-coding another HOB scan
> -- this approach looks quadratic, even though it could be linear. More
> or less, as proposed, we call GetMpHandOffHob() for each MP_HAND_OFF
> HOB, which will scan n/2 HOBs on average. (Even if the GUID HOB list is
> sorted by ProcessorIndex, we'll scan 1 + 2 + 3 +... HOBs.) But if we
> open-coded GetFirstGuidHob() and GetNextGuidHob() here, then a single
> scan would suffice.

Ray raised performance concerns too.

Does HobLib provides any ordering guarantees?  Specifically in case the
HOBs are returned in the same order they are created (which implies they
are sorted by ProcessorIndex because patch #5 creates them in that
order) this can certainly be optimized.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 3/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SwitchApContext()

[Laszlo Ersek]

On 2/15/24 10:31, Gerd Hoffmann wrote:
> Remove the MpHandOff parameter.  This is not useful in case multiple
> HOBs are present in the system.  The function will use GetMpHandOffHob()
> to loop over all HOBs instead.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.h |  2 +-
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 35 +---
>  2 files changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index 7e409cceaddf..a141a95b45ea 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -482,7 +482,7 @@ GetWakeupBuffer (
>  **/
>  VOID
>  SwitchApContext (
> -  IN MP_HAND_OFF  *MpHandOff
> +  VOID
>);
>  
>  /**
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 8e6cf50ed171..35f47d3b1289 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1936,32 +1936,41 @@ GetBspNumber (
>begin running the procedure called SwitchContextPerAp.
>This procedure allows the AP to switch to another section of
>memory and continue its loop there.
> -
> -  @param[in] MpHandOff  Pointer to MP hand-off data structure.
>  **/
>  VOID
>  SwitchApContext (
> -  IN MP_HAND_OFF  *MpHandOff
> +  VOID
>)
>  {
> -  UINTN   Index;
> -  UINT32  BspNumber;
> +  UINTNIndex;
> +  UINT32   BspNumber;
> +  MP_HAND_OFF  *MpHandOff;
>  
>BspNumber = GetBspNumber ();
>  
> -  for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (Index != BspNumber) {
> -  *(UINTN *)(UINTN)MpHandOff->Info[Index].StartupProcedureAddress = 
> (UINTN)SwitchContextPerAp;
> -  *(UINT32 *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress   = 
> MpHandOff->StartupSignalValue;
> +  for (MpHandOff = GetMpHandOffHob (0);
> +   MpHandOff != NULL;
> +   MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex + 
> MpHandOff->CpuCount))
> +  {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> +  if (MpHandOff->ProcessorIndex + Index != BspNumber) {
> +*(UINTN *)(UINTN)MpHandOff->Info[Index].StartupProcedureAddress = 
> (UINTN)SwitchContextPerAp;
> +*(UINT32 *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress   = 
> MpHandOff->StartupSignalValue;
> +  }
>  }
>}
>  
>//
>// Wait all APs waken up if this is not the 1st broadcast of SIPI
>//
> -  for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (Index != BspNumber) {
> -  WaitApWakeup ((UINT32 
> *)(UINTN)(MpHandOff->Info[Index].StartupSignalAddress));
> +  for (MpHandOff = GetMpHandOffHob (0);
> +   MpHandOff != NULL;
> +   MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex + 
> MpHandOff->CpuCount))
> +  {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> +  if (MpHandOff->ProcessorIndex + Index != BspNumber) {
> +WaitApWakeup ((UINT32 
> *)(UINTN)(MpHandOff->Info[Index].StartupSignalAddress));
> +  }
>  }
>}
>  }
> @@ -2226,7 +2235,7 @@ MpInitLibInitialize (
>// enables the APs to switch to a different memory section and 
> continue their
>// looping process there.
>//
> -  SwitchApContext (MpHandOff);
> +  SwitchApContext ();
>//
>// Wait for all APs finished initialization
>//

Same comment as under the previous patch. We could just iterate with
MpHandOff over the GUID HOB list in the outer loops, and perform the
proper actions upon

  MpHandOff->ProcessorIndex + Index != BspNumber

in the inner loop.

It is not necessary for us to ask for the HOBs in any particular
sequence, so we shouldn't pay the O(n) lookup price for every HOB in turn.

Laszlo



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

Re: [edk2-devel] [PATCH 1/5] UefiCpuPkg/MpInitLib: Add ProcessorIndex argument to GetMpHandOffHob()

[Laszlo Ersek]

On 2/15/24 10:31, Gerd Hoffmann wrote:
> This allows to specify which HOB should be returned in case multiple
> MP_HAND_OFF HOBs are present in the system.
> 
> Also add the function prototype to the MpLib.h header file.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.h | 12 
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 20 +---
>  2 files changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index a96a6389c17d..7e409cceaddf 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -485,6 +485,18 @@ SwitchApContext (
>IN MP_HAND_OFF  *MpHandOff
>);
>  
> +/**
> +  Get pointer to MP_HAND_OFF GUIDed HOB, starting with ProcessorIndex
> +
> +  @param[in] ProcessorIndex.
> +
> +  @return  The pointer to MP_HAND_OFF structure.
> +**/
> +MP_HAND_OFF *
> +GetMpHandOffHob (
> +  IN UINT32  ProcessorIndex
> +  );
> +
>  /**
>Get available EfiBootServicesCode memory below 4GB by specified size.
>  
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index cdfb570e61a0..e0a2366073a7 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1961,25 +1961,31 @@ SwitchApContext (
>  }
>  
>  /**
> -  Get pointer to MP_HAND_OFF GUIDed HOB.
> +  Get pointer to MP_HAND_OFF GUIDed HOB, starting with ProcessorIndex
> +
> +  @param[in] ProcessorIndex.
>  
>@return  The pointer to MP_HAND_OFF structure.
>  **/
>  MP_HAND_OFF *
>  GetMpHandOffHob (
> -  VOID
> +  IN UINT32  ProcessorIndex
>)
>  {
>EFI_HOB_GUID_TYPE  *GuidHob;
>MP_HAND_OFF*MpHandOff;
>  
> -  MpHandOff = NULL;
> -  GuidHob   = GetFirstGuidHob ();
> -  if (GuidHob != NULL) {
> +  for (GuidHob = GetFirstGuidHob ();
> +   GuidHob != NULL;
> +   GuidHob = GetNextGuidHob (, GET_NEXT_HOB (GuidHob)))
> +  {
>  MpHandOff = (MP_HAND_OFF *)GET_GUID_HOB_DATA (GuidHob);
> +if (MpHandOff->ProcessorIndex == ProcessorIndex) {
> +  return MpHandOff;
> +}
>}
>  
> -  return MpHandOff;
> +  return NULL;
>  }
>  
>  /**
> @@ -2020,7 +2026,7 @@ MpInitLibInitialize (
>UINTNBackupBufferAddr;
>UINTNApIdtBase;
>  
> -  MpHandOff = GetMpHandOffHob ();
> +  MpHandOff = GetMpHandOffHob (0);
>if (MpHandOff == NULL) {
>  MaxLogicalProcessorNumber = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
>} else {

Seems to do what it says on the tin; not sure what it's going to be good
for, though.

Reviewed-by: Laszlo Ersek 



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

Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()

[Laszlo Ersek]

On 2/15/24 10:31, Gerd Hoffmann wrote:
> Remove the MpHandOff parameter.  This is not useful in case multiple
> HOBs are present in the system.  The function will use GetMpHandOffHob()
> to loop over all HOBs instead.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index e0a2366073a7..8e6cf50ed171 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1894,26 +1894,32 @@ CheckAllAPs (
>  /**
>This function Get BspNumber.
>  
> -  @param[in] MpHandOffPointer to MpHandOff
>@return BspNumber
>  **/
>  UINT32
>  GetBspNumber (
> -  IN CONST MP_HAND_OFF  *MpHandOff
> +  VOID
>)
>  {
> -  UINT32  ApicId;
> -  UINT32  BspNumber;
> -  UINT32  Index;
> +  UINT32   ApicId;
> +  UINT32   BspNumber;
> +  UINT32   Index;
> +  MP_HAND_OFF  *MpHandOff;
>  
>//
>// Get the processor number for the BSP
>//
>BspNumber = MAX_UINT32;
>ApicId= GetInitialApicId ();
> -  for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (MpHandOff->Info[Index].ApicId == ApicId) {
> -  BspNumber = Index;
> +
> +  for (MpHandOff = GetMpHandOffHob (0);
> +   MpHandOff != NULL;
> +   MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex + 
> MpHandOff->CpuCount))
> +  {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> +  if (MpHandOff->Info[Index].ApicId == ApicId) {
> +BspNumber = MpHandOff->ProcessorIndex + Index;
> +  }
>  }
>}
>  

(I'm missing the larger picture here -- is this related to the problem
-- too many CPUs to fit their infos into a single HOB -- that Pawel
worked on for a while?

"UefiCpuPkg/Library/MpInitLib/MpHandOff.h" was created in commit
8bb018afaf2a ("UefiCpuPkg: Create MpHandOff.", 2023-07-11); I don't have
memories from that time frame. Either way, I do have a question /
observation here:)

The outer loop is suboptimal, IMO, to just open-coding another HOB scan
-- this approach looks quadratic, even though it could be linear. More
or less, as proposed, we call GetMpHandOffHob() for each MP_HAND_OFF
HOB, which will scan n/2 HOBs on average. (Even if the GUID HOB list is
sorted by ProcessorIndex, we'll scan 1 + 2 + 3 +... HOBs.) But if we
open-coded GetFirstGuidHob() and GetNextGuidHob() here, then a single
scan would suffice.

Laszlo

> @@ -1941,7 +1947,7 @@ SwitchApContext (
>UINTN   Index;
>UINT32  BspNumber;
>  
> -  BspNumber = GetBspNumber (MpHandOff);
> +  BspNumber = GetBspNumber ();
>  
>for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
>  if (Index != BspNumber) {
> @@ -2191,7 +2197,7 @@ MpInitLibInitialize (
>  }
>  
>  CpuMpData->CpuCount  = MpHandOff->CpuCount;
> -CpuMpData->BspNumber = GetBspNumber (MpHandOff);
> +CpuMpData->BspNumber = GetBspNumber ();
>  CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
>  for (Index = 0; Index < CpuMpData->CpuCount; Index++) {
>InitializeSpinLock (>CpuData[Index].ApLock);



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115590): https://edk2.groups.io/g/devel/message/115590
Mute This Topic: https://groups.io/mt/104369845/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 12/12] OvmfPkg: only add shell to FV in case secure boot is disabled

[Gerd Hoffmann]

> > -!if $(BUILD_SHELL) == TRUE
> > +!if $(BUILD_SHELL) == TRUE && $(SECURE_BOOT_ENABLE) == FALSE
> >
> >  !if $(TOOL_CHAIN_TAG) != "XCODE5"
> >  !if $(NETWORK_ENABLE) == TRUE
> 
> This does the job:
> 
> Reviewed-by: Laszlo Ersek 
> 
> An alternative could be (perhaps informing the user better):
> 
>   !if $(BUILD_SHELL) == TRUE
>   !if $(SECURE_BOOT_ENABLE) == TRUE
>   !error BUILD_SHELL and SECURE_BOOT_ENABLE conflict
>   !endif
>   ...
>   !endif

That would break CI.

Patch 11/12 depends on the shell being built even if not included in the
firmware image, so it can be copied to the virtual drive used by the
qemu test.

> A repost might be worth your while either way, because some of the
> patches are identical to their first versions, and Jiewen's v1 Acked-by,
> from [1], is missing from the unchanged (or trivially rebased) patches
> in v2.

Oops, right, went over all individual patches updating them, then forgot
the Jiewen's ack for the whole series.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 1/5] UefiCpuPkg/MpInitLib: Add ProcessorIndex argument to GetMpHandOffHob()

[Gerd Hoffmann]

On Mon, Feb 19, 2024 at 02:34:42AM +, Ni, Ray wrote:
> > +  for (GuidHob = GetFirstGuidHob ();
> > +   GuidHob != NULL;
> > +   GuidHob = GetNextGuidHob (, GET_NEXT_HOB
> > (GuidHob)))
> > +  {
> >  MpHandOff = (MP_HAND_OFF *)GET_GUID_HOB_DATA (GuidHob);
> > +if (MpHandOff->ProcessorIndex == ProcessorIndex) {
> > +  return MpHandOff;
> > +}
> 
> Gerd,
> The code is doing correctly but I have concerns about the performance impact.
> 
> With the prototype GetMpHandOffHob(), callers call it multiple times to 
> enumerate all HOB instances.
> 
> But every call is a HOB list enumeration from top of the HOB list which may 
> be slow in a platform
> that contains lots of HOB items and the MpHandOff HOB instances happen to be 
> in the very bottom.
> 
> How about add another parameter "HobStart" to GetMpHandOffHob()? So that only 
> the first call to
> GetMpHandOffHob() is a HOB list enumeration from top, latter calls start from 
> the next HOB of the previous
> found MpHandOff HOB instance.

That will only work if the HOBs are returned in ProcessorIndex order.

That happens to be the case in my testing; the HOBs are returned in the
same order they are created by patch #5 of this series.

Is that behavior guaranteed?  MdePkg/Include/Library/HobLib.h doesn't
say anything about the ordering.

take care,
  Gerd



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

Re: [edk2-devel] Problem Booting Starlingx On PXE

[Michael Brown]

On 19/02/2024 06:44, Hamit Can Karaca wrote:
I am having problem while booting Starlingx on iPXE on UEFI. It says 
malformed binary and does not allow me to boot afterwards. What should I 
do in BIOS to solve this problem?


I can boot Starlingx on other platforms using OEM BIOS.

Our platform is Intel Xeon Purley server. We are using EDK2 BIOS. I have 
added iPXE.efi to fdf file to enable PXE boot.


Any help or suggestions are appreciated.


From your screenshot: iPXE is starting up with no problems, is 
successfully completing DHCP and downloading the file bootx64.efi as 
directed by your DHCP server.


This downloaded file is the UEFI shim, and the error messages you are 
seeing are coming from shim (not from iPXE):


  https://github.com/rhboot/shim/blob/main/pe.c#L264-L286

It appears that shim does not think that your next-stage binary is 
valid.  Unfortunately shim does not provide any information about what 
this next stage binary is (beyond the message "Fetching Netboot Image"), 
and so there is no further diagnostic information available in your 
screenshot.



Using shim's own netboot support in this way is strongly deprecated. 
Please instead use iPXE to load the kernel, initrd, and (if required) 
shim directly.  Documentation is available at


  https://ipxe.org/cmd/shim

Thanks,

Michael



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

Re: [edk2-devel] [edk2-stable202402 PATCH 1/2] UefiCpuPkg/PiSmmCpuDxeSmm: distinguish GetSmBase() failure modes

[duntan]

Laszlo,

Sorry for the late reply. Thanks for your code refactoring patch and bugfix 
patch!

Thanks,
Dun

-Original Message-
From: Laszlo Ersek  
Sent: Thursday, February 15, 2024 4:45 PM
To: Kinney, Michael D ; Leif Lindholm 
; devel@edk2.groups.io; Leif Lindholm 
; Andrew Fish (af...@apple.com) ; 
Gao, Liming 
Cc: Tan, Dun ; Gerd Hoffmann ; Kumar, 
Rahul R ; Ni, Ray 
Subject: Re: [edk2-devel] [edk2-stable202402 PATCH 1/2] 
UefiCpuPkg/PiSmmCpuDxeSmm: distinguish GetSmBase() failure modes

On 2/14/24 18:26, Kinney, Michael D wrote:
> Merged: https://github.com/tianocore/edk2/pull/5373

Thanks!
Laszlo

> 
>> -Original Message-
>> From: Leif Lindholm 
>> Sent: Wednesday, February 14, 2024 5:08 AM
>> To: devel@edk2.groups.io; Kinney, Michael D 
>> ; ler...@redhat.com; Leif Lindholm 
>> ; Andrew Fish (af...@apple.com) 
>> ; Gao, Liming 
>> Cc: Tan, Dun ; Gerd Hoffmann ; 
>> Kumar, Rahul R ; Ni, Ray 
>> Subject: Re: [edk2-devel] [edk2-stable202402 PATCH 1/2]
>> UefiCpuPkg/PiSmmCpuDxeSmm: distinguish GetSmBase() failure modes
>>
>> On 2024-02-14 03:43, Michael D Kinney wrote:
>>> Hi Laszlo,
>>>
>>> Thank you for the quick fix.
>>>
>>> I have reviewed the changes.  I agree they fix the issue at hand.
>>>
>>> Reviewed-by: Michael D Kinney 
>>>
>>> I have adjusted the commit message with your suggested changes in 
>>> the PR I have prepared:
>>>
>>> https://github.com/tianocore/edk2/pull/5373
>>>
>>> There may be better ways to organize this code in general to make it 
>>> easier to understand and maintain in the future, but we can let Ray 
>>> review that when he returns.  That will also likely be a much bugger 
>>> change that can be accepted just before a release.
>>>
>>> I also approve this as a critical fix for edk2-stable202402
>>>
>>> I will wait till tomorrow morning my time to see if Gerd and Rahul 
>>> and Leif can also provide their reviews/approvals and to give me 
>>> some time to run some tests.
>>
>> For the series:
>> Reviewed-by: Leif Lindholm  I'm happy for 
>> this to go into the stable tag.
>>
>> /
>>  Leif
>>
>>> I do not expect Ray Ni or Dun Tan to be available this week.
>>>
>>> Best regards,
>>>
>>> Mike
>>>
 -Original Message-
 From: devel@edk2.groups.io  On Behalf Of
>> Laszlo
 Ersek
 Sent: Tuesday, February 13, 2024 1:36 PM
 To: devel@edk2.groups.io
 Cc: Tan, Dun ; Gerd Hoffmann 
 ; Kumar, Rahul R ; Ni, 
 Ray 
 Subject: Re: [edk2-devel] [edk2-stable202402 PATCH 1/2]
 UefiCpuPkg/PiSmmCpuDxeSmm: distinguish GetSmBase() failure modes

 On 2/13/24 22:09, Laszlo Ersek wrote:
> Commit 725acd0b9cc0 ("UefiCpuPkg: Avoid assuming only one
 smmbasehob",
> 2023-12-12) introduced a helper function called GetSmBase(),
 replacing the
> lookup of the first and only "gSmmBaseHobGuid" GUID HOB, with
 iterated
> lookups plus memory allocation.
>
> This introduced a new failure mode for setting
 "mCpuHotPlugData.SmBase".
> Namely, before commit 725acd0b9cc0, "mCpuHotPlugData.SmBase" would
>> be
 set
> to NULL if and only if the GUID HOB was absent. After the commit, 
> a
 NULL
> assignment would be possible if the GUID HOB was absent, *or* one
>> of
 the
> memory allocations inside GetSmBase() failed.

 Sorry, these two paragraphs are not precise. A better version:

 --
 Commit 725acd0b9cc0 ("UefiCpuPkg: Avoid assuming only one
>> smmbasehob",
 2023-12-12) introduced a helper function called GetSmBase(),
>> replacing
 the lookup of the first and only "gSmmBaseHobGuid" GUID HOB and 
 unconditional "mCpuHotPlugData.SmBase" allocation, with iterated 
 lookups plus conditional memory allocation.

 This introduced a new failure mode for setting 
 "mCpuHotPlugData.SmBase".
 Namely, before commit 725acd0b9cc0, "mCpuHotPlugData.SmBase" would
>> be
 allocated regardless of the GUID HOB being absent. After the 
 commit, "mCpuHotPlugData.SmBase" could remain NULL if the GUID HOB 
 was
>> absent,
 *or* one of the memory allocations inside GetSmBase() failed; and 
 in the former case, we'd even proceed to the rest of 
 PiCpuSmmEntry().
 --

 Sorry, it's late.

 If this patch set is accepted otherwise, then Mike or Liming, can
>> you
 please update the first two paragraphs of the commit message upon 
 merge?

 Thanks
 Laszlo

>
> In relation to this conflation of distinct failure modes, commit
> 725acd0b9cc0 actually introduced a NULL pointer dereference.
>> Namely,
 a
> NULL "mCpuHotPlugData.SmBase" is not handled properly at all now.
 We're
> going to fix that NULL pointer dereference in a subsequent patch;
 however,
> as a pre-requisite for that we need to tell apart the failure 
> modes
 of
> GetSmBase().
>
> For memory allocation failures, return EFI_OUT_OF_RESOURCES. Move
>> the