date:20230116

[edk2-devel] EDK2 biuild errors

2023-01-16 Thread 王志文_Pegatron

Hi Devel,
I am trying to build Z@Pega005 Capsule on EDK2 base code. But I got below 
errors when building the package. Could you give me some advice about below 
error massage? Thank you.

[cid:image001.png@01D92784.A833BE70]

Best Regards,
王志文 | Joe Wang
PEGATRON 和碩聯合科技
Tel: +886 2 81439001 EXT: 37458
Mobile: 0978713458
E-mail：joe8_w...@pegatroncorp.com
No. 96, Ligong St. , Beitou District, Taipei City 112, Taiwan
台北巿北投區立功街96號



This e-mail and its attachment may contain information that is confidential or 
privileged, and are solely for the use of the individual to whom this e-mail is 
addressed. If you are not the intended recipient or have received it 
accidentally, please immediately notify the sender by reply e-mail and destroy 
all copies of this email and its attachment. Please be advised that any 
unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.

本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止
 。



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98653): https://edk2.groups.io/g/devel/message/98653
Mute This Topic: https://groups.io/mt/96325963/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, January 17, 2023 #cal-reminder

2023-01-16 Thread gaoliming via groups.io

Few issues are submitted this week. This week meeting is cancelled. 

 

Thanks

Liming

发件人: devel@edk2.groups.io  代表 Group Notification
发送时间: 2023年1月17日 10:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, January 
17, 2023 #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO 

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

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

Organizer: Liming Gao gaolim...@byosoft.com.cn 

  

View Event  

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 

Join with a video conferencing device 

te...@conf.intel.com   

Video Conference ID: 116 062 094 0 

 

 Alternate VTC dialing instructions 

Or call in (audio only) 

  +1 916-245-6934,,77463821#   United States, 
Sacramento 

Phone Conference ID: 774 638 21# 

 

 Find a local number |   Reset 
PIN 

  Learn More |  

 Meeting options 





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

[edk2-devel] [PATCH V3 2/2] OvmfPkg/CcExitLib: Refactor TDX MmioExit

2023-01-16 Thread Min Xu

From: Min M Xu 

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

The previous TDX MmioExit doesn't handle the Mmio instructions correctly
in some scenarios. This patch refactors the implementation to fix the
issues.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Ryan Afranji 
Reported-by: Ryan Afranji 
Signed-off-by: Min Xu 
---
 OvmfPkg/Library/CcExitLib/CcExitVeHandler.c | 546 ++--
 1 file changed, 382 insertions(+), 164 deletions(-)

diff --git a/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c 
b/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
index 30d547d5fe55..b8979ec2c0c0 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
@@ -13,6 +13,10 @@
 #include 
 #include 
 #include 
+#include "CcInstruction.h"
+
+#define TDX_MMIO_READ   0
+#define TDX_MMIO_WRITE  1
 
 typedef union {
   struct {
@@ -216,14 +220,15 @@ STATIC
 VOID
 EFIAPI
 TdxDecodeInstruction (
-  IN UINT8  *Rip
+  IN UINT8   *Rip,
+  IN UINT32  Length
   )
 {
   UINTN  i;
 
   DEBUG ((DEBUG_INFO, "TDX: #TD[EPT] instruction (%p):", Rip));
-  for (i = 0; i < 15; i++) {
-DEBUG ((DEBUG_INFO, "%02x:", Rip[i]));
+  for (i = 0; i < MIN (15, Length); i++) {
+DEBUG ((DEBUG_INFO, "%02x ", Rip[i]));
   }
 
   DEBUG ((DEBUG_INFO, "\n"));
@@ -233,52 +238,339 @@ TdxDecodeInstruction (
   if ((x)) {\
 TdxDecodeInstruction(Rip);  \
 TdVmCall(TDVMCALL_HALT, 0, 0, 0, 0, 0); \
+CpuDeadLoop (); \
   }
 
+/**
+ * Tdx MMIO access via TdVmcall.
+ *
+ * @param MmioSize  Size of the MMIO access
+ * @param ReadOrWrite   Read or write operation
+ * @param GuestPA   Guest physical address
+ * @param Val   Pointer to the value which is read or written
+
+ * @retval EFI_SUCCESS  Successfully access the mmio
+ * @retval Others   Other errors as indicated
+ */
 STATIC
-UINT64 *
-EFIAPI
-GetRegFromContext (
-  IN EFI_SYSTEM_CONTEXT_X64  *Regs,
-  IN UINTN   RegIndex
+EFI_STATUS
+TdxMmioReadWrite (
+  IN UINT32  MmioSize,
+  IN UINT32  ReadOrWrite,
+  IN UINT64  GuestPA,
+  IN UINT64  *Val
   )
 {
-  switch (RegIndex) {
-case 0: return &Regs->Rax;
-  break;
-case 1: return &Regs->Rcx;
-  break;
-case 2: return &Regs->Rdx;
-  break;
-case 3: return &Regs->Rbx;
-  break;
-case 4: return &Regs->Rsp;
-  break;
-case 5: return &Regs->Rbp;
-  break;
-case 6: return &Regs->Rsi;
-  break;
-case 7: return &Regs->Rdi;
-  break;
-case 8: return &Regs->R8;
-  break;
-case 9: return &Regs->R9;
+  UINT64  TdStatus;
+
+  if ((MmioSize != 1) && (MmioSize != 2) && (MmioSize != 4) && (MmioSize != 
8)) {
+DEBUG ((DEBUG_ERROR, "%a: Invalid MmioSize - %d\n", __FUNCTION__, 
MmioSize));
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (Val == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  TdStatus = 0;
+  if (ReadOrWrite == TDX_MMIO_READ) {
+TdStatus = TdVmCall (TDVMCALL_MMIO, MmioSize, TDX_MMIO_READ, GuestPA, 0, 
Val);
+  } else if (ReadOrWrite == TDX_MMIO_WRITE) {
+TdStatus = TdVmCall (TDVMCALL_MMIO, MmioSize, TDX_MMIO_WRITE, GuestPA, 
*Val, 0);
+  } else {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (TdStatus != 0) {
+DEBUG ((DEBUG_ERROR, "%a: TdVmcall failed with %llx\n", __FUNCTION__, 
TdStatus));
+return EFI_ABORTED;
+  }
+
+  return EFI_SUCCESS;
+}
+
+typedef struct {
+  UINT8   OpCode;
+  UINT32  Bytes;
+  EFI_PHYSICAL_ADDRESSAddress;
+  UINT64  Val;
+  UINT64  *Register;
+  UINT32  ReadOrWrite;
+} MMIO_EXIT_PARSED_INSTRUCTION;
+
+/**
+ * Parse the MMIO instructions.
+ *
+ * @param Regs  Pointer to the EFI_SYSTEM_CONTEXT_X64 which 
includes the instructions
+ * @param InstructionData   Pointer to the CC_INSTRUCTION_DATA
+ * @param ParsedInstruction Pointer to the parsed instruction data
+ *
+ * @retval EFI_SUCCESS  Successfully parsed the instructions
+ * @retval Others   Other error as indicated
+ */
+STATIC
+EFI_STATUS
+ParseMmioExitInstructions (
+  IN OUT EFI_SYSTEM_CONTEXT_X64 *Regs,
+  IN OUT CC_INSTRUCTION_DATA*InstructionData,
+  OUT MMIO_EXIT_PARSED_INSTRUCTION  *ParsedInstruction
+  )
+{
+  EFI_STATUSStatus;
+  UINT8 OpCode;
+  UINT8 SignByte;
+  UINT32Bytes;
+  EFI_PHYSICAL_ADDRESS  Address;
+  UINT64Val;
+  UINT64*Register;
+  UINT32ReadOrWrite;
+
+  Address  = 0;
+  Bytes= 0;
+  Register = NULL;
+  Status   = EFI_SUCCESS;
+  Val  = 0;
+
+  Status = CcInitInstructionData (InstructionData, NULL, Regs);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Initialize InstructionData failed! (%r)\n", 
__FUNCTION__, Status));
+return Status;
+  }
+
+  OpCode = *(InstructionData->OpCodes);
+  if (OpCode == TWO_BYTE_OPCOD

[edk2-devel] [PATCH V3 1/2] OvmfPkg/CcExitLib: Move common X86 instruction code to separate file

2023-01-16 Thread Min Xu

From: Min M Xu 

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

Move common X86 instruction codes from CcExitVcHandler.c to separate
files (CcInstruction.h / CcInstruction.c) so that these codes can be
re-used in TDX.

Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Reviewed-by: Jiewen Yao 
Reviewed-by: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/Library/CcExitLib/CcExitLib.inf |   1 +
 OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 697 +++-
 OvmfPkg/Library/CcExitLib/CcInstruction.c   | 454 +
 OvmfPkg/Library/CcExitLib/CcInstruction.h   | 197 ++
 OvmfPkg/Library/CcExitLib/SecCcExitLib.inf  |   1 +
 5 files changed, 735 insertions(+), 615 deletions(-)
 create mode 100644 OvmfPkg/Library/CcExitLib/CcInstruction.c
 create mode 100644 OvmfPkg/Library/CcExitLib/CcInstruction.h

diff --git a/OvmfPkg/Library/CcExitLib/CcExitLib.inf 
b/OvmfPkg/Library/CcExitLib/CcExitLib.inf
index 131fa6267522..bc75cd5f5a04 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitLib.inf
+++ b/OvmfPkg/Library/CcExitLib/CcExitLib.inf
@@ -25,6 +25,7 @@
   CcExitLib.c
   CcExitVcHandler.c
   CcExitVcHandler.h
+  CcInstruction.c
   PeiDxeCcExitVcHandler.c
   CcExitVeHandler.c
   X64/TdVmcallCpuid.nasm
diff --git a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c 
b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
index 985e5479775c..7fe11c53249e 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
@@ -17,107 +17,7 @@
 #include 
 
 #include "CcExitVcHandler.h"
-
-//
-// Instruction execution mode definition
-//
-typedef enum {
-  LongMode64Bit = 0,
-  LongModeCompat32Bit,
-  LongModeCompat16Bit,
-} SEV_ES_INSTRUCTION_MODE;
-
-//
-// Instruction size definition (for operand and address)
-//
-typedef enum {
-  Size8Bits = 0,
-  Size16Bits,
-  Size32Bits,
-  Size64Bits,
-} SEV_ES_INSTRUCTION_SIZE;
-
-//
-// Intruction segment definition
-//
-typedef enum {
-  SegmentEs = 0,
-  SegmentCs,
-  SegmentSs,
-  SegmentDs,
-  SegmentFs,
-  SegmentGs,
-} SEV_ES_INSTRUCTION_SEGMENT;
-
-//
-// Instruction rep function definition
-//
-typedef enum {
-  RepNone = 0,
-  RepZ,
-  RepNZ,
-} SEV_ES_INSTRUCTION_REP;
-
-typedef struct {
-  UINT8Rm;
-  UINT8Reg;
-  UINT8Mod;
-} SEV_ES_INSTRUCTION_MODRM_EXT;
-
-typedef struct {
-  UINT8Base;
-  UINT8Index;
-  UINT8Scale;
-} SEV_ES_INSTRUCTION_SIB_EXT;
-
-//
-// Instruction opcode definition
-//
-typedef struct {
-  SEV_ES_INSTRUCTION_MODRM_EXTModRm;
-
-  SEV_ES_INSTRUCTION_SIB_EXT  Sib;
-
-  UINTN   RegData;
-  UINTN   RmData;
-} SEV_ES_INSTRUCTION_OPCODE_EXT;
-
-//
-// Instruction parsing context definition
-//
-typedef struct {
-  GHCB *Ghcb;
-
-  SEV_ES_INSTRUCTION_MODE  Mode;
-  SEV_ES_INSTRUCTION_SIZE  DataSize;
-  SEV_ES_INSTRUCTION_SIZE  AddrSize;
-  BOOLEAN  SegmentSpecified;
-  SEV_ES_INSTRUCTION_SEGMENT   Segment;
-  SEV_ES_INSTRUCTION_REP   RepMode;
-
-  UINT8*Begin;
-  UINT8*End;
-
-  UINT8*Prefixes;
-  UINT8*OpCodes;
-  UINT8*Displacement;
-  UINT8*Immediate;
-
-  INSTRUCTION_REX_PREFIX   RexPrefix;
-
-  BOOLEAN  ModRmPresent;
-  INSTRUCTION_MODRMModRm;
-
-  BOOLEAN  SibPresent;
-  INSTRUCTION_SIB  Sib;
-
-  UINTNPrefixSize;
-  UINTNOpCodeSize;
-  UINTNDisplacementSize;
-  UINTNImmediateSize;
-
-  SEV_ES_INSTRUCTION_OPCODE_EXTExt;
-} SEV_ES_INSTRUCTION_DATA;
+#include "CcInstruction.h"
 
 //
 // Non-automatic Exit function prototype
@@ -125,9 +25,9 @@ typedef struct {
 typedef
 UINT64
 (*NAE_EXIT) (
-  GHCB *Ghcb,
-  EFI_SYSTEM_CONTEXT_X64   *Regs,
-  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  GHCB*Ghcb,
+  EFI_SYSTEM_CONTEXT_X64  *Regs,
+  CC_INSTRUCTION_DATA *InstructionData
   );
 
 //
@@ -155,439 +55,6 @@ typedef PACKED struct {
   SEV_SNP_CPUID_FUNCTIONfunction[0];
 } SEV_SNP_CPUID_INFO;
 
-/**
-  Return a pointer to the contents of the specified register.
-
-  Based upon the input register, return a pointer to the registers contents
-  in the x86 processor context.
-
-  @param[in] Regs  x64 processor context
-  @param[in] Register  Register to obtain pointer for
-
-  @return  Pointer to the contents of the requested register
-
-**/
-STATIC
-UINT64 *
-GetRegisterPointer (
-  IN EFI_SYSTEM_CONTEXT_X64  *Regs,
-  IN UINT8   Register
-  )
-{
-  UINT64  *Reg;
-
-  switch (Register) {
-case 0:
-  Reg = &Regs->Rax;
-  break;
-case 1:
-  Reg = &Reg

[edk2-devel] [PATCH V3 0/2] [PATCH V1 0/2] Refactor TDX MmioExit

2023-01-16 Thread Min Xu

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

The previous TDX MmioExit doesn't handle the Mmio instructions correctly
in some scenarios. This patch-set refactors the implementation to fix the
issues.

Before the refactoring, common X86 instruction codes in CcExitVcHandler.c
are moved to separate files (CcInstruction.h / CcInstruction.c) so that
these codes can be re-used in TDX.

Code: https://github.com/mxu9/edk2/tree/TdxMmioExit.v3

v3 changes:
 - Handle the error if an error is returned from TdxMmioReadWrite.
 - Add more check in ParseMmioExitInstructions.

v2 changes:
 - Add CpuDeadLoop () after each TDVMCALL(HALT) in VE handler. Because
   TDVMCALL(HALT) is not trusted.
 - Other minor changes such as deleting ASSERT in VE handler. Because
   any error in VE handler will trigger CpuDeadLoop (). So ASSERT is not
   needed any more.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Ryan Afranji 
Reported-by: Ryan Afranji 
Signed-off-by: Min Xu 

Min M Xu (2):
  OvmfPkg/CcExitLib: Move common X86 instruction code to separate file
  OvmfPkg/CcExitLib: Refactor TDX MmioExit

 OvmfPkg/Library/CcExitLib/CcExitLib.inf |   1 +
 OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 697 +++-
 OvmfPkg/Library/CcExitLib/CcExitVeHandler.c | 546 ++-
 OvmfPkg/Library/CcExitLib/CcInstruction.c   | 454 +
 OvmfPkg/Library/CcExitLib/CcInstruction.h   | 197 ++
 OvmfPkg/Library/CcExitLib/SecCcExitLib.inf  |   1 +
 6 files changed, 1117 insertions(+), 779 deletions(-)
 create mode 100644 OvmfPkg/Library/CcExitLib/CcInstruction.c
 create mode 100644 OvmfPkg/Library/CcExitLib/CcInstruction.h

-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH V1 7/7] OvmfPkg/PlatformPei: Build GuidHob for Tdx measurement

2023-01-16 Thread Min Xu

From: Min M Xu 

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

TdxHelperBuildGuidHobForTdxMeasurement is called in PlatformPei to build
GuidHob for Tdx measurement.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc   | 5 -
 OvmfPkg/CloudHv/CloudHvX64.dsc | 5 -
 OvmfPkg/Microvm/MicrovmX64.dsc | 5 -
 OvmfPkg/OvmfPkgX64.dsc | 5 -
 OvmfPkg/PlatformPei/IntelTdx.c | 3 +++
 5 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 36100f5fdc11..1cebd6b4bcc2 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -570,7 +570,10 @@
   }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf
+  OvmfPkg/PlatformPei/PlatformPei.inf {
+
+  NULL|OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperLibNull.inf
+  }
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
   UefiCpuPkg/CpuMpPei/CpuMpPei.inf
   OvmfPkg/AmdSev/SecretPei/SecretPei.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 7326417eab62..fc5e73158a71 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -678,7 +678,10 @@
   }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf
+  OvmfPkg/PlatformPei/PlatformPei.inf {
+
+  NULL|OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperLibNull.inf
+  }
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 2d53b5c2950d..1161e1f39bf2 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -679,7 +679,10 @@
   }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf
+  OvmfPkg/PlatformPei/PlatformPei.inf {
+
+  NULL|OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperLibNull.inf
+  }
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
   UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0bf16a4815b3..3eade00a6eb4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -747,7 +747,10 @@
   }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf
+  OvmfPkg/PlatformPei/PlatformPei.inf {
+
+  NULL|OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelperLib.inf
+  }
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/PlatformPei/IntelTdx.c b/OvmfPkg/PlatformPei/IntelTdx.c
index 3c1ddbfafd80..3d625cabd844 100644
--- a/OvmfPkg/PlatformPei/IntelTdx.c
+++ b/OvmfPkg/PlatformPei/IntelTdx.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,8 @@ IntelTdxInitialize (
 return;
   }
 
+  TdxHelperBuildGuidHobForTdxMeasurement ();
+
   PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrIntelTdx);
   ASSERT_RETURN_ERROR (PcdStatus);
 
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH V1 6/7] OvmfPkg/PlatformInitLib: Delete the ProcessTdxHobList()

2023-01-16 Thread Min Xu

From: Min M Xu 

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

ProcessTdxHobList is moved to TdxHelperLib and is renamed as
TdxHelperProcessTdHob(). So the duplicated codes are deleted
in PlatformInitLib.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/Include/Library/PlatformInitLib.h |  17 -
 OvmfPkg/Library/PlatformInitLib/IntelTdx.c| 768 --
 .../Library/PlatformInitLib/IntelTdxNull.c|  20 -
 .../PlatformInitLib/PlatformInitLib.inf   |   1 -
 4 files changed, 806 deletions(-)

diff --git a/OvmfPkg/Include/Library/PlatformInitLib.h 
b/OvmfPkg/Include/Library/PlatformInitLib.h
index bf6f90a5761c..67403a1dd93c 100644
--- a/OvmfPkg/Include/Library/PlatformInitLib.h
+++ b/OvmfPkg/Include/Library/PlatformInitLib.h
@@ -209,23 +209,6 @@ PlatformMaxCpuCountInitialization (
   IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
   );
 
-/**
-  In Tdx guest, some information need to be passed from host VMM to guest
-  firmware. For example, the memory resource, etc. These information are
-  prepared by host VMM and put in HobList which is described in TdxMetadata.
-
-  Information in HobList is treated as external input. From the security
-  perspective before it is consumed, it should be validated.
-
-  @retval   EFI_SUCCESS   Successfully process the hoblist
-  @retval   OthersOther error as indicated
-**/
-EFI_STATUS
-EFIAPI
-ProcessTdxHobList (
-  VOID
-  );
-
 /**
   In Tdx guest, the system memory is passed in TdHob by host VMM. So
   the major task of PlatformTdxPublishRamRegions is to walk thru the
diff --git a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c 
b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
index 6cb63139cba0..ada8592ddd5a 100644
--- a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
+++ b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
@@ -16,779 +16,11 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 
-#define ALIGNED_2MB_MASK  0x1f
-#define MEGABYTE_SHIFT20
-
-#define ACCEPT_CHUNK_SIZE  SIZE_32MB
-#define AP_STACK_SIZE  SIZE_16KB
-#define APS_STACK_SIZE(CpusNum)  (ALIGN_VALUE(CpusNum*AP_STACK_SIZE, SIZE_2MB))
-
-/**
-  This function will be called to accept pages. Only BSP accepts pages.
-
-  TDCALL(ACCEPT_PAGE) supports the accept page size of 4k and 2M. To
-  simplify the implementation, the Memory to be accpeted is splitted
-  into 3 parts:
-  -  <-- StartAddress1 (not 2M aligned)
-  |  part 1   |  Length1 < 2M
-  |---|  <-- StartAddress2 (2M aligned)
-  |   |  Length2 = Integer multiples of 2M
-  |  part 2   |
-  |   |
-  |---|  <-- StartAddress3
-  |  part 3   |  Length3 < 2M
-  |---|
-
-  @param[in] PhysicalAddress   Start physical adress
-  @param[in] PhysicalEnd   End physical address
-
-  @retvalEFI_SUCCESS   Accept memory successfully
-  @retvalOthersOther errors as indicated
-**/
-EFI_STATUS
-EFIAPI
-BspAcceptMemoryResourceRange (
-  IN EFI_PHYSICAL_ADDRESS  PhysicalAddress,
-  IN EFI_PHYSICAL_ADDRESS  PhysicalEnd
-  )
-{
-  EFI_STATUS  Status;
-  UINT32  AcceptPageSize;
-  UINT64  StartAddress1;
-  UINT64  StartAddress2;
-  UINT64  StartAddress3;
-  UINT64  TotalLength;
-  UINT64  Length1;
-  UINT64  Length2;
-  UINT64  Length3;
-  UINT64  Pages;
-
-  AcceptPageSize = FixedPcdGet32 (PcdTdxAcceptPageSize);
-  TotalLength= PhysicalEnd - PhysicalAddress;
-  StartAddress1  = 0;
-  StartAddress2  = 0;
-  StartAddress3  = 0;
-  Length1= 0;
-  Length2= 0;
-  Length3= 0;
-
-  if (TotalLength == 0) {
-return EFI_SUCCESS;
-  }
-
-  if (ALIGN_VALUE (PhysicalAddress, SIZE_2MB) != PhysicalAddress) {
-StartAddress1 = PhysicalAddress;
-Length1   = ALIGN_VALUE (PhysicalAddress, SIZE_2MB) - PhysicalAddress;
-if (Length1 >= TotalLength) {
-  Length1 = TotalLength;
-}
-
-PhysicalAddress += Length1;
-TotalLength -= Length1;
-  }
-
-  if (TotalLength > SIZE_2MB) {
-StartAddress2= PhysicalAddress;
-Length2  = TotalLength & ~(UINT64)ALIGNED_2MB_MASK;
-PhysicalAddress += Length2;
-TotalLength -= Length2;
-  }
-
-  if (TotalLength) {
-StartAddress3 = PhysicalAddress;
-Length3   = TotalLength;
-  }
-
-  Status = EFI_SUCCESS;
-  if (Length1 > 0) {
-Pages  = Length1 / SIZE_4KB;
-Status = TdAcceptPages (StartAddress1, Pages, SIZE_4KB);
-if (EFI_ERROR (Status)) {
-  return Status;
-}
-  }
-
-  if (Length2 > 0) {
-Pages  = Length2 / AcceptPageSize;
-Status = TdAcceptPages (StartAddress2, Pages, AcceptPageSize);
-if (EFI_ERROR (Status)) {
-  return Status;
-}
-  }
-
-  if (Length3 > 0) {
-Pages  = Length3 / SIZE_4KB;
-Status = TdAcceptPages (StartAddress3, Pages, SIZE_4

[edk2-devel] [PATCH V1 5/7] OvmfPkg: Enable Tdx measurement in OvmfPkgX64

2023-01-16 Thread Min Xu

From: Min M Xu 

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

This patch enables Tdx measurement in OvmfPkgX64 with below changes:
1) TDX_ENABLE is introduced in OvmfPkgX64.dsc. This flag indicates
   if Intel TDX is enabled in OvmfPkgX64. Its default value is FALSE.
2) Update SecMain.c with the functions provided by TdxHelperLib
3) Include TdTcg2Dxe in OvmfPkgX64 so that CC_MEASUREMENT_PROTOCOL
   is installed in a Td-guest. TdTcg2Dxe is controlled by TDX_ENABLE
   because it is only valid when Intel TDX is enabled.
3) OvmfTpmLibs.dsc.inc and OvmfTpmSecurityStub.dsc.inc are updated
   because DxeTpm2MeasureBootLib.inf and DxeTpmMeasurementLib.inf
   should be included to support CC_MEASUREMENT_PROTOCOL.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc | 10 +-
 OvmfPkg/Include/Dsc/OvmfTpmSecurityStub.dsc.inc |  8 
 OvmfPkg/OvmfPkgX64.dsc  | 15 ++-
 OvmfPkg/OvmfPkgX64.fdf  |  7 +++
 OvmfPkg/Sec/SecMain.c   | 17 +++--
 5 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc 
b/OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
index cd1a899d68f7..df228dc5e2ca 100644
--- a/OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
+++ b/OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
@@ -10,9 +10,17 @@
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
-  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
 !else
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
+!endif
+
+!if $(TPM2_ENABLE) == TRUE || $(TDX_ENABLE) == TRUE
+  #
+  # DxeTpmMeasurementLib supports measurement functions for both TPM and 
Confidential Computing.
+  # It should be controlled by TPM2_ENABLE and TDX_ENABLE.
+  #
+  
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+!else
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
 !endif
 
diff --git a/OvmfPkg/Include/Dsc/OvmfTpmSecurityStub.dsc.inc 
b/OvmfPkg/Include/Dsc/OvmfTpmSecurityStub.dsc.inc
index e9ab2fca7bc7..a08e29720f5d 100644
--- a/OvmfPkg/Include/Dsc/OvmfTpmSecurityStub.dsc.inc
+++ b/OvmfPkg/Include/Dsc/OvmfTpmSecurityStub.dsc.inc
@@ -6,5 +6,13 @@
 !if $(TPM1_ENABLE) == TRUE
   NULL|SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.inf
 !endif
+!endif
+
+!if $(TPM2_ENABLE) == TRUE || $(TDX_ENABLE) == TRUE
+  #
+  # DxeTpm2MeasureBootLib provides security service of TPM2 measure boot 
and
+  # Confidential Computing (CC) measure boot. It should be controlled by
+  # TPM2_ENABLE and TDX_ENABLE
+  #
   NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 3f970a79a08a..0bf16a4815b3 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -32,6 +32,7 @@
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE SMM_REQUIRE = FALSE
   DEFINE SOURCE_DEBUG_ENABLE = FALSE
+  DEFINE TDX_ENABLE  = FALSE
 
 !include OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc
 
@@ -724,7 +725,8 @@
   OvmfPkg/Sec/SecMain.inf {
 
   
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
-  NULL|OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
+  NULL|OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelperLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SecCryptLib.inf
   }
 
   #
@@ -1100,6 +1102,17 @@
   }
 !endif
 
+  #
+  # Cc Measurement Protocol for Td guest
+  #
+!if $(TDX_ENABLE) == TRUE
+  SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf {
+
+  HashLib|SecurityPkg/Library/HashLibTdx/HashLibTdx.inf
+  NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
+  }
+!endif
+
   #
   # TPM support
   #
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 8c02dfe11e37..0df986f7ebec 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -402,6 +402,13 @@ INF  
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
 INF  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 !endif
 
+#
+# EFI_CC_MEASUREMENT_PROTOCOL
+#
+!if $(TDX_ENABLE) == TRUE
+INF SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf
+!endif
+
 #
 # TPM support
 #
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 1167d22a68cc..4bb3b641701e 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include "AmdSev.h"
 
@@ -760,12 +760,25 @@ S

[edk2-devel] [PATCH V1 4/7] OvmfPkg/IntelTdx: Update tdx measurement in SEC phase

2023-01-16 Thread Min Xu

From: Min M Xu 

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

After TdxHelperLib is instroduced, the SecMain.c in IntelTdx is updated
with the new functions provided by TdxHelperLib.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc |  4 +---
 OvmfPkg/IntelTdx/Sec/SecMain.c   | 17 +++--
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 81511e3556a6..d8232f27dae9 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -541,10 +541,8 @@
   OvmfPkg/IntelTdx/Sec/SecMain.inf {
 
   
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
-  
TpmMeasurementLib|SecurityPkg/Library/SecTpmMeasurementLib/SecTpmMeasurementLibTdx.inf
+  NULL|OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelperLib.inf
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SecCryptLib.inf
-  HashLib|SecurityPkg/Library/HashLibTdx/HashLibTdx.inf
-  NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
   }
 
   #
diff --git a/OvmfPkg/IntelTdx/Sec/SecMain.c b/OvmfPkg/IntelTdx/Sec/SecMain.c
index ab01ec9ab19c..ccb217b709a0 100644
--- a/OvmfPkg/IntelTdx/Sec/SecMain.c
+++ b/OvmfPkg/IntelTdx/Sec/SecMain.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -62,12 +62,25 @@ SecCoreStartupWithStack (
   volatile UINT8*Table;
 
   if (CcProbe () == CcGuestTypeIntelTdx) {
+//
+// From the security perspective all the external input should be measured 
before
+// it is consumed. TdHob and Configuration FV (Cfv) image are passed from 
VMM
+// and should be measured here.
+//
+if (EFI_ERROR (TdxHelperMeasureTdHob ())) {
+  CpuDeadLoop ();
+}
+
+if (EFI_ERROR (TdxHelperMeasureCfvImage ())) {
+  CpuDeadLoop ();
+}
+
 //
 // For Td guests, the memory map info is in TdHobLib. It should be 
processed
 // first so that the memory is accepted. Otherwise access to the unaccepted
 // memory will trigger tripple fault.
 //
-if (ProcessTdxHobList () != EFI_SUCCESS) {
+if (TdxHelperProcessTdHob () != EFI_SUCCESS) {
   CpuDeadLoop ();
 }
   }
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH V1 3/7] OvmfPkg/PeilessStartupLib: Build GuidHob for Tdx measurements

2023-01-16 Thread Min Xu

From: Min M Xu 

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

With the introduction of TdxHelperBuildGuidHobForTdxMeasurement in
TdxHelperLib PeilessStartup should also be updated. It should call
TdxHelperBuildGuidHobForTdxMeasurement to build the GuidHob for Tdx
measurement.

The deprecated codes are deleted as well in this patch.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/Library/PeilessStartupLib/IntelTdx.c  | 196 --
 .../PeilessStartupLib/PeilessStartup.c|  16 +-
 .../PeilessStartupInternal.h  |  36 
 .../PeilessStartupLib/PeilessStartupLib.inf   |   3 -
 4 files changed, 3 insertions(+), 248 deletions(-)
 delete mode 100644 OvmfPkg/Library/PeilessStartupLib/IntelTdx.c

diff --git a/OvmfPkg/Library/PeilessStartupLib/IntelTdx.c 
b/OvmfPkg/Library/PeilessStartupLib/IntelTdx.c
deleted file mode 100644
index 216c413caad5..
--- a/OvmfPkg/Library/PeilessStartupLib/IntelTdx.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/** @file
-  Copyright (c) 2022, Intel Corporation. All rights reserved.
-  SPDX-License-Identifier: BSD-2-Clause-Patent
-**/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "PeilessStartupInternal.h"
-
-#pragma pack(1)
-
-#define HANDOFF_TABLE_DESC  "TdxTable"
-typedef struct {
-  UINT8  TableDescriptionSize;
-  UINT8  TableDescription[sizeof (HANDOFF_TABLE_DESC)];
-  UINT64 NumberOfTables;
-  EFI_CONFIGURATION_TABLETableEntry[1];
-} TDX_HANDOFF_TABLE_POINTERS2;
-
-#define FV_HANDOFF_TABLE_DESC  "Fv(----)"
-typedef struct {
-  UINT8   BlobDescriptionSize;
-  UINT8   BlobDescription[sizeof (FV_HANDOFF_TABLE_DESC)];
-  EFI_PHYSICAL_ADDRESSBlobBase;
-  UINT64  BlobLength;
-} FV_HANDOFF_TABLE_POINTERS2;
-
-#pragma pack()
-
-/**
-  Measure the Hoblist passed from the VMM.
-
-  @param[in] VmmHobListThe Hoblist pass the firmware
-
-  @retval EFI_SUCCESS   Fv image is measured successfully
-or it has been already measured.
-  @retval OthersOther errors as indicated
-**/
-EFI_STATUS
-EFIAPI
-MeasureHobList (
-  IN CONST VOID  *VmmHobList
-  )
-{
-  EFI_PEI_HOB_POINTERS Hob;
-  TDX_HANDOFF_TABLE_POINTERS2  HandoffTables;
-  EFI_STATUS   Status;
-
-  if (!TdIsEnabled ()) {
-ASSERT (FALSE);
-return EFI_UNSUPPORTED;
-  }
-
-  Hob.Raw = (UINT8 *)VmmHobList;
-
-  //
-  // Parse the HOB list until end of list.
-  //
-  while (!END_OF_HOB_LIST (Hob)) {
-Hob.Raw = GET_NEXT_HOB (Hob);
-  }
-
-  //
-  // Init the log event for HOB measurement
-  //
-
-  HandoffTables.TableDescriptionSize = sizeof (HandoffTables.TableDescription);
-  CopyMem (HandoffTables.TableDescription, HANDOFF_TABLE_DESC, sizeof 
(HandoffTables.TableDescription));
-  HandoffTables.NumberOfTables = 1;
-  CopyGuid (&(HandoffTables.TableEntry[0].VendorGuid), 
&gUefiOvmfPkgTokenSpaceGuid);
-  HandoffTables.TableEntry[0].VendorTable = (VOID *)VmmHobList;
-
-  Status = TpmMeasureAndLogData (
- 1,  // PCRIndex
- EV_EFI_HANDOFF_TABLES2, // EventType
- (VOID *)&HandoffTables, // EventData
- sizeof (HandoffTables), // EventSize
- (UINT8 *)(UINTN)VmmHobList, // HashData
- (UINTN)((UINT8 *)Hob.Raw - (UINT8 *)VmmHobList) // HashDataLen
- );
-
-  if (EFI_ERROR (Status)) {
-ASSERT (FALSE);
-  }
-
-  return Status;
-}
-
-/**
-  Get the FvName from the FV header.
-
-  Causion: The FV is untrusted input.
-
-  @param[in]  FvBaseBase address of FV image.
-  @param[in]  FvLength  Length of FV image.
-
-  @return FvName pointer
-  @retval NULL   FvName is NOT found
-**/
-VOID *
-GetFvName (
-  IN EFI_PHYSICAL_ADDRESS  FvBase,
-  IN UINT64FvLength
-  )
-{
-  EFI_FIRMWARE_VOLUME_HEADER  *FvHeader;
-  EFI_FIRMWARE_VOLUME_EXT_HEADER  *FvExtHeader;
-
-  if (FvBase >= MAX_ADDRESS) {
-return NULL;
-  }
-
-  if (FvLength >= MAX_ADDRESS - FvBase) {
-return NULL;
-  }
-
-  if (FvLength < sizeof (EFI_FIRMWARE_VOLUME_HEADER)) {
-return NULL;
-  }
-
-  FvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)FvBase;
-  if (FvHeader->ExtHeaderOffset < sizeof (EFI_FIRMWARE_VOLUME_HEADER)) {
-return NULL;
-  }
-
-  if (FvHeader->ExtHeaderOffset + sizeof (EFI_FIRMWARE_VOLUME_EXT_HEADER) > 
FvLength) {
-return NULL;
-  }
-
-  FvExtHeader = (EFI_FIRMWARE_VOLUME_EXT_HEADER *)(UINTN)(FvBase + 
FvHeader->ExtHeaderOffset);
-
-  return &FvExtHeader->FvName;
-}
-
-/**
-  Measure FV image.
-
-  @param[in]  FvBaseBase address of FV image.
-  @param[

[edk2-devel] [PATCH V1 2/7] OvmfPkg/IntelTdx: Add TdxHelperLib

2023-01-16 Thread Min Xu

From: Min M Xu 

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

TdxHelperLib provides below helper functions for a td-guest.
 - TdxHelperProcessTdHob
 - TdxHelperMeasureTdHob
 - TdxHelperMeasureCfvImage
 - TdxHelperBuildGuidHobForTdxMeasurement

TdxHelperLibNull is the NULL instance of TdxHelperLib.

SecTdxHelperLib is the SEC instance of TdxHelperLib. It implements 4
functions for tdx in SEC phase:
 - TdxHelperProcessTdHob consumes TdHob to accept un-accepted memories.
   Before the TdHob is consumed, it is first validated. Most of the codes
   are copied from PlatformInitLib/IntelTdx.c. The duplicated code in
   PlatformInitLib/IntelTdx.c will be deleted later so that the build
   will not be broken.

 - TdxHelperMeasureTdHob measure/extend TdHob and store the measurement
   value in workarea.

 - TdxHelperMeasureCfvImage measure/extend the Configuration FV image and
   store the measurement value in workarea.

 - TdxHelperBuildGuidHobForTdxMeasurement is only valid in PEI-LESS
   startup mode. It builds GuidHob for tdx measurement in SEC phase.

PeiTdxHelperLib is the PEI instance of TdxHelperLib. It implements 1
function for tdx in PEI phase.
  - TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for tdx
measurement in PEI phase.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/Include/Library/TdxHelperLib.h|  70 ++
 OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c  |  91 ++
 .../IntelTdx/TdxHelperLib/PeiTdxHelperLib.inf |  48 +
 OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c  | 989 ++
 .../IntelTdx/TdxHelperLib/SecTdxHelperLib.inf |  53 +
 .../TdxHelperLib/TdxHelperLibNull.inf |  32 +
 OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperNull.c |  79 ++
 .../IntelTdx/TdxHelperLib/TdxMeasurementHob.c | 266 +
 OvmfPkg/OvmfPkg.dec   |   4 +
 9 files changed, 1632 insertions(+)
 create mode 100644 OvmfPkg/Include/Library/TdxHelperLib.h
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelperLib.inf
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelper.c
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelperLib.inf
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperLibNull.inf
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperNull.c
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/TdxMeasurementHob.c

diff --git a/OvmfPkg/Include/Library/TdxHelperLib.h 
b/OvmfPkg/Include/Library/TdxHelperLib.h
new file mode 100644
index ..199aade42f8e
--- /dev/null
+++ b/OvmfPkg/Include/Library/TdxHelperLib.h
@@ -0,0 +1,70 @@
+/** @file
+  TdxHelperLib header file
+
+  Copyright (c) 2021 - 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef TDX_HELPER_LIB_H
+#define TDX_HELPER_LIB_H
+
+#include 
+
+/**
+  In Tdx guest, some information need to be passed from host VMM to guest
+  firmware. For example, the memory resource, etc. These information are
+  prepared by host VMM and put in TdHob which is described in TdxMetadata.
+  TDVF processes the TdHob to accept memories.
+
+  @retval   EFI_SUCCESS   Successfully process the TdHob
+  @retval   OthersOther error as indicated
+**/
+EFI_STATUS
+EFIAPI
+TdxHelperProcessTdHob (
+  VOID
+  );
+
+/**
+  In Tdx guest, TdHob is passed from host VMM to guest firmware and it contains
+  the information of the memory resource. From the security perspective before
+  it is consumed, it should be measured and extended.
+ *
+ * @retval EFI_SUCCESS Successfully measure the TdHob
+ * @retval Others  Other error as indicated
+ */
+EFI_STATUS
+EFIAPI
+TdxHelperMeasureTdHob (
+  VOID
+  );
+
+/**
+ * In Tdx guest, Configuration FV (CFV) is treated as external input because it
+ * may contain the data provided by VMM. From the sucurity perspective Cfv 
image
+ * should be measured before it is consumed.
+ *
+ * @retval EFI_SUCCESS Successfully measure the CFV image
+ * @retval Others  Other error as indicated
+ */
+EFI_STATUS
+EFIAPI
+TdxHelperMeasureCfvImage (
+  VOID
+  );
+
+/**
+  Build the GuidHob for tdx measurements which were done in SEC phase.
+  The measurement values are stored in WorkArea.
+
+  @retval EFI_SUCCESS  The GuidHob is built successfully
+  @retval Others   Other errors as indicated
+**/
+EFI_STATUS
+EFIAPI
+TdxHelperBuildGuidHobForTdxMeasurement (
+  VOID
+  );
+
+#endif
diff --git a/OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c 
b/OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c
new file mode 100644
index ..91ab53ed14ad
--- /dev/null
+++ b/OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c
@@ -0,0 +1,91 @@
+/** @file
+  TdxHelper Functions which are used in PEI phase
+
+  Copyright (c) 2022 - 2023, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+/**

[edk2-devel] [PATCH V1 1/7] OvmfPkg: Add Tdx measurement data structure in WorkArea

2023-01-16 Thread Min Xu

From: Min M Xu 

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

>From the perspective of security any external input should be measured
and extended to some registers (TPM PCRs or TDX RTMR registers).

There are below 2 external input in a Td guest:
 - TdHob
 - Configuration FV (CFV)

TdHob contains the resource information passed from VMM, such as
unaccepted memory region. CFV contains the configurations, such as
secure boot variables.

TdHob and CFV should be measured and extended to RTMRs before they're
consumed. TdHob is consumed in the very early stage of boot process.
At that moment the memory service is not ready. Cfv is consumed in
PlatformPei to initialize the EmuVariableNvStore. To make the
implementation simple and clean, these 2 external input are measured
and extended to RTMRs in SEC phase. The measurement values are stored
in WorkArea. Then after the Hob service is available, these 2 measurement
values are retrieved and GuidHobs for these 2 tdx measurements are
generated.

This patch defines the structure of TDX_MEASUREMENTS_DATA in
SEC_TDX_WORK_AREA to store above 2 tdx measurements. It can be extended
to store more tdx measurements if needed in the future.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/Include/WorkArea.h | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Include/WorkArea.h b/OvmfPkg/Include/WorkArea.h
index 6c3702b716f0..b1c7045ce18c 100644
--- a/OvmfPkg/Include/WorkArea.h
+++ b/OvmfPkg/Include/WorkArea.h
@@ -11,6 +11,7 @@
 #define __OVMF_WORK_AREA_H__
 
 #include 
+#include 
 
 //
 // Confidential computing work area header definition. Any change
@@ -64,13 +65,27 @@ typedef struct _SEV_WORK_AREA {
   SEC_SEV_ES_WORK_AREA   SevEsWorkArea;
 } SEV_WORK_AREA;
 
+//
+// Start of TDX Specific WorkArea definition
+//
+
+#define TDX_MEASUREMENT_TDHOB_BITMASK   0x1
+#define TDX_MEASUREMENT_CFVIMG_BITMASK  0x2
+
+typedef struct _TDX_MEASUREMENTS_DATA {
+  UINT32MeasurementsBitmap;
+  UINT8 TdHobHashValue[SHA384_DIGEST_SIZE];
+  UINT8 CfvImgHashValue[SHA384_DIGEST_SIZE];
+} TDX_MEASUREMENTS_DATA;
+
 //
 // The TDX work area definition
 //
 typedef struct _SEC_TDX_WORK_AREA {
-  UINT32PageTableReady;
-  UINT32Gpaw;
-  UINT64HobList;
+  UINT32   PageTableReady;
+  UINT32   Gpaw;
+  UINT64   HobList;
+  TDX_MEASUREMENTS_DATATdxMeasurementsData;
 } SEC_TDX_WORK_AREA;
 
 typedef struct _TDX_WORK_AREA {
@@ -78,6 +93,10 @@ typedef struct _TDX_WORK_AREA {
   SEC_TDX_WORK_AREA  SecTdxWorkArea;
 } TDX_WORK_AREA;
 
+//
+// End of TDX Specific WorkArea definition
+//
+
 typedef union {
   CONFIDENTIAL_COMPUTING_WORK_AREA_HEADERHeader;
   SEV_WORK_AREA  SevWorkArea;
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH V1 0/7] Enable Tdx measurement in OvmfPkgX64

2023-01-16 Thread Min Xu

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

Tdx measurement (RTMR based measurement) is enabled in OvmfPkg/IntelTdx.
This patch-set enables the feature in OvmfPkgX64 as well.

Patch #1:
  Introduce TDX_MEASUREMETNS_DATA in SEC_TDX_WORK_AREA. That is because
  the RTMR measurement of TdHob and Configuration FV (CFV) are executed
  in very early stage of boot process. At that time the memory service is
  not ready and the measurement values have to be stored in OvmfWorkArea.

Patch #2:
  Introduce TdxHelperLib which provides helper functions for td-guest.

Patch #3/4:
  These 2 patches are the changes for OvmfPkg/IntelTdx because of the
  introduction of TdxHelperLib.

Patch #5/7:
  These 2 patches are the changes for OvmfPkg/OvmfPkgX64 to enable Tdx
  measurement.

Patch #6:
  ProcessTdxHobList is moved to TdxHelperLib and is renamed as
  TdxHelperProcessTdHob(). So the duplicated codes are deleted in this
  patch.

Code: https://github.com/mxu9/edk2/tree/TdxMeasurementInOvmfX64.v1

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 

Min M Xu (7):
  OvmfPkg: Add Tdx measurement data structure in WorkArea
  OvmfPkg/IntelTdx: Add TdxHelperLib
  OvmfPkg/PeilessStartupLib: Build GuidHob for Tdx measurements
  OvmfPkg/IntelTdx: Update tdx measurement in SEC phase
  OvmfPkg: Enable Tdx measurement in OvmfPkgX64
  OvmfPkg/PlatformInitLib: Delete the ProcessTdxHobList()
  OvmfPkg/PlatformPei: Build GuidHob for Tdx measurement

 OvmfPkg/AmdSev/AmdSevX64.dsc  |   5 +-
 OvmfPkg/CloudHv/CloudHvX64.dsc|   5 +-
 OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc   |  10 +-
 .../Include/Dsc/OvmfTpmSecurityStub.dsc.inc   |   8 +
 OvmfPkg/Include/Library/PlatformInitLib.h |  17 -
 OvmfPkg/Include/Library/TdxHelperLib.h|  70 ++
 OvmfPkg/Include/WorkArea.h|  25 +-
 OvmfPkg/IntelTdx/IntelTdxX64.dsc  |   4 +-
 OvmfPkg/IntelTdx/Sec/SecMain.c|  17 +-
 OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c  |  91 +++
 .../IntelTdx/TdxHelperLib/PeiTdxHelperLib.inf |  48 ++
 .../TdxHelperLib/SecTdxHelper.c}  | 338 
 .../IntelTdx/TdxHelperLib/SecTdxHelperLib.inf |  53 ++
 .../TdxHelperLib/TdxHelperLibNull.inf |  32 +
 OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperNull.c |  79 ++
 .../IntelTdx/TdxHelperLib/TdxMeasurementHob.c | 266 ++
 OvmfPkg/Library/PeilessStartupLib/IntelTdx.c  | 196 -
 .../PeilessStartupLib/PeilessStartup.c|  16 +-
 .../PeilessStartupInternal.h  |  36 -
 .../PeilessStartupLib/PeilessStartupLib.inf   |   3 -
 OvmfPkg/Library/PlatformInitLib/IntelTdx.c| 768 --
 .../Library/PlatformInitLib/IntelTdxNull.c|  20 -
 .../PlatformInitLib/PlatformInitLib.inf   |   1 -
 OvmfPkg/Microvm/MicrovmX64.dsc|   5 +-
 OvmfPkg/OvmfPkg.dec   |   4 +
 OvmfPkg/OvmfPkgX64.dsc|  20 +-
 OvmfPkg/OvmfPkgX64.fdf|   7 +
 OvmfPkg/PlatformPei/IntelTdx.c|   3 +
 OvmfPkg/Sec/SecMain.c |  17 +-
 29 files changed, 944 insertions(+), 1220 deletions(-)
 create mode 100644 OvmfPkg/Include/Library/TdxHelperLib.h
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelper.c
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/PeiTdxHelperLib.inf
 copy OvmfPkg/{Library/PlatformInitLib/IntelTdx.c => 
IntelTdx/TdxHelperLib/SecTdxHelper.c} (79%)
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/SecTdxHelperLib.inf
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperLibNull.inf
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/TdxHelperNull.c
 create mode 100644 OvmfPkg/IntelTdx/TdxHelperLib/TdxMeasurementHob.c
 delete mode 100644 OvmfPkg/Library/PeilessStartupLib/IntelTdx.c

-- 
2.29.2.windows.2



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

Re: [edk2-devel] [edk2-platforms][PATCH V1 1/1] Platform/Loongson: Support vga for loongarch.

2023-01-16 Thread Chao Li


Reviewed-by: Chao Li 


Thanks,
Chao
在 2023/1/17 09:07, xianglai 写道:

Add VGA graphics card support for Loongarch,
VGA graphics cards have GOP to support early
kernel information printing, so we need it.

Cc: Ard Biesheuvel
Cc: Bibo Mao
Cc: Chao Li
Cc: Leif Lindholm
Cc: Liming Gao
Cc: Michael D Kinney
Signed-off-by: xianglai li
---
  Platform/Loongson/LoongArchQemuPkg/Loongson.dsc | 1 +
  Platform/Loongson/LoongArchQemuPkg/Loongson.fdf | 1 +
  2 files changed, 2 insertions(+)

diff --git a/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc 
b/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
index 2d63f7d168..b3f3841ea1 100644
--- a/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
+++ b/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
@@ -597,6 +597,7 @@
#
# Video
#
+  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
OvmfPkg/PlatformDxe/Platform.inf
diff --git a/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf 
b/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
index 784f255910..31f7e28fc5 100644
--- a/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
+++ b/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
@@ -169,6 +169,7 @@ INF  
MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
  #
  #Video
  #
+INF  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
  INF  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
  INF  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
  INF  OvmfPkg/PlatformDxe/Platform.inf



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

Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM build

2023-01-16 Thread Bob Feng

Konstantin,

The patch missed "Signed-off-by:", I help you add it and open a PR 
https://github.com/tianocore/edk2/pull/3909 for merge.

Thanks,
Bob
From: devel@edk2.groups.io  On Behalf Of Bob Feng
Sent: Tuesday, January 17, 2023 1:05 PM
To: Jake Garver ; Konstantin Aladyshev 
; devel@edk2.groups.io
Cc: Gao, Liming ; Chen, Christine 

Subject: Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM build

Reviewed-by: Bob Feng mailto:bob.c.f...@intel.com>>

From: Jake Garver mailto:j...@nvidia.com>>
Sent: Wednesday, December 14, 2022 2:48 AM
To: Konstantin Aladyshev mailto:aladyshe...@gmail.com>>; 
devel@edk2.groups.io
Cc: Feng, Bob C mailto:bob.c.f...@intel.com>>; Gao, 
Liming mailto:gaolim...@byosoft.com.cn>>; Chen, 
Christine mailto:yuwei.c...@intel.com>>
Subject: Re: [PATCH] Fix cyclic dependency error on OptionROM build

Thanks, Konstantin,

I approve this version.

Thanks,
Jake

From: Konstantin Aladyshev mailto:aladyshe...@gmail.com>>
Sent: Tuesday, December 13, 2022 11:22 AM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: bob.c.f...@intel.com 
mailto:bob.c.f...@intel.com>>; 
gaolim...@byosoft.com.cn 
mailto:gaolim...@byosoft.com.cn>>; 
yuwei.c...@intel.com 
mailto:yuwei.c...@intel.com>>; Jake Garver 
mailto:j...@nvidia.com>>; Konstantin Aladyshev 
mailto:aladyshe...@gmail.com>>
Subject: [PATCH] Fix cyclic dependency error on OptionROM build

External email: Use caution opening links or attachments


EDKII build system supports OptionROM generation if particular PCI_*
defines are present in the module INF file:
```
[Defines]
  ...
  PCI_VENDOR_ID  = <...>
  PCI_DEVICE_ID  = <...>
  PCI_CLASS_CODE = <...>
  PCI_REVISION   = <...>
```
Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698
("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
possible.
The build system fails with the error:
```
Cyclic dependency detected while generating rule for
"<...>/DEBUG/<...>.efi" file
```
Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
to fix the cyclic dependency.
---
 BaseTools/Conf/build_rule.template | 1 -
 1 file changed, 1 deletion(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index af4819de92..21ccd864fa 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -342,7 +342,6 @@


 

 $(OUTPUT_DIR)(+)$(MODULE_NAME).efi

-$(DEBUG_DIR)(+)$(MODULE_NAME).efi

 $(OUTPUT_DIR)(+)$(MODULE_NAME).map



 

--
2.34.1



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

Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM build

2023-01-16 Thread Bob Feng

Reviewed-by: Bob Feng 

From: Jake Garver 
Sent: Wednesday, December 14, 2022 2:48 AM
To: Konstantin Aladyshev ; devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ; 
Chen, Christine 
Subject: Re: [PATCH] Fix cyclic dependency error on OptionROM build

Thanks, Konstantin,

I approve this version.

Thanks,
Jake

From: Konstantin Aladyshev mailto:aladyshe...@gmail.com>>
Sent: Tuesday, December 13, 2022 11:22 AM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: bob.c.f...@intel.com 
mailto:bob.c.f...@intel.com>>; 
gaolim...@byosoft.com.cn 
mailto:gaolim...@byosoft.com.cn>>; 
yuwei.c...@intel.com 
mailto:yuwei.c...@intel.com>>; Jake Garver 
mailto:j...@nvidia.com>>; Konstantin Aladyshev 
mailto:aladyshe...@gmail.com>>
Subject: [PATCH] Fix cyclic dependency error on OptionROM build

External email: Use caution opening links or attachments


EDKII build system supports OptionROM generation if particular PCI_*
defines are present in the module INF file:
```
[Defines]
  ...
  PCI_VENDOR_ID  = <...>
  PCI_DEVICE_ID  = <...>
  PCI_CLASS_CODE = <...>
  PCI_REVISION   = <...>
```
Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698
("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
possible.
The build system fails with the error:
```
Cyclic dependency detected while generating rule for
"<...>/DEBUG/<...>.efi" file
```
Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
to fix the cyclic dependency.
---
 BaseTools/Conf/build_rule.template | 1 -
 1 file changed, 1 deletion(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index af4819de92..21ccd864fa 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -342,7 +342,6 @@


 

 $(OUTPUT_DIR)(+)$(MODULE_NAME).efi

-$(DEBUG_DIR)(+)$(MODULE_NAME).efi

 $(OUTPUT_DIR)(+)$(MODULE_NAME).map



 

--
2.34.1


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

Re: [edk2-devel] Several messages to devel@edk2.groups.io (from Intel/NVIDIA/AMD/etc.) being flagged as spam

2023-01-16 Thread Rebecca Cran


It seems to have been resolved.

On 1/16/23 19:17, Rebecca Cran wrote:
I'm seeing many emails to edk2-devel being flagged as spam and ending up 
in my Spam folder, starting yesterday. This might be an isolated issue 
with my mail provider (Fastmail), but thought I'd mention it in case 
it's more widespread. For example, Mike's email "Re: [edk2-devel] 
edk2-platforms, continuous integration, testing, and you" about moving 
the meeting to 10am pacific on Tue Jan 17th was flagged.


Some of the headers are:

X-Spam-known-sender: no ("Email failed DMARC policy for domain"); 
in-addressbook;
  53d73d40-71d5-42b2-826f-50ae0b28b233 ("Autosaved")
X-Spam-sender-reputation: 500 (none)
X-Spam-score: 9.4
X-Spam-hits: DCC_REPUT_00_12 -0.8, HEADER_FROM_DIFFERENT_DOMAINS 0.25,
   MAILING_LIST_MULTI -1, ME_HAS_VSSU 0.001, ME_SENDERREP_NEUTRAL 0.001,
   RCVD_IN_MSPIKE_H2 -0.001, RCVD_IN_SBL_CSS 3, RCVD_IN_ZEN_LASTEXTERNAL 8,
   SPF_HELO_NONE 0.001, SPF_PASS -0.001, LANGUAGES en, BAYES_USED none,
   SA_VERSION 3.4.6
...
Received: from mx6 ([10.202.2.205])
   by compute2.internal (LMTPProxy); Mon, 16 Jan 2023 16:06:47 -0500
Received: from mx6.messagingengine.com (localhost [127.0.0.1])
by mailmx.nyi.internal (Postfix) with ESMTP id 2F6A65C0100
for; Mon, 16 Jan 2023 16:06:47 -0500 (EST)
Received: from mx6.messagingengine.com (localhost [127.0.0.1])
 by mx6.messagingengine.com (Authentication Milter) with ESMTP
 id DAF368511B6;
 Mon, 16 Jan 2023 16:06:47 -0500
ARC-Seal: i=2; a=rsa-sha256; cv=fail; d=messagingengine.com; s=fm3; t=
 1673903207; b=NCILAE0Pl7emFvkAgRZlYmfCsbh+fmjbKvGGzCOm3ZUr3x3jEH
 6MpNPU00ARmEvmO1QLLQWrFWOHg4XET5a3P7idl1hdpjeUghaT8OJXZBEps3GuHi
 4ykzXktjfzzfrl0MBdV/wdRKza9Pwt6RzcLUIPbiBj6p+CIaCc9x9R9YOprKaCY+
 o5p9k7icZvMgYcsMETYjExHD8ej/rdtpsK8aBzkb7BFEf8WwpapRRG/JXj+uJK2g
 pwKSUx9Y9e4YR2WsfhzYiAJopcoYVlGn5xMW1vDBGXIvO7mA76mUe3U0EslfLvWn
 P1VZjvKqIOx9Ezumkue7C8Ta8WVTAzQ7eG+w==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=from:to:cc:subject:date:message-id
 :references:in-reply-to:mime-version:list-unsubscribe
 :list-subscribe:list-help:sender:list-id:reply-to:content-type
 :content-transfer-encoding; s=fm3; t=1673903207; bh=WMWTNJfxt8zF
 e0IEE4kAaXc5RiExQVIiD6mLKj0sze8=; b=IqLCWbpck5DimVkBCCSNBBhRUcSw
 H9fS/WIWlB0ra3THxzgBcAqrs1RV0Rz8NGgsFMVlNSXry9OIdEGZ5F2Pdvff4RwZ
 npnrMx0AvzwcZjN3A6x+t/AuULezpW4MJGxKyvK2kZ9hQW7jcVisBNK5E5inYdG0
 3CVpuz4NRYwdKTkFMbXQt4JGQPZlgZs63rWvX+aimC87uAEtNnBm1fY0GX76RnCN
 jtGq3cOOFiTPkS7NlYmX7sN5ROYnD2LLa6EEqpVQYjyVDXJnjTacWe2BlBV3RTAQ
 wNpxexuCNl0895LPLM9+tiTpdaizBlDswc6zu8YK1I9Pn2h7D8U7wARi9Q==
ARC-Authentication-Results: i=2; mx6.messagingengine.com;
 x-csa=none;
 x-me-sender=none;
 x-ptr=pass smtp.helo=mail02.groups.io policy.ptr=mail02.groups.io;
 bimi=skipped (DMARC did not pass);
 arc=fail
 (as.1.microsoft.com=pass, ams.1.microsoft.com=fail (message has been 
altered))
 smtp.remote-ip=66.175.222.108;
 dkim=pass (1024-bit rsa key sha256) header.d=groups.io
 header.i=@groups.io  header.b=pvOonOAx header.a=rsa-sha256
 header.s=20140610 x-bits=1024;
 dmarc=fail policy.published-domain-policy=none
 policy.published-subdomain-policy=none policy.applied-disposition=none
 policy.evaluated-disposition=none
 policy.override-reason=trusted_forwarder policy.arc-aware-result=fail
 
(p=none,sp=none,has-list-id=yes,d=none,d.eval=none,override=trusted_forwarder,arc_aware_result=fail)
 policy.policy-from=p header.from=intel.com;
 iprev=pass smtp.remote-ip=66.175.222.108 (mail02.groups.io);
 spf=passsmtp.mailfrom=bounce+27952+98602+3953573+7659...@groups.io
 smtp.helo=mail02.groups.io
X-ME-Authentication-Results: mx6.messagingengine.com;
 x-aligned-from=fail;
 x-return-mx=pass header.domain=intel.com policy.is_org=yes
   (MX Records found: 
mga17.intel.com,mga07.intel.com,mga18.intel.com,mga01.intel.com,mga02.intel.com,mga11.intel.com,mga09.intel.com,mga14.intel.com,mga03.intel.com,mga04.intel.com,mga05.intel.com,mga06.intel.com,mga12.intel.com);
 x-return-mx=pass smtp.domain=groups.io policy.is_org=yes
   (MX Records found: lb01.groups.io,lb02.groups.io);
 x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_AES_256_GCM_SHA384
   smtp.bits=256/256;
 x-vs=clean score=-100 state=0
Authentication-Results: mx6.messagingengine.com;
 x-csa=none;
 x-me-sender=none;
 x-ptr=pass smtp.helo=mail02.groups.io policy.ptr=mail02.groups.io
Authentication-Results: mx6.messagingengine.com;
 bimi=skipped (DMARC did not pass)
Authentication-Results: mx6.messagingengine.com;
 arc=fail
   (as.1.microsoft.com=pass, ams.1.microsoft.com=fail (message has been 
altered))
   smtp.remote-ip=66.175.222.108
Authentication-Results: mx6.messagingengine.com;
 dkim=pass (1024-bit rsa key sha256) header.d=groups.io
   header.i=@groups.io  header.b=pvOonOAx head

[edk2-devel] [PATCH v5 2/2] ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls

2023-01-16 Thread Rebecca Cran

Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under
AArch64.

PSCI_CPU_ON is called to power on the core, the supplied procedure is
executed and PSCI_CPU_OFF is called to power off the core.

Fixes contributed by Ard Biesheuvel.

Signed-off-by: Rebecca Cran 
---
 ArmPkg/ArmPkg.dsc|1 +
 ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf |   56 +
 ArmPkg/Drivers/ArmPsciMpServicesDxe/MpServicesInternal.h |  345 
 ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c   | 1859 

 ArmPkg/Drivers/ArmPsciMpServicesDxe/MpFuncs.S|   74 +
 5 files changed, 2335 insertions(+)

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index ac24ebce4892..1e873b90c56d 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -164,6 +164,7 @@ [Components.common]
   ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
 
 [Components.AARCH64]
+  ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf
   ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
   ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
 
diff --git a/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf 
b/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf
new file mode 100644
index ..2c9ab99038f2
--- /dev/null
+++ b/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf
@@ -0,0 +1,56 @@
+## @file
+#  ARM MP services protocol driver
+#
+#  Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights 
reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 1.27
+  BASE_NAME  = ArmPsciMpServicesDxe
+  FILE_GUID  = 007ab472-dc4a-4df8-a5c2-abb4a327278c
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= ArmPsciMpServicesDxeInitialize
+
+[Sources.Common]
+  ArmPsciMpServicesDxe.c
+  MpFuncs.S
+  MpServicesInternal.h
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  ArmLib
+  ArmMmuLib
+  ArmSmcLib
+  BaseMemoryLib
+  CacheMaintenanceLib
+  CpuExceptionHandlerLib
+  DebugLib
+  HobLib
+  MemoryAllocationLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  UefiLib
+
+[Protocols]
+  gEfiMpServiceProtocolGuid## PRODUCES
+  gEfiLoadedImageProtocolGuid  ## CONSUMES
+
+[Guids]
+  gArmMpCoreInfoGuid
+
+[Depex]
+  TRUE
+
+[BuildOptions]
+  GCC:*_*_*_CC_FLAGS = -mstrict-align
diff --git a/ArmPkg/Drivers/ArmPsciMpServicesDxe/MpServicesInternal.h 
b/ArmPkg/Drivers/ArmPsciMpServicesDxe/MpServicesInternal.h
new file mode 100644
index ..a0c203f0a27f
--- /dev/null
+++ b/ArmPkg/Drivers/ArmPsciMpServicesDxe/MpServicesInternal.h
@@ -0,0 +1,345 @@
+/** @file
+
+Copyright (c) 2022, Qualcomm Innovation Center, Inc. All rights reserved.
+Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.
+Portions copyright (c) 2011, Apple Inc. All rights reserved.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MP_SERVICES_INTERNAL_H_
+#define MP_SERVICES_INTERNAL_H_
+
+#include 
+#include 
+
+#include 
+#include 
+
+#define AP_STACK_SIZE  0x1000
+
+//
+// Internal Data Structures
+//
+
+//
+// AP state
+//
+// The state transitions for an AP when it processes a procedure are:
+//  Idle > Ready > Busy > Finished > Idle
+//   [BSP]   [BSP]  [AP]   [BSP]
+//
+typedef enum {
+  CpuStateIdle,
+  CpuStateReady,
+  CpuStateBlocked,
+  CpuStateBusy,
+  CpuStateFinished,
+  CpuStateDisabled
+} CPU_STATE;
+
+//
+// Define Individual Processor Data block.
+//
+typedef struct {
+  EFI_PROCESSOR_INFORMATIONInfo;
+  EFI_AP_PROCEDURE Procedure;
+  VOID *Parameter;
+  CPU_STATEState;
+  EFI_EVENTCheckThisAPEvent;
+  EFI_EVENTWaitEvent;
+  UINTNTimeout;
+  UINTNTimeTaken;
+  BOOLEAN  TimeoutActive;
+  BOOLEAN  *SingleApFinished;
+} CPU_AP_DATA;
+
+//
+// Define MP data block which consumes individual processor block.
+//
+typedef struct {
+  UINTN   NumberOfProcessors;
+  UINTN   NumberOfEnabledProcessors;
+  EFI_EVENT   CheckAllAPsEvent;
+  EFI_EVENT   AllWaitEvent;
+  UINTN   FinishCount;
+  UINTN   StartCount;
+  EFI_AP_PROCEDUREProcedure;
+  VOID*ProcedureArgument;
+  BOOLEAN SingleThread;
+  UINTN   StartedNumber;
+  CPU_AP_DATA *CpuData;
+  UINTN   *FailedList;
+  UINTN   FailedListIndex;
+  UINTN   AllTimeout;
+  UINTN   AllTimeTaken;
+  BOOLEAN AllTimeoutActive;
+} CPU_MP_DATA;
+
+/** S

[edk2-devel] [PATCH v5 1/2] ArmPkg: Add GET_MPIDR_AFFINITY_BITS and MPIDR_MT_BIT to ArmLib.h

2023-01-16 Thread Rebecca Cran

Signed-off-by: Rebecca Cran 
---
 ArmPkg/Include/Library/ArmLib.h | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
index 6566deebdde2..fa605f128bfd 100644
--- a/ArmPkg/Include/Library/ArmLib.h
+++ b/ArmPkg/Include/Library/ArmLib.h
@@ -108,14 +108,16 @@ typedef enum {
 
 #define ARM_CORE_MASK ARM_CORE_AFF0
 #define ARM_CLUSTER_MASK  ARM_CORE_AFF1
-#define GET_CORE_ID(MpId)((MpId) & ARM_CORE_MASK)
-#define GET_CLUSTER_ID(MpId) (((MpId) & ARM_CLUSTER_MASK) >> 8)
-#define GET_MPID(ClusterId, CoreId)  (((ClusterId) << 8) | (CoreId))
-#define GET_MPIDR_AFF0(MpId) ((MpId) & ARM_CORE_AFF0)
-#define GET_MPIDR_AFF1(MpId) (((MpId) & ARM_CORE_AFF1) >> 8)
-#define GET_MPIDR_AFF2(MpId) (((MpId) & ARM_CORE_AFF2) >> 16)
-#define GET_MPIDR_AFF3(MpId) (((MpId) & ARM_CORE_AFF3) >> 32)
+#define GET_CORE_ID(MpId)  ((MpId) & ARM_CORE_MASK)
+#define GET_CLUSTER_ID(MpId)   (((MpId) & ARM_CLUSTER_MASK) >> 8)
+#define GET_MPID(ClusterId, CoreId)(((ClusterId) << 8) | (CoreId))
+#define GET_MPIDR_AFF0(MpId)   ((MpId) & ARM_CORE_AFF0)
+#define GET_MPIDR_AFF1(MpId)   (((MpId) & ARM_CORE_AFF1) >> 8)
+#define GET_MPIDR_AFF2(MpId)   (((MpId) & ARM_CORE_AFF2) >> 16)
+#define GET_MPIDR_AFF3(MpId)   (((MpId) & ARM_CORE_AFF3) >> 32)
+#define GET_MPIDR_AFFINITY_BITS(MpId)  ((MpId) & 0xFF00FF)
 #define PRIMARY_CORE_ID  (PcdGet32(PcdArmPrimaryCore) & ARM_CORE_MASK)
+#define MPIDR_MT_BIT BIT24
 
 /** Reads the CCSIDR register for the specified cache.
 
-- 
2.30.2



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

[edk2-devel] [PATCH v5 0/2] ArmPkg: Implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls for AArch64

2023-01-16 Thread Rebecca Cran

Implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls for AArch64.

Note that several tests from UefiCpuPkg/Test/UnitTest/EfiMpServicesPpiProtocol
will fail because there's currently no mechanism implemented to reset
APs that are stuck running the user's code (e.g. tests that run an
infinite loop). 
On x86 an IPI is sent to take back control: something similar should be
implemented on Arm.

Changes from v4:

o Changes based on review feedback from Kun Qin.
o Dropped the MpServicesTest patch, since
UefiCpuPkg/Test/UnitTest/EfiMpServicesPpiProtocol implements similar
functionality.

Changes from v2:

Added a CPU exception handler for the APs so that if the user's code
causes an exception (e.g. because the application terminates) the AP
state is set to CpuStateFinished and the core powered off.

Rebecca Cran (2):
  ArmPkg: Add GET_MPIDR_AFFINITY_BITS and MPIDR_MT_BIT to ArmLib.h
  ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls

 ArmPkg/ArmPkg.dsc|1 +
 ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf |   56 +
 ArmPkg/Drivers/ArmPsciMpServicesDxe/MpServicesInternal.h |  345 
 ArmPkg/Include/Library/ArmLib.h  |   16 +-
 ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c   | 1859 

 ArmPkg/Drivers/ArmPsciMpServicesDxe/MpFuncs.S|   74 +
 6 files changed, 2344 insertions(+), 7 deletions(-)
 create mode 100644 ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.inf
 create mode 100644 ArmPkg/Drivers/ArmPsciMpServicesDxe/MpServicesInternal.h
 create mode 100644 ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
 create mode 100644 ArmPkg/Drivers/ArmPsciMpServicesDxe/MpFuncs.S

-- 
2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98634): https://edk2.groups.io/g/devel/message/98634
Mute This Topic: https://groups.io/mt/96324766/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] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread Wang, William2

OK, I've updated the reserved bit.

Thanks,
William Wang

-Original Message-
From: Kuo, Donald  
Sent: Monday, January 16, 2023 5:23 PM
To: Ni, Ray ; Wang, William2 ; 
devel@edk2.groups.io
Cc: Kinney, Michael D ; Gao, Liming 
; Kumar, Chandana C 
Subject: RE: [PATCH v2] Update CPUID Leaf 06H to follow latest SDM.

Thanks Ray to clarify.

@Wang, William2 let's follow the EDK2 recommendation.   

Thanks,

-Original Message-
From: Ni, Ray  
Sent: Monday, January 16, 2023 5:19 PM
To: Kuo, Donald ; Wang, William2 
; devel@edk2.groups.io
Cc: Kinney, Michael D ; Gao, Liming 
; Kumar, Chandana C 
Subject: RE: [PATCH v2] Update CPUID Leaf 06H to follow latest SDM.

Donald,
Old code might reference existing Reserved field in the structure definition.
So, to avoid old code assigning value to different bits if using same field 
name but for different bits position,
edk2 recommends to change the field name from ReservedX to ReservedY when the 
bits covered by ReservedX are changed. Y is the next unused index.

So comments as below:

> 
> -UINT32Reserved5  : 11;
> 
> +UINT32Reserved4  : 2;
We should rename Reserved5 to Reserved6.

> 
> +UINT32IA32_THERM_INTERRUPT   : 1;
> 
> +UINT32Reserved5  : 7;
Reserved7.

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

[edk2-devel] [PATCH v5] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread william2 . wang

From: William2 Wang 

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

Update CPUID Leaf 06H to follow latest SDM.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
---
 MdePkg/Include/Register/Intel/Cpuid.h | 59 +++-
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Register/Intel/Cpuid.h 
b/MdePkg/Include/Register/Intel/Cpuid.h
index 350bf60252..44ceb85803 100644
--- a/MdePkg/Include/Register/Intel/Cpuid.h
+++ b/MdePkg/Include/Register/Intel/Cpuid.h
@@ -1195,12 +1195,24 @@ typedef union {
 /// [Bit 18] Fast access mode for the IA32_HWP_REQUEST MSR is supported if 
set.
 ///
 UINT32FastAccessMode : 1;
-UINT32Reserved4  : 1;
+///
+/// [Bit 19] IA32_HW_FEEDBACK_PTR MSR, IA32_HW_FEEDBACK_CONFIG MSR,
+/// IA32_PACKAGE_THERM_STATUS MSR bit 26, and IA32_PACKAGE_THERM_INTERRUPT 
MSR bit 25 are supported if set.
+UINT32HW_FEEDBACK: 1;
 ///
 /// [Bit 20] Ignoring Idle Logical Processor HWP request is supported if 
set.
 ///
 UINT32IgnoringIdleLogicalProcessorHWPRequest : 1;
-UINT32Reserved5  : 11;
+UINT32Reserved6  : 2;
+///
+/// [Bit 23] Intel Thread Director supported if set. IA32_HW_FEEDBACK_CHAR 
and
+/// IA32_HW_FEEDBACK_THREAD_CONFIG MSRs are supported if set.
+UINT32ThreadDirector : 1;
+///
+/// [Bit 24] IA32_THERM_INTERRUPT MSR bit 25 is supported if set.
+///
+UINT32IA32_THERM_INTERRUPT   : 1;
+UINT32Reserved7  : 7;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
@@ -1252,7 +1264,13 @@ typedef union {
 /// (1B0H).
 ///
 UINT32PerformanceEnergyBias: 1;
-UINT32Reserved2: 28;
+UINT32Reserved2: 4;
+///
+/// {Bit 15:8] Number of Intel Thread Director classes supported by the 
processor. Information for that
+/// many classes is written into the Intel Thread Director Table by the 
hardware.
+///
+UINT32ThreadDirectorClasses: 8;
+UINT32Reserved3: 16;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
@@ -1260,6 +1278,41 @@ typedef union {
   UINT32Uint32;
 } CPUID_THERMAL_POWER_MANAGEMENT_ECX;
 
+/**
+  CPUID Thermal and Power Management Information returned in EDX for CPUID leaf
+  #CPUID_THERMAL_POWER_MANAGEMENT.
+**/
+typedef union {
+  ///
+  /// Individual bit fields
+  ///
+  struct {
+///
+/// {Bits 7:0] Bitmap of supported hardware feedback interface 
capabilities.
+///   0 = When set to 1, indicates support for performance capability 
reporting.
+///   1 = When set to 1, indicates support for energy efficiency 
capability reporting.
+///   2-7 = Reserved
+///
+UINT32InterfaceCapability  : 8;
+///
+/// {Bits 11:8] Enumerates the size of the hardware feedback interface 
structure in number of 4 KB pages;
+/// add one to the return value to get the result.
+///
+UINT32InterfaceStructureSize   : 4;
+UINT32Reserved : 4;
+///
+/// {Bits 31:16] : Index (starting at 0) of this logical processor's row 
in the hardware feedback interface structure.
+/// Note that on some parts the index may be same for multiple logical 
processors. On some parts the
+/// indices may not be contiguous, i.e., there may be unused rows in the 
hardware feedback interface structure.
+///
+UINT32LogicalProcessorRowIndex : 16;
+  } Bits;
+  ///
+  /// All bit fields as a 32-bit value
+  ///
+  UINT32Uint32;
+} CPUID_THERMAL_POWER_MANAGEMENT_EDX;
+
 /**
   CPUID Structured Extended Feature Flags Enumeration
 
-- 
2.34.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98632): https://edk2.groups.io/g/devel/message/98632
Mute This Topic: https://groups.io/mt/96324028/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 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Min Xu

On January 17, 2023 10:13 AM, Yao Jiewen wrote:
> Sorry, I would like to withdraw my comment on ACPI table event and event type.
> 
> PFP spec defines the ACPI table on flash be measured to PCR[0] as part of
> POST_CODE.
> 
> But here ACPI table is configuration from VMM. I feel it is more suitable to
> extend to PCR[1] as part of configuration data.
> 
Thanks for clarification. So the measurement of the ACPI table from QEMU looks 
like below, right?

  Status = TpmMeasureAndLogData (
 1,
 EV_PLATFORM_CONFIG_FLAGS, <-- event type
 EV_POSTCODE_INFO_ACPI_DATA,  <-- "ACPI DATA"
 ACPI_DATA_LEN,
 (VOID *)(UINTN)Table,
 TableSize
 );

Thanks
Min


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98631): https://edk2.groups.io/g/devel/message/98631
Mute This Topic: https://groups.io/mt/96299277/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, January 17, 2023 #cal-reminder

2023-01-16 Thread Group Notification

*Reminder: TianoCore Bug Triage - APAC / NAMO*

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

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

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

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

*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&ivr=teams&d=conf.intel.com&test=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&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US
 )


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

[edk2-devel] Several messages to devel@edk2.groups.io (from Intel/NVIDIA/AMD/etc.) being flagged as spam

2023-01-16 Thread Rebecca Cran

I'm seeing many emails to edk2-devel being flagged as spam and ending up 
in my Spam folder, starting yesterday. This might be an isolated issue 
with my mail provider (Fastmail), but thought I'd mention it in case 
it's more widespread. For example, Mike's email "Re: [edk2-devel] 
edk2-platforms, continuous integration, testing, and you" about moving 
the meeting to 10am pacific on Tue Jan 17th was flagged.


Some of the headers are:

X-Spam-known-sender: no ("Email failed DMARC policy for domain"); 
in-addressbook;
 53d73d40-71d5-42b2-826f-50ae0b28b233 ("Autosaved")
X-Spam-sender-reputation: 500 (none)
X-Spam-score: 9.4
X-Spam-hits: DCC_REPUT_00_12 -0.8, HEADER_FROM_DIFFERENT_DOMAINS 0.25,
  MAILING_LIST_MULTI -1, ME_HAS_VSSU 0.001, ME_SENDERREP_NEUTRAL 0.001,
  RCVD_IN_MSPIKE_H2 -0.001, RCVD_IN_SBL_CSS 3, RCVD_IN_ZEN_LASTEXTERNAL 8,
  SPF_HELO_NONE 0.001, SPF_PASS -0.001, LANGUAGES en, BAYES_USED none,
  SA_VERSION 3.4.6
...
Received: from mx6 ([10.202.2.205])
  by compute2.internal (LMTPProxy); Mon, 16 Jan 2023 16:06:47 -0500
Received: from mx6.messagingengine.com (localhost [127.0.0.1])
by mailmx.nyi.internal (Postfix) with ESMTP id 2F6A65C0100
for; Mon, 16 Jan 2023 16:06:47 -0500 (EST)
Received: from mx6.messagingengine.com (localhost [127.0.0.1])
by mx6.messagingengine.com (Authentication Milter) with ESMTP
id DAF368511B6;
Mon, 16 Jan 2023 16:06:47 -0500
ARC-Seal: i=2; a=rsa-sha256; cv=fail; d=messagingengine.com; s=fm3; t=
1673903207; b=NCILAE0Pl7emFvkAgRZlYmfCsbh+fmjbKvGGzCOm3ZUr3x3jEH
6MpNPU00ARmEvmO1QLLQWrFWOHg4XET5a3P7idl1hdpjeUghaT8OJXZBEps3GuHi
4ykzXktjfzzfrl0MBdV/wdRKza9Pwt6RzcLUIPbiBj6p+CIaCc9x9R9YOprKaCY+
o5p9k7icZvMgYcsMETYjExHD8ej/rdtpsK8aBzkb7BFEf8WwpapRRG/JXj+uJK2g
pwKSUx9Y9e4YR2WsfhzYiAJopcoYVlGn5xMW1vDBGXIvO7mA76mUe3U0EslfLvWn
P1VZjvKqIOx9Ezumkue7C8Ta8WVTAzQ7eG+w==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=from:to:cc:subject:date:message-id
:references:in-reply-to:mime-version:list-unsubscribe
:list-subscribe:list-help:sender:list-id:reply-to:content-type
:content-transfer-encoding; s=fm3; t=1673903207; bh=WMWTNJfxt8zF
e0IEE4kAaXc5RiExQVIiD6mLKj0sze8=; b=IqLCWbpck5DimVkBCCSNBBhRUcSw
H9fS/WIWlB0ra3THxzgBcAqrs1RV0Rz8NGgsFMVlNSXry9OIdEGZ5F2Pdvff4RwZ
npnrMx0AvzwcZjN3A6x+t/AuULezpW4MJGxKyvK2kZ9hQW7jcVisBNK5E5inYdG0
3CVpuz4NRYwdKTkFMbXQt4JGQPZlgZs63rWvX+aimC87uAEtNnBm1fY0GX76RnCN
jtGq3cOOFiTPkS7NlYmX7sN5ROYnD2LLa6EEqpVQYjyVDXJnjTacWe2BlBV3RTAQ
wNpxexuCNl0895LPLM9+tiTpdaizBlDswc6zu8YK1I9Pn2h7D8U7wARi9Q==
ARC-Authentication-Results: i=2; mx6.messagingengine.com;
x-csa=none;
x-me-sender=none;
x-ptr=pass smtp.helo=mail02.groups.io policy.ptr=mail02.groups.io;
bimi=skipped (DMARC did not pass);
arc=fail
(as.1.microsoft.com=pass, ams.1.microsoft.com=fail (message has been 
altered))
smtp.remote-ip=66.175.222.108;
dkim=pass (1024-bit rsa key sha256) header.d=groups.io
header.i=@groups.io  header.b=pvOonOAx header.a=rsa-sha256
header.s=20140610 x-bits=1024;
dmarc=fail policy.published-domain-policy=none
policy.published-subdomain-policy=none policy.applied-disposition=none
policy.evaluated-disposition=none
policy.override-reason=trusted_forwarder policy.arc-aware-result=fail

(p=none,sp=none,has-list-id=yes,d=none,d.eval=none,override=trusted_forwarder,arc_aware_result=fail)
policy.policy-from=p header.from=intel.com;
iprev=pass smtp.remote-ip=66.175.222.108 (mail02.groups.io);
spf=passsmtp.mailfrom=bounce+27952+98602+3953573+7659...@groups.io
smtp.helo=mail02.groups.io
X-ME-Authentication-Results: mx6.messagingengine.com;
x-aligned-from=fail;
x-return-mx=pass header.domain=intel.com policy.is_org=yes
  (MX Records found: 
mga17.intel.com,mga07.intel.com,mga18.intel.com,mga01.intel.com,mga02.intel.com,mga11.intel.com,mga09.intel.com,mga14.intel.com,mga03.intel.com,mga04.intel.com,mga05.intel.com,mga06.intel.com,mga12.intel.com);
x-return-mx=pass smtp.domain=groups.io policy.is_org=yes
  (MX Records found: lb01.groups.io,lb02.groups.io);
x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_AES_256_GCM_SHA384
  smtp.bits=256/256;
x-vs=clean score=-100 state=0
Authentication-Results: mx6.messagingengine.com;
x-csa=none;
x-me-sender=none;
x-ptr=pass smtp.helo=mail02.groups.io policy.ptr=mail02.groups.io
Authentication-Results: mx6.messagingengine.com;
bimi=skipped (DMARC did not pass)
Authentication-Results: mx6.messagingengine.com;
arc=fail
  (as.1.microsoft.com=pass, ams.1.microsoft.com=fail (message has been 
altered))
  smtp.remote-ip=66.175.222.108
Authentication-Results: mx6.messagingengine.com;
dkim=pass (1024-bit rsa key sha256) header.d=groups.io
  header.i=@groups.io  header.b=pvOonOAx header.a=rsa-sha256
  header.s=20140610 x-bits=1024;
dmarc=fail policy.published-domain-policy=none
  policy.published-subdom

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Yao, Jiewen

And we should still follow the rule to measure the *exact* input data from VMM. 
That is the table *before* modification and installation.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao,
> Jiewen
> Sent: Tuesday, January 17, 2023 10:13 AM
> To: Xu, Min M ; devel@edk2.groups.io;
> a...@kernel.org
> Cc: Aktas, Erdem ; James Bottomley
> ; Gerd Hoffmann ; Tom
> Lendacky ; Michael Roth
> 
> Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> Measure ACPI table from QEMU in TDVF
> 
> Sorry, I would like to withdraw my comment on ACPI table event and event
> type.
> 
> PFP spec defines the ACPI table on flash be measured to PCR[0] as part of
> POST_CODE.
> 
> But here ACPI table is configuration from VMM. I feel it is more suitable to
> extend to PCR[1] as part of configuration data.
> 
> I apologize for the confusing.
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: Xu, Min M 
> > Sent: Tuesday, January 17, 2023 8:36 AM
> > To: Yao, Jiewen ; devel@edk2.groups.io;
> > a...@kernel.org
> > Cc: Aktas, Erdem ; James Bottomley
> > ; Gerd Hoffmann ; Tom
> > Lendacky ; Michael Roth
> > 
> > Subject: RE: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > Measure ACPI table from QEMU in TDVF
> >
> > Thanks Jiewen. It will be updated in the next version.
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Tuesday, January 17, 2023 8:30 AM
> > > To: devel@edk2.groups.io; Yao, Jiewen ;
> > > a...@kernel.org
> > > Cc: Xu, Min M ; Aktas, Erdem
> > > ; James Bottomley ;
> Gerd
> > > Hoffmann ; Tom Lendacky
> > > ; Michael Roth 
> > > Subject: RE: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > Measure
> > > ACPI table from QEMU in TDVF
> > >
> > > Hi Min
> > > One more thing: This is to measure ACPI table.
> > >
> > > According to https://trustedcomputinggroup.org/resource/pc-client-
> > specific-
> > > platform-firmware-profile-specification/, the event type should be
> > > EV_POST_CODE, and event data should be "ACPI DATA" in all caps. You
> can
> > > use below pattern:
> > > =
> > >   TpmMeasureAndLogData (
> > > 0,
> > > EV_POST_CODE,
> > > EV_POSTCODE_INFO_ACPI_DATA,
> > > ACPI_DATA_LEN,
> > > Table,
> > > TableSize
> > > );
> > > =
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of Yao,
> > > > Jiewen
> > > > Sent: Monday, January 16, 2023 10:28 PM
> > > > To: devel@edk2.groups.io; a...@kernel.org
> > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > ; James Bottomley ;
> > Gerd
> > > > Hoffmann ; Tom Lendacky
> > > ;
> > > > Michael Roth 
> > > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > > Measure ACPI table from QEMU in TDVF
> > > >
> > > > Each module, which wants to load ACPI table.
> > > >
> > > > Most codes are from close source platform.
> > > >
> > > > One example in EDKII SecurityPkg is TPM2.
> > > >
> > https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi
> > > > /
> > > > Tcg2Acpi.c#L690
> > > >
> > > >
> > https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi
> > > > /
> > > > Tcg2Acpi.c#L794
> > > >
> > > > Just search "TpmMeasureAndLogData" ...
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: devel@edk2.groups.io  On Behalf Of
> Ard
> > > > > Biesheuvel
> > > > > Sent: Monday, January 16, 2023 10:15 PM
> > > > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > ; James Bottomley ;
> > > Gerd
> > > > > Hoffmann ; Tom Lendacky
> > > > > ; Michael Roth
> 
> > > > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > > > Measure ACPI table from QEMU in TDVF
> > > > >
> > > > > On Mon, 16 Jan 2023 at 14:57, Yao, Jiewen 
> > > wrote:
> > > > > >
> > > > > > Do you mean real platform BIOS?
> > > > > >
> > > > >
> > > > > Yes
> > > > >
> > > > > > The rules are:
> > > > > > 1) The ACPI table on the flash loaded by the BIOS is measured
> > > > > > *before*
> > > > any
> > > > > modification and *before* installation. For example, DSDT, SSDT.
> > > > > > 2) The ACPI table constructed by the BIOS dynamically does not
> > > > > > need to
> > > > be
> > > > > measured. For example MADT.
> > > > > >
> > > > >
> > > > > OK so which EDK2 component is normally in charge of this?
> > > > >
> > > > >
> > > > >
> > > > > > > -Original Message-
> > > > > > > From: Ard Biesheuvel 
> > > > > > > Sent: Monday, January 16, 2023 6:38 PM
> > > > > > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > > > ; James Bottomley
> > ;
> > > > > Gerd
> > > > > > > Hoffmann ; Tom Lendacky
> > > > > > > ; Michael Roth
> > > 
> > > > > > > Subject: Re: [edk2-devel] [PATCH V1 1/1]
> OvmfPkg/AcpiPlatformDxe:
> > > > > > > Measure ACPI table from QEMU in TDVF
> > > > > > >
> > > > > > > Another question: how does this deviate from ordinary measured
> > boot?
> > > >

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Yao, Jiewen

Sorry, I would like to withdraw my comment on ACPI table event and event type.

PFP spec defines the ACPI table on flash be measured to PCR[0] as part of 
POST_CODE.

But here ACPI table is configuration from VMM. I feel it is more suitable to 
extend to PCR[1] as part of configuration data.

I apologize for the confusing.

Thank you
Yao, Jiewen

> -Original Message-
> From: Xu, Min M 
> Sent: Tuesday, January 17, 2023 8:36 AM
> To: Yao, Jiewen ; devel@edk2.groups.io;
> a...@kernel.org
> Cc: Aktas, Erdem ; James Bottomley
> ; Gerd Hoffmann ; Tom
> Lendacky ; Michael Roth
> 
> Subject: RE: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> Measure ACPI table from QEMU in TDVF
> 
> Thanks Jiewen. It will be updated in the next version.
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Tuesday, January 17, 2023 8:30 AM
> > To: devel@edk2.groups.io; Yao, Jiewen ;
> > a...@kernel.org
> > Cc: Xu, Min M ; Aktas, Erdem
> > ; James Bottomley ; Gerd
> > Hoffmann ; Tom Lendacky
> > ; Michael Roth 
> > Subject: RE: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> Measure
> > ACPI table from QEMU in TDVF
> >
> > Hi Min
> > One more thing: This is to measure ACPI table.
> >
> > According to https://trustedcomputinggroup.org/resource/pc-client-
> specific-
> > platform-firmware-profile-specification/, the event type should be
> > EV_POST_CODE, and event data should be "ACPI DATA" in all caps. You can
> > use below pattern:
> > =
> >   TpmMeasureAndLogData (
> > 0,
> > EV_POST_CODE,
> > EV_POSTCODE_INFO_ACPI_DATA,
> > ACPI_DATA_LEN,
> > Table,
> > TableSize
> > );
> > =
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Yao,
> > > Jiewen
> > > Sent: Monday, January 16, 2023 10:28 PM
> > > To: devel@edk2.groups.io; a...@kernel.org
> > > Cc: Xu, Min M ; Aktas, Erdem
> > > ; James Bottomley ;
> Gerd
> > > Hoffmann ; Tom Lendacky
> > ;
> > > Michael Roth 
> > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > Measure ACPI table from QEMU in TDVF
> > >
> > > Each module, which wants to load ACPI table.
> > >
> > > Most codes are from close source platform.
> > >
> > > One example in EDKII SecurityPkg is TPM2.
> > >
> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi
> > > /
> > > Tcg2Acpi.c#L690
> > >
> > >
> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi
> > > /
> > > Tcg2Acpi.c#L794
> > >
> > > Just search "TpmMeasureAndLogData" ...
> > >
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of Ard
> > > > Biesheuvel
> > > > Sent: Monday, January 16, 2023 10:15 PM
> > > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > ; James Bottomley ;
> > Gerd
> > > > Hoffmann ; Tom Lendacky
> > > > ; Michael Roth 
> > > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > > Measure ACPI table from QEMU in TDVF
> > > >
> > > > On Mon, 16 Jan 2023 at 14:57, Yao, Jiewen 
> > wrote:
> > > > >
> > > > > Do you mean real platform BIOS?
> > > > >
> > > >
> > > > Yes
> > > >
> > > > > The rules are:
> > > > > 1) The ACPI table on the flash loaded by the BIOS is measured
> > > > > *before*
> > > any
> > > > modification and *before* installation. For example, DSDT, SSDT.
> > > > > 2) The ACPI table constructed by the BIOS dynamically does not
> > > > > need to
> > > be
> > > > measured. For example MADT.
> > > > >
> > > >
> > > > OK so which EDK2 component is normally in charge of this?
> > > >
> > > >
> > > >
> > > > > > -Original Message-
> > > > > > From: Ard Biesheuvel 
> > > > > > Sent: Monday, January 16, 2023 6:38 PM
> > > > > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > > ; James Bottomley
> ;
> > > > Gerd
> > > > > > Hoffmann ; Tom Lendacky
> > > > > > ; Michael Roth
> > 
> > > > > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > > > > Measure ACPI table from QEMU in TDVF
> > > > > >
> > > > > > Another question: how does this deviate from ordinary measured
> boot?
> > > > > > How and when are ACPI tables measured on such systems?
> > > > > >
> > > > > >
> > > > > > On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen 
> > > > wrote:
> > > > > > >
> > > > > > > Hi
> > > > > > > I have two feedback:
> > > > > > >
> > > > > > > 1) What we need measure is the input from VMM *before* any
> > > > > > modification and *before* installation.
> > > > > > > Please don't use ACPI SDT protocol to get the table *after*
> > > modification.
> > > > > > >
> > > > > > > 2) Why not use TpmMeasureAndLogData() in
> > > > > >
> > > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Li
> > > > > > brary/TpmMeasurementLib.h ?
> > > > > > > Please don't use locate protocol.
> > > > > > >
> > > > > > > Thank you
> > > > > > > Yao, Jiewen
> > > > > > >
> > > > > > > > -Original M

[edk2-devel] [edk2-platforms][PATCH V1 1/1] Platform/Loongson: Support vga for loongarch.

2023-01-16 Thread xianglai

Add VGA graphics card support for Loongarch,
VGA graphics cards have GOP to support early
kernel information printing, so we need it.

Cc: Ard Biesheuvel 
Cc: Bibo Mao 
Cc: Chao Li 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Michael D Kinney 
Signed-off-by: xianglai li 
---
 Platform/Loongson/LoongArchQemuPkg/Loongson.dsc | 1 +
 Platform/Loongson/LoongArchQemuPkg/Loongson.fdf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc 
b/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
index 2d63f7d168..b3f3841ea1 100644
--- a/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
+++ b/Platform/Loongson/LoongArchQemuPkg/Loongson.dsc
@@ -597,6 +597,7 @@
   #
   # Video
   #
+  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
   OvmfPkg/PlatformDxe/Platform.inf
diff --git a/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf 
b/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
index 784f255910..31f7e28fc5 100644
--- a/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
+++ b/Platform/Loongson/LoongArchQemuPkg/Loongson.fdf
@@ -169,6 +169,7 @@ INF  
MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 #
 #Video
 #
+INF  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 INF  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
 INF  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
 INF  OvmfPkg/PlatformDxe/Platform.inf
-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98626): https://edk2.groups.io/g/devel/message/98626
Mute This Topic: https://groups.io/mt/96321350/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/1] SecurityPkg/AuthVariableLib: Check SHA-256 OID with ContentInfo present

2023-01-16 Thread Jan Bobek via groups.io

> I linked email with Bugzilla. Either email or Bugzilla is OK for the
> discussion.

Sounds good.

> Personally, I don't understand one thing.
> If EDKII causes such failure, how the archlinux validates the correctness of 
> the tool and document in [3] ?
>
> Or are they using a different UEFI implementation?

My understanding is that Archlinux assumes a standard-compliant UEFI
implementation. A Linux distribution doesn't typically provide UEFI
implementation; it's up to your platform vendor (e.g. laptop
manufacturer) to provide one. If the vendor wanted to use EDK2 as a
basis for their (typically proprietary) UEFI implementation, they would
need to address this issue one way or the other on their own.

-Jan

>> -Original Message-
>> From: Jan Bobek 
>> Sent: Tuesday, January 17, 2023 6:30 AM
>> To: Yao, Jiewen 
>> Cc: devel@edk2.groups.io; Jeff Brasen ; Girish
>> Mahadevan ; Wang, Jian J
>> ; Xu, Min M 
>> Subject: Re: [edk2-devel] [PATCH 1/1] SecurityPkg/AuthVariableLib: Check
>> SHA-256 OID with ContentInfo present
>>
>> > Hi
>> > That is good catch!
>> > My apology to miss it before.
>> >
>> > 1) Please file a bugzilla (https://bugzilla.tianocore.org/) to record the 
>> > issue
>> and associate to the patch.
>>
>> Filed bug 4305 [1]. Sorry for the delay, I didn't get my bugzilla
>> credentials until late last week.
>>
>> > 2) Would you please share with us that how you discover the issue?
>> > For example, any real use case to include ContentInfo? If yes, please share
>> a URL.
>> > Or this is just a purely spec compliance fix ?
>> >
>> > 3) Please describe how you validate the fix.
>> > If possible, would you please share your test case?
>>
>> I believe both of these answered / included in the bug description.
>>
>> > 4) Since the new code is handling ContentInfo structure is present, I 
>> > believe
>> we need also check if the ContentInfo structure is valid.
>> > For example:
>> > 
>> > c SignedData.contentInfo.contentType shall be set to id-data
>> > d SignedData.contentInfo.content shall be absent
>> > 
>> > What do you think?
>>
>> I think you're talking about the ContentInfo structure that's part of
>> the SignedData structure, but the real problem is with ContentInfo
>> structure that _wraps_ the SignedData structure. More info in the bug
>> description.
>>
>> Also, is it customary to continue the discussion here on edk2-devel or
>> in the bug comments on bugzilla?
>>
>> -Jan
>>
>> References:
>> 1. https://bugzilla.tianocore.org/show_bug.cgi?id=4305



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98625): https://edk2.groups.io/g/devel/message/98625
Mute This Topic: https://groups.io/mt/95419835/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 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Min Xu

Thanks Jiewen. It will be updated in the next version.

> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, January 17, 2023 8:30 AM
> To: devel@edk2.groups.io; Yao, Jiewen ;
> a...@kernel.org
> Cc: Xu, Min M ; Aktas, Erdem
> ; James Bottomley ; Gerd
> Hoffmann ; Tom Lendacky
> ; Michael Roth 
> Subject: RE: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure
> ACPI table from QEMU in TDVF
> 
> Hi Min
> One more thing: This is to measure ACPI table.
> 
> According to https://trustedcomputinggroup.org/resource/pc-client-specific-
> platform-firmware-profile-specification/, the event type should be
> EV_POST_CODE, and event data should be "ACPI DATA" in all caps. You can
> use below pattern:
> =
>   TpmMeasureAndLogData (
> 0,
> EV_POST_CODE,
> EV_POSTCODE_INFO_ACPI_DATA,
> ACPI_DATA_LEN,
> Table,
> TableSize
> );
> =
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Yao,
> > Jiewen
> > Sent: Monday, January 16, 2023 10:28 PM
> > To: devel@edk2.groups.io; a...@kernel.org
> > Cc: Xu, Min M ; Aktas, Erdem
> > ; James Bottomley ; Gerd
> > Hoffmann ; Tom Lendacky
> ;
> > Michael Roth 
> > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > Measure ACPI table from QEMU in TDVF
> >
> > Each module, which wants to load ACPI table.
> >
> > Most codes are from close source platform.
> >
> > One example in EDKII SecurityPkg is TPM2.
> > https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi
> > /
> > Tcg2Acpi.c#L690
> >
> > https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi
> > /
> > Tcg2Acpi.c#L794
> >
> > Just search "TpmMeasureAndLogData" ...
> >
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Ard
> > > Biesheuvel
> > > Sent: Monday, January 16, 2023 10:15 PM
> > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > Cc: Xu, Min M ; Aktas, Erdem
> > > ; James Bottomley ;
> Gerd
> > > Hoffmann ; Tom Lendacky
> > > ; Michael Roth 
> > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > Measure ACPI table from QEMU in TDVF
> > >
> > > On Mon, 16 Jan 2023 at 14:57, Yao, Jiewen 
> wrote:
> > > >
> > > > Do you mean real platform BIOS?
> > > >
> > >
> > > Yes
> > >
> > > > The rules are:
> > > > 1) The ACPI table on the flash loaded by the BIOS is measured
> > > > *before*
> > any
> > > modification and *before* installation. For example, DSDT, SSDT.
> > > > 2) The ACPI table constructed by the BIOS dynamically does not
> > > > need to
> > be
> > > measured. For example MADT.
> > > >
> > >
> > > OK so which EDK2 component is normally in charge of this?
> > >
> > >
> > >
> > > > > -Original Message-
> > > > > From: Ard Biesheuvel 
> > > > > Sent: Monday, January 16, 2023 6:38 PM
> > > > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > ; James Bottomley ;
> > > Gerd
> > > > > Hoffmann ; Tom Lendacky
> > > > > ; Michael Roth
> 
> > > > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > > > Measure ACPI table from QEMU in TDVF
> > > > >
> > > > > Another question: how does this deviate from ordinary measured boot?
> > > > > How and when are ACPI tables measured on such systems?
> > > > >
> > > > >
> > > > > On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen 
> > > wrote:
> > > > > >
> > > > > > Hi
> > > > > > I have two feedback:
> > > > > >
> > > > > > 1) What we need measure is the input from VMM *before* any
> > > > > modification and *before* installation.
> > > > > > Please don't use ACPI SDT protocol to get the table *after*
> > modification.
> > > > > >
> > > > > > 2) Why not use TpmMeasureAndLogData() in
> > > > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Li
> > > > > brary/TpmMeasurementLib.h ?
> > > > > > Please don't use locate protocol.
> > > > > >
> > > > > > Thank you
> > > > > > Yao, Jiewen
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Xu, Min M 
> > > > > > > Sent: Monday, January 16, 2023 9:57 AM
> > > > > > > To: devel@edk2.groups.io
> > > > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > > > ; James Bottomley
> > ;
> > > > > Yao,
> > > > > > > Jiewen ; Gerd Hoffmann
> > > ;
> > > > > > > Tom Lendacky ; Michael Roth
> > > > > > > 
> > > > > > > Subject: [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure
> > > > > > > ACPI
> > > table
> > > > > from
> > > > > > > QEMU in TDVF
> > > > > > >
> > > > > > > From: Min M Xu 
> > > > > > >
> > > > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=4245
> > > > > > >
> > > > > > > The ACPI tables are downloaded from QEMU. QEMU/VMM is
> > treated
> > > as
> > > > > > > un-trusted in a td-guest. From the security perspective they
> > > > > > > should be measured and extended if possible. So that they
> > > > > > > can be audited later. The measurement protocol may be not
> > > > > > > installed. In this case it still returns EFI_SUCCE

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Yao, Jiewen

Hi Min
One more thing: This is to measure ACPI table.

According to 
https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/,
 the event type should be EV_POST_CODE, and event data should be "ACPI DATA" in 
all caps. You can use below pattern:
=
  TpmMeasureAndLogData (
0,
EV_POST_CODE,
EV_POSTCODE_INFO_ACPI_DATA,
ACPI_DATA_LEN,
Table,
TableSize
);
=

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao,
> Jiewen
> Sent: Monday, January 16, 2023 10:28 PM
> To: devel@edk2.groups.io; a...@kernel.org
> Cc: Xu, Min M ; Aktas, Erdem
> ; James Bottomley ; Gerd
> Hoffmann ; Tom Lendacky
> ; Michael Roth 
> Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> Measure ACPI table from QEMU in TDVF
> 
> Each module, which wants to load ACPI table.
> 
> Most codes are from close source platform.
> 
> One example in EDKII SecurityPkg is TPM2.
> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi/
> Tcg2Acpi.c#L690
> 
> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi/
> Tcg2Acpi.c#L794
> 
> Just search "TpmMeasureAndLogData" ...
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Ard
> > Biesheuvel
> > Sent: Monday, January 16, 2023 10:15 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Xu, Min M ; Aktas, Erdem
> > ; James Bottomley ; Gerd
> > Hoffmann ; Tom Lendacky
> > ; Michael Roth 
> > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > Measure ACPI table from QEMU in TDVF
> >
> > On Mon, 16 Jan 2023 at 14:57, Yao, Jiewen  wrote:
> > >
> > > Do you mean real platform BIOS?
> > >
> >
> > Yes
> >
> > > The rules are:
> > > 1) The ACPI table on the flash loaded by the BIOS is measured *before*
> any
> > modification and *before* installation. For example, DSDT, SSDT.
> > > 2) The ACPI table constructed by the BIOS dynamically does not need to
> be
> > measured. For example MADT.
> > >
> >
> > OK so which EDK2 component is normally in charge of this?
> >
> >
> >
> > > > -Original Message-
> > > > From: Ard Biesheuvel 
> > > > Sent: Monday, January 16, 2023 6:38 PM
> > > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > ; James Bottomley ;
> > Gerd
> > > > Hoffmann ; Tom Lendacky
> > > > ; Michael Roth 
> > > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > > Measure ACPI table from QEMU in TDVF
> > > >
> > > > Another question: how does this deviate from ordinary measured boot?
> > > > How and when are ACPI tables measured on such systems?
> > > >
> > > >
> > > > On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen 
> > wrote:
> > > > >
> > > > > Hi
> > > > > I have two feedback:
> > > > >
> > > > > 1) What we need measure is the input from VMM *before* any
> > > > modification and *before* installation.
> > > > > Please don't use ACPI SDT protocol to get the table *after*
> modification.
> > > > >
> > > > > 2) Why not use TpmMeasureAndLogData() in
> > > >
> >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Li
> > > > brary/TpmMeasurementLib.h ?
> > > > > Please don't use locate protocol.
> > > > >
> > > > > Thank you
> > > > > Yao, Jiewen
> > > > >
> > > > > > -Original Message-
> > > > > > From: Xu, Min M 
> > > > > > Sent: Monday, January 16, 2023 9:57 AM
> > > > > > To: devel@edk2.groups.io
> > > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > > ; James Bottomley
> ;
> > > > Yao,
> > > > > > Jiewen ; Gerd Hoffmann
> > ;
> > > > > > Tom Lendacky ; Michael Roth
> > > > > > 
> > > > > > Subject: [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI
> > table
> > > > from
> > > > > > QEMU in TDVF
> > > > > >
> > > > > > From: Min M Xu 
> > > > > >
> > > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=4245
> > > > > >
> > > > > > The ACPI tables are downloaded from QEMU. QEMU/VMM is
> treated
> > as
> > > > > > un-trusted in a td-guest. From the security perspective they should
> > > > > > be measured and extended if possible. So that they can be audited
> > > > > > later. The measurement protocol may be not installed. In this case
> > > > > > it still returns EFI_SUCCESS.
> > > > > >
> > > > > > Cc: Erdem Aktas 
> > > > > > Cc: James Bottomley 
> > > > > > Cc: Jiewen Yao 
> > > > > > Cc: Gerd Hoffmann 
> > > > > > Cc: Tom Lendacky 
> > > > > > Cc: Michael Roth 
> > > > > > Signed-off-by: Min Xu 
> > > > > > ---
> > > > > >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> > > > > >  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 168
> > > > > > 
> > > > > >  2 files changed, 170 insertions(+)
> > > > > >
> > > > > > diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > > b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > > index 8939dde42549..ae22bab38cf9 100644
> > > > > > --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > > +++ b/OvmfPkg/AcpiPla

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/AuthVariableLib: Check SHA-256 OID with ContentInfo present

2023-01-16 Thread Yao, Jiewen

I linked email with Bugzilla. Either email or Bugzilla is OK for the discussion.

Personally, I don't understand one thing.
If EDKII causes such failure, how the archlinux validates the correctness of 
the tool and document in [3] ?

Or are they using a different UEFI implementation?

Thank you
Yao, Jiewen

> -Original Message-
> From: Jan Bobek 
> Sent: Tuesday, January 17, 2023 6:30 AM
> To: Yao, Jiewen 
> Cc: devel@edk2.groups.io; Jeff Brasen ; Girish
> Mahadevan ; Wang, Jian J
> ; Xu, Min M 
> Subject: Re: [edk2-devel] [PATCH 1/1] SecurityPkg/AuthVariableLib: Check
> SHA-256 OID with ContentInfo present
> 
> > Hi
> > That is good catch!
> > My apology to miss it before.
> >
> > 1) Please file a bugzilla (https://bugzilla.tianocore.org/) to record the 
> > issue
> and associate to the patch.
> 
> Filed bug 4305 [1]. Sorry for the delay, I didn't get my bugzilla
> credentials until late last week.
> 
> > 2) Would you please share with us that how you discover the issue?
> > For example, any real use case to include ContentInfo? If yes, please share
> a URL.
> > Or this is just a purely spec compliance fix ?
> >
> > 3) Please describe how you validate the fix.
> > If possible, would you please share your test case?
> 
> I believe both of these answered / included in the bug description.
> 
> > 4) Since the new code is handling ContentInfo structure is present, I 
> > believe
> we need also check if the ContentInfo structure is valid.
> > For example:
> > 
> > c SignedData.contentInfo.contentType shall be set to id-data
> > d SignedData.contentInfo.content shall be absent
> > 
> > What do you think?
> 
> I think you're talking about the ContentInfo structure that's part of
> the SignedData structure, but the real problem is with ContentInfo
> structure that _wraps_ the SignedData structure. More info in the bug
> description.
> 
> Also, is it customary to continue the discussion here on edk2-devel or
> in the bug comments on bugzilla?
> 
> -Jan
> 
> References:
> 1. https://bugzilla.tianocore.org/show_bug.cgi?id=4305


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

Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

2023-01-16 Thread Yao, Jiewen

Not sure the detail.

Could you please add more comment, such as, what issue? Why crash? Why changing 
to Broadwell can resolve it?
any URL?



> -Original Message-
> From: Oliver Steffen 
> Sent: Tuesday, January 17, 2023 1:41 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ard Biesheuvel
> ; Feng, Bob C ; Bi,
> Dandan ; Gerd Hoffmann ;
> Wang, Jian J ; Yao, Jiewen ;
> Justen, Jordan L ; Leif Lindholm
> ; Gao, Liming ;
> Kinney, Michael D ; Michael Kubacki
> ; Ni, Ray ; Sami
> Mujawar ; Sean Brogan
> ; Chen, Christine ;
> Pawel Polawski ; chris.fern...@outlook.com; Oliver
> Steffen 
> Subject: [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell
> 
> Work around a bug in Ovmf that causes Ovmf to crash on startup
> when running in recent versions of Qemu.  Setting the cpu model
> to something older, for example "Broadwell" works around the issue.
> 
> Signed-off-by: Oliver Steffen 
> ---
>  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> index bfef9849c749..93f7d7aa13d6 100644
> --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> @@ -194,6 +194,7 @@ class PlatformBuilder( UefiBuilder,
> BuildSettingsManager):
>  cmd = "qemu-system-x86_64"
>  args  = "-debugcon stdio"   
> # write messages to
> stdio
>  args += " -global isa-debugcon.iobase=0x402"
> # debug
> messages out thru virtual io port
> +args += " -cpu Broadwell"   
> # workaround Qvmf
> bug
>  args += " -net none"
> # turn off network
>  args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" #
> Mount disk with startup.nsh
> 
> --
> 2.39.0



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

Re: [edk2-devel] [PATCH v11 15/17] OvmfPkg: CI: use ubuntu-22.04 vm_image (Linux only)

2023-01-16 Thread Yao, Jiewen

Acked-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Oliver
> Steffen
> Sent: Tuesday, January 17, 2023 1:41 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ard Biesheuvel
> ; Feng, Bob C ; Bi,
> Dandan ; Gerd Hoffmann ;
> Wang, Jian J ; Yao, Jiewen ;
> Justen, Jordan L ; Leif Lindholm
> ; Gao, Liming ;
> Kinney, Michael D ; Michael Kubacki
> ; Ni, Ray ; Sami
> Mujawar ; Sean Brogan
> ; Chen, Christine ;
> Pawel Polawski ; chris.fern...@outlook.com; Oliver
> Steffen ; Kubacki, Michael
> 
> Subject: [edk2-devel] [PATCH v11 15/17] OvmfPkg: CI: use ubuntu-22.04
> vm_image (Linux only)
> 
> Switch over to ubuntu-22.04 as the vm_image for Linux CI jobs.  The
> previously used ubuntu-18.04 which is not available anymore since
> Dec 1st 2022.
> 
> Signed-off-by: Oliver Steffen 
> Reviewed-by: Michael Kubacki 
> ---
>  OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> index 85be431ca5e7..1cf9bdf8b9c2 100644
> --- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> @@ -22,7 +22,7 @@ jobs:
>- job: Platform_CI
>  variables:
>package: 'OvmfPkg'
> -  vm_image: 'ubuntu-18.04'
> +  vm_image: 'ubuntu-22.04'
>should_run: true
>run_flags: "MAKE_STARTUP_NSH=TRUE QEMU_HEADLESS=TRUE"
> 
> --
> 2.39.0
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v11 10/17] OvmfPkg: CI: Use Fedora 35 container (Linux only)

2023-01-16 Thread Yao, Jiewen

Acked-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Oliver
> Steffen
> Sent: Tuesday, January 17, 2023 1:41 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ard Biesheuvel
> ; Feng, Bob C ; Bi,
> Dandan ; Gerd Hoffmann ;
> Wang, Jian J ; Yao, Jiewen ;
> Justen, Jordan L ; Leif Lindholm
> ; Gao, Liming ;
> Kinney, Michael D ; Michael Kubacki
> ; Ni, Ray ; Sami
> Mujawar ; Sean Brogan
> ; Chen, Christine ;
> Pawel Polawski ; chris.fern...@outlook.com; Oliver
> Steffen 
> Subject: [edk2-devel] [PATCH v11 10/17] OvmfPkg: CI: Use Fedora 35
> container (Linux only)
> 
> Run the Linux jobs of the OvmfPkg platform CI inside a container,
> in the same way the general CI does now. Make use of the default image
> specified in the defaults.yml template.
> 
> Do not run apt-get in CI jobs to install qemu and gcc dependencies.
> Assume the container image provides these.
> 
> Use Python from the container image, do not download at runtime.
> 
> Signed-off-by: Oliver Steffen 
> ---
>  OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> index 6dd90711ac70..85be431ca5e7 100644
> --- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> @@ -180,6 +180,8 @@ jobs:
>  pool:
>vmImage: $(vm_image)
> 
> +container: ${{ variables.default_linux_image }}
> +
>  steps:
>  - template: ../../../.azurepipelines/templates/platform-build-run-
> steps.yml
>parameters:
> @@ -190,8 +192,4 @@ jobs:
>  build_file: $(Build.File)
>  build_flags: $(Build.Flags)
>  run_flags: $(Run.Flags)
> -usePythonVersion: ${{ variables.default_python_version }}
> -extra_install_step:
> -- bash: sudo apt-get install qemu
> -  displayName: Install qemu
> -  condition: and(gt(variables.pkg_count, 0), succeeded())
> +usePythonVersion: '' # use Python from the container image
> --
> 2.39.0
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v11 04/17] OvmfPkg: CI: use Python version from defaults template

2023-01-16 Thread Yao, Jiewen

Acked-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Oliver
> Steffen
> Sent: Tuesday, January 17, 2023 1:41 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ard Biesheuvel
> ; Feng, Bob C ; Bi,
> Dandan ; Gerd Hoffmann ;
> Wang, Jian J ; Yao, Jiewen ;
> Justen, Jordan L ; Leif Lindholm
> ; Gao, Liming ;
> Kinney, Michael D ; Michael Kubacki
> ; Ni, Ray ; Sami
> Mujawar ; Sean Brogan
> ; Chen, Christine ;
> Pawel Polawski ; chris.fern...@outlook.com; Oliver
> Steffen ; Kubacki, Michael
> 
> Subject: [edk2-devel] [PATCH v11 04/17] OvmfPkg: CI: use Python version
> from defaults template
> 
> Use the default Python version from the defaults template
> (.azurepipelines/templates/defaults.yml) in the Windows and
> Linux CI jobs.
> 
> Previous changes to the CI job templates make it necessary
> to specify a version number, if Python shall be pulled
> at CI runtime.
> 
> Signed-off-by: Oliver Steffen 
> Reviewed-by: Michael Kubacki 
> ---
>  OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml| 4 
>  OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml | 5 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> index 7160d95f7e04..6dd90711ac70 100644
> --- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> @@ -15,6 +15,9 @@ pr:
>- master
>- stable/*
> 
> +variables:
> +  - template: ../../../.azurepipelines/templates/defaults.yml
> +
>  jobs:
>- job: Platform_CI
>  variables:
> @@ -187,6 +190,7 @@ jobs:
>  build_file: $(Build.File)
>  build_flags: $(Build.Flags)
>  run_flags: $(Run.Flags)
> +usePythonVersion: ${{ variables.default_python_version }}
>  extra_install_step:
>  - bash: sudo apt-get install qemu
>displayName: Install qemu
> diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
> b/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
> index 7d6344d6383d..7e63f419b26b 100644
> --- a/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
> +++ b/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
> @@ -14,6 +14,10 @@ trigger:
>  pr:
>- master
>- stable/*
> +
> +variables:
> +  - template: ../../../.azurepipelines/templates/defaults.yml
> +
>  jobs:
>- job: Platform_CI
>  variables:
> @@ -133,6 +137,7 @@ jobs:
>  build_file: $(Build.File)
>  build_flags: $(Build.Flags)
>  run_flags: $(Run.Flags)
> +usePythonVersion: ${{ variables.default_python_version }}
>  extra_install_step:
>  - powershell: choco install qemu --version=2021.5.5; Write-Host
> "##vso[task.prependpath]c:\Program Files\qemu"
>displayName: Install QEMU and Set QEMU on path # friendly name
> displayed in the UI
> --
> 2.39.0
> 
> 
> 
> 
> 



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

[edk2-devel] [PATCH] StandaloneMmPkg/StandaloneMmMemLib: Update AARCH64 address size

2023-01-16 Thread Milosek, Damian

Enable StandaloneMmMemLib to use longer physical addresses than 36 bits.
According to ARM "Learn the architecture - AArch64 memory management"
since Armv8.2-A physical address size was extended to 52 bits.
https://developer.arm.com/documentation/101811/0102/Address-spaces

Signed-off-by: Damian Milosek 
---
.../StandaloneMmMemLib/ArmStandaloneMmMemLibInternal.c| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/StandaloneMmPkg/Library/StandaloneMmMemLib/ArmStandaloneMmMemLibInternal.c 
b/StandaloneMmPkg/Library/StandaloneMmMemLib/ArmStandaloneMmMemLibInternal.c
index 297cfae916..dff3e0145f 100644
--- a/StandaloneMmPkg/Library/StandaloneMmMemLib/ArmStandaloneMmMemLibInternal.c
+++ b/StandaloneMmPkg/Library/StandaloneMmMemLib/ArmStandaloneMmMemLibInternal.c
@@ -6,7 +6,7 @@
   all MMRAM range via MM_ACCESS_PROTOCOL, including the range for firmware 
(like MM Core
   and MM driver) and/or specific dedicated hardware.

-  Copyright (c) 2015, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2023, Intel Corporation. All rights reserved.
   Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.

   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -21,7 +21,7 @@
extern EFI_PHYSICAL_ADDRESS  mMmMemLibInternalMaximumSupportAddress;

#ifdef MDE_CPU_AARCH64
-#define ARM_PHYSICAL_ADDRESS_BITS  36
+#define ARM_PHYSICAL_ADDRESS_BITS  52
#endif
#ifdef MDE_CPU_ARM
#define ARM_PHYSICAL_ADDRESS_BITS  32
--
2.37.2.windows.2
-
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z 
dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach 
handlowych.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by others 
is strictly prohibited.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98615): https://edk2.groups.io/g/devel/message/98615
Mute This Topic: https://groups.io/mt/96320111/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Kirill A. Shutemov

On Mon, Jan 16, 2023 at 11:43:15AM -0800, Dionna Amalie Glaze wrote:
> > > I still don't understand why we need to support every imaginable
> > > combination of firmware, bootloader and OS. Unaccepted memory only
> > > exists on a special kind of virtual machine, which provides very
> > > little added value unless you opt into the security and attestation
> > > features, which are all heavily based on firmware protocols. So why
> > > should care about a EFI-aware bootloader calling ExitBootServices()
> > > and subsequently doing a legacy boot of Linux on such systems?
> >
> > Why break what works? Some users want it.
> >
> 
> The users that want legacy boot features will not be broken,

Why do you call boot with a bootloader a legacy feature?

> they'll only get a safe view of the memory map. I don't think it's right
> to choose unsafe behavior for a legacy setup.

Present memory map with unaccepted memory to OS that doesn't about it is
perfectly safe. This portion of the memory will be ignored. It is "feature
not [yet] implemented" case.

> > This patch adds complexity, breaks what works and the only upside will
> > turn into a dead weight soon.
> >
> > There's alternative to add option to instruct firmware to accept all
> > memory from VMM side. It will serve legacy OS that doesn't know about
> > unaccepted memory and it is also can be use by latency-sensitive users
> > later on (analog of qemu -mem-prealloc).
> >
> 
> This means that users of a distro that has not enabled unaccepted
> memory support cannot simply start a VM with the usual command, but
> instead have to know a baroque extra flag to get access to all the
> memory that they configured the machine (and for a CSP customer, paid
> for). That's not a good experience.

New features require enabling. It is not something new.

> With GCE at least, you can't (shouldn't) associate the boot feature
> flag with a disk image because disks are mutable. If a customer
> upgrades their kernel after initially starting their VM, they can't
> remove the flag due to the way image annotations work.

I guess a new VM has to be created, right? Doesn't sound like a big deal
to me.

The old will not break with upgraded kernel. Just not get benefit of the
feature.

> All of this headache goes away by adopting a small patch to the kernel
> that calls a 0-ary protocol interface and keeping safe acceptance
> behavior in the firmware. I think Gerd is right here that we should
> treat it as a transition feature that we can remove later.

Removing a feature is harder than adding one. How do you define that
"later" has come?

Anyway, I think we walk in a circle. I consider it a misfeature. If you
want still go this path, please add my

Nacked-by: Kirill A. Shutemov 

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98617): https://edk2.groups.io/g/devel/message/98617
Mute This Topic: https://groups.io/mt/96256524/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 4/6] UefiCpuPkg: Implements SmmSmramSaveStateLib library class

2023-01-16 Thread Attar, AbdulLateef (Abdul Lateef) via groups.io

Hi Abner,

Please see inline for my reply under [Abdul].

Thanks
AbduL
-Original Message-
From: Chang, Abner  
Sent: 15 January 2023 10:15
To: devel@edk2.groups.io; Attar, AbdulLateef (Abdul Lateef) 

Cc: Grimes, Paul ; Kirkendall, Garrett 
; Eric Dong ; Ray Ni 
; Rahul Kumar ; Gerd Hoffmann 

Subject: RE: [edk2-devel] [PATCH v2 4/6] UefiCpuPkg: Implements 
SmmSmramSaveStateLib library class

[AMD Official Use Only - General]

According to the section 4.2.3 in edk2 c coding standard spec in below link, 
the processor vendor directory must be under the processor arch directory. We 
use vendor directory because the different implementations of the same 
processor arch.
https://tianocore-docs.github.io/edk2-CCodingStandardsSpecification/draft/edk2-CCodingStandardsSpecification-draft.pdf
So for this case, we can just have AmdSmramSaveState.c under SmramSaveStateLib\ 
according to the file naming defined in 4.3.5.4 because this library is only 
for X86 platform. 


[Abdul] SmramSaveState.c will be different for Intel's implementation, that's 
the reason added Amd directory.

After this patch set is reviewed and merged, we should have another patch set 
to update PiSmmCpuDxeSmm to use this library for SMM register access, remove 
the one in SmmCpuFeaturelib. Also update OVMF to use SmmSmramSaveStateLib. 
Migration SmmSaveState.c under PiSmmCpuDxeSmm to SmmSmramSaveStateLib for Intel 
implementation.

SmmSmramSaveStateLib implementation is AMD processor specific.
I haven't added Intel's implementation, hence cant use this library in 
PiSmmCpuDxeSmm until Intel's implementation added.
Same applies to the OVMF.

Other comments in below, 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abdul 
> Lateef Attar via groups.io
> Sent: Wednesday, January 11, 2023 2:16 PM
> To: devel@edk2.groups.io
> Cc: Attar, AbdulLateef (Abdul Lateef) ; 
> Grimes, Paul ; Kirkendall, Garrett 
> ; Chang, Abner ; Eric 
> Dong ; Ray Ni ; Rahul Kumar 
> ; Gerd Hoffmann ; Attar, 
> AbdulLateef (Abdul Lateef) 
> Subject: [edk2-devel] [PATCH v2 4/6] UefiCpuPkg: Implements 
> SmmSmramSaveStateLib library class
> 
> Caution: This message originated from an External Source. Use proper 
> caution when opening attachments, clicking links, or responding.
> 
> 
> From: Abdul Lateef Attar 
> 
> BZ:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.tianocore.org%2Fshow_bug.cgi%3Fid%3D4182&data=05%7C01%7Cabner.
> chang%40amd.com%7C21622ff06cd949cc7e1608daf39b82a2%7C3dd8961fe48
> 84e608e11a82d994e183d%7C0%7C0%7C638090146492954852%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QgHzNdcBkpCNbjGLPfx0L
> Em6ECHYowjuSryyNiWf0ww%3D&reserved=0
> 
> Implements SmmSmramSaveStateLib Library class for AMD cpu family.
> 
> Cc: Paul Grimes 
> Cc: Garrett Kirkendall 
> Cc: Abner Chang 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> 
> Signed-off-by: Abdul Lateef Attar 
> ---
>  UefiCpuPkg/UefiCpuPkg.dsc |   3 +
>  .../AmdSmmSmramSaveStateLib.inf   |  28 ++
>  .../SmmSmramSaveStateLib/SmramSaveState.h | 102 ++
>  .../SmmSmramSaveStateLib/Amd/SmramSaveState.c | 318
> ++
>  .../SmramSaveStateCommon.c| 124 +++
>  5 files changed, 575 insertions(+)
>  create mode 100644
> UefiCpuPkg/Library/SmmSmramSaveStateLib/AmdSmmSmramSaveStateLib.
> inf
>  create mode 100644
> UefiCpuPkg/Library/SmmSmramSaveStateLib/SmramSaveState.h
>  create mode 100644
> UefiCpuPkg/Library/SmmSmramSaveStateLib/Amd/SmramSaveState.c
>  create mode 100644
> UefiCpuPkg/Library/SmmSmramSaveStateLib/SmramSaveStateCommon.c
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc 
> index f9a46089d2c7..99f7532ce00b 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -2,6 +2,7 @@
>  #  UefiCpuPkg Package
> 
>  #
> 
>  #  Copyright (c) 2007 - 2022, Intel Corporation. All rights 
> reserved.
> 
> +#  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights 
> +reserved.
> 
>  #
> 
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #
> 
> @@ -104,6 +105,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
> 
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMe
> moryAllocationLib.inf
> 
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> 
> 
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Smm
> CpuExceptionHandlerLib.inf
> 
> +
> +
> SmmSmramSaveStateLib|UefiCpuPkg/Library/SmmSmramSaveStateLib/Am
> dSmmSmr
> + amSaveStateLib.inf
> 
> 
> 
>  [LibraryClasses.common.MM_STANDALONE]
> 
> 
> MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/Stan
> daloneMmServicesTableLib.inf
> 
> @@ -191,6 +193,7 @@ [Components.IA32, Components.X64]
>  
> 
> 
> UnitTestResultReportLib|UnitTestFrameworkPkg/Library/UnitTestResultRep
> ortLib/UnitTestResultReportLibConOut.inf
> 
>}
> 
> +
> UefiCpuPk

Re: [edk2-devel] [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Kirill A. Shutemov

On Fri, Jan 13, 2023 at 09:29:26PM +, Dionna Glaze wrote:
> This patch depends on Kirill A. Shutemov's series
> 
> [PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
> 
> The UEFI v2.9 specification includes a new memory type to be used in
> environments where the OS must accept memory that is provided from its
> host. Before the introduction of this memory type, all memory was
> accepted eagerly in the firmware. In order for the firmware to safely
> stop accepting memory on the OS's behalf, the OS must affirmatively
> indicate support to the firmware.

I think it is a bad idea.

This approach breaks use case with a bootloader between BIOS and OS.
As the bootloader does ExitBootServices() it has to make the call on
behalf of OS when it has no idea if the OS supports unaccepted.

Note that kexec is such use-case: original kernel has to make a decision
on whether it is okay to leave some memory unaccepted for the new kernel.

And we add this protocol to address very temporary problem: once
unaccepted memory support get upstream it is just a dead weight.

Let's not do this.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98611): https://edk2.groups.io/g/devel/message/98611
Mute This Topic: https://groups.io/mt/96256524/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Kirill A. Shutemov

On Mon, Jan 16, 2023 at 02:11:26PM +0100, Ard Biesheuvel wrote:
> On Mon, 16 Jan 2023 at 13:31, Kirill A. Shutemov  wrote:
> >
> > On Mon, Jan 16, 2023 at 11:56:48AM +0100, Gerd Hoffmann wrote:
> > > On Sat, Jan 14, 2023 at 01:20:24AM +0300, Kirill A. Shutemov wrote:
> > > > On Fri, Jan 13, 2023 at 09:29:26PM +, Dionna Glaze wrote:
> > > > > This patch depends on Kirill A. Shutemov's series
> > > > >
> > > > > [PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
> > > > >
> > > > > The UEFI v2.9 specification includes a new memory type to be used in
> > > > > environments where the OS must accept memory that is provided from its
> > > > > host. Before the introduction of this memory type, all memory was
> > > > > accepted eagerly in the firmware. In order for the firmware to safely
> > > > > stop accepting memory on the OS's behalf, the OS must affirmatively
> > > > > indicate support to the firmware.
> > > >
> > > > I think it is a bad idea.
> > > >
> > > > This approach breaks use case with a bootloader between BIOS and OS.
> > > > As the bootloader does ExitBootServices() it has to make the call on
> > > > behalf of OS when it has no idea if the OS supports unaccepted.
> > >
> > > Nothing breaks, it'll error on the safe side.  If the protocol callback
> > > is not called the firmware will simply accept all memory.  The guest OS
> > > will only see unaccepted memory if it explicitly asked for it (assuming
> > > the firmware wants know to support both cases, of course the firmware
> > > could also enforce the one or the other and just not offer the
> > > protocol).
> >
> > How bootloader suppose to know if OS will ask for unaccepted memory?
> > It can't. It means the use-case with bootloader cannot ever use
> > unaccepted memory. That's broken design.
> >
> 
> I still don't understand why we need to support every imaginable
> combination of firmware, bootloader and OS. Unaccepted memory only
> exists on a special kind of virtual machine, which provides very
> little added value unless you opt into the security and attestation
> features, which are all heavily based on firmware protocols. So why
> should care about a EFI-aware bootloader calling ExitBootServices()
> and subsequently doing a legacy boot of Linux on such systems?

Why break what works? Some users want it.

This patch adds complexity, breaks what works and the only upside will
turn into a dead weight soon.

There's alternative to add option to instruct firmware to accept all
memory from VMM side. It will serve legacy OS that doesn't know about
unaccepted memory and it is also can be use by latency-sensitive users
later on (analog of qemu -mem-prealloc).

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98614): https://edk2.groups.io/g/devel/message/98614
Mute This Topic: https://groups.io/mt/96256524/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Dave Hansen

On 1/16/23 02:56, Gerd Hoffmann wrote:
>> And we add this protocol to address very temporary problem: once
>> unaccepted memory support get upstream it is just a dead weight.
> Maybe, maybe not.  unaccepted memory support has a Kconfig switch after
> all.  If we figure in 3-5 years that all distros have enabled it anyway
> we can drop it again.  For the transition period it will surely be
> useful.

I agree with Kirill here.

Having unaccepted memory *AND* this firmware-driven feature really is
just implementing the same thing twice.

I'd much rather have the Kconfig option forced on for all guests that
*might* need unaccepted memory support than carry redundant implementations.

Also, _if_ we allow folks to turn the Kconfig off and get access to all
their memory, they might get used to that.  Removing this firmware
interface from the kernel in a few years could be viewed as a
regression.  Then, we'll be stuck with this forever.

In any case, the firmware side of things didn't seem like _that_ much
code.  So, I'm not protesting *that* strongly.  But, I also don't
believe for a second that this is going to be removed in 3-5 years.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98616): https://edk2.groups.io/g/devel/message/98616
Mute This Topic: https://groups.io/mt/96256524/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Kirill A. Shutemov

On Mon, Jan 16, 2023 at 11:56:48AM +0100, Gerd Hoffmann wrote:
> On Sat, Jan 14, 2023 at 01:20:24AM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jan 13, 2023 at 09:29:26PM +, Dionna Glaze wrote:
> > > This patch depends on Kirill A. Shutemov's series
> > > 
> > > [PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
> > > 
> > > The UEFI v2.9 specification includes a new memory type to be used in
> > > environments where the OS must accept memory that is provided from its
> > > host. Before the introduction of this memory type, all memory was
> > > accepted eagerly in the firmware. In order for the firmware to safely
> > > stop accepting memory on the OS's behalf, the OS must affirmatively
> > > indicate support to the firmware.
> > 
> > I think it is a bad idea.
> > 
> > This approach breaks use case with a bootloader between BIOS and OS.
> > As the bootloader does ExitBootServices() it has to make the call on
> > behalf of OS when it has no idea if the OS supports unaccepted.
> 
> Nothing breaks, it'll error on the safe side.  If the protocol callback
> is not called the firmware will simply accept all memory.  The guest OS
> will only see unaccepted memory if it explicitly asked for it (assuming
> the firmware wants know to support both cases, of course the firmware
> could also enforce the one or the other and just not offer the
> protocol).

How bootloader suppose to know if OS will ask for unaccepted memory?
It can't. It means the use-case with bootloader cannot ever use
unaccepted memory. That's broken design.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


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

Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior

2023-01-16 Thread Dave Hansen

On 1/13/23 09:06, Dionna Amalie Glaze wrote:
> Thanks for your perspective, Dave. From what I understand,
> distributions lag behind, user kernel configurations can be varied,
> and Kirill's patch set is still untested with regards to memory
> latency of workloads. We may yet see folks opt for a slow boot for
> better latency. This protocol is for safety purposes, since "hope is
> not a strategy" as is commonly said at Google.

Hold on a sec though.

There are two basic strategies here:

 1. Boot to userspace as fast as possible without accepting memory.
This runs apps more sooner after boot, but exposes those apps to the
latency of memory acceptance.

 2. Accept all memory before running userspace.  This makes the boot
slower but means that apps never see memory acceptance latency.

Kirill's _initial_ patch does #1.  If anyone desperately wants #2, they
have mechanisms available to make a kernel with only #1 approximate #2.
A user on that kernel could allocate and memset()ing a bunch of memory.
Or, they could have a firmware stub accept the memory before booting the
real kernel.

It also doesn't rule out having a runtime knob or a boot parameter
implement #2.  It's not a lot of code, but it involves new ABI.

However, *NONE* of this points me in the direction of saying that we
should have an OS/firmware protocol to negotiate whether the firmware or
OS does page acceptance other than the existing UEFI memory map bit.

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

[edk2-devel] [PATCH V3 4/4] OvmfPkg/PeilessStartupLib: Find NCCFV in non-td guest

2023-01-16 Thread Min Xu

From: Min M Xu 

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

As described in BZ#4152, NCCFV includes the DXE phase drivers for non-cc
guest. PeilessStartupLib is updated to find NCCFV for non-cc guest.

Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/Library/PeilessStartupLib/DxeLoad.c   | 134 +-
 .../PeilessStartupInternal.h  |   6 +
 .../PeilessStartupLib/PeilessStartupLib.inf   |   1 +
 3 files changed, 140 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/PeilessStartupLib/DxeLoad.c 
b/OvmfPkg/Library/PeilessStartupLib/DxeLoad.c
index 6e79c3084672..4b1fefd452dc 100644
--- a/OvmfPkg/Library/PeilessStartupLib/DxeLoad.c
+++ b/OvmfPkg/Library/PeilessStartupLib/DxeLoad.c
@@ -22,6 +22,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 
 #define STACK_SIZE  0x2
+extern EFI_GUID  gEfiNonCcFvGuid;
 
 /**
Transfers control to DxeCore.
@@ -136,6 +137,133 @@ FindDxeCore (
   return Status;
 }
 
+/**
+ * This is a FFS_CHECK_SECTION_HOOK which is defined by caller to check
+ * if the section is an EFI_SECTION_FIRMWARE_VOLUME_IMAGE and if it is
+ * a NonCc FV.
+ *
+ * @param Section   The section in which we're checking for the NonCc FV.
+ * @return EFI_STATUS   The section is the NonCc FV.
+ */
+EFI_STATUS
+EFIAPI
+CheckSectionHookForDxeNonCc (
+  IN EFI_COMMON_SECTION_HEADER  *Section
+  )
+{
+  VOID *Buffer;
+  EFI_STATUS   Status;
+  EFI_FV_INFO  FvImageInfo;
+
+  if (Section->Type != EFI_SECTION_FIRMWARE_VOLUME_IMAGE) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (IS_SECTION2 (Section)) {
+Buffer = (VOID *)((UINT8 *)Section + sizeof (EFI_COMMON_SECTION_HEADER2));
+  } else {
+Buffer = (VOID *)((UINT8 *)Section + sizeof (EFI_COMMON_SECTION_HEADER));
+  }
+
+  ZeroMem (&FvImageInfo, sizeof (FvImageInfo));
+  Status = FfsGetVolumeInfo ((EFI_PEI_FV_HANDLE)(UINTN)Buffer, &FvImageInfo);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "Cannot get volume info! %r\n", Status));
+return Status;
+  }
+
+  return CompareGuid (&FvImageInfo.FvName, &gEfiNonCcFvGuid) ? EFI_SUCCESS : 
EFI_NOT_FOUND;
+}
+
+/**
+ * Find the NonCc FV.
+ *
+ * @param FvInstanceThe FvInstance number.
+ * @return EFI_STATUS   Successfuly find the NonCc FV.
+ */
+EFI_STATUS
+EFIAPI
+FindDxeNonCc (
+  IN INTN  FvInstance
+  )
+{
+  EFI_STATUS   Status;
+  EFI_PEI_FV_HANDLEVolumeHandle;
+  EFI_PEI_FILE_HANDLE  FileHandle;
+  EFI_PEI_FV_HANDLEFvImageHandle;
+  EFI_FV_INFO  FvImageInfo;
+  UINT32   FvAlignment;
+  VOID *FvBuffer;
+
+  FileHandle = NULL;
+
+  //
+  // Caller passed in a specific FV to try, so only try that one
+  //
+  Status = FfsFindNextVolume (FvInstance, &VolumeHandle);
+  ASSERT (Status == EFI_SUCCESS);
+
+  Status = FfsFindNextFile (EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE, 
VolumeHandle, &FileHandle);
+  ASSERT (FileHandle != NULL);
+
+  //
+  // Find FvImage in FvFile
+  //
+  Status = FfsFindSectionData (EFI_SECTION_FIRMWARE_VOLUME_IMAGE, 
CheckSectionHookForDxeNonCc, FileHandle, (VOID **)&FvImageHandle);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  //
+  // Collect FvImage Info.
+  //
+  ZeroMem (&FvImageInfo, sizeof (FvImageInfo));
+  Status = FfsGetVolumeInfo (FvImageHandle, &FvImageInfo);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // FvAlignment must be more than 8 bytes required by FvHeader structure.
+  //
+  FvAlignment = 1 << ((FvImageInfo.FvAttributes & EFI_FVB2_ALIGNMENT) >> 16);
+  if (FvAlignment < 8) {
+FvAlignment = 8;
+  }
+
+  //
+  // Check FvImage
+  //
+  if ((UINTN)FvImageInfo.FvStart % FvAlignment != 0) {
+FvBuffer = AllocateAlignedPages (EFI_SIZE_TO_PAGES 
((UINT32)FvImageInfo.FvSize), FvAlignment);
+if (FvBuffer == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+
+CopyMem (FvBuffer, FvImageInfo.FvStart, (UINTN)FvImageInfo.FvSize);
+//
+// Update FvImageInfo after reload FvImage to new aligned memory
+//
+FfsGetVolumeInfo ((EFI_PEI_FV_HANDLE)FvBuffer, &FvImageInfo);
+  }
+
+  //
+  // Inform HOB consumer phase, i.e. DXE core, the existence of this FV
+  //
+  BuildFvHob ((EFI_PHYSICAL_ADDRESS)(UINTN)FvImageInfo.FvStart, 
FvImageInfo.FvSize);
+
+  //
+  // Makes the encapsulated volume show up in DXE phase to skip processing of
+  // encapsulated file again.
+  //
+  BuildFv2Hob (
+(EFI_PHYSICAL_ADDRESS)(UINTN)FvImageInfo.FvStart,
+FvImageInfo.FvSize,
+&FvImageInfo.FvName,
+&(((EFI_FFS_FILE_HEADER *)FileHandle)->Name)
+);
+
+  return Status;
+}
+
 /**
This function finds DXE Core in the firmware volume and transfer the 
control to
DXE core.
@@ -168,10 +296,14 @@ DxeLoadCore (
 return Status;
   }
 
+  if (!TdIsEnabled ()) {
+FindDxeNonCc (FvInstance);
+  }
+
   //
   // Load the DXE Core from a Firmware Volume.
   //
-  Status = FfsFindSectionData (EFI_SECTION_PE32, FileHandle, &PeCoffImage);

[edk2-devel] [PATCH V3 3/4] OvmfPkg/IntelTdx: Enable separate-fv in IntelTdx/IntelTdxX64.fdf

2023-01-16 Thread Min Xu

From: Min M Xu 

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

In current DXE FV there are 100+ drivers. Some of the drivers are not
used in Td guest. (Such as USB support drivers, network related drivers,
etc).

>From the security perspective if a driver is not used, we'd should prevent
it from being loaded / started. There are 2 benefits:
1. Reduce the attack surface
2. Improve the boot performance

So we separate DXEFV into 2 FVs: DXEFV and NCCFV. All the drivers which
are not needed by a Confidential Computing guest are moved from DXEFV
to NCCFV.

The following patch will find NCCFV for non-cc guest and build FVHob
so that NCCFV drivers can be loaded / started in DXE phase.

Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc |  11 ++-
 OvmfPkg/IntelTdx/IntelTdxX64.fdf | 112 ---
 2 files changed, 83 insertions(+), 40 deletions(-)

diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 81511e3556a6..0f1e970fbbb3 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -31,6 +31,11 @@
   #
   DEFINE SECURE_BOOT_ENABLE  = FALSE
 
+  #
+  # Shell can be useful for debugging but should not be enabled for production
+  #
+  DEFINE BUILD_SHELL = TRUE
+
   #
   # Device drivers
   #
@@ -204,7 +209,9 @@
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
+!if $(BUILD_SHELL) == TRUE
   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+!endif
   ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
@@ -720,12 +727,13 @@
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
   OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
 !endif
+!if $(BUILD_SHELL) == TRUE
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
@@ -744,6 +752,7 @@
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
   }
+!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
index a57bbcee8986..73dffc104301 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
@@ -97,10 +97,14 @@ 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCp
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-0x10|0xC0
+0x10|0x70
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
+0x80|0x50
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeNonCcFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeNonCcFvSize
+FV = NCCFV
+
 
##
 # Set the SEV-ES specific work area PCDs
 #
@@ -183,7 +187,6 @@ INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
 
 INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
-INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
@@ -201,17 +204,6 @@ INF  
PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
 INF  OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
 INF  OvmfPkg/Virtio10Dxe/Virtio10.inf
 INF  OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
-INF  OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-INF  OvmfPkg/VirtioRngDxe/VirtioRng.inf
-!if $(PVSCSI_ENABLE) == TRUE
-INF  OvmfPkg/PvScsiDxe/PvScsiDxe.inf
-!endif
-!if $(MPT_SCSI_ENABLE) == TRUE
-INF  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
-!endif
-!if $(LSI_SCSI_ENABLE) == TRUE
-INF  OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf
-!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF  
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
@@ -222,19 +214,14 @@ INF  
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDx
 INF  MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 INF  MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
-INF  MdeModulePkg/Universal/Console/GraphicsConsol

[edk2-devel] [PATCH V3 2/4] OvmfPkg: Add PCDs/GUID for NCCFV

2023-01-16 Thread Min Xu

From: Min M Xu 

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

NCCFV refers to Non-Confidential-Computing-FV. It includes the DXE phase
drivers which are only loaded/started in non-cc guest. Hence the
PCDs / GUID for NCCFV are defined in OvmfPkg.dec.

Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/OvmfPkg.dec | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index e07546f4a701..1b521f2604ff 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -156,6 +156,7 @@
   gUefiOvmfPkgPlatformInfoGuid  = {0xdec9b486, 0x1f16, 0x47c7, {0x8f, 
0x68, 0xdf, 0x1a, 0x41, 0x88, 0x8b, 0xa5}}
   gVMMBootOrderGuid = {0x668f4529, 0x63d0, 0x4bb5, {0xb6, 
0x5d, 0x6f, 0xbb, 0x9d, 0x36, 0xa4, 0x4a}}
   gUefiOvmfPkgTdxAcpiHobGuid= {0x6a0c5870, 0xd4ed, 0x44f4, {0xa1, 
0x35, 0xdd, 0x23, 0x8b, 0x6f, 0x0c, 0x8d}}
+  gEfiNonCcFvGuid   = {0xae047c6d, 0xbce9, 0x426c, {0xae, 
0x03, 0xa6, 0x8e, 0x3b, 0x8a, 0x04, 0x88}}
 
 [Ppis]
   # PPI whose presence in the PPI database signals that the TPM base address
@@ -192,6 +193,8 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize|0x0|UINT32|1
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|0x0|UINT32|0x15
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize|0x0|UINT32|0x16
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeNonCcFvBase|0x0|UINT32|0x6a
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeNonCcFvSize|0x0|UINT32|0x6b
 
   ## This flag is used to control the destination port for 
PlatformDebugLibIoPort
   gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0x402|UINT16|4
-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98607): https://edk2.groups.io/g/devel/message/98607
Mute This Topic: https://groups.io/mt/96319663/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/4] EmbeddedPkg/PrePiLib: Add FFS_CHECK_SECTION_HOOK when finding section

2023-01-16 Thread Min Xu

From: Min M Xu 

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

EmbeddedPkg/PrePiLib provides the service of finding sections based on
the input SectionType. But sometimes there maybe multiple sections
with the same SectionType. FFS_CHECK_SECTION_HOOK is a hook which can
be called to do additional check.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Abner Chang 
Cc: Daniel Schaefer 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Acked-by: Ard Biesheuvel 
Signed-off-by: Min Xu 
---
 EmbeddedPkg/Include/Library/PrePiLib.h  | 23 +++---
 EmbeddedPkg/Library/PrePiLib/FwVol.c| 42 ++---
 EmbeddedPkg/Library/PrePiLib/PrePiLib.c |  2 +-
 3 files changed, 49 insertions(+), 18 deletions(-)

diff --git a/EmbeddedPkg/Include/Library/PrePiLib.h 
b/EmbeddedPkg/Include/Library/PrePiLib.h
index 3741b08c4478..f60b6678185a 100644
--- a/EmbeddedPkg/Include/Library/PrePiLib.h
+++ b/EmbeddedPkg/Include/Library/PrePiLib.h
@@ -52,11 +52,23 @@ FfsFindNextFile (
   IN OUT EFI_PEI_FILE_HANDLE  *FileHandle
   );
 
+/**
+ * This is a hook which is used to check if the section is the target one.
+ *
+ */
+typedef
+EFI_STATUS
+(EFIAPI *FFS_CHECK_SECTION_HOOK)(
+  IN EFI_COMMON_SECTION_HEADER *Section
+  );
+
 /**
   This service enables discovery sections of a given type within a valid FFS 
file.
+  Caller also can provide a SectionCheckHook to do additional checking.
 
-  @param  SearchTypeThe value of the section type to find.
-  @param  FfsFileHeader A pointer to the file header that contains the 
set of sections to
+  @param  SectionType   The value of the section type to find.
+  @param  SectionCheckHook  A hook which can check if the section is the 
target one.
+  @param  FileHeaderA pointer to the file header that contains the 
set of sections to
 be searched.
   @param  SectionData   A pointer to the discovered section, if 
successful.
 
@@ -67,9 +79,10 @@ FfsFindNextFile (
 EFI_STATUS
 EFIAPI
 FfsFindSectionData (
-  IN EFI_SECTION_TYPE SectionType,
-  IN EFI_PEI_FILE_HANDLE  FileHandle,
-  OUT VOID**SectionData
+  IN EFI_SECTION_TYPESectionType,
+  IN FFS_CHECK_SECTION_HOOK  SectionCheckHook,
+  IN EFI_PEI_FILE_HANDLE FileHandle,
+  OUT VOID   **SectionData
   );
 
 /**
diff --git a/EmbeddedPkg/Library/PrePiLib/FwVol.c 
b/EmbeddedPkg/Library/PrePiLib/FwVol.c
index 0a6d6925b7ea..778d8b13c33b 100644
--- a/EmbeddedPkg/Library/PrePiLib/FwVol.c
+++ b/EmbeddedPkg/Library/PrePiLib/FwVol.c
@@ -264,16 +264,18 @@ FindFileEx (
   Go through the file to search SectionType section,
   when meeting an encapsuled section.
 
-  @param  SectionType  - Filter to find only section of this type.
-  @param  Section  - From where to search.
-  @param  SectionSize  - The file size to search.
-  @param  OutputBuffer - Pointer to the section to search.
+  @param  SectionType   - Filter to find only section of this type.
+  @param  SectionCheckHook  - A hook which can check if the section is the 
target one.
+  @param  Section   - From where to search.
+  @param  SectionSize   - The file size to search.
+  @param  OutputBuffer  - Pointer to the section to search.
 
   @retval EFI_SUCCESS
 **/
 EFI_STATUS
 FfsProcessSection (
   IN EFI_SECTION_TYPE   SectionType,
+  IN FFS_CHECK_SECTION_HOOK SectionCheckHook,
   IN EFI_COMMON_SECTION_HEADER  *Section,
   IN UINTN  SectionSize,
   OUT VOID  **OutputBuffer
@@ -292,7 +294,9 @@ FfsProcessSection (
   UINT32AuthenticationStatus;
   CHAR8 *CompressedData;
   UINT32CompressedDataLength;
+  BOOLEAN   Found;
 
+  Found = FALSE;
   *OutputBuffer = NULL;
   ParsedLength  = 0;
   Status= EFI_NOT_FOUND;
@@ -302,13 +306,23 @@ FfsProcessSection (
 }
 
 if (Section->Type == SectionType) {
-  if (IS_SECTION2 (Section)) {
-*OutputBuffer = (VOID *)((UINT8 *)Section + sizeof 
(EFI_COMMON_SECTION_HEADER2));
+  if (SectionCheckHook != NULL) {
+Found = SectionCheckHook (Section) == EFI_SUCCESS;
   } else {
-*OutputBuffer = (VOID *)((UINT8 *)Section + sizeof 
(EFI_COMMON_SECTION_HEADER));
+Found = TRUE;
   }
 
-  return EFI_SUCCESS;
+  if (Found) {
+if (IS_SECTION2 (Section)) {
+  *OutputBuffer = (VOID *)((UINT8 *)Section + sizeof 
(EFI_COMMON_SECTION_HEADER2));
+} else {
+  *OutputBuffer = (VOID *)((UINT8 *)Section + sizeof 
(EFI_COMMON_SECTION_HEADER));
+}
+
+return EFI_SUCCESS;
+  } else {
+goto CheckNextSection;
+  }
 } else if ((Section->Type == EFI_SECTION_COMPRESSION) || (Section->Type == 
EFI_SECTION_GUID_DEFINED)) {
   if (Section->Type == EFI_SECTION_COMPRESSION) {
 if (IS_SECTION2 (Section)) {
@@ -

[edk2-devel] [PATCH V3 0/4] Introduce Separate-Fv in OvmfPkg/IntelTdx

2023-01-16 Thread Min Xu

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

In current DXE FV there are 100+ drivers. Some of the drivers are not
used in Td guest. (Such as USB support drivers, network related
drivers, etc).

>From the security perspective if a driver is not used, we should prevent
it from being loaded/started. There are 2 benefits: 
1. Reduce the attack surface
2. Improve the boot performance

So we introduce Separate-Fv which separates DXEFV into 2 FVs: DXEFV
and NCCFV. All the drivers which are not needed by a Confidential
Computing guest are moved from DXEFV to NCCFV.

When booting a CC guest only the drivers in DXEFV will be loaded and
started. For a Non-CC guest both DXEFV and NCCFV drivers will be
loaded and started.

Patch#1 updates EmbeddedPkg/PrePiLib with FFS_CHECK_SECTION_HOOK.
Patch#2 adds PCDs/GUID for NCCFV.
Patch#3 moves cc-unused drivers to NCCFV.
Patch#4 update PeilessStartupLib to find NCCFV for non-cc guest.

Code: https://github.com/mxu9/edk2/tree/Separate-Fv.v3

v3 changes:
 - Rebase the code base to 7cd55f3009.

v2 changes:
 - Move shell from DXEFV to NCCFV.
 - Wrap shell into "!if $(BUILD_SHELL) == TRUE" for consistency with
   the other ovmf build variants.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Abner Chang 
Cc: Daniel Schaefer 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 

Min M Xu (4):
  EmbeddedPkg/PrePiLib: Add FFS_CHECK_SECTION_HOOK when finding section
  OvmfPkg: Add PCDs/GUID for NCCFV
  OvmfPkg/IntelTdx: Enable separate-fv in IntelTdx/IntelTdxX64.fdf
  OvmfPkg/PeilessStartupLib: Find NCCFV in non-td guest

 EmbeddedPkg/Include/Library/PrePiLib.h|  23 ++-
 EmbeddedPkg/Library/PrePiLib/FwVol.c  |  42 --
 EmbeddedPkg/Library/PrePiLib/PrePiLib.c   |   2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.dsc  |  11 +-
 OvmfPkg/IntelTdx/IntelTdxX64.fdf  | 112 ++-
 OvmfPkg/Library/PeilessStartupLib/DxeLoad.c   | 134 +-
 .../PeilessStartupInternal.h  |   6 +
 .../PeilessStartupLib/PeilessStartupLib.inf   |   1 +
 OvmfPkg/OvmfPkg.dec   |   3 +
 9 files changed, 275 insertions(+), 59 deletions(-)

-- 
2.29.2.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98605): https://edk2.groups.io/g/devel/message/98605
Mute This Topic: https://groups.io/mt/96319661/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Lendacky, Thomas via groups.io


On 1/16/23 15:22, Dave Hansen wrote:

On 1/16/23 02:56, Gerd Hoffmann wrote:

And we add this protocol to address very temporary problem: once
unaccepted memory support get upstream it is just a dead weight.

Maybe, maybe not.  unaccepted memory support has a Kconfig switch after
all.  If we figure in 3-5 years that all distros have enabled it anyway
we can drop it again.  For the transition period it will surely be
useful.


I agree with Kirill here.

Having unaccepted memory *AND* this firmware-driven feature really is
just implementing the same thing twice.


I'm not sure I follow you. This feature merely tells the firmware whether 
or not the OS supports unaccepted memory, which then tells the firmware 
whether it needs to accept the memory or whether the kernel can.


We have had SNP guest support since 5.19 without support for unaccepted 
memory. Imagine now using a newer OVMF that can support unaccepted memory. 
How does the firmware know whether it must accept all the memory or 
whether it can advertise unaccepted memory. By having the kernel call this 
boot service protocol once support for unaccepted memory is in place, the 
firmware now knows that it need not accept all the memory.


Thanks,
Tom



I'd much rather have the Kconfig option forced on for all guests that
*might* need unaccepted memory support than carry redundant implementations.

Also, _if_ we allow folks to turn the Kconfig off and get access to all
their memory, they might get used to that.  Removing this firmware
interface from the kernel in a few years could be viewed as a
regression.  Then, we'll be stuck with this forever.

In any case, the firmware side of things didn't seem like _that_ much
code.  So, I'm not protesting *that* strongly.  But, I also don't
believe for a second that this is going to be removed in 3-5 years.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98604): https://edk2.groups.io/g/devel/message/98604
Mute This Topic: https://groups.io/mt/96256524/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/1] SecurityPkg/AuthVariableLib: Check SHA-256 OID with ContentInfo present

2023-01-16 Thread Jan Bobek via groups.io

> Hi
> That is good catch!
> My apology to miss it before.
>
> 1) Please file a bugzilla (https://bugzilla.tianocore.org/) to record the 
> issue and associate to the patch.

Filed bug 4305 [1]. Sorry for the delay, I didn't get my bugzilla
credentials until late last week.

> 2) Would you please share with us that how you discover the issue?
> For example, any real use case to include ContentInfo? If yes, please share a 
> URL.
> Or this is just a purely spec compliance fix ?
>
> 3) Please describe how you validate the fix.
> If possible, would you please share your test case?

I believe both of these answered / included in the bug description.

> 4) Since the new code is handling ContentInfo structure is present, I believe 
> we need also check if the ContentInfo structure is valid.
> For example:
> 
> c SignedData.contentInfo.contentType shall be set to id-data
> d SignedData.contentInfo.content shall be absent
> 
> What do you think?

I think you're talking about the ContentInfo structure that's part of
the SignedData structure, but the real problem is with ContentInfo
structure that _wraps_ the SignedData structure. More info in the bug
description.

Also, is it customary to continue the discussion here on edk2-devel or
in the bug comments on bugzilla?

-Jan

References:
1. https://bugzilla.tianocore.org/show_bug.cgi?id=4305


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98603): https://edk2.groups.io/g/devel/message/98603
Mute This Topic: https://groups.io/mt/95419835/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, continuous integration, testing, and you

2023-01-16 Thread Michael D Kinney

Hi Sean,

I moved this week's meeting to 10am pacific on Tuesday Jan 17th.

Mike


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Pedro Falcato
> Sent: Friday, January 13, 2023 6:54 PM
> To: Sean Brogan 
> Cc: Théo Jehl ; devel@edk2.groups.io; Marvin Häuser 
> ; Oram, Isaac W
> 
> Subject: Re: [edk2-devel] edk2-platforms, continuous integration, testing, 
> and you
> 
> On Fri, Jan 13, 2023 at 10:32 PM Sean Brogan  wrote:
> >
> > how about 10am pacific Jan 17th.  should be 7pm your time?
> >
> > Thanks
> >
> > Sean
> >
> Hi Sean,
> 
> Should work for me (6pm btw, GMT here).
> 
> Thanks,
> Pedro
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98602): https://edk2.groups.io/g/devel/message/98602
Mute This Topic: https://groups.io/mt/96060477/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/1] OvmfPkg/PlatformInitLib: pass through reservations from qemu

2023-01-16 Thread Lendacky, Thomas via groups.io


On 1/16/23 11:09, Ard Biesheuvel wrote:

On Thu, 12 Jan 2023 at 18:09, Tom Lendacky  wrote:


On 12/6/22 23:32, Gerd Hoffmann via groups.io wrote:

qemu uses the etc/e820 fw_cfg file not only for memory, but
also for reservations.  Handle reservations by adding resource
descriptor hobs for them.

A typical qemu configuration has a small reservation between
lapic and flash:

# sudo cat /proc/iomem
[ ... ]
fee0-fee00fff : Local APIC
feffc000-feff : Reserved  <= HERE
ffc0- : Reserved
[ ... ]

Signed-off-by: Gerd Hoffmann 


On newer versions of Qemu, this patch causes a boot failure on my
AMD system with the following output:

...
PciHostBridgeUtilityInitRootBridge: populated root bus 0, with room for 255 
subordinate bus(es)
RootBridge: PciRoot(0x0)
Support/Attr: 70069 / 70069
  DmaAbove4G: No
NoExtConfSpace: No
   AllocAttr: 3 (CombineMemPMem Mem64Decode)
 Bus: 0 - FF Translation=0
  Io: 6000 -  Translation=0
 Mem: C000 - FBFF Translation=0
  MemAbove4G: E0 - FF Translation=0
PMem:  - 0 Translation=0
 PMemAbove4G:  - 0 Translation=0
PciHostBridgeDxe: IntersectMemoryDescriptor: desc [FD, 100) 
type 1 cap 80026000 conflicts with aperture [E0, 100) 
cap 1

ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [PciHostBridgeDxe] 
/root/kernels/ovmf-build-X64/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(550):
 !(((INTN)(RETURN_STATUS)(Status)) < 0)

Doing some bisecting, before Qemu patch

 8504f129450b ("i386/pc: relocate 4g start to 1T where applicable")

this issue wasn't observed. And before this OVMF patch, the newer version
of Qemu doesn't have an issue.

Also, if I add host-phys-bits=true to the Qemu -cpu parameter, then
the issue isn't observed regardless of Qemu/OVMF level.

I'm hoping someone has an understanding of what is going on and what
can be done to fix it.



Could someone look into this please? Gerd?


Looks like Gerd is already on it.

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

Thanks,
Tom




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98601): https://edk2.groups.io/g/devel/message/98601
Mute This Topic: https://groups.io/mt/95510762/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Dionna Glaze via groups.io

> > I still don't understand why we need to support every imaginable
> > combination of firmware, bootloader and OS. Unaccepted memory only
> > exists on a special kind of virtual machine, which provides very
> > little added value unless you opt into the security and attestation
> > features, which are all heavily based on firmware protocols. So why
> > should care about a EFI-aware bootloader calling ExitBootServices()
> > and subsequently doing a legacy boot of Linux on such systems?
>
> Why break what works? Some users want it.
>

The users that want legacy boot features will not be broken, they'll
only get a safe view of the memory map. I don't think it's right to
choose unsafe behavior for a legacy setup.

> This patch adds complexity, breaks what works and the only upside will
> turn into a dead weight soon.
>
> There's alternative to add option to instruct firmware to accept all
> memory from VMM side. It will serve legacy OS that doesn't know about
> unaccepted memory and it is also can be use by latency-sensitive users
> later on (analog of qemu -mem-prealloc).
>

This means that users of a distro that has not enabled unaccepted
memory support cannot simply start a VM with the usual command, but
instead have to know a baroque extra flag to get access to all the
memory that they configured the machine (and for a CSP customer, paid
for). That's not a good experience.

With GCE at least, you can't (shouldn't) associate the boot feature
flag with a disk image because disks are mutable. If a customer
upgrades their kernel after initially starting their VM, they can't
remove the flag due to the way image annotations work.

All of this headache goes away by adopting a small patch to the kernel
that calls a 0-ary protocol interface and keeping safe acceptance
behavior in the firmware. I think Gerd is right here that we should
treat it as a transition feature that we can remove later.

> --
>   Kiryl Shutsemau / Kirill A. Shutemov



-- 
-Dionna Glaze, PhD (she/her)


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

Re: [edk2-devel] [PATCH v4 2/3] ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls

2023-01-16 Thread Rebecca Cran


On 1/12/23 19:01, Kun Qin wrote:


On 1/4/2023 7:37 AM, Rebecca Cran wrote:

+  if (WaitEvent != NULL) {
+    // Non Blocking
+    if (Finished != NULL) {
+  mCpuMpData.SingleApFinished = Finished;
+  *Finished   = FALSE;
+    }
+
+    mCpuMpData.WaitEvent = WaitEvent;
[KQ-3] Similar to the above [KQ] comment, for a wait event on the single 
AP, I think there should be a designated

wait event for each CPU available?


Yes! I've made that change in the v5 patch series.

+    Status = gBS->SetTimer (CpuData->CheckThisAPEvent, TimerCancel, 
0);
[KQ-3] Should we leave this timer keep checking the status of this AP 
even the time is up? Otherwise, there will
still be no mechanism to recover the CPU state to "Idle" if it ever 
times out and this CPU is essentially unusable for

the rest of this boot in UEFI.


I think I've fixed this by allowing CpuStateFinished as a starting 
state, or resetting CpuStateFinished back to CpuStateIdle (depending on 
the function being called).



+    if (mCpuMpData.WaitEvent != NULL) {
[KQ-3] The same idea would apply that the event being signaled should be 
per CPU specific, instead

of the common event for "start all APs" call.

+  Status = gBS->SignalEvent (mCpuMpData.WaitEvent);
[KQ-3] Then we probably want to set this to NULL after signalling this 
event, just to be on the safe side.


Good point.

--
Rebecca Cran


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

Re: [edk2-devel] [PATCH v4 2/3] ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls

2023-01-16 Thread Rebecca Cran


On 1/6/23 15:16, Kun Qin wrote:


+  // Blocking
+  while (TRUE) {
+    if (GetApState (CpuData) == CpuStateFinished) {
+  CpuData->State = CpuStateIdle;
+  break;
+    }
+
+    if ((TimeoutInMicroseconds != 0) && (Timeout == 0)) {
[KQ-2] This will make the core never being able to accept the subsequent 
start up calls due to this CPU data state will
never be updated to CpuStateIdle. If this AP completes the job after 
timeout, ApProcedure will only be able to transition
its state to CpuStateFinished. Should we add a timer (when there is a 
timeout period specified) and use CpuData->CheckThisAPEvent

to check and try to sync the CPU states for this case?


I think making a change to StartupThisAP and StartupAllAPs to reset any 
cores in CpuStateFinished back to CpuStateIdle should work?


--
Rebecca Cran


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

Re: [edk2-devel] [PATCH v4 2/3] ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls

2023-01-16 Thread Rebecca Cran


On 1/6/23 15:11, Kun Qin wrote:


On 1/4/2023 7:37 AM, Rebecca Cran wrote:

+  mCpuMpData.Timeout   = TimeoutInMicroseconds;
+  mCpuMpData.TimeTaken = 0;
+  mCpuMpData.TimeoutActive = (BOOLEAN)(TimeoutInMicroseconds != 0);


[KQ] Adding a timeout active flag is correct. However, I think each AP 
should have its own timeout related
data (that is Timeout, TimeTaken and TimeoutActive). Because i.e. if 
this StartupThisAp call is used on AP 1 in
a non-blocking mode, then a subsequent call on AP 2 is blocking, the 
common flag and timeout values will

impact both cores, and create unintended timeout events.


Good catch! Thanks, I've fixed it by adding per-CPU fields for 
StartupThisAP.


+  if (mCpuMpData.TimeoutActive && (mCpuMpData.TimeTaken > 
mCpuMpData.Timeout)) {
[KQ] Similar to the other comment, this is probably better using a 
per-core data to track elapsed time.
On a side note, if this timeout ever occurs, this core will never be 
usable in next StartupThisAp calls due
to this AP state will not be set to Idle even if the AP procedure is 
complete. Is this the intended behavior?


No, it wasn't. I've added code to StartupThisAP and StartupAllAPs to 
accept CpuStateFinished or reset CPUs in that state back to Idle.


--
Rebecca Cran


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

[edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

2023-01-16 Thread Oliver Steffen

Work around a bug in Ovmf that causes Ovmf to crash on startup
when running in recent versions of Qemu.  Setting the cpu model
to something older, for example "Broadwell" works around the issue.

Signed-off-by: Oliver Steffen 
---
 OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
b/OvmfPkg/PlatformCI/PlatformBuildLib.py
index bfef9849c749..93f7d7aa13d6 100644
--- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
+++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
@@ -194,6 +194,7 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
 cmd = "qemu-system-x86_64"
 args  = "-debugcon stdio"   # 
write messages to stdio
 args += " -global isa-debugcon.iobase=0x402"# 
debug messages out thru virtual io port
+args += " -cpu Broadwell"   # 
workaround Qvmf bug
 args += " -net none"# 
turn off network
 args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" # 
Mount disk with startup.nsh
 
-- 
2.39.0



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

[edk2-devel] [PATCH v11 16/17] CI: use ubuntu-22.04 image (Linux only)

2023-01-16 Thread Oliver Steffen

Use the same vm_image as the other Linux CIs in
ArmVirtPkg, EmulatorPkg, and OvmfPkg.
Switch over to ubuntu-22.04 form ubuntu-latest.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 .azurepipelines/Ubuntu-GCC5.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/Ubuntu-GCC5.yml b/.azurepipelines/Ubuntu-GCC5.yml
index 246e2d272e20..d93604fadbdb 100644
--- a/.azurepipelines/Ubuntu-GCC5.yml
+++ b/.azurepipelines/Ubuntu-GCC5.yml
@@ -20,7 +20,7 @@ jobs:
 - template: templates/pr-gate-build-job.yml
   parameters:
 tool_chain_tag: 'GCC5'
-vm_image: 'ubuntu-latest'
+vm_image: 'ubuntu-22.04'
 container: ${{ variables.default_linux_image }}
 arch_list: "IA32,X64,ARM,AARCH64,RISCV64,LOONGARCH64"
 usePythonVersion: ''  # use Python from the container image
-- 
2.39.0



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

[edk2-devel] [PATCH v11 14/17] EmulatorPgk: CI: use ubuntu-22.04 vm_image (Linux only)

2023-01-16 Thread Oliver Steffen

Switch over to ubuntu-22.04 as the vm_image for Linux CI jobs.  The
previously used ubuntu-18.04 which is not available anymore since
Dec 1st 2022.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 3861457ac70a..8af4c9c778cb 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -23,7 +23,7 @@ jobs:
   - job: Platform_CI
 variables:
   package: 'EmulatorPkg'
-  vm_image: 'ubuntu-18.04'
+  vm_image: 'ubuntu-22.04'
   should_run: false
   run_flags: "MAKE_STARTUP_NSH=TRUE"
 
-- 
2.39.0



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

[edk2-devel] [PATCH v11 15/17] OvmfPkg: CI: use ubuntu-22.04 vm_image (Linux only)

2023-01-16 Thread Oliver Steffen

Switch over to ubuntu-22.04 as the vm_image for Linux CI jobs.  The
previously used ubuntu-18.04 which is not available anymore since
Dec 1st 2022.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 85be431ca5e7..1cf9bdf8b9c2 100644
--- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -22,7 +22,7 @@ jobs:
   - job: Platform_CI
 variables:
   package: 'OvmfPkg'
-  vm_image: 'ubuntu-18.04'
+  vm_image: 'ubuntu-22.04'
   should_run: true
   run_flags: "MAKE_STARTUP_NSH=TRUE QEMU_HEADLESS=TRUE"
 
-- 
2.39.0



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

[edk2-devel] [PATCH v11 13/17] ArmVirtPkg: CI: use ubuntu-22.04 vm_image (Linux only)

2023-01-16 Thread Oliver Steffen

Switch over to ubuntu-22.04 as the vm_image for Linux CI jobs.  The
previously used ubuntu-18.04 which is not available anymore since
Dec 1st 2022.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index c0a2e0f20d4f..5fa7518d2c5e 100644
--- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -22,7 +22,7 @@ jobs:
   - job: Platform_CI
 variables:
   package: 'ArmVirtPkg'
-  vm_image: 'ubuntu-18.04'
+  vm_image: 'ubuntu-22.04'
   should_run: true
   run_flags: "MAKE_STARTUP_NSH=TRUE QEMU_HEADLESS=TRUE"
 
-- 
2.39.0



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

[edk2-devel] [PATCH v11 12/17] BaseTools: remove ext_dep files for gcc

2023-01-16 Thread Oliver Steffen

Remove BaseTools/Bin/gcc_*_ext_dep.yaml to stop
downloading gcc from external locations; use the
gcc provided by the container image instead.
The container image sets the variable GCC5_*_PREFIX accordingly.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml  | 21 --
 BaseTools/Bin/gcc_arm_linux_ext_dep.yaml  | 21 --
 ...gcc_loongarch64_unknown_linux_ext_dep.yaml | 22 ---
 .../Bin/gcc_riscv64_unknown_ext_dep.yaml  | 22 ---
 4 files changed, 86 deletions(-)
 delete mode 100644 BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml
 delete mode 100644 BaseTools/Bin/gcc_arm_linux_ext_dep.yaml
 delete mode 100644 BaseTools/Bin/gcc_loongarch64_unknown_linux_ext_dep.yaml
 delete mode 100644 BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml

diff --git a/BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml 
b/BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml
deleted file mode 100644
index ff8a9e868100..
--- a/BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-## @file
-# Download GCC AARCH64 compiler from Arm's release site
-# Set shell variable GCC5_AARCH64_INSTALL to this folder
-#
-# This is only downloaded when a build activates scope gcc_aarch64_linux
-#
-# Copyright (c) Microsoft Corporation.
-# SPDX-License-Identifier: BSD-2-Clause-Patent
-##
-{
-  "scope": "gcc_aarch64_linux",
-  "type": "web",
-  "name": "gcc_aarch64_linux",
-  "source": 
"https://developer.arm.com/-/media/Files/downloads/gnu/11.2-2022.02/binrel/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu.tar.xz";,
-  "version": "11.2-2022.02",
-  "sha256": "52dbac3eb71dbe0916f60a8c5ab9b7dc9b66b3ce513047baa09fae56234e53f3",
-  "compression_type": "tar",
-  "internal_path": "/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu/",
-  "flags": ["set_shell_var", ],
-  "var_name": "GCC5_AARCH64_INSTALL"
-}
diff --git a/BaseTools/Bin/gcc_arm_linux_ext_dep.yaml 
b/BaseTools/Bin/gcc_arm_linux_ext_dep.yaml
deleted file mode 100644
index 151cbfa4b532..
--- a/BaseTools/Bin/gcc_arm_linux_ext_dep.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-## @file
-# Download GCC ARM compiler from Arm's release site
-# Set shell variable GCC5_ARM_INSTALL to this folder
-#
-# This is only downloaded when a build activates scope gcc_arm_linux
-#
-# Copyright (c) Microsoft Corporation.
-# SPDX-License-Identifier: BSD-2-Clause-Patent
-##
-{
-  "scope": "gcc_arm_linux",
-  "type": "web",
-  "name": "gcc_arm_linux",
-  "source": 
"https://developer.arm.com/-/media/Files/downloads/gnu/11.2-2022.02/binrel/gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf.tar.xz";,
-  "version": "11.2-2022.02",
-  "sha256": "c254f7199261fe76c32ef42187502839bda7efad0a66646cf739d074eff45fad",
-  "compression_type": "tar",
-  "internal_path": "/gcc-arm-11.2-2022.02-x86_64-arm-none-linux-gnueabihf/",
-  "flags": ["set_shell_var", ],
-  "var_name": "GCC5_ARM_INSTALL"
-}
diff --git a/BaseTools/Bin/gcc_loongarch64_unknown_linux_ext_dep.yaml 
b/BaseTools/Bin/gcc_loongarch64_unknown_linux_ext_dep.yaml
deleted file mode 100644
index 6ebc93a07c66..
--- a/BaseTools/Bin/gcc_loongarch64_unknown_linux_ext_dep.yaml
+++ /dev/null
@@ -1,22 +0,0 @@
-## @file
-# Download GCC LoongArch64 compiler from LoongArch GitHub release site
-# Set shell variable GCC5_LOONGARCH64_INSTALL to this folder
-#
-# This is only downloaded when a build activates scope 
gcc_loongarch64_unknown_linux
-#
-# Copyright (c) Microsoft Corporation.
-# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
reserved.
-# SPDX-License-Identifier: BSD-2-Clause-Patent
-##
-{
-  "scope": "gcc_loongarch64_unknown_linux",
-  "type": "web",
-  "name": "gcc_loongarch64_unknown_linux",
-  
"source":"https://github.com/loongson/build-tools/releases/download/2022.09.06/loongarch64-clfs-6.3-cross-tools-c-only.tar.xz";,
-  "version": "13.0.0",
-  "sha256":"744cbb50c6ef07c96551bddf07a8b85cee3250bb18b6040f6ed051e389514951",
-  "compression_type": "tar",
-  "internal_path": "/cross-tools/",
-  "flags": ["set_shell_var", ],
-  "var_name": "GCC5_LOONGARCH64_INSTALL"
-}
diff --git a/BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml 
b/BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml
deleted file mode 100644
index 8abbcd7ba040..
--- a/BaseTools/Bin/gcc_riscv64_unknown_ext_dep.yaml
+++ /dev/null
@@ -1,22 +0,0 @@
-## @file
-# Download GCC RISCV64 compiler from RISC-V Organization release site
-# Set shell variable GCC5_RISCV64_INSTALL to this folder
-#
-# This is only downloaded when a build activates scope gcc_riscv64_unknown
-#
-# Copyright (c) Microsoft Corporation.
-# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
-# SPDX-License-Identifier: BSD-2-Clause-Patent
-##
-{
-  "scope": "gcc_riscv64_unknown",
-  "type": "web",
-  "name": "gcc_riscv64_unknown",
-  "source": 
"https://raw.githubusercontent.com/riscv/riscv-uefi-edk2-docs/master/gcc-riscv-ed

[edk2-devel] [PATCH v11 09/17] EmulatorPkg: CI: Use Fedora 35 container (Linux only)

2023-01-16 Thread Oliver Steffen

Run the Linux jobs of the EmulatorPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
 EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index a32c57d4aab4..3861457ac70a 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -79,6 +79,8 @@ jobs:
 pool:
   vmImage: $(vm_image)
 
+container: ${{ variables.default_linux_image }}
+
 steps:
 - template: ../../../.azurepipelines/templates/platform-build-run-steps.yml
   parameters:
@@ -89,4 +91,4 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
-usePythonVersion: ${{ variables.default_python_version }}
+usePythonVersion: '' # use Python from the container image
-- 
2.39.0



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

[edk2-devel] [PATCH v11 10/17] OvmfPkg: CI: Use Fedora 35 container (Linux only)

2023-01-16 Thread Oliver Steffen

Run the Linux jobs of the OvmfPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
 OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 6dd90711ac70..85be431ca5e7 100644
--- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -180,6 +180,8 @@ jobs:
 pool:
   vmImage: $(vm_image)
 
+container: ${{ variables.default_linux_image }}
+
 steps:
 - template: ../../../.azurepipelines/templates/platform-build-run-steps.yml
   parameters:
@@ -190,8 +192,4 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
-usePythonVersion: ${{ variables.default_python_version }}
-extra_install_step:
-- bash: sudo apt-get install qemu
-  displayName: Install qemu
-  condition: and(gt(variables.pkg_count, 0), succeeded())
+usePythonVersion: '' # use Python from the container image
-- 
2.39.0



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

[edk2-devel] [PATCH v11 11/17] .pytool: CISettings.py: don't add scopes for GCC

2023-01-16 Thread Oliver Steffen

All ext_dep.yml files for gcc have been removed and gcc
is expected to be installed on the system (GCC5_*_PREFIX
may indicate the location).
No need to adjust the toolchain scopes for Linux builds
anymore.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 .pytool/CISettings.py | 9 -
 1 file changed, 9 deletions(-)

diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index 76ac2b09dba6..d87c8e838e61 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -169,15 +169,6 @@ class Settings(CiBuildSettingsManager, 
UpdateSettingsManager, SetupSettingsManag
 else:
 logging.warning("Falling back to using in-tree BaseTools")
 
-if is_linux and self.ActualToolChainTag.upper().startswith("GCC"):
-if "AARCH64" in self.ActualArchitectures:
-scopes += ("gcc_aarch64_linux",)
-if "ARM" in self.ActualArchitectures:
-scopes += ("gcc_arm_linux",)
-if "RISCV64" in self.ActualArchitectures:
-scopes += ("gcc_riscv64_unknown",)
-if "LOONGARCH64" in self.ActualArchitectures:
-scopes += ("gcc_loongarch64_unknown_linux",)
 self.ActualScopes = scopes
 return self.ActualScopes
 
-- 
2.39.0



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

[edk2-devel] [PATCH v11 08/17] ArmVirtPkg: CI: Use Fedora 35 container (Linux only)

2023-01-16 Thread Oliver Steffen

Run the Linux jobs of the ArmVirtPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
 ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 5a0e589ed4a7..c0a2e0f20d4f 100644
--- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -78,6 +78,8 @@ jobs:
 pool:
   vmImage: $(vm_image)
 
+container: ${{ variables.default_linux_image }}
+
 steps:
 - template: ../../../.azurepipelines/templates/platform-build-run-steps.yml
   parameters:
@@ -88,8 +90,4 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
-usePythonVersion: ${{ variables.default_python_version }}
-extra_install_step:
-- bash: sudo apt-get install qemu
-  displayName: Install qemu
-  condition: and(gt(variables.pkg_count, 0), succeeded())
+usePythonVersion: '' # use Python from the container image
-- 
2.39.0



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

[edk2-devel] [PATCH v11 06/17] CI: Allow running in a container.

2023-01-16 Thread Oliver Steffen

Add a parameter of the pr-gate-build-job template to specify a
container image URL.  If the value is not '' (default), then the
jobs will be run inside a container based on that image.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 .azurepipelines/templates/pr-gate-build-job.yml | 4 
 1 file changed, 4 insertions(+)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index b8573b90da1c..3999bb166813 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -14,6 +14,7 @@ parameters:
   arch_list: ''
   extra_install_step: []
   usePythonVersion: ''
+  container: ''
 
 # Build step
 jobs:
@@ -72,6 +73,9 @@ jobs:
   pool:
 vmImage: ${{ parameters.vm_image }}
 
+  ${{ if not(eq(parameters.container, '')) }}:
+container: ${{ parameters.container }}
+
   steps:
   - template: pr-gate-steps.yml
 parameters:
-- 
2.39.0



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

[edk2-devel] [PATCH v11 07/17] CI: Use Fedora 35 container (Linux only)

2023-01-16 Thread Oliver Steffen

Run all Linux based jobs in a container, using a custom Fedora 35 image
(gcc 11).  The image URL specified in the defaults.yml template, so that
all CI jobs can use it. The image is hosted on ghcr.io and the
Dockerfiles are here: https://github.com/tianocore/containers The
version numbers of gcc, iasl, and nasm are pinned to avoid unintended
upgrades during image rebuild.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
 .azurepipelines/Ubuntu-GCC5.yml | 3 ++-
 .azurepipelines/templates/basetools-build-steps.yml | 9 -
 .azurepipelines/templates/defaults.yml  | 1 +
 3 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/.azurepipelines/Ubuntu-GCC5.yml b/.azurepipelines/Ubuntu-GCC5.yml
index 4ed6cb601b8e..246e2d272e20 100644
--- a/.azurepipelines/Ubuntu-GCC5.yml
+++ b/.azurepipelines/Ubuntu-GCC5.yml
@@ -21,6 +21,7 @@ jobs:
   parameters:
 tool_chain_tag: 'GCC5'
 vm_image: 'ubuntu-latest'
+container: ${{ variables.default_linux_image }}
 arch_list: "IA32,X64,ARM,AARCH64,RISCV64,LOONGARCH64"
-usePythonVersion: ${{ variables.default_python_version }}
+usePythonVersion: ''  # use Python from the container image
 
diff --git a/.azurepipelines/templates/basetools-build-steps.yml 
b/.azurepipelines/templates/basetools-build-steps.yml
index d8c108c6e212..a72758bc3395 100644
--- a/.azurepipelines/templates/basetools-build-steps.yml
+++ b/.azurepipelines/templates/basetools-build-steps.yml
@@ -10,15 +10,6 @@ parameters:
   tool_chain_tag: ''
 
 steps:
-- ${{ if contains(parameters.tool_chain_tag, 'GCC') }}:
-  - bash: sudo apt-get update
-displayName: Update apt
-condition: and(gt(variables.pkg_count, 0), succeeded())
-
-  - bash: sudo apt-get install gcc g++ make uuid-dev
-displayName: Install required tools
-condition: and(gt(variables.pkg_count, 0), succeeded())
-
 - task: CmdLine@1
   displayName: Build Base Tools from source
   inputs:
diff --git a/.azurepipelines/templates/defaults.yml 
b/.azurepipelines/templates/defaults.yml
index b4909448bdea..74d6b417839d 100644
--- a/.azurepipelines/templates/defaults.yml
+++ b/.azurepipelines/templates/defaults.yml
@@ -9,3 +9,4 @@
 
 variables:
   default_python_version: ">=3.10.6"
+  default_linux_image: "ghcr.io/tianocore/containers/fedora-35-test:47addc9"
-- 
2.39.0



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

[edk2-devel] [PATCH v11 05/17] CI: add ~/.local/bin to PATH (Linux only)

2023-01-16 Thread Oliver Steffen

Without adding ~/.local/bin to PATH, `pip install` will throw
an error when running inside a container.
Containers will be introduced to the CI in the following commits.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 .azurepipelines/templates/platform-build-run-steps.yml | 6 ++
 .azurepipelines/templates/pr-gate-steps.yml| 6 ++
 2 files changed, 12 insertions(+)

diff --git a/.azurepipelines/templates/platform-build-run-steps.yml 
b/.azurepipelines/templates/platform-build-run-steps.yml
index 8803d80cf51c..087f460d7fec 100644
--- a/.azurepipelines/templates/platform-build-run-steps.yml
+++ b/.azurepipelines/templates/platform-build-run-steps.yml
@@ -39,6 +39,12 @@ parameters:
   default: ''
 
 steps:
+- bash: |
+echo "##vso[task.prependpath]${HOME}/.local/bin"
+echo "new PATH=${PATH}"
+  displayName: Set PATH
+  condition: eq('${{ parameters.tool_chain_tag }}', 'GCC5')
+
 - checkout: self
   clean: true
   fetchDepth: 1
diff --git a/.azurepipelines/templates/pr-gate-steps.yml 
b/.azurepipelines/templates/pr-gate-steps.yml
index ebc1e86c37d4..78b2b2c8d934 100644
--- a/.azurepipelines/templates/pr-gate-steps.yml
+++ b/.azurepipelines/templates/pr-gate-steps.yml
@@ -16,6 +16,12 @@ parameters:
   extra_install_step: []
 
 steps:
+- bash: |
+echo "##vso[task.prependpath]${HOME}/.local/bin"
+echo "new PATH=${PATH}"
+  displayName: Set PATH
+  condition: eq('${{ parameters.tool_chain_tag }}', 'GCC5')
+
 - checkout: self
   clean: true
   fetchDepth: 1
-- 
2.39.0



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

[edk2-devel] [PATCH v11 04/17] OvmfPkg: CI: use Python version from defaults template

2023-01-16 Thread Oliver Steffen

Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.

Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml| 4 
 OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml | 5 +
 2 files changed, 9 insertions(+)

diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 7160d95f7e04..6dd90711ac70 100644
--- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -15,6 +15,9 @@ pr:
   - master
   - stable/*
 
+variables:
+  - template: ../../../.azurepipelines/templates/defaults.yml
+
 jobs:
   - job: Platform_CI
 variables:
@@ -187,6 +190,7 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
+usePythonVersion: ${{ variables.default_python_version }}
 extra_install_step:
 - bash: sudo apt-get install qemu
   displayName: Install qemu
diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml 
b/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
index 7d6344d6383d..7e63f419b26b 100644
--- a/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
+++ b/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
@@ -14,6 +14,10 @@ trigger:
 pr:
   - master
   - stable/*
+
+variables:
+  - template: ../../../.azurepipelines/templates/defaults.yml
+
 jobs:
   - job: Platform_CI
 variables:
@@ -133,6 +137,7 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
+usePythonVersion: ${{ variables.default_python_version }}
 extra_install_step:
 - powershell: choco install qemu --version=2021.5.5; Write-Host 
"##vso[task.prependpath]c:\Program Files\qemu"
   displayName: Install QEMU and Set QEMU on path # friendly name 
displayed in the UI
-- 
2.39.0



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

[edk2-devel] [PATCH v11 03/17] EmulatorPkg: CI: use Python version from defaults template

2023-01-16 Thread Oliver Steffen

Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.

Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml| 5 +
 EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml | 4 
 2 files changed, 9 insertions(+)

diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 416c15e70840..a32c57d4aab4 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -15,6 +15,10 @@ trigger:
 pr:
   - master
   - stable/*
+
+variables:
+  - template: ../../../.azurepipelines/templates/defaults.yml
+
 jobs:
   - job: Platform_CI
 variables:
@@ -85,3 +89,4 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
+usePythonVersion: ${{ variables.default_python_version }}
diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
index e7ead06ae266..09960e7c7a6e 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
@@ -16,6 +16,9 @@ pr:
   - master
   - stable/*
 
+variables:
+  - template: ../../../.azurepipelines/templates/defaults.yml
+
 jobs:
   - job: Platform_CI
 variables:
@@ -128,3 +131,4 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
+usePythonVersion: ${{ variables.default_python_version }}
-- 
2.39.0



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

[edk2-devel] [PATCH v11 02/17] ArmVirtPkg: CI: use Python version from defaults template

2023-01-16 Thread Oliver Steffen

Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.

Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 
 1 file changed, 4 insertions(+)

diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index b07e3199f143..5a0e589ed4a7 100644
--- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -15,6 +15,9 @@ pr:
   - master
   - stable/*
 
+variables:
+  - template: ../../../.azurepipelines/templates/defaults.yml
+
 jobs:
   - job: Platform_CI
 variables:
@@ -85,6 +88,7 @@ jobs:
 build_file: $(Build.File)
 build_flags: $(Build.Flags)
 run_flags: $(Run.Flags)
+usePythonVersion: ${{ variables.default_python_version }}
 extra_install_step:
 - bash: sudo apt-get install qemu
   displayName: Install qemu
-- 
2.39.0



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

[edk2-devel] [PATCH v11 01/17] CI: make Python version configurable

2023-01-16 Thread Oliver Steffen

Add a new parameter "usePythonVersion" to the CI job templates.
This makes it possible to specify the version of Python to use.
The default value is '', in which case Python will not be downloaded
at runtime and the one provided by the VM/container image will be used.

Additionally, add a template .azurepipelines/templates/defaults.yml,
from which the default Pyhton version string can be obtained.

Signed-off-by: Oliver Steffen 
Reviewed-by: Michael Kubacki 
---
 .azurepipelines/Ubuntu-GCC5.yml   |  9 +
 .azurepipelines/Windows-VS2019.yml|  4 
 .azurepipelines/templates/defaults.yml| 11 +++
 .../templates/platform-build-run-steps.yml|  6 +-
 .azurepipelines/templates/pr-gate-build-job.yml   |  2 ++
 .azurepipelines/templates/pr-gate-steps.yml   |  6 --
 6 files changed, 31 insertions(+), 7 deletions(-)
 create mode 100644 .azurepipelines/templates/defaults.yml

diff --git a/.azurepipelines/Ubuntu-GCC5.yml b/.azurepipelines/Ubuntu-GCC5.yml
index f83951eeaf86..4ed6cb601b8e 100644
--- a/.azurepipelines/Ubuntu-GCC5.yml
+++ b/.azurepipelines/Ubuntu-GCC5.yml
@@ -13,13 +13,14 @@ pr:
 - master
 - stable/*
 
+variables:
+  - template: templates/defaults.yml
+
 jobs:
 - template: templates/pr-gate-build-job.yml
   parameters:
 tool_chain_tag: 'GCC5'
 vm_image: 'ubuntu-latest'
 arch_list: "IA32,X64,ARM,AARCH64,RISCV64,LOONGARCH64"
-extra_install_step:
-- bash: sudo apt-get install -y lcov
-  displayName: Install Code Coverage Tools
-  condition: and(gt(variables.pkg_count, 0), succeeded())
+usePythonVersion: ${{ variables.default_python_version }}
+
diff --git a/.azurepipelines/Windows-VS2019.yml 
b/.azurepipelines/Windows-VS2019.yml
index c07e5bb43424..58bb98d42b28 100644
--- a/.azurepipelines/Windows-VS2019.yml
+++ b/.azurepipelines/Windows-VS2019.yml
@@ -12,12 +12,16 @@ pr:
 - master
 - stable/*
 
+variables:
+  - template: templates/defaults.yml
+
 jobs:
 - template: templates/pr-gate-build-job.yml
   parameters:
 tool_chain_tag: 'VS2019'
 vm_image: 'windows-2019'
 arch_list: "IA32,X64"
+usePythonVersion: ${{ variables.default_python_version }}
 extra_install_step:
 - powershell: choco install opencppcoverage; Write-Host 
"##vso[task.prependpath]C:\Program Files\OpenCppCoverage"
   displayName: Install Code Coverage Tool
diff --git a/.azurepipelines/templates/defaults.yml 
b/.azurepipelines/templates/defaults.yml
new file mode 100644
index ..b4909448bdea
--- /dev/null
+++ b/.azurepipelines/templates/defaults.yml
@@ -0,0 +1,11 @@
+## @file
+# File templates/default.yml
+#
+# template file containing common default values
+#
+# Copyright (c) Red Hat, Inc.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+variables:
+  default_python_version: ">=3.10.6"
diff --git a/.azurepipelines/templates/platform-build-run-steps.yml 
b/.azurepipelines/templates/platform-build-run-steps.yml
index 40a31a509fc5..8803d80cf51c 100644
--- a/.azurepipelines/templates/platform-build-run-steps.yml
+++ b/.azurepipelines/templates/platform-build-run-steps.yml
@@ -34,6 +34,9 @@ parameters:
 - name: extra_install_step
   type: stepList
   default: []
+- name: usePythonVersion
+  type: string
+  default: ''
 
 steps:
 - checkout: self
@@ -42,8 +45,9 @@ steps:
 
 - task: UsePythonVersion@0
   inputs:
-versionSpec: ">=3.10.6"
+versionSpec: ${{ parameters.usePythonVersion }}
 architecture: "x64"
+  condition: ne('${{ parameters.usePythonVersion }}', '')
 
 - script: pip install -r pip-requirements.txt --upgrade
   displayName: 'Install/Upgrade pip modules'
diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index fff61a3193b0..b8573b90da1c 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -13,6 +13,7 @@ parameters:
   vm_image: ''
   arch_list: ''
   extra_install_step: []
+  usePythonVersion: ''
 
 # Build step
 jobs:
@@ -78,6 +79,7 @@ jobs:
   build_pkgs: $(Build.Pkgs)
   build_targets: $(Build.Targets)
   build_archs: ${{ parameters.arch_list }}
+  usePythonVersion: ${{ parameters.usePythonVersion }}
   extra_install_step: ${{ parameters.extra_install_step }}
 
 - job: Build_${{ parameters.tool_chain_tag }}_TARGET_CODE_COVERAGE
diff --git a/.azurepipelines/templates/pr-gate-steps.yml 
b/.azurepipelines/templates/pr-gate-steps.yml
index 080f60aea6ab..ebc1e86c37d4 100644
--- a/.azurepipelines/templates/pr-gate-steps.yml
+++ b/.azurepipelines/templates/pr-gate-steps.yml
@@ -12,6 +12,7 @@ parameters:
   build_pkgs: ''
   build_targets: ''
   build_archs: ''
+  usePythonVersion: ''
   extra_install_step: []
 
 steps:
@@ -21,8 +22,9 @@ steps:
 
 - task: UsePythonVersion@0
   inputs:
-versionSpec: '>=3.10.6'
-architecture: 'x64'
+versionSpec: ${{ parameters.usePythonVersion }}
+architecture: "x6

[edk2-devel] [PATCH v11 00/17] CI: Use Fedora 35 container for Linux jobs

2023-01-16 Thread Oliver Steffen

Update CI, run all Linux (aka Ubuntu-GCC5) based jobs in custom
containers.  This decouples the CI environment from the virtual machine
images that Azure DevOps provides.  The currently used ubuntu-18.04 image
has been deprecated for a while now and will be removed soon.

The container image provides the required compiler toolchains and Qemu
for the supported architectures. These are then no longer downloaded at
runtime, avoiding CI failures due to download errors. This approach also
makes it easier to switch to other or newer compilers. It makes the CI
setup independent from the default images that Azure DevOps provides.
It can also help debugging CI problems, because the CI environment
can be reproduced on a local machine.

The container images are hosted on ghcr.io and are automatically
generated using GitHub Actions. The Dockerfiles are maintained in the
Tianocore "containers" repository:
https://github.com/tianocore/containers.

The current image is based on Fedora 35, with gcc 11. Fedora was chosen
because of its fast release cycle which makes it easy to keep the
toolchains up-to-date.

Some further possible changes not included in this series:
- The Tianocore/containers repository provides stack of layered images.
  One image for general purpose (build+test) and build-only jobs.
  The build+test image is based on the build-only one and adds Qemu,
  for the testing job that involve Qemu.  The work in the image side
  is done, we just need to change the CI setup accordingly.
  This patch set uses the build+test images for all jobs.
- Further reduce the number of external dependencies that need to be
  downloaded at runtime. Candidates are iasl and nasm, which are already
  included in the image but not used yet.

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

v11:
- Rebase to current master branch
- Use lasted image, includes Qemu 7.2
- Set container image URL in a central place (the defaults.yml template)

v10:
- Split commits by package
- Use ubuntu-22.04 as vm_image (instead of the floating ubuntu-latest)
- Some fixups around the Python version template argument and defaults.yml
- Fix some commit messages
- Add license statement to defaults.yml

v9:
- Drop the "Don't install cspell" patch
- Use explicitly use ubuntu-22.04 as vm_image

v8:
- Use updated container image that contains gcc for LoongArch64.
- Remove ext_dep files for the LoongArch64 gcc.
- Don't change the scopes in .pytool/CISettings.py if running Linux CI
  it.
- Split commits that touch multiple packages.
- Use the smaller "build" image for jobs that allow it.
- Add a CI template file as a central place to define the default Python version
  and use it where needed.

v7:
- Rebase to latest master branch.
- Use latest Fedora 35 CI image.
- Stop using the ubuntu-18.04 vm_image since this will no longer be available
  after Dec 1st.  Use ubuntu-latest instead.

v6:
- Include suggestions by Chris Fernald.
- Added a parameter for the container image to the job template, makes usage
  of containers optional.
- Added a parameter to configure the Python version to download. Allows
  using Python from the VM/container image also.
- Restructure the commits (no further functional changes).

v5:
- Update image

v4:
- Use the latest image from the tianocode/containers repository which
  - does not include acpica-tools
  - includes Pyhton 3.10

v3:
- Use the latest image from the tianocode/containers repository which
  pins down version numbers of gcc, iasl, and nasm in the Dockerfile.

v2:
- Images are now hosted under the Tianocore Organization
  https://github.com/tianocore/containers

v1:
- Thread: https://edk2.groups.io/g/devel/message/89058
- Images were hosted at https://github.com/osteffenrh/edk2-build-images

Signed-off-by: Oliver Steffen 
Acked-by: Ard Biesheuvel 
Acked-by: Gerd Hoffmann 
Reviewed-by: Chris Fernald 

Oliver Steffen (17):
  CI: make Python version configurable
  ArmVirtPkg: CI: use Python version from defaults template
  EmulatorPkg: CI: use Python version from defaults template
  OvmfPkg: CI: use Python version from defaults template
  CI: add ~/.local/bin to PATH (Linux only)
  CI: Allow running in a container.
  CI: Use Fedora 35 container (Linux only)
  ArmVirtPkg: CI: Use Fedora 35 container (Linux only)
  EmulatorPkg: CI: Use Fedora 35 container (Linux only)
  OvmfPkg: CI: Use Fedora 35 container (Linux only)
  .pytool: CISettings.py: don't add scopes for GCC
  BaseTools: remove ext_dep files for gcc
  ArmVirtPkg: CI: use ubuntu-22.04 vm_image (Linux only)
  EmulatorPgk: CI: use ubuntu-22.04 vm_image (Linux only)
  OvmfPkg: CI: use ubuntu-22.04 vm_image (Linux only)
  CI: use ubuntu-22.04 image (Linux only)
  OfmvPkg: CI: Qemu tests: set CPU to Broadwell

 .azurepipelines/Ubuntu-GCC5.yml   | 12 +-
 .azurepipelines/Windows-VS2019.yml|  4 
 .../templates/basetools-build-steps.yml   |  9 
 .azurepipelines/templates/defaults.yml| 12 ++
 .../templates/plat

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/PlatformInitLib: pass through reservations from qemu

2023-01-16 Thread Ard Biesheuvel

On Thu, 12 Jan 2023 at 18:09, Tom Lendacky  wrote:
>
> On 12/6/22 23:32, Gerd Hoffmann via groups.io wrote:
> > qemu uses the etc/e820 fw_cfg file not only for memory, but
> > also for reservations.  Handle reservations by adding resource
> > descriptor hobs for them.
> >
> > A typical qemu configuration has a small reservation between
> > lapic and flash:
> >
> ># sudo cat /proc/iomem
> >[ ... ]
> >fee0-fee00fff : Local APIC
> >feffc000-feff : Reserved  <= HERE
> >ffc0- : Reserved
> >[ ... ]
> >
> > Signed-off-by: Gerd Hoffmann 
>
> On newer versions of Qemu, this patch causes a boot failure on my
> AMD system with the following output:
>
> ...
> PciHostBridgeUtilityInitRootBridge: populated root bus 0, with room for 255 
> subordinate bus(es)
> RootBridge: PciRoot(0x0)
>Support/Attr: 70069 / 70069
>  DmaAbove4G: No
> NoExtConfSpace: No
>   AllocAttr: 3 (CombineMemPMem Mem64Decode)
> Bus: 0 - FF Translation=0
>  Io: 6000 -  Translation=0
> Mem: C000 - FBFF Translation=0
>  MemAbove4G: E0 - FF Translation=0
>PMem:  - 0 Translation=0
> PMemAbove4G:  - 0 Translation=0
> PciHostBridgeDxe: IntersectMemoryDescriptor: desc [FD, 100) 
> type 1 cap 80026000 conflicts with aperture [E0, 100) 
> cap 1
>
> ASSERT_EFI_ERROR (Status = Invalid Parameter)
> ASSERT [PciHostBridgeDxe] 
> /root/kernels/ovmf-build-X64/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(550):
>  !(((INTN)(RETURN_STATUS)(Status)) < 0)
>
> Doing some bisecting, before Qemu patch
>
> 8504f129450b ("i386/pc: relocate 4g start to 1T where applicable")
>
> this issue wasn't observed. And before this OVMF patch, the newer version
> of Qemu doesn't have an issue.
>
> Also, if I add host-phys-bits=true to the Qemu -cpu parameter, then
> the issue isn't observed regardless of Qemu/OVMF level.
>
> I'm hoping someone has an understanding of what is going on and what
> can be done to fix it.
>

Could someone look into this please? Gerd?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98578): https://edk2.groups.io/g/devel/message/98578
Mute This Topic: https://groups.io/mt/95510762/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/2] MdePkg: Support for MPAM ACPI Table

2023-01-16 Thread Rohit Mathew

Hi Swatisri,

Just wanted to check if you would still be interested in posting MPAM ACPI 2.0 
header? If you are caught up with something else, I could try to post a patch 
for the same.

Regards,
Rohit

From: devel@edk2.groups.io  On Behalf Of Sami Mujawar via 
groups.io
Sent: 03 October 2022 14:01
To: Name ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 1/2] MdePkg: Support for MPAM ACPI Table

Hi Swatisri,

Rohit pointed me to this patch series, which I believe is v2. I happened to 
have missed this as the subject line was not clear.
However, I believe my feedback (or some parts) for the v1 series would still 
apply.

Regards,

Sami Mujawar



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98577): https://edk2.groups.io/g/devel/message/98577
Mute This Topic: https://groups.io/mt/93824432/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] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

2023-01-16 Thread Laszlo Ersek

On 1/13/23 13:22, Gerd Hoffmann wrote:
> On Fri, Jan 13, 2023 at 11:10:54AM +0100, Laszlo Ersek wrote:
>> On 1/13/23 10:32, Gerd Hoffmann wrote:
>>> On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
   Hi,

> - QEMU can be configured with other compat properties on the
> command line so that "CPU hotplug with SMI" and "CPU hot-unplug
> with SMI" *not* be offered to the firmware. Then QEMU will reject
> hotplug attempts, and the SMM hotplug code in edk2 will not be
> triggered by the (virtual) hardware.

 Can we have edk2 print instructions for that in the error message?
>>>
>>> This seems to be:
>>>
>>> qemu -M q35 \
>>> -global ICH9-LPC.x-smi-cpu-hotplug=off \
>>> -global ICH9-LPC.x-smi-cpu-hotunplug=off
>>
>> Yes, those are the flags.
>>
>>> But it appears to not work.
>>
>> They should work, but they take effect in QEMU, and not in the
>> firmware. These knobs control what CPU hot(un)plug+SMI features QEMU
>> exposes to the guest fw, via fw_cfg,
>
> Ok, I see, only the SMM code actually checks that.
>
>> In particular the firmware makes no further decisions based on
>> whether QEMU advertized some of these features.
>
> I was thinking the other way around:  When cpu hotplug is disabled in
> qemu it should be safe to skip the whole cpu hotplug checking dance.
> See test patch below.
>
> That would give us a config switch (turn off cpu hotplug support)
> which would allow edk2 run on qemu versions with broken cpu hotplug.
>
> Does the idea look sane or do I miss something?
>
> take care,
>   Gerd
>
> commit bd2e36eba35268ab46c0125d2b9125391ea6f9fc
> Author: Gerd Hoffmann 
> Date:   Fri Jan 13 13:07:36 2023 +0100
>
> skip cpu present checking when hotplug is off
>
> diff --git a/OvmfPkg/Library/PlatformInitLib/Platform.c 
> b/OvmfPkg/Library/PlatformInitLib/Platform.c
> index 13348afb4890..2b0f0c836f85 100644
> --- a/OvmfPkg/Library/PlatformInitLib/Platform.c
> +++ b/OvmfPkg/Library/PlatformInitLib/Platform.c
> @@ -415,8 +415,9 @@ PlatformMaxCpuCountInitialization (
>IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
>)
>  {
> -  UINT16  BootCpuCount = 0;
> -  UINT32  MaxCpuCount;
> +  UINT16   BootCpuCount = 0;
> +  UINT32   MaxCpuCount;
> +  BOOLEAN  CpuHotplugSupported = FALSE;
>
>//
>// Try to fetch the boot CPU count.
> @@ -424,6 +425,31 @@ PlatformMaxCpuCountInitialization (
>if (QemuFwCfgIsAvailable ()) {
>  QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
>  BootCpuCount = QemuFwCfgRead16 ();
> +DEBUG ((DEBUG_INFO, "%a: BootCpuCount: %d\n", __FUNCTION__, 
> BootCpuCount));
> +  }
> +
> +  {
> +FIRMWARE_CONFIG_ITEM  SupportedFeaturesItem;
> +UINTN SupportedFeaturesSize;
> +UINT64mSmiFeatures;
> +EFI_STATUSStatus;
> +
> +Status = QemuFwCfgFindFile (
> +   "etc/smi/supported-features",
> +   &SupportedFeaturesItem,
> +   &SupportedFeaturesSize
> +   );
> +
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_INFO, "%a: etc/smi/supported-features: %r\n", 
> __FUNCTION__, Status));
> +} else {
> +  QemuFwCfgSelectItem (SupportedFeaturesItem);
> +  QemuFwCfgReadBytes (sizeof mSmiFeatures, &mSmiFeatures);
> +  DEBUG ((DEBUG_INFO, "%a: etc/smi/supported-features: 0x%x\n", 
> __FUNCTION__, mSmiFeatures));
> +  if (mSmiFeatures & (BIT1 /* hotplug */ | BIT2 /* hotunplug */)) {
> +CpuHotplugSupported = TRUE;
> +  }
> +}
>}
>
>if (BootCpuCount == 0) {
> @@ -435,6 +461,9 @@ PlatformMaxCpuCountInitialization (
>  //
>  DEBUG ((DEBUG_WARN, "%a: boot CPU count unavailable\n", __FUNCTION__));
>  MaxCpuCount = PlatformInfoHob->DefaultMaxCpuNumber;
> +  } else if (!CpuHotplugSupported) {
> +DEBUG ((DEBUG_INFO, "%a: CPU hotplug support not available\n", 
> __FUNCTION__));
> +MaxCpuCount = BootCpuCount;
>} else {
>  //
>  // We will expose BootCpuCount to MpInitLib. MpInitLib will count APs up 
> to
>

This would be wrong.

Let me provide a summary of CPU hotplug with SMM. It consists of the
following patch sets, in edk2. Note that these sets were implemented and
merged in dependency order, and I'm listing them likewise.

(E1) a7e2d20193e8..778832bcad33, for TianoCore#1515

(E2) c8b8157e126a..83357313dd67, for TianoCore#1515

(E3) 422da35375c6..75839f977d37, for TianoCore#1512

(E4) 61d3b2d4279e..1158fc8e2c7b, for TianoCore#1512

(E5) 5ba203b54e59, no BZ

(E6) 63d92674d240..cbccf995920a, for TianoCore#2929 [not really relevant
here, just for completeness]

(I'm ignoring hot-unplug now, which came later. See TianoCore#3132; the
commit range is noted there too.)

On the QEMU side, some relevant series are (again in dependency order):

(Q1) be9612e8cbb4..3a61c8db9d25

(Q2) fd9b0830b0be [just for completeness]

(Q3) 2d69eba5fe52..6e2e2e8a4220

I recommend reading through all those commits.


*** Series E1+E2 allow OVMF to expose the preci

Re: [edk2-devel] [PATCH v2] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

2023-01-16 Thread Ard Biesheuvel

On Fri, 13 Jan 2023 at 13:22, Gerd Hoffmann  wrote:
>
> On Fri, Jan 13, 2023 at 11:10:54AM +0100, Laszlo Ersek wrote:
> > On 1/13/23 10:32, Gerd Hoffmann wrote:
> > > On Fri, Jan 13, 2023 at 07:03:54AM +0100, Gerd Hoffmann wrote:
> > >>   Hi,
> > >>
> > >>> - QEMU can be configured with other compat properties on the command
> > >>> line so that "CPU hotplug with SMI" and "CPU hot-unplug with SMI" *not*
> > >>> be offered to the firmware. Then QEMU will reject hotplug attempts, and
> > >>> the SMM hotplug code in edk2 will not be triggered by the (virtual)
> > >>> hardware.
> > >>
> > >> Can we have edk2 print instructions for that in the error message?
> > >
> > > This seems to be:
> > >
> > > qemu -M q35 \
> > > -global ICH9-LPC.x-smi-cpu-hotplug=off \
> > > -global ICH9-LPC.x-smi-cpu-hotunplug=off
> >
> > Yes, those are the flags.
> >
> > > But it appears to not work.
> >
> > They should work, but they take effect in QEMU, and not in the firmware.
> > These knobs control what CPU hot(un)plug+SMI features QEMU exposes to
> > the guest fw, via fw_cfg,
>
> Ok, I see, only the SMM code actually checks that.
>
> > In particular the firmware makes no further decisions based on whether
> > QEMU advertized some of these features.
>
> I was thinking the other way around:  When cpu hotplug is disabled in
> qemu it should be safe to skip the whole cpu hotplug checking dance.
> See test patch below.
>
> That would give us a config switch (turn off cpu hotplug support) which
> would allow edk2 run on qemu versions with broken cpu hotplug.
>
> Does the idea look sane or do I miss something?
>

I cannot review the actual patch due to lack of x86/smm/qemu/hotplug
knowledge, but if this allows us to merge Laszlo's fix without
breaking all current QEMU/x86 TCG users, I'm all for it.


>
> commit bd2e36eba35268ab46c0125d2b9125391ea6f9fc
> Author: Gerd Hoffmann 
> Date:   Fri Jan 13 13:07:36 2023 +0100
>
> skip cpu present checking when hotplug is off
>
> diff --git a/OvmfPkg/Library/PlatformInitLib/Platform.c 
> b/OvmfPkg/Library/PlatformInitLib/Platform.c
> index 13348afb4890..2b0f0c836f85 100644
> --- a/OvmfPkg/Library/PlatformInitLib/Platform.c
> +++ b/OvmfPkg/Library/PlatformInitLib/Platform.c
> @@ -415,8 +415,9 @@ PlatformMaxCpuCountInitialization (
>IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
>)
>  {
> -  UINT16  BootCpuCount = 0;
> -  UINT32  MaxCpuCount;
> +  UINT16   BootCpuCount = 0;
> +  UINT32   MaxCpuCount;
> +  BOOLEAN  CpuHotplugSupported = FALSE;
>
>//
>// Try to fetch the boot CPU count.
> @@ -424,6 +425,31 @@ PlatformMaxCpuCountInitialization (
>if (QemuFwCfgIsAvailable ()) {
>  QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
>  BootCpuCount = QemuFwCfgRead16 ();
> +DEBUG ((DEBUG_INFO, "%a: BootCpuCount: %d\n", __FUNCTION__, 
> BootCpuCount));
> +  }
> +
> +  {
> +FIRMWARE_CONFIG_ITEM  SupportedFeaturesItem;
> +UINTN SupportedFeaturesSize;
> +UINT64mSmiFeatures;
> +EFI_STATUSStatus;
> +
> +Status = QemuFwCfgFindFile (
> +   "etc/smi/supported-features",
> +   &SupportedFeaturesItem,
> +   &SupportedFeaturesSize
> +   );
> +
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_INFO, "%a: etc/smi/supported-features: %r\n", 
> __FUNCTION__, Status));
> +} else {
> +  QemuFwCfgSelectItem (SupportedFeaturesItem);
> +  QemuFwCfgReadBytes (sizeof mSmiFeatures, &mSmiFeatures);
> +  DEBUG ((DEBUG_INFO, "%a: etc/smi/supported-features: 0x%x\n", 
> __FUNCTION__, mSmiFeatures));
> +  if (mSmiFeatures & (BIT1 /* hotplug */ | BIT2 /* hotunplug */)) {
> +CpuHotplugSupported = TRUE;
> +  }
> +}
>}
>
>if (BootCpuCount == 0) {
> @@ -435,6 +461,9 @@ PlatformMaxCpuCountInitialization (
>  //
>  DEBUG ((DEBUG_WARN, "%a: boot CPU count unavailable\n", __FUNCTION__));
>  MaxCpuCount = PlatformInfoHob->DefaultMaxCpuNumber;
> +  } else if (!CpuHotplugSupported) {
> +DEBUG ((DEBUG_INFO, "%a: CPU hotplug support not available\n", 
> __FUNCTION__));
> +MaxCpuCount = BootCpuCount;
>} else {
>  //
>  // We will expose BootCpuCount to MpInitLib. MpInitLib will count APs up 
> to
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98575): https://edk2.groups.io/g/devel/message/98575
Mute This Topic: https://groups.io/mt/96218818/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 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Yao, Jiewen

Each module, which wants to load ACPI table.

Most codes are from close source platform.

One example in EDKII SecurityPkg is TPM2.
https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c#L690

https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c#L794

Just search "TpmMeasureAndLogData" ...


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Monday, January 16, 2023 10:15 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Xu, Min M ; Aktas, Erdem
> ; James Bottomley ; Gerd
> Hoffmann ; Tom Lendacky
> ; Michael Roth 
> Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> Measure ACPI table from QEMU in TDVF
> 
> On Mon, 16 Jan 2023 at 14:57, Yao, Jiewen  wrote:
> >
> > Do you mean real platform BIOS?
> >
> 
> Yes
> 
> > The rules are:
> > 1) The ACPI table on the flash loaded by the BIOS is measured *before* any
> modification and *before* installation. For example, DSDT, SSDT.
> > 2) The ACPI table constructed by the BIOS dynamically does not need to be
> measured. For example MADT.
> >
> 
> OK so which EDK2 component is normally in charge of this?
> 
> 
> 
> > > -Original Message-
> > > From: Ard Biesheuvel 
> > > Sent: Monday, January 16, 2023 6:38 PM
> > > To: devel@edk2.groups.io; Yao, Jiewen 
> > > Cc: Xu, Min M ; Aktas, Erdem
> > > ; James Bottomley ;
> Gerd
> > > Hoffmann ; Tom Lendacky
> > > ; Michael Roth 
> > > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > > Measure ACPI table from QEMU in TDVF
> > >
> > > Another question: how does this deviate from ordinary measured boot?
> > > How and when are ACPI tables measured on such systems?
> > >
> > >
> > > On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen 
> wrote:
> > > >
> > > > Hi
> > > > I have two feedback:
> > > >
> > > > 1) What we need measure is the input from VMM *before* any
> > > modification and *before* installation.
> > > > Please don't use ACPI SDT protocol to get the table *after* 
> > > > modification.
> > > >
> > > > 2) Why not use TpmMeasureAndLogData() in
> > >
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Li
> > > brary/TpmMeasurementLib.h ?
> > > > Please don't use locate protocol.
> > > >
> > > > Thank you
> > > > Yao, Jiewen
> > > >
> > > > > -Original Message-
> > > > > From: Xu, Min M 
> > > > > Sent: Monday, January 16, 2023 9:57 AM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > > ; James Bottomley ;
> > > Yao,
> > > > > Jiewen ; Gerd Hoffmann
> ;
> > > > > Tom Lendacky ; Michael Roth
> > > > > 
> > > > > Subject: [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI
> table
> > > from
> > > > > QEMU in TDVF
> > > > >
> > > > > From: Min M Xu 
> > > > >
> > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=4245
> > > > >
> > > > > The ACPI tables are downloaded from QEMU. QEMU/VMM is treated
> as
> > > > > un-trusted in a td-guest. From the security perspective they should
> > > > > be measured and extended if possible. So that they can be audited
> > > > > later. The measurement protocol may be not installed. In this case
> > > > > it still returns EFI_SUCCESS.
> > > > >
> > > > > Cc: Erdem Aktas 
> > > > > Cc: James Bottomley 
> > > > > Cc: Jiewen Yao 
> > > > > Cc: Gerd Hoffmann 
> > > > > Cc: Tom Lendacky 
> > > > > Cc: Michael Roth 
> > > > > Signed-off-by: Min Xu 
> > > > > ---
> > > > >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> > > > >  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 168
> > > > > 
> > > > >  2 files changed, 170 insertions(+)
> > > > >
> > > > > diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > index 8939dde42549..ae22bab38cf9 100644
> > > > > --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > > @@ -51,6 +51,8 @@
> > > > >gEfiAcpiTableProtocolGuid # PROTOCOL
> > > ALWAYS_CONSUMED
> > > > >gEfiPciIoProtocolGuid # PROTOCOL
> > > SOMETIMES_CONSUMED
> > > > >gQemuAcpiTableNotifyProtocolGuid  # PROTOCOL PRODUCES
> > > > > +  gEfiCcMeasurementProtocolGuid # PROTOCOL
> > > > > SOMETIMES_CONSUMED
> > > > > +  gEfiAcpiSdtProtocolGuid   # PROTOCOL
> > > > > SOMETIMES_CONSUMED
> > > > >
> > > > >  [Guids]
> > > > >gRootBridgesConnectedEventGroupGuid
> > > > > diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > > b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > > index f0d81d6fd73d..f442850c2e00 100644
> > > > > --- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > > +++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > > @@ -18,6 +18,8 @@
> > > > >  #include  // QemuFwCfgFindFile()
> > > > >  #include//
> QemuFwCfgS3Enabled()
> > > > >  #include  // gBS
> > > > > +#include 
> > > > > +#include 
> >

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Ard Biesheuvel

On Mon, 16 Jan 2023 at 14:57, Yao, Jiewen  wrote:
>
> Do you mean real platform BIOS?
>

Yes

> The rules are:
> 1) The ACPI table on the flash loaded by the BIOS is measured *before* any 
> modification and *before* installation. For example, DSDT, SSDT.
> 2) The ACPI table constructed by the BIOS dynamically does not need to be 
> measured. For example MADT.
>

OK so which EDK2 component is normally in charge of this?



> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Monday, January 16, 2023 6:38 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Xu, Min M ; Aktas, Erdem
> > ; James Bottomley ; Gerd
> > Hoffmann ; Tom Lendacky
> > ; Michael Roth 
> > Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> > Measure ACPI table from QEMU in TDVF
> >
> > Another question: how does this deviate from ordinary measured boot?
> > How and when are ACPI tables measured on such systems?
> >
> >
> > On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen  wrote:
> > >
> > > Hi
> > > I have two feedback:
> > >
> > > 1) What we need measure is the input from VMM *before* any
> > modification and *before* installation.
> > > Please don't use ACPI SDT protocol to get the table *after* modification.
> > >
> > > 2) Why not use TpmMeasureAndLogData() in
> > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Li
> > brary/TpmMeasurementLib.h ?
> > > Please don't use locate protocol.
> > >
> > > Thank you
> > > Yao, Jiewen
> > >
> > > > -Original Message-
> > > > From: Xu, Min M 
> > > > Sent: Monday, January 16, 2023 9:57 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Xu, Min M ; Aktas, Erdem
> > > > ; James Bottomley ;
> > Yao,
> > > > Jiewen ; Gerd Hoffmann ;
> > > > Tom Lendacky ; Michael Roth
> > > > 
> > > > Subject: [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table
> > from
> > > > QEMU in TDVF
> > > >
> > > > From: Min M Xu 
> > > >
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=4245
> > > >
> > > > The ACPI tables are downloaded from QEMU. QEMU/VMM is treated as
> > > > un-trusted in a td-guest. From the security perspective they should
> > > > be measured and extended if possible. So that they can be audited
> > > > later. The measurement protocol may be not installed. In this case
> > > > it still returns EFI_SUCCESS.
> > > >
> > > > Cc: Erdem Aktas 
> > > > Cc: James Bottomley 
> > > > Cc: Jiewen Yao 
> > > > Cc: Gerd Hoffmann 
> > > > Cc: Tom Lendacky 
> > > > Cc: Michael Roth 
> > > > Signed-off-by: Min Xu 
> > > > ---
> > > >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> > > >  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 168
> > > > 
> > > >  2 files changed, 170 insertions(+)
> > > >
> > > > diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > index 8939dde42549..ae22bab38cf9 100644
> > > > --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > > @@ -51,6 +51,8 @@
> > > >gEfiAcpiTableProtocolGuid # PROTOCOL
> > ALWAYS_CONSUMED
> > > >gEfiPciIoProtocolGuid # PROTOCOL
> > SOMETIMES_CONSUMED
> > > >gQemuAcpiTableNotifyProtocolGuid  # PROTOCOL PRODUCES
> > > > +  gEfiCcMeasurementProtocolGuid # PROTOCOL
> > > > SOMETIMES_CONSUMED
> > > > +  gEfiAcpiSdtProtocolGuid   # PROTOCOL
> > > > SOMETIMES_CONSUMED
> > > >
> > > >  [Guids]
> > > >gRootBridgesConnectedEventGroupGuid
> > > > diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > index f0d81d6fd73d..f442850c2e00 100644
> > > > --- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > +++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > > @@ -18,6 +18,8 @@
> > > >  #include  // QemuFwCfgFindFile()
> > > >  #include// QemuFwCfgS3Enabled()
> > > >  #include  // gBS
> > > > +#include 
> > > > +#include 
> > > >
> > > >  #include "AcpiPlatform.h"
> > > >
> > > > @@ -812,12 +814,168 @@ UndoCmdWritePointer (
> > > >  ));
> > > >  }
> > > >
> > > > +/**
> > > > +  Mesure firmware ACPI table with CcMeasurement Protocol
> > > > +
> > > > +  @param[in] CcProtocol   Pointer to the CcMeasurment Protocol
> > > > +  @param[in] EventDataPointer to the event data.
> > > > +  @param[in] EventSizeSize of event data.
> > > > +  @param[in] CfgDataBase  Configuration data base address.
> > > > +  @param[in] EventSizeSize of configuration data .
> > > > +  @retval  EFI_NOT_FOUND   Cannot locate protocol.
> > > > +  @retval  EFI_OUT_OF_RESOURCESAllocate zero pool failure.
> > > > +  @return  Status codes returned by
> > > > +   mTcg2Protocol->HashLogExtendEvent.
> > > > +**/
> > > > +STATIC
> > > > +EFI_STATUS
> > > > +EFIAPI
> > > > +CcMeasureAcpiTable (
> > > > +  IN EFI_CC_MEASUREMENT_PROTOCOL  *CcProtoco

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Yao, Jiewen

Do you mean real platform BIOS?

The rules are:
1) The ACPI table on the flash loaded by the BIOS is measured *before* any 
modification and *before* installation. For example, DSDT, SSDT.
2) The ACPI table constructed by the BIOS dynamically does not need to be 
measured. For example MADT.

Thank You
Yao, Jiewen

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Monday, January 16, 2023 6:38 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Xu, Min M ; Aktas, Erdem
> ; James Bottomley ; Gerd
> Hoffmann ; Tom Lendacky
> ; Michael Roth 
> Subject: Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe:
> Measure ACPI table from QEMU in TDVF
> 
> Another question: how does this deviate from ordinary measured boot?
> How and when are ACPI tables measured on such systems?
> 
> 
> On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen  wrote:
> >
> > Hi
> > I have two feedback:
> >
> > 1) What we need measure is the input from VMM *before* any
> modification and *before* installation.
> > Please don't use ACPI SDT protocol to get the table *after* modification.
> >
> > 2) Why not use TpmMeasureAndLogData() in
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Li
> brary/TpmMeasurementLib.h ?
> > Please don't use locate protocol.
> >
> > Thank you
> > Yao, Jiewen
> >
> > > -Original Message-
> > > From: Xu, Min M 
> > > Sent: Monday, January 16, 2023 9:57 AM
> > > To: devel@edk2.groups.io
> > > Cc: Xu, Min M ; Aktas, Erdem
> > > ; James Bottomley ;
> Yao,
> > > Jiewen ; Gerd Hoffmann ;
> > > Tom Lendacky ; Michael Roth
> > > 
> > > Subject: [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table
> from
> > > QEMU in TDVF
> > >
> > > From: Min M Xu 
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=4245
> > >
> > > The ACPI tables are downloaded from QEMU. QEMU/VMM is treated as
> > > un-trusted in a td-guest. From the security perspective they should
> > > be measured and extended if possible. So that they can be audited
> > > later. The measurement protocol may be not installed. In this case
> > > it still returns EFI_SUCCESS.
> > >
> > > Cc: Erdem Aktas 
> > > Cc: James Bottomley 
> > > Cc: Jiewen Yao 
> > > Cc: Gerd Hoffmann 
> > > Cc: Tom Lendacky 
> > > Cc: Michael Roth 
> > > Signed-off-by: Min Xu 
> > > ---
> > >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> > >  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 168
> > > 
> > >  2 files changed, 170 insertions(+)
> > >
> > > diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > index 8939dde42549..ae22bab38cf9 100644
> > > --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > > @@ -51,6 +51,8 @@
> > >gEfiAcpiTableProtocolGuid # PROTOCOL
> ALWAYS_CONSUMED
> > >gEfiPciIoProtocolGuid # PROTOCOL
> SOMETIMES_CONSUMED
> > >gQemuAcpiTableNotifyProtocolGuid  # PROTOCOL PRODUCES
> > > +  gEfiCcMeasurementProtocolGuid # PROTOCOL
> > > SOMETIMES_CONSUMED
> > > +  gEfiAcpiSdtProtocolGuid   # PROTOCOL
> > > SOMETIMES_CONSUMED
> > >
> > >  [Guids]
> > >gRootBridgesConnectedEventGroupGuid
> > > diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > index f0d81d6fd73d..f442850c2e00 100644
> > > --- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > +++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > > @@ -18,6 +18,8 @@
> > >  #include  // QemuFwCfgFindFile()
> > >  #include// QemuFwCfgS3Enabled()
> > >  #include  // gBS
> > > +#include 
> > > +#include 
> > >
> > >  #include "AcpiPlatform.h"
> > >
> > > @@ -812,12 +814,168 @@ UndoCmdWritePointer (
> > >  ));
> > >  }
> > >
> > > +/**
> > > +  Mesure firmware ACPI table with CcMeasurement Protocol
> > > +
> > > +  @param[in] CcProtocol   Pointer to the CcMeasurment Protocol
> > > +  @param[in] EventDataPointer to the event data.
> > > +  @param[in] EventSizeSize of event data.
> > > +  @param[in] CfgDataBase  Configuration data base address.
> > > +  @param[in] EventSizeSize of configuration data .
> > > +  @retval  EFI_NOT_FOUND   Cannot locate protocol.
> > > +  @retval  EFI_OUT_OF_RESOURCESAllocate zero pool failure.
> > > +  @return  Status codes returned by
> > > +   mTcg2Protocol->HashLogExtendEvent.
> > > +**/
> > > +STATIC
> > > +EFI_STATUS
> > > +EFIAPI
> > > +CcMeasureAcpiTable (
> > > +  IN EFI_CC_MEASUREMENT_PROTOCOL  *CcProtocol,
> > > +  IN CHAR8*EventData,
> > > +  IN UINT32   EventSize,
> > > +  IN EFI_PHYSICAL_ADDRESS CfgDataBase,
> > > +  IN UINTNCfgDataLength
> > > +  )
> > > +{
> > > +  EFI_STATUSStatus;
> > > +  EFI_CC_EVENT  *CcEvent;
> > > +  UINT32MrIndex;
> > > +
> > > +  if (

Re: [edk2-devel] [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Ard Biesheuvel

On Mon, 16 Jan 2023 at 13:31, Kirill A. Shutemov  wrote:
>
> On Mon, Jan 16, 2023 at 11:56:48AM +0100, Gerd Hoffmann wrote:
> > On Sat, Jan 14, 2023 at 01:20:24AM +0300, Kirill A. Shutemov wrote:
> > > On Fri, Jan 13, 2023 at 09:29:26PM +, Dionna Glaze wrote:
> > > > This patch depends on Kirill A. Shutemov's series
> > > >
> > > > [PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
> > > >
> > > > The UEFI v2.9 specification includes a new memory type to be used in
> > > > environments where the OS must accept memory that is provided from its
> > > > host. Before the introduction of this memory type, all memory was
> > > > accepted eagerly in the firmware. In order for the firmware to safely
> > > > stop accepting memory on the OS's behalf, the OS must affirmatively
> > > > indicate support to the firmware.
> > >
> > > I think it is a bad idea.
> > >
> > > This approach breaks use case with a bootloader between BIOS and OS.
> > > As the bootloader does ExitBootServices() it has to make the call on
> > > behalf of OS when it has no idea if the OS supports unaccepted.
> >
> > Nothing breaks, it'll error on the safe side.  If the protocol callback
> > is not called the firmware will simply accept all memory.  The guest OS
> > will only see unaccepted memory if it explicitly asked for it (assuming
> > the firmware wants know to support both cases, of course the firmware
> > could also enforce the one or the other and just not offer the
> > protocol).
>
> How bootloader suppose to know if OS will ask for unaccepted memory?
> It can't. It means the use-case with bootloader cannot ever use
> unaccepted memory. That's broken design.
>

I still don't understand why we need to support every imaginable
combination of firmware, bootloader and OS. Unaccepted memory only
exists on a special kind of virtual machine, which provides very
little added value unless you opt into the security and attestation
features, which are all heavily based on firmware protocols. So why
should care about a EFI-aware bootloader calling ExitBootServices()
and subsequently doing a legacy boot of Linux on such systems?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98571): https://edk2.groups.io/g/devel/message/98571
Mute This Topic: https://groups.io/mt/96256524/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 0/3] Customize lazy-accepted memory size for TDVF

2023-01-16 Thread Min Xu

On January 2, 2023 6:37 PM, Gerd Hoffmann wrote:
> On Mon, Dec 26, 2022 at 09:33:35AM +0800, Min Xu wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181
> >
> > Current lazy-accept accepts the memory under address of 4G. To improve
> > boot performance further more, we introduce the feature of customizing
> > the physical end address of lazy-accept in build time.
> 
> Do you have numbers?  I'm wondering how much of a difference this actually
> is, given that 2M pages is fast and tdx already uses all processors to accept
> memory ...
This feature is tested in Intel SPR platform (boot up a td guest configured 
with 4vCPU + 4G memory).
It costs about 91ms to accept memories under address of 0x2000. As a 
comparison it costs about 240ms to accept memories under address of 0x1.

> 
> What happens in case the firmware runs out of memory in DXE phase?
We create an initrd which size is 881MB. The td guest is configured to accept 
memories under address of 0x2000.
 1) Direct boot
If we set the boot mode as direct boot, then it will turn to next boot option. 
In our case it is a grub boot.
If the log message is turned on, then we can see below errors when trying to 
FetchBlob "initrd":
  AllocatePoolPages: failed to allocate 225423 pages
  AllocatePool: failed to allocate 923331624 bytes
  FetchBlob: failed to allocate 923331584 bytes for "initrd"
  Error: Image at 0001E152000 start failed: Out of Resources

2) Grub boot
If we set the boot mode as grub boot, then below error message is shown:
error: ../../grub-core/loader/i386/efi/linux.c:119:can't allocate initrd.
error: ../../grub-core/loader/i386/efi/linux.c:119:can't allocate initrd.
Press any key to continue...Press any key to continue...

After a while the boot process continued. Finally the td guest is successfully 
brought up.

Thanks
Min


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98570): https://edk2.groups.io/g/devel/message/98570
Mute This Topic: https://groups.io/mt/95882249/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/1] ArmVirt: don't use unaligned CopyMem () on NOR flash

2023-01-16 Thread Ard Biesheuvel

On Mon, 16 Jan 2023 at 12:10, Ard Biesheuvel  wrote:
>
> On Mon, 16 Jan 2023 at 10:46, Gerd Hoffmann  wrote:
> >
> > Fixes: e5ec3ba409b5 ("OvmfPkg/VirtNorFlashDxe: map flash memory as 
> > uncacheable")
> > Signed-off-by: Gerd Hoffmann 
>
> Thanks Gerd.
>
> I'll tweak the fixes line and the commit log a bit:
>
> Commit 789a72328553 reclassified the NOR flash region as EFI_MEMORY_WC
> in the OS visible EFI memory map, and dropped the explicit aligned
> CopyMem() implementation, in the assumption that EFI_MEMORY_WC will be
> honored by the OS, and that the region will be mapped in a way that
> tolerates misaligned accesses. However, Linux today uses device
> attributes for all EFI MMIO regions, in spite of the memory type
> attributes, and so using misaligned accesses is never safe.
>
> So instead, switch to the generic CopyMem() implementation entirely,
> just like we already did for VariableRuntimeDxe.
>
> Fixes: 789a72328553 ("OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and
> drop AlignedCopyMem()")
>

Merged as #3903.

> > ---
> >  ArmVirtPkg/ArmVirtKvmTool.dsc| 6 +-
> >  ArmVirtPkg/ArmVirtQemu.dsc   | 6 +-
> >  ArmVirtPkg/ArmVirtQemuKernel.dsc | 6 +-
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
> > index 2ba00bd08ff1..d0afe1b49e25 100644
> > --- a/ArmVirtPkg/ArmVirtKvmTool.dsc
> > +++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
> > @@ -296,7 +296,11 @@ [Components.common]
> >
> > NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
> >}
> >
> > -  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> > +  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
> > +
> > +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
> > region
> > +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> > +  }
> >
> >MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> >
> > diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> > index 5dd8b6104cca..0f1c6395488a 100644
> > --- a/ArmVirtPkg/ArmVirtQemu.dsc
> > +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> > @@ -428,7 +428,11 @@ [Components.common]
> >  
> >
> > NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
> >}
> > -  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> > +  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
> > +
> > +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
> > region
> > +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> > +  }
> >MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> >
> >#
> > diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> > b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> > index f5db3ac432f3..807c85d48285 100644
> > --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> > +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> > @@ -331,7 +331,11 @@ [Components.common]
> >  
> >
> > NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
> >}
> > -  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> > +  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
> > +
> > +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
> > region
> > +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> > +  }
> >MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> >
> >#
> > --
> > 2.39.0
> >
> >
> >
> > 
> >
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98569): https://edk2.groups.io/g/devel/message/98569
Mute This Topic: https://groups.io/mt/96303660/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/1] ArmVirt: don't use unaligned CopyMem () on NOR flash

2023-01-16 Thread Ard Biesheuvel

On Mon, 16 Jan 2023 at 10:46, Gerd Hoffmann  wrote:
>
> Fixes: e5ec3ba409b5 ("OvmfPkg/VirtNorFlashDxe: map flash memory as 
> uncacheable")
> Signed-off-by: Gerd Hoffmann 

Thanks Gerd.

I'll tweak the fixes line and the commit log a bit:

Commit 789a72328553 reclassified the NOR flash region as EFI_MEMORY_WC
in the OS visible EFI memory map, and dropped the explicit aligned
CopyMem() implementation, in the assumption that EFI_MEMORY_WC will be
honored by the OS, and that the region will be mapped in a way that
tolerates misaligned accesses. However, Linux today uses device
attributes for all EFI MMIO regions, in spite of the memory type
attributes, and so using misaligned accesses is never safe.

So instead, switch to the generic CopyMem() implementation entirely,
just like we already did for VariableRuntimeDxe.

Fixes: 789a72328553 ("OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and
drop AlignedCopyMem()")

> ---
>  ArmVirtPkg/ArmVirtKvmTool.dsc| 6 +-
>  ArmVirtPkg/ArmVirtQemu.dsc   | 6 +-
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 6 +-
>  3 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
> index 2ba00bd08ff1..d0afe1b49e25 100644
> --- a/ArmVirtPkg/ArmVirtKvmTool.dsc
> +++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
> @@ -296,7 +296,11 @@ [Components.common]
>
> NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
>}
>
> -  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> +  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
> +
> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> +  }
>
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 5dd8b6104cca..0f1c6395488a 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -428,7 +428,11 @@ [Components.common]
>  
>
> NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
>}
> -  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> +  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
> +
> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> +  }
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>
>#
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index f5db3ac432f3..807c85d48285 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -331,7 +331,11 @@ [Components.common]
>  
>
> NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
>}
> -  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
> +  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
> +
> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> +  }
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>
>#
> --
> 2.39.0
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98568): https://edk2.groups.io/g/devel/message/98568
Mute This Topic: https://groups.io/mt/96303660/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] x86/efi: Safely enable unaccepted memory in UEFI

2023-01-16 Thread Gerd Hoffmann

On Sat, Jan 14, 2023 at 01:20:24AM +0300, Kirill A. Shutemov wrote:
> On Fri, Jan 13, 2023 at 09:29:26PM +, Dionna Glaze wrote:
> > This patch depends on Kirill A. Shutemov's series
> > 
> > [PATCHv8 00/14] mm, x86/cc: Implement support for unaccepted memory
> > 
> > The UEFI v2.9 specification includes a new memory type to be used in
> > environments where the OS must accept memory that is provided from its
> > host. Before the introduction of this memory type, all memory was
> > accepted eagerly in the firmware. In order for the firmware to safely
> > stop accepting memory on the OS's behalf, the OS must affirmatively
> > indicate support to the firmware.
> 
> I think it is a bad idea.
> 
> This approach breaks use case with a bootloader between BIOS and OS.
> As the bootloader does ExitBootServices() it has to make the call on
> behalf of OS when it has no idea if the OS supports unaccepted.

Nothing breaks, it'll error on the safe side.  If the protocol callback
is not called the firmware will simply accept all memory.  The guest OS
will only see unaccepted memory if it explicitly asked for it (assuming
the firmware wants know to support both cases, of course the firmware
could also enforce the one or the other and just not offer the
protocol).

> Note that kexec is such use-case: original kernel has to make a
> decision on whether it is okay to leave some memory unaccepted for the
> new kernel.

Not sure what you are trying to tell.  The kexec case doesn't go
through the efi stub anyway.

> And we add this protocol to address very temporary problem: once
> unaccepted memory support get upstream it is just a dead weight.

Maybe, maybe not.  unaccepted memory support has a Kconfig switch after
all.  If we figure in 3-5 years that all distros have enabled it anyway
we can drop it again.  For the transition period it will surely be
useful.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH] OvmfPkg: Create additional PML4 entries for large SEV-SNP VMs

2023-01-16 Thread Gerd Hoffmann

  Hi,

> (now that I check, all of this insane behavior seems to have been
> inherited from MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c. Sorry
> for the rant.)

We have UefiCpuPkg/Library/CpuPageTableLib meanwhile.

So switch the code over to use that instead, and reduce the number
of VirtualMemory.c copies floating around in the tree?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98566): https://edk2.groups.io/g/devel/message/98566
Mute This Topic: https://groups.io/mt/96250316/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 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

2023-01-16 Thread Ard Biesheuvel

Another question: how does this deviate from ordinary measured boot?
How and when are ACPI tables measured on such systems?


On Mon, 16 Jan 2023 at 03:42, Yao, Jiewen  wrote:
>
> Hi
> I have two feedback:
>
> 1) What we need measure is the input from VMM *before* any modification and 
> *before* installation.
> Please don't use ACPI SDT protocol to get the table *after* modification.
>
> 2) Why not use TpmMeasureAndLogData() in 
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Library/TpmMeasurementLib.h
>  ?
> Please don't use locate protocol.
>
> Thank you
> Yao, Jiewen
>
> > -Original Message-
> > From: Xu, Min M 
> > Sent: Monday, January 16, 2023 9:57 AM
> > To: devel@edk2.groups.io
> > Cc: Xu, Min M ; Aktas, Erdem
> > ; James Bottomley ; Yao,
> > Jiewen ; Gerd Hoffmann ;
> > Tom Lendacky ; Michael Roth
> > 
> > Subject: [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from
> > QEMU in TDVF
> >
> > From: Min M Xu 
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=4245
> >
> > The ACPI tables are downloaded from QEMU. QEMU/VMM is treated as
> > un-trusted in a td-guest. From the security perspective they should
> > be measured and extended if possible. So that they can be audited
> > later. The measurement protocol may be not installed. In this case
> > it still returns EFI_SUCCESS.
> >
> > Cc: Erdem Aktas 
> > Cc: James Bottomley 
> > Cc: Jiewen Yao 
> > Cc: Gerd Hoffmann 
> > Cc: Tom Lendacky 
> > Cc: Michael Roth 
> > Signed-off-by: Min Xu 
> > ---
> >  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   2 +
> >  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 168
> > 
> >  2 files changed, 170 insertions(+)
> >
> > diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > index 8939dde42549..ae22bab38cf9 100644
> > --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> > @@ -51,6 +51,8 @@
> >gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
> >gEfiPciIoProtocolGuid # PROTOCOL 
> > SOMETIMES_CONSUMED
> >gQemuAcpiTableNotifyProtocolGuid  # PROTOCOL PRODUCES
> > +  gEfiCcMeasurementProtocolGuid # PROTOCOL
> > SOMETIMES_CONSUMED
> > +  gEfiAcpiSdtProtocolGuid   # PROTOCOL
> > SOMETIMES_CONSUMED
> >
> >  [Guids]
> >gRootBridgesConnectedEventGroupGuid
> > diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > index f0d81d6fd73d..f442850c2e00 100644
> > --- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > +++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
> > @@ -18,6 +18,8 @@
> >  #include  // QemuFwCfgFindFile()
> >  #include// QemuFwCfgS3Enabled()
> >  #include  // gBS
> > +#include 
> > +#include 
> >
> >  #include "AcpiPlatform.h"
> >
> > @@ -812,12 +814,168 @@ UndoCmdWritePointer (
> >  ));
> >  }
> >
> > +/**
> > +  Mesure firmware ACPI table with CcMeasurement Protocol
> > +
> > +  @param[in] CcProtocol   Pointer to the CcMeasurment Protocol
> > +  @param[in] EventDataPointer to the event data.
> > +  @param[in] EventSizeSize of event data.
> > +  @param[in] CfgDataBase  Configuration data base address.
> > +  @param[in] EventSizeSize of configuration data .
> > +  @retval  EFI_NOT_FOUND   Cannot locate protocol.
> > +  @retval  EFI_OUT_OF_RESOURCESAllocate zero pool failure.
> > +  @return  Status codes returned by
> > +   mTcg2Protocol->HashLogExtendEvent.
> > +**/
> > +STATIC
> > +EFI_STATUS
> > +EFIAPI
> > +CcMeasureAcpiTable (
> > +  IN EFI_CC_MEASUREMENT_PROTOCOL  *CcProtocol,
> > +  IN CHAR8*EventData,
> > +  IN UINT32   EventSize,
> > +  IN EFI_PHYSICAL_ADDRESS CfgDataBase,
> > +  IN UINTNCfgDataLength
> > +  )
> > +{
> > +  EFI_STATUSStatus;
> > +  EFI_CC_EVENT  *CcEvent;
> > +  UINT32MrIndex;
> > +
> > +  if (CcProtocol == NULL) {
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> > +  Status = CcProtocol->MapPcrToMrIndex (CcProtocol, 1, &MrIndex);
> > +  if (EFI_ERROR (Status)) {
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> > +  CcEvent = AllocateZeroPool (EventSize + sizeof (EFI_CC_EVENT) - sizeof
> > (CcEvent->Event));
> > +  if (CcEvent == NULL) {
> > +return EFI_OUT_OF_RESOURCES;
> > +  }
> > +
> > +  CcEvent->Size = EventSize + sizeof (EFI_CC_EVENT) - 
> > sizeof
> > (CcEvent->Event);
> > +  CcEvent->Header.EventType = EV_PLATFORM_CONFIG_FLAGS;
> > +  CcEvent->Header.MrIndex   = MrIndex;
> > +  CcEvent->Header.HeaderSize= sizeof (EFI_CC_EVENT_HEADER);
> > +  CcEvent->Header.HeaderVersion = EFI_CC_EVENT_HEADER_VERSION;
> > +  CopyMem (&CcEvent->Event[0], EventData, EventSize);
> > +
> > +  Status = CcProtocol->HashLogExtendEvent (
> > +

Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior

2023-01-16 Thread Gerd Hoffmann

On Fri, Jan 13, 2023 at 10:34:15AM -0800, Dave Hansen wrote:
> On 1/13/23 10:23, Dionna Glaze via groups.io wrote:
> >> However, *NONE* of this points me in the direction of saying that we
> >> should have an OS/firmware protocol to negotiate whether the firmware or
> >> OS does page acceptance other than the existing UEFI memory map bit.
> > We know of distributions that are going to release SEV-SNP support
> > without unaccepted memory support,
> 
> Well, I guess that's a bit of a different problem.
> 
> I'd love to hear from the distros what they're planning on carrying
> outside of mainline and what their plans are for the kernel side of this
> series.

Fedora has near zero additional patches, so it pretty much depends on
how mainline merges stuff.  If SEV-SNP or TDX or both will land in an
upstream release before support for unaccepted memory lands too you'll
see that in Fedora kernels, and I guess likewise in most non-enterprise
distros.

RHEL/CentOS typically requires mainline acceptance too for backports, so
it likewise depends on upstream merging, and additionally rhel release
planning comes into play.  In case unaccepted memory support lands later
than TDX it could (depending on timing) very well be that the choices
are to either backport TDX without unaccepted memory support, or move
both TDX support and unaccepted memory support to a later release.

take care,
  Gerd

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

[edk2-devel] [PATCH 1/1] ArmVirt: don't use unaligned CopyMem () on NOR flash

2023-01-16 Thread Gerd Hoffmann

Fixes: e5ec3ba409b5 ("OvmfPkg/VirtNorFlashDxe: map flash memory as uncacheable")
Signed-off-by: Gerd Hoffmann 
---
 ArmVirtPkg/ArmVirtKvmTool.dsc| 6 +-
 ArmVirtPkg/ArmVirtQemu.dsc   | 6 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 6 +-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
index 2ba00bd08ff1..d0afe1b49e25 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -296,7 +296,11 @@ [Components.common]
   
NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
   }
 
-  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
+  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
+
+  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  }
 
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 5dd8b6104cca..0f1c6395488a 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -428,7 +428,11 @@ [Components.common]
 
   
NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
   }
-  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
+  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
+
+  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index f5db3ac432f3..807c85d48285 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -331,7 +331,11 @@ [Components.common]
 
   
NULL|ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.inf
   }
-  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
+  OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf {
+
+  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
   #
-- 
2.39.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98563): https://edk2.groups.io/g/devel/message/98563
Mute This Topic: https://groups.io/mt/96303660/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] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread Donald Kuo

Thanks Ray to clarify.

@Wang, William2 let's follow the EDK2 recommendation.   

Thanks,

-Original Message-
From: Ni, Ray  
Sent: Monday, January 16, 2023 5:19 PM
To: Kuo, Donald ; Wang, William2 
; devel@edk2.groups.io
Cc: Kinney, Michael D ; Gao, Liming 
; Kumar, Chandana C 
Subject: RE: [PATCH v2] Update CPUID Leaf 06H to follow latest SDM.

Donald,
Old code might reference existing Reserved field in the structure definition.
So, to avoid old code assigning value to different bits if using same field 
name but for different bits position,
edk2 recommends to change the field name from ReservedX to ReservedY when the 
bits covered by ReservedX are changed. Y is the next unused index.

So comments as below:

> 
> -UINT32Reserved5  : 11;
> 
> +UINT32Reserved4  : 2;
We should rename Reserved5 to Reserved6.

> 
> +UINT32IA32_THERM_INTERRUPT   : 1;
> 
> +UINT32Reserved5  : 7;
Reserved7.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98562): https://edk2.groups.io/g/devel/message/98562
Mute This Topic: https://groups.io/mt/96250318/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] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread Ni, Ray

Donald,
Old code might reference existing Reserved field in the structure definition.
So, to avoid old code assigning value to different bits if using same field 
name but for different bits position,
edk2 recommends to change the field name from ReservedX to ReservedY when the 
bits covered by ReservedX
are changed. Y is the next unused index.

So comments as below:

> 
> -UINT32Reserved5  : 11;
> 
> +UINT32Reserved4  : 2;
We should rename Reserved5 to Reserved6.


> 
> +UINT32IA32_THERM_INTERRUPT   : 1;
> 
> +UINT32Reserved5  : 7;
Reserved7.



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

Re: [edk2-devel] [PATCH v4] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread Donald Kuo

Thanks William

Looks good to me

Reviewed-by: Kuo, Donald donald@intel.com

-Original Message-
From: Wang, William2  
Sent: Monday, January 16, 2023 4:50 PM
To: devel@edk2.groups.io
Cc: Wang, William2 ; Kinney, Michael D 
; Gao, Liming ; Ni, Ray 
; Kuo, Donald ; Kumar, Chandana C 

Subject: [PATCH v4] Update CPUID Leaf 06H to follow latest SDM.

From: William2 Wang 

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

Update CPUID Leaf 06H to follow latest SDM.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
---
 MdePkg/Include/Register/Intel/Cpuid.h | 59 +++-
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Register/Intel/Cpuid.h 
b/MdePkg/Include/Register/Intel/Cpuid.h
index 350bf60252..9569a8805a 100644
--- a/MdePkg/Include/Register/Intel/Cpuid.h
+++ b/MdePkg/Include/Register/Intel/Cpuid.h
@@ -1195,12 +1195,24 @@ typedef union {
 /// [Bit 18] Fast access mode for the IA32_HWP_REQUEST MSR is supported if 
set.

 ///

 UINT32FastAccessMode : 1;

-UINT32Reserved4  : 1;

+///

+/// [Bit 19] IA32_HW_FEEDBACK_PTR MSR, IA32_HW_FEEDBACK_CONFIG MSR,

+/// IA32_PACKAGE_THERM_STATUS MSR bit 26, and IA32_PACKAGE_THERM_INTERRUPT 
MSR bit 25 are supported if set.

+UINT32HW_FEEDBACK: 1;

 ///

 /// [Bit 20] Ignoring Idle Logical Processor HWP request is supported if 
set.

 ///

 UINT32IgnoringIdleLogicalProcessorHWPRequest : 1;

-UINT32Reserved5  : 11;

+UINT32Reserved3  : 2;

+///

+/// [Bit 23] Intel Thread Director supported if set. IA32_HW_FEEDBACK_CHAR 
and

+/// IA32_HW_FEEDBACK_THREAD_CONFIG MSRs are supported if set.

+UINT32ThreadDirector : 1;

+///

+/// [Bit 24] IA32_THERM_INTERRUPT MSR bit 25 is supported if set.

+///

+UINT32IA32_THERM_INTERRUPT   : 1;

+UINT32Reserved4  : 7;

   } Bits;

   ///

   /// All bit fields as a 32-bit value

@@ -1252,7 +1264,13 @@ typedef union {
 /// (1B0H).

 ///

 UINT32PerformanceEnergyBias: 1;

-UINT32Reserved2: 28;

+UINT32Reserved2: 4;

+///

+/// {Bit 15:8] Number of Intel Thread Director classes supported by the 
processor. Information for that

+/// many classes is written into the Intel Thread Director Table by the 
hardware.

+///

+UINT32ThreadDirectorClasses: 8;

+UINT32Reserved3: 16;

   } Bits;

   ///

   /// All bit fields as a 32-bit value

@@ -1260,6 +1278,41 @@ typedef union {
   UINT32Uint32;

 } CPUID_THERMAL_POWER_MANAGEMENT_ECX;

 

+/**

+  CPUID Thermal and Power Management Information returned in EDX for CPUID leaf

+  #CPUID_THERMAL_POWER_MANAGEMENT.

+**/

+typedef union {

+  ///

+  /// Individual bit fields

+  ///

+  struct {

+///

+/// {Bits 7:0] Bitmap of supported hardware feedback interface 
capabilities.

+///   0 = When set to 1, indicates support for performance capability 
reporting.

+///   1 = When set to 1, indicates support for energy efficiency 
capability reporting.

+///   2-7 = Reserved

+///

+UINT32InterfaceCapability  : 8;

+///

+/// {Bits 11:8] Enumerates the size of the hardware feedback interface 
structure in number of 4 KB pages;

+/// add one to the return value to get the result.

+///

+UINT32InterfaceStructureSize   : 4;

+UINT32Reserved : 4;

+///

+/// {Bits 31:16] : Index (starting at 0) of this logical processor's row 
in the hardware feedback interface structure.

+/// Note that on some parts the index may be same for multiple logical 
processors. On some parts the

+/// indices may not be contiguous, i.e., there may be unused rows in the 
hardware feedback interface structure.

+///

+UINT32LogicalProcessorRowIndex : 16;

+  } Bits;

+  ///

+  /// All bit fields as a 32-bit value

+  ///

+  UINT32Uint32;

+} CPUID_THERMAL_POWER_MANAGEMENT_EDX;

+

 /**

   CPUID Structured Extended Feature Flags Enumeration

 

-- 
2.34.1.windows.1



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

[edk2-devel] [PATCH v4] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread william2 . wang

From: William2 Wang 

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

Update CPUID Leaf 06H to follow latest SDM.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
---
 MdePkg/Include/Register/Intel/Cpuid.h | 59 +++-
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Register/Intel/Cpuid.h 
b/MdePkg/Include/Register/Intel/Cpuid.h
index 350bf60252..9569a8805a 100644
--- a/MdePkg/Include/Register/Intel/Cpuid.h
+++ b/MdePkg/Include/Register/Intel/Cpuid.h
@@ -1195,12 +1195,24 @@ typedef union {
 /// [Bit 18] Fast access mode for the IA32_HWP_REQUEST MSR is supported if 
set.
 ///
 UINT32FastAccessMode : 1;
-UINT32Reserved4  : 1;
+///
+/// [Bit 19] IA32_HW_FEEDBACK_PTR MSR, IA32_HW_FEEDBACK_CONFIG MSR,
+/// IA32_PACKAGE_THERM_STATUS MSR bit 26, and IA32_PACKAGE_THERM_INTERRUPT 
MSR bit 25 are supported if set.
+UINT32HW_FEEDBACK: 1;
 ///
 /// [Bit 20] Ignoring Idle Logical Processor HWP request is supported if 
set.
 ///
 UINT32IgnoringIdleLogicalProcessorHWPRequest : 1;
-UINT32Reserved5  : 11;
+UINT32Reserved3  : 2;
+///
+/// [Bit 23] Intel Thread Director supported if set. IA32_HW_FEEDBACK_CHAR 
and
+/// IA32_HW_FEEDBACK_THREAD_CONFIG MSRs are supported if set.
+UINT32ThreadDirector : 1;
+///
+/// [Bit 24] IA32_THERM_INTERRUPT MSR bit 25 is supported if set.
+///
+UINT32IA32_THERM_INTERRUPT   : 1;
+UINT32Reserved4  : 7;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
@@ -1252,7 +1264,13 @@ typedef union {
 /// (1B0H).
 ///
 UINT32PerformanceEnergyBias: 1;
-UINT32Reserved2: 28;
+UINT32Reserved2: 4;
+///
+/// {Bit 15:8] Number of Intel Thread Director classes supported by the 
processor. Information for that
+/// many classes is written into the Intel Thread Director Table by the 
hardware.
+///
+UINT32ThreadDirectorClasses: 8;
+UINT32Reserved3: 16;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
@@ -1260,6 +1278,41 @@ typedef union {
   UINT32Uint32;
 } CPUID_THERMAL_POWER_MANAGEMENT_ECX;
 
+/**
+  CPUID Thermal and Power Management Information returned in EDX for CPUID leaf
+  #CPUID_THERMAL_POWER_MANAGEMENT.
+**/
+typedef union {
+  ///
+  /// Individual bit fields
+  ///
+  struct {
+///
+/// {Bits 7:0] Bitmap of supported hardware feedback interface 
capabilities.
+///   0 = When set to 1, indicates support for performance capability 
reporting.
+///   1 = When set to 1, indicates support for energy efficiency 
capability reporting.
+///   2-7 = Reserved
+///
+UINT32InterfaceCapability  : 8;
+///
+/// {Bits 11:8] Enumerates the size of the hardware feedback interface 
structure in number of 4 KB pages;
+/// add one to the return value to get the result.
+///
+UINT32InterfaceStructureSize   : 4;
+UINT32Reserved : 4;
+///
+/// {Bits 31:16] : Index (starting at 0) of this logical processor's row 
in the hardware feedback interface structure.
+/// Note that on some parts the index may be same for multiple logical 
processors. On some parts the
+/// indices may not be contiguous, i.e., there may be unused rows in the 
hardware feedback interface structure.
+///
+UINT32LogicalProcessorRowIndex : 16;
+  } Bits;
+  ///
+  /// All bit fields as a 32-bit value
+  ///
+  UINT32Uint32;
+} CPUID_THERMAL_POWER_MANAGEMENT_EDX;
+
 /**
   CPUID Structured Extended Feature Flags Enumeration
 
-- 
2.34.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98559): https://edk2.groups.io/g/devel/message/98559
Mute This Topic: https://groups.io/mt/96303267/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] Update Architecture MSR to follow latest SDM.

2023-01-16 Thread Donald Kuo

Hi William

Looks good to me

Reviewed-by: Kuo, Donald donald@intel.com


-Original Message-
From: Wang, William2  
Sent: Friday, January 13, 2023 4:22 PM
To: devel@edk2.groups.io
Cc: Wang, William2 ; Kinney, Michael D 
; Gao, Liming ; Ni, Ray 
; Kuo, Donald ; Kumar, Chandana C 

Subject: [PATCH v2] Update Architecture MSR to follow latest SDM.

From: William2 Wang 

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

Update Architecture MSR contains the MSR10A.BIT23 and
MSR195.BIT2-0 for overclocking undervolt protection.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
---
 MdePkg/Include/Register/Intel/ArchitecturalMsr.h | 198 
 1 file changed, 198 insertions(+)

diff --git a/MdePkg/Include/Register/Intel/ArchitecturalMsr.h 
b/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
index 071a8c689c..f548b56672 100644
--- a/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
+++ b/MdePkg/Include/Register/Intel/ArchitecturalMsr.h
@@ -682,6 +682,149 @@ typedef union {
   UINT64Uint64;

 } MSR_IA32_MTRRCAP_REGISTER;

 

+/**

+  Enumeration of Architectural Features (R/O). If CPUID.(EAX=07H, 
ECX=0):EDX[29]=1.

+

+  @param  ECX  IA32_ARCH_CAPABILITIES (0x010A)

+  @param  EAX  Lower 32-bits of MSR value.

+   Described by the type IA32_ARCH_CAPABILITIES_REGISTER.

+  @param  EDX  Upper 32-bits of MSR value.

+   Described by the type IA32_ARCH_CAPABILITIES_REGISTER.

+

+  Example usage

+  @code

+  IA32_ARCH_CAPABILITIES_REGISTER  Msr;

+

+  Msr.Uint64 = AsmReadMsr64 (IA32_ARCH_CAPABILITIES);

+  @endcode

+  @note IA32_ARCH_CAPABILITIES is defined as IA32_ARCH_CAPABILITIES in SDM.

+**/

+#define IA32_ARCH_CAPABILITIES  0x010A

+

+/**

+  MSR information returned for MSR index #IA32_ARCH_CAPABILITIES

+**/

+typedef union {

+  ///

+  /// Individual bit fields

+  ///

+  struct {

+///

+/// [Bits 0]  RDCL_NO: The processor is not susceptible to Rogue Data 
Cache Load (RDCL).

+///

+UINT32RDCL_NO  : 1;

+///

+/// [Bit 1] IBRS_ALL: The processor supports enhanced IBRS.

+///

+UINT32IBRS_ALL : 1;

+///

+/// [Bit 2] RSBA: The processor supports RSB Alternate. Alternative branch 
predictors

+/// may be used by RET instructions when the RSB is empty. SW using 
retpoline may be

+/// affected by this behavior.

+///

+UINT32RSBA : 1;

+///

+/// [Bit 3] SKIP_L1DFL_VMENTRY: A value of 1 indicates the hypervisor need 
not flush the

+/// L1D on VM entry.

+///

+UINT32SKIP_L1DFL_VMENTRY   : 1;

+///

+/// [Bit 4] SSB_NO: Processor is not susceptible to Speculative Store 
Bypass.

+///

+UINT32SSB_NO   : 1;

+///

+/// [Bit 5] MDS_NO: Processor is not susceptible to Microarchitectural 
Data Sampling (MDS).

+///

+UINT32MDS_NO   : 1;

+///

+/// [Bit 6] IF_PSCHANGE_MC_NO: The processor is not susceptible to a 
machine check error due to

+/// modifying the size of a code page without TLB invalidation.

+///

+UINT32IF_PSCHANGE_MC_NO: 1;

+///

+/// [Bit 7] TSX_CTRL: If 1, indicates presence of IA32_TSX_CTRL MSR.

+///

+UINT32TSX_CTRL : 1;

+///

+/// [Bit 8] TAA_NO: If 1, processor is not affected by TAA.

+///

+UINT32TAA_NO   : 1;

+UINT32Reserved1: 1;

+///

+/// [Bit 10] MISC_PACKAGE_CTLS: The processor supports 
IA32_MISC_PACKAGE_CTLS MSR.

+///

+UINT32MISC_PACKAGE_CTLS: 1;

+///

+/// [Bit 11] ENERGY_FILTERING_CTL: The processor supports setting and 
reading the

+/// IA32_MISC_PACKAGE_CTLS[0] (ENERGY_FILTERING_ENABLE) bit.

+///

+UINT32ENERGY_FILTERING_CTL : 1;

+///

+/// [Bit 12] DOITM: If 1, the processor supports Data Operand Independent 
Timing Mode.

+///

+UINT32DOITM: 1;

+///

+/// [Bit 13] SBDR_SSDP_NO: The processor is not affected by either the 
Shared Buffers Data

+/// Read (SBDR) vulnerability or the Sideband Stale Data Propagator (SSDP).

+///

+UINT32SBDR_SSDP_NO : 1;

+///

+/// [Bit 14] FBSDP_NO: The processor is not affected by the Fill Buffer 
Stale Data Propagator (FBSDP).

+///

+UINT32FBSDP_NO : 1;

+///

+/// [Bit 15] PSDP_NO: The processor is not affected by vulnerabilities 
involving the Primary Stale Data Propagator (PSDP).

+///

+UINT32PSDP_NO  : 1;

+UINT32Reserved2: 1;

+///

+/// [Bit 17] FB_CLEAR: If 1, the processor supports overwrite of fill 
buffer values as part of MD_CLEAR operations

+/// with the VERW instruction.

+///

+UINT32FB_CLEAR : 1;

+///

+/// [Bit 18] FB_CLEAR_CTRL: If 1, the processor supports the

Re: [edk2-devel] [PATCH v2] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread Donald Kuo

Hi William

Overall looks good to me.

1. For EAX: Can we change Reserved4 & 5 to Reserved3 & 4, since only 4 reserved.

2. For EDX: Bits [7:0], how about to add more detail description for BIT0 and 
BIT1, and BIT [7:2] = Reserved to align with SDM


+/// {Bits 7:0] Bitmap of supported hardware feedback interface 
capabilities.

+///

+UINT32InterfaceCapability  : 8;

Thanks,





-Original Message-
From: Wang, William2  
Sent: Friday, January 13, 2023 4:26 PM
To: devel@edk2.groups.io
Cc: Wang, William2 ; Kinney, Michael D 
; Gao, Liming ; Ni, Ray 
; Kuo, Donald ; Kumar, Chandana C 

Subject: [PATCH v2] Update CPUID Leaf 06H to follow latest SDM.

From: William2 Wang 

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

Update CPUID Leaf 06H to follow latest SDM.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
---
 MdePkg/Include/Register/Intel/Cpuid.h | 56 ++--
 1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Register/Intel/Cpuid.h 
b/MdePkg/Include/Register/Intel/Cpuid.h
index 350bf60252..46cdb827e2 100644
--- a/MdePkg/Include/Register/Intel/Cpuid.h
+++ b/MdePkg/Include/Register/Intel/Cpuid.h
@@ -1195,12 +1195,24 @@ typedef union {
 /// [Bit 18] Fast access mode for the IA32_HWP_REQUEST MSR is supported if 
set.

 ///

 UINT32FastAccessMode : 1;

-UINT32Reserved4  : 1;

+///

+/// [Bit 19] IA32_HW_FEEDBACK_PTR MSR, IA32_HW_FEEDBACK_CONFIG MSR,

+/// IA32_PACKAGE_THERM_STATUS MSR bit 26, and IA32_PACKAGE_THERM_INTERRUPT 
MSR bit 25 are supported if set.

+UINT32HW_FEEDBACK: 1;

 ///

 /// [Bit 20] Ignoring Idle Logical Processor HWP request is supported if 
set.

 ///

 UINT32IgnoringIdleLogicalProcessorHWPRequest : 1;

-UINT32Reserved5  : 11;

+UINT32Reserved4  : 2;

+///

+/// [Bit 23] Intel Thread Director supported if set. IA32_HW_FEEDBACK_CHAR 
and

+/// IA32_HW_FEEDBACK_THREAD_CONFIG MSRs are supported if set.

+UINT32ThreadDirector : 1;

+///

+/// [Bit 24] IA32_THERM_INTERRUPT MSR bit 25 is supported if set.

+///

+UINT32IA32_THERM_INTERRUPT   : 1;

+UINT32Reserved5  : 7;

   } Bits;

   ///

   /// All bit fields as a 32-bit value

@@ -1252,7 +1264,13 @@ typedef union {
 /// (1B0H).

 ///

 UINT32PerformanceEnergyBias: 1;

-UINT32Reserved2: 28;

+UINT32Reserved2: 4;

+///

+/// {Bit 15:8] Number of Intel Thread Director classes supported by the 
processor. Information for that

+/// many classes is written into the Intel Thread Director Table by the 
hardware.

+///

+UINT32ThreadDirectorClasses: 8;

+UINT32Reserved3: 16;

   } Bits;

   ///

   /// All bit fields as a 32-bit value

@@ -1260,6 +1278,38 @@ typedef union {
   UINT32Uint32;

 } CPUID_THERMAL_POWER_MANAGEMENT_ECX;

 

+/**

+  CPUID Thermal and Power Management Information returned in EDX for CPUID leaf

+  #CPUID_THERMAL_POWER_MANAGEMENT.

+**/

+typedef union {

+  ///

+  /// Individual bit fields

+  ///

+  struct {

+///

+/// {Bits 7:0] Bitmap of supported hardware feedback interface 
capabilities.

+///

+UINT32InterfaceCapability  : 8;

+///

+/// {Bits 11:8] Enumerates the size of the hardware feedback interface 
structure in number of 4 KB pages;

+/// add one to the return value to get the result.

+///

+UINT32InterfaceStructureSize   : 4;

+UINT32Reserved : 4;

+///

+/// {Bits 31:16] : Index (starting at 0) of this logical processor's row 
in the hardware feedback interface structure.

+/// Note that on some parts the index may be same for multiple logical 
processors. On some parts the

+/// indices may not be contiguous, i.e., there may be unused rows in the 
hardware feedback interface structure.

+///

+UINT32LogicalProcessorRowIndex : 16;

+  } Bits;

+  ///

+  /// All bit fields as a 32-bit value

+  ///

+  UINT32Uint32;

+} CPUID_THERMAL_POWER_MANAGEMENT_EDX;

+

 /**

   CPUID Structured Extended Feature Flags Enumeration

 

-- 
2.34.1.windows.1



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

[edk2-devel] [PATCH v3] Update CPUID Leaf 06H to follow latest SDM.

2023-01-16 Thread william2 . wang

From: William2 Wang 

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

Update CPUID Leaf 06H to follow latest SDM.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
---
 MdePkg/Include/Register/Intel/Cpuid.h | 56 ++--
 1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Register/Intel/Cpuid.h 
b/MdePkg/Include/Register/Intel/Cpuid.h
index 350bf60252..5fb316f7a1 100644
--- a/MdePkg/Include/Register/Intel/Cpuid.h
+++ b/MdePkg/Include/Register/Intel/Cpuid.h
@@ -1195,12 +1195,24 @@ typedef union {
 /// [Bit 18] Fast access mode for the IA32_HWP_REQUEST MSR is supported if 
set.
 ///
 UINT32FastAccessMode : 1;
-UINT32Reserved4  : 1;
+///
+/// [Bit 19] IA32_HW_FEEDBACK_PTR MSR, IA32_HW_FEEDBACK_CONFIG MSR,
+/// IA32_PACKAGE_THERM_STATUS MSR bit 26, and IA32_PACKAGE_THERM_INTERRUPT 
MSR bit 25 are supported if set.
+UINT32HW_FEEDBACK: 1;
 ///
 /// [Bit 20] Ignoring Idle Logical Processor HWP request is supported if 
set.
 ///
 UINT32IgnoringIdleLogicalProcessorHWPRequest : 1;
-UINT32Reserved5  : 11;
+UINT32Reserved3  : 2;
+///
+/// [Bit 23] Intel Thread Director supported if set. IA32_HW_FEEDBACK_CHAR 
and
+/// IA32_HW_FEEDBACK_THREAD_CONFIG MSRs are supported if set.
+UINT32ThreadDirector : 1;
+///
+/// [Bit 24] IA32_THERM_INTERRUPT MSR bit 25 is supported if set.
+///
+UINT32IA32_THERM_INTERRUPT   : 1;
+UINT32Reserved4  : 7;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
@@ -1252,7 +1264,13 @@ typedef union {
 /// (1B0H).
 ///
 UINT32PerformanceEnergyBias: 1;
-UINT32Reserved2: 28;
+UINT32Reserved2: 4;
+///
+/// {Bit 15:8] Number of Intel Thread Director classes supported by the 
processor. Information for that
+/// many classes is written into the Intel Thread Director Table by the 
hardware.
+///
+UINT32ThreadDirectorClasses: 8;
+UINT32Reserved3: 16;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
@@ -1260,6 +1278,38 @@ typedef union {
   UINT32Uint32;
 } CPUID_THERMAL_POWER_MANAGEMENT_ECX;
 
+/**
+  CPUID Thermal and Power Management Information returned in EDX for CPUID leaf
+  #CPUID_THERMAL_POWER_MANAGEMENT.
+**/
+typedef union {
+  ///
+  /// Individual bit fields
+  ///
+  struct {
+///
+/// {Bits 7:0] Bitmap of supported hardware feedback interface 
capabilities.
+///
+UINT32InterfaceCapability  : 8;
+///
+/// {Bits 11:8] Enumerates the size of the hardware feedback interface 
structure in number of 4 KB pages;
+/// add one to the return value to get the result.
+///
+UINT32InterfaceStructureSize   : 4;
+UINT32Reserved : 4;
+///
+/// {Bits 31:16] : Index (starting at 0) of this logical processor's row 
in the hardware feedback interface structure.
+/// Note that on some parts the index may be same for multiple logical 
processors. On some parts the
+/// indices may not be contiguous, i.e., there may be unused rows in the 
hardware feedback interface structure.
+///
+UINT32LogicalProcessorRowIndex : 16;
+  } Bits;
+  ///
+  /// All bit fields as a 32-bit value
+  ///
+  UINT32Uint32;
+} CPUID_THERMAL_POWER_MANAGEMENT_EDX;
+
 /**
   CPUID Structured Extended Feature Flags Enumeration
 
-- 
2.34.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98556): https://edk2.groups.io/g/devel/message/98556
Mute This Topic: https://groups.io/mt/96303214/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/1] OvmfPkg/VirtNorFlashDxe: map flash memory as uncacheable

2023-01-16 Thread Ard Biesheuvel

On Mon, 16 Jan 2023 at 07:38, Gerd Hoffmann  wrote:
>
> On Thu, Jan 12, 2023 at 11:20:00AM +0100, Ard Biesheuvel wrote:
> > On Wed, 11 Jan 2023 at 19:00, Gerd Hoffmann  wrote:
> > >
> > > Switching from the ArmPlatformPkg/NorFlashDxe driver to the
> > > OvmfPkg/VirtNorFlashDxe driver had the side effect that flash address
> > > space got registered as EFI_MEMORY_WC instead of EFI_MEMORY_UC.
> > >
> > > That confuses the linux kernel's numa code, seems this makes kernel
> > > consider the flash being node memory.  "lsmem" changes from ...
> > >
> > > RANGE SIZE  STATE REMOVABLE BLOCK
> > > 0x4000-0x00013fff   4G online   yes  8-39
> > >
> > > ... to ...
> > >
> > > RANGE  SIZE  STATE REMOVABLE BLOCK
> > > 0x-0x07ff  128M online   yes 0
> > > 0x4000-0x00013fff4G online   yes  8-39
> > >
> > > ... and in the kernel log got new error lines:
> > >
> > > NUMA: Warning: invalid memblk node 512 [mem 
> > > 0x0400-0x07ff]
> > > NUMA: Faking a node at [mem 0x0400-0x00013fff]
> > >
> > > Changing the attributes back to EFI_MEMORY_UC fixes this.
> > >
> > > Fixes: b92298af8218 ("ArmVirtPkg/ArmVirtQemu: migrate to OVMF's 
> > > VirtNorFlashDxe")
> > > Signed-off-by: Gerd Hoffmann 
> >
> > Reviewed-by: Ard Biesheuvel 
>
> Laszlo pointed me to commit 789a72328553 ("OvmfPkg/VirtNorFlashDxe: use
> EFI_MEMORY_WC and drop AlignedCopyMem()") and I'm wondering whenever we
> need to also bring back AlignedCopyMem, or is it safe to use CopyMem
> because we know we operate on virtual hardware?
>

Ugh, thanks for spotting that.

So there is one occurrence of CopyMem() that may operate on a device
region with a misaligned address, and this is the one in
NorFlashRead(). This call is made while the flash is in array mode,
and so the device region is backed by a KVM memslot at that point, and
a misaligned load or store will trigger a fault.

We already swap out the optimized BaseMemoryLib for the generic one
when building VariableRuntimeDxe, and so the best course of action
here is probably to do the same for NorFlashDxe, rather than bringing
back AlignedCopyMem.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98555): https://edk2.groups.io/g/devel/message/98555
Mute This Topic: https://groups.io/mt/96205414/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 4/4] OvmfPkg/SmmCpuFeaturesLib: Skip to configure SMBASE

2023-01-16 Thread Gerd Hoffmann

On Fri, Jan 13, 2023 at 11:30:45PM +0800, Jiaxin Wu wrote:
> This patch is to avoid configure SMBASE if SmBase relocation has been
> done. If gSmmBaseHobGuid found, means SmBase info has been relocated
> and recorded in the SmBase array. No need to do the relocation in
> SmmCpuFeaturesInitializeProcessor().

You will not find a gSmmBaseHobGuid HOB if you don't produce it
somewhere.

take care,
  Gerd



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

1 2 >

100 matches

Mail list logo