[edk2-devel] [PATCH v2 2/2] OvmfPkg/IntelGvtGopDxe: Enable GVT-g GOP in OvmfPkg DSC & DFD.

[Colin Xu]

Intel GVT-g is already enabled by default in upstream kernel.

V2:
Refresh.

Signed-off-by: Colin Xu 
---
 OvmfPkg/OvmfPkgX64.dsc | 4 
 OvmfPkg/OvmfPkgX64.fdf | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fabb8b2f29e4..971fd262151b 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -52,6 +52,7 @@
   DEFINE PVSCSI_ENABLE   = TRUE
   DEFINE MPT_SCSI_ENABLE = TRUE
   DEFINE LSI_SCSI_ENABLE = FALSE
+  DEFINE INTEL_GVT_KVMGT_ENABLE  = TRUE
 
   #
   # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
@@ -808,6 +809,9 @@
 !endif
 !if $(LSI_SCSI_ENABLE) == TRUE
   OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf
+!endif
+!if $(INTEL_GVT_KVMGT_ENABLE) == TRUE
+  OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
 !endif
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index d519f8532822..6d0bcf3fcd31 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -252,6 +252,9 @@ INF  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
 !if $(LSI_SCSI_ENABLE) == TRUE
 INF  OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf
 !endif
+!if $(INTEL_GVT_KVMGT_ENABLE) == TRUE
+INF  OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
+!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF  
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-- 
2.30.1

[edk2-devel] [PATCH v2 0/2] OvmfPkg/IntelGvtGopDxe: Add Intel GVT-g GOP.

[Colin Xu]

This patch set add Intel GVT-g GOP DXE to OvmfPkg.

V2:
Program PIPESRC to match active H/V.

Colin Xu (2):
  OvmfPkg/IntelGvtGopDxe: Intel GVT-g GOP Implementation.
  OvmfPkg/IntelGvtGopDxe: Enable GVT-g GOP in OvmfPkg DSC & DFD.

 OvmfPkg/IntelGvtGopDxe/Common.h   |   45 +
 OvmfPkg/IntelGvtGopDxe/DebugHelper.h  |   20 +
 OvmfPkg/IntelGvtGopDxe/Display.c  | 1077 +
 OvmfPkg/IntelGvtGopDxe/Display.h  |  141 +++
 OvmfPkg/IntelGvtGopDxe/GopDriver.c|  478 +
 OvmfPkg/IntelGvtGopDxe/GpuReg.c   |   91 ++
 OvmfPkg/IntelGvtGopDxe/GpuReg.h   |  175 
 OvmfPkg/IntelGvtGopDxe/Gtt.c  |  162 
 OvmfPkg/IntelGvtGopDxe/Gtt.h  |   51 +
 OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf |   59 ++
 OvmfPkg/IntelGvtGopDxe/VbeShim.asm|  343 +++
 OvmfPkg/IntelGvtGopDxe/VbeShim.c  |  258 +
 OvmfPkg/IntelGvtGopDxe/VbeShim.h  |  912 +
 OvmfPkg/IntelGvtGopDxe/VbeShim.sh |   81 ++
 OvmfPkg/IntelGvtGopDxe/VirtualGpu.c   |  400 
 OvmfPkg/IntelGvtGopDxe/VirtualGpu.h   |   52 +
 OvmfPkg/OvmfPkgX64.dsc|4 +
 OvmfPkg/OvmfPkgX64.fdf|3 +
 18 files changed, 4352 insertions(+)
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Common.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/DebugHelper.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Display.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Display.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/GopDriver.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/GpuReg.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/GpuReg.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Gtt.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Gtt.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.asm
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.h
 create mode 100755 OvmfPkg/IntelGvtGopDxe/VbeShim.sh
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VirtualGpu.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VirtualGpu.h

-- 
2.30.1

Re: [edk2-devel] [PATCH 0/2] OvmfPkg/IntelGvtGopDxe: Add Intel GVT-g GOP.

[Colin Xu]

Will fix transferEncoding and re-send.

--
Best Regards,
Colin Xu

On Fri, 5 Mar 2021, Colin Xu wrote:


This patch set add Intel GVT-g GOP DXE to OvmfPkg.

Colin Xu (2):
 OvmfPkg/IntelGvtGopDxe: Intel GVT-g GOP Implementation.
 OvmfPkg/IntelGvtGopDxe: Enable GVT-g GOP in OvmfPkg DSC & DFD.

OvmfPkg/IntelGvtGopDxe/Common.h   |   45 +
OvmfPkg/IntelGvtGopDxe/DebugHelper.h  |   20 +
OvmfPkg/IntelGvtGopDxe/Display.c  | 1073 +
OvmfPkg/IntelGvtGopDxe/Display.h  |  141 +++
OvmfPkg/IntelGvtGopDxe/GopDriver.c|  478 +
OvmfPkg/IntelGvtGopDxe/GpuReg.c   |   91 ++
OvmfPkg/IntelGvtGopDxe/GpuReg.h   |  173 
OvmfPkg/IntelGvtGopDxe/Gtt.c  |  162 
OvmfPkg/IntelGvtGopDxe/Gtt.h  |   51 +
OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf |   59 ++
OvmfPkg/IntelGvtGopDxe/VbeShim.asm|  343 +++
OvmfPkg/IntelGvtGopDxe/VbeShim.c  |  258 +
OvmfPkg/IntelGvtGopDxe/VbeShim.h  |  912 +
OvmfPkg/IntelGvtGopDxe/VbeShim.sh |   81 ++
OvmfPkg/IntelGvtGopDxe/VirtualGpu.c   |  400 
OvmfPkg/IntelGvtGopDxe/VirtualGpu.h   |   52 +
OvmfPkg/OvmfPkgX64.dsc|4 +
OvmfPkg/OvmfPkgX64.fdf|3 +
18 files changed, 4346 insertions(+)
create mode 100644 OvmfPkg/IntelGvtGopDxe/Common.h
create mode 100644 OvmfPkg/IntelGvtGopDxe/DebugHelper.h
create mode 100644 OvmfPkg/IntelGvtGopDxe/Display.c
create mode 100644 OvmfPkg/IntelGvtGopDxe/Display.h
create mode 100644 OvmfPkg/IntelGvtGopDxe/GopDriver.c
create mode 100644 OvmfPkg/IntelGvtGopDxe/GpuReg.c
create mode 100644 OvmfPkg/IntelGvtGopDxe/GpuReg.h
create mode 100644 OvmfPkg/IntelGvtGopDxe/Gtt.c
create mode 100644 OvmfPkg/IntelGvtGopDxe/Gtt.h
create mode 100644 OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.asm
create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.c
create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.h
create mode 100755 OvmfPkg/IntelGvtGopDxe/VbeShim.sh
create mode 100644 OvmfPkg/IntelGvtGopDxe/VirtualGpu.c
create mode 100644 OvmfPkg/IntelGvtGopDxe/VirtualGpu.h

--
2.30.1










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

Re: [edk2-devel] [PATCH v6 0/7] Add MmUnblockMemoryLib Interface and Usages

[Kun Qin]

Hi,

Thanks to all the reviewers helping through this patch series. Each individual 
patch has received reviewed-by tag in this v6 version. It has also just passed 
all CI build tests here: Unblock mem v6 by kuqin12 · Pull Request #1473 · 
tianocore/edk2 (github.com) Could 
one of the maintainers help to merge these patches into the mainline when you 
have a chance?

Please let me know if there is anything needed from me to merge in these 
patches. Thanks in advance!

Regards,
Kun

From: Kun Qin
Sent: Thursday, March 4, 2021 20:13
To: devel@edk2.groups.io
Cc: Michael D Kinney; Liming 
Gao; Zhiguang 
Liu; Jiewen Yao; 
Jian J Wang; Hao A Wu; 
Laszlo Ersek; Ard 
Biesheuvel; Jordan 
Justen; Qi Zhang; 
Rahul Kumar
Subject: [edk2-devel] [PATCH v6 0/7] Add MmUnblockMemoryLib Interface and Usages

This patch series is a follow up of previous submission:
https://edk2.groups.io/g/devel/message/72442

v6 patches mainly focus on feedback for reviewed commits in v5 patches,
including:
a. Adding "Reviewed-by" and "Acked-by" tags for applicable patch;
b. Updating library class description for newly added interface;

Patch v6 branch: https://github.com/kuqin12/edk2/tree/unblock_mem_v6

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Kun Qin (7):
  MdePkg: MmUnblockMemoryLib: Added definition and null instance
  OvmfPkg: resolve MmUnblockMemoryLib (mainly for VariableSmmRuntimeDxe)
  MdeModulePkg: VariableSmmRuntimeDxe: Added request unblock memory
interface
  SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst
  SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2 modules
  SecurityPkg: Tcg2Smm: Added support for Standalone Mm
  SecurityPkg: Tcg2Acpi: Added unblock memory interface for NVS region

 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c   |  42 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   |  44 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c}   | 362 
-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c|  48 ++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c| 857 

 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c   |  71 ++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c  |  82 ++
 MdeModulePkg/MdeModulePkg.dsc|   1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf |   1 +
 MdePkg/Include/Library/MmUnblockMemoryLib.h  |  44 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf |  34 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni |  21 +
 MdePkg/MdePkg.dec|   5 +
 MdePkg/MdePkg.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.dsc  |   3 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   3 +
 OvmfPkg/OvmfPkgX64.dsc   |   3 +
 SecurityPkg/Include/Guid/TpmNvsMm.h  |  68 ++
 SecurityPkg/SecurityPkg.ci.yaml  |   1 +
 SecurityPkg/SecurityPkg.dec  |   8 +
 SecurityPkg/SecurityPkg.dsc  |  12 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf}   |  35 +-
 SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl|   0
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf  |  43 +
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h| 121 +--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf  |  27 +-
 SecurityPkg/Tcg/Tcg2Smm/{Tcg2Smm.inf => Tcg2StandaloneMm.inf}|  50 +-
 27 files changed, 952 insertions(+), 1035 deletions(-)
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
 copy SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c} (72%)
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c
 create mode 100644 MdePkg/Include/Library/MmUnblockMemoryLib.h
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 create mode 100644 

[edk2-devel] [PATCH v6 7/7] SecurityPkg: Tcg2Acpi: Added unblock memory interface for NVS region

[Kun Qin]

This changes added usage of MmUnblockMemoryLib to explicitly request
allocated NVS region to be accessible from MM environment. It will bring
in compatibility with architectures that supports full memory blockage
inside MM.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v6:
- Previously reviewed, no change.

v5:
- Previously reviewed, no change.

v4:
- Previously reviewed, no change.

v3:
- Added review-by tag. [Jiewen]
- Remove Dxe prefix to match interface update. [Jiewen]

v2:
- Newly added in v2.

 SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c   | 6 ++
 SecurityPkg/SecurityPkg.dsc   | 1 +
 SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf | 1 +
 3 files changed, 8 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c 
b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
index 924c3b4edda6..e8844e474a9b 100644
--- a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
+++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
@@ -38,6 +38,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 //
 // Physical Presence Interface Version supported by Platform
@@ -147,6 +148,11 @@ AssignOpRegion (
   ZeroMem ((VOID *)(UINTN)MemoryAddress, Size);
   OpRegion->RegionOffset = (UINT32) (UINTN) MemoryAddress;
   OpRegion->RegionLen= (UINT8) Size;
+  // Request to unblock this region from MM core
+  Status = MmUnblockMemoryRequest (MemoryAddress, EFI_SIZE_TO_PAGES 
(Size));
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+  }
   break;
 }
   }
diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index 74ec42966273..a77665518bdd 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -67,6 +67,7 @@ [LibraryClasses]
   VariableKeyLib|SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf
   RpmcLib|SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf
   
TcgEventLogRecordLib|SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.inf
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 
 [LibraryClasses.ARM]
   #
diff --git a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf 
b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
index 42ddb4bd1f39..f1c6ae5b1cb4 100644
--- a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
+++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
@@ -57,6 +57,7 @@ [LibraryClasses]
   Tpm2CommandLib
   Tcg2PhysicalPresenceLib
   PcdLib
+  MmUnblockMemoryLib
 
 [Guids]
   gEfiTpmDeviceInstanceTpm20DtpmGuid## PRODUCES
   ## GUID   # TPM device identifier
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v6 6/7] SecurityPkg: Tcg2Smm: Added support for Standalone Mm

[Kun Qin]

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

This change added Standalone MM instance of Tcg2. The notify function for
Standalone MM instance is left empty.

A dependency DXE driver with a Depex of gEfiMmCommunication2ProtocolGuid
was created to indicate the readiness of Standalone MM Tcg2 driver.

Lastly, the support of CI build for Tcg2 Standalone MM module is added.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v6:
- Previously reviewed, no change.

v5:
- Added reviewed-by tag. [Jiewen]

v4:
- Changed dependency module from anonymous lib to Dxe driver. [Jiewen]

v3:
- No change.

v2:
- Newly added.

 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c   | 48 
 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c  | 71 ++
 SecurityPkg/SecurityPkg.ci.yaml |  1 +
 SecurityPkg/SecurityPkg.dec |  1 +
 SecurityPkg/SecurityPkg.dsc | 10 +++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf | 43 +++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.inf| 77 
 7 files changed, 251 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
new file mode 100644
index ..4f2d7c58ed86
--- /dev/null
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
@@ -0,0 +1,48 @@
+/** @file
+  Runtime DXE part corresponding to StandaloneMM Tcg2 module.
+
+This module installs gTcg2MmSwSmiRegisteredGuid to notify readiness of
+StandaloneMM Tcg2 module.
+
+Copyright (c) 2019 - 2021, Arm Ltd. All rights reserved.
+Copyright (c) Microsoft Corporation.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include 
+#include 
+
+/**
+  The constructor function installs gTcg2MmSwSmiRegisteredGuid to notify
+  readiness of StandaloneMM Tcg2 module.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the Management mode System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+Tcg2MmDependencyDxeEntryPoint (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  EFI_STATUSStatus;
+  EFI_HANDLEHandle;
+
+  Handle = NULL;
+  Status = gBS->InstallProtocolInterface (
+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  NULL
+  );
+  ASSERT_EFI_ERROR (Status);
+  return EFI_SUCCESS;
+}
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
new file mode 100644
index ..9e0095efbc5e
--- /dev/null
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
@@ -0,0 +1,71 @@
+/** @file
+  TCG2 Standalone MM driver that updates TPM2 items in ACPI table and registers
+  SMI2 callback functions for Tcg2 physical presence, ClearMemory, and
+  sample for dTPM StartMethod.
+
+  Caution: This module requires additional review when modified.
+  This driver will have external input - variable and ACPINvs data in SMM mode.
+  This external input must be validated carefully to avoid security issue.
+
+  PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted 
input and do some check.
+
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "Tcg2Smm.h"
+#include 
+
+/**
+  Notify the system that the SMM variable driver is ready.
+**/
+VOID
+Tcg2NotifyMmReady (
+  VOID
+  )
+{
+  // Do nothing
+}
+
+/**
+  This function is an abstraction layer for implementation specific Mm buffer 
validation routine.
+
+  @param Buffer  The buffer start address to be checked.
+  @param Length  The buffer length to be checked.
+
+  @retval TRUE  This buffer is valid per processor architecture and not 
overlap with SMRAM.
+  @retval FALSE This buffer is not valid per processor architecture or overlap 
with SMRAM.
+**/
+BOOLEAN
+IsBufferOutsideMmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  )
+{
+  return MmIsBufferOutsideMmValid (Buffer, Length);
+}
+
+/**
+  The driver's entry point.
+
+  It install callbacks for TPM physical presence and MemoryClear, and locate
+  SMM variable to be used in the callback function.
+
+  @param[in] ImageHandle  The firmware allocated handle for the EFI image.
+  @param[in] SystemTable  A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS The entry point is executed successfully.
+  @retval Others  Some error occurs when executing this entry point.
+
+**/
+EFI_STATUS
+EFIAPI
+InitializeTcgStandaloneMm (
+  IN EFI_HANDLE  ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE *SystemTable
+  )
+{
+  return InitializeTcgCommon 

[edk2-devel] [PATCH v6 5/7] SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2 modules

[Kun Qin]

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

This change separated the original Tcg2Smm module into 2 drivers: the
SMM driver that registers callback for physical presence and memory
clear; the Tcg2Acpi driver that patches and publishes ACPI table for
runtime use.

Tcg2Smm introduced an SMI root handler to allow Tcg2Acpi to communicate
the NVS region used by Tpm.asl and exchange the registered SwSmiValue.

Lastly, Tcg2Smm driver will publish gTcg2MmSwSmiRegisteredGuid at the end
of entrypoint to ensure Tcg2Acpi to load after Tcg2Smm is ready to
communicate.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v6:
- Updated Tcg2Acpi driver entrypoint function description.

v5:
- Previously reviewed, no change.

v4:
- Previously reviewed, no change.

v3:
- Added review-by tag. [Jiewen]
- Added expected usage in driver header.
- Initialized pointer variables to null at entrypoint.

v2:
- Newly added.

 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c} | 356 
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c  | 853 

 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c|  82 ++
 SecurityPkg/Include/Guid/TpmNvsMm.h|  68 ++
 SecurityPkg/SecurityPkg.dec|   7 +
 SecurityPkg/SecurityPkg.dsc|   1 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf} |  34 +-
 SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl  |   0
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h  | 119 +--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf|  25 +-
 10 files changed, 551 insertions(+), 994 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
similarity index 72%
copy from SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
copy to SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
index 08105c3692ba..924c3b4edda6 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
@@ -1,20 +1,76 @@
 /** @file
-  It updates TPM2 items in ACPI table and registers SMI2 callback
-  functions for Tcg2 physical presence, ClearMemory, and sample
-  for dTPM StartMethod.
+  This driver implements TPM 2.0 definition block in ACPI table and
+  populates registered SMI callback functions for Tcg2 physical presence
+  and MemoryClear to handle the requests for ACPI method. It needs to be
+  used together with Tcg2 MM drivers to exchange information on registered
+  SwSmiValue and allocated NVS region address.
 
   Caution: This module requires additional review when modified.
   This driver will have external input - variable and ACPINvs data in SMM mode.
   This external input must be validated carefully to avoid security issue.
 
-  PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted 
input and do some check.
-
 Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
-#include "Tcg2Smm.h"
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//
+// Physical Presence Interface Version supported by Platform
+//
+#define PHYSICAL_PRESENCE_VERSION_TAG  "$PV"
+#define PHYSICAL_PRESENCE_VERSION_SIZE 4
+
+//
+// PNP _HID for TPM2 device
+//
+#define TPM_HID_TAG""
+#define TPM_HID_PNP_SIZE   8
+#define TPM_HID_ACPI_SIZE  9
+
+#define TPM_PRS_RESL   "RESL"
+#define TPM_PRS_RESS   "RESS"
+#define TPM_PRS_RES_NAME_SIZE  4
+//
+// Minimum PRS resource template size
+//  1 bytefor  BufferOp
+//  1 bytefor  PkgLength
+//  2 bytes   for  BufferSize
+//  12 bytes  for  Memory32Fixed descriptor
+//  5 bytes   for  Interrupt descriptor
+//  2 bytes   for  END Tag
+//
+#define TPM_POS_RES_TEMPLATE_MIN_SIZE  (1 + 1 + 2 
+ 12 + 5 + 2)
+
+//
+// Max Interrupt buffer size for PRS interrupt resource
+// Now support 15 interrupts in maxmum
+//
+#define MAX_PRS_INT_BUF_SIZE   (15*4)
 
 #pragma pack(1)
 
@@ -49,142 +105,8 @@ EFI_TPM2_ACPI_TABLE_V4  mTpm2AcpiTemplate = {
   EFI_TPM2_ACPI_TABLE_START_METHOD_TIS, // StartMethod
 };
 
-EFI_SMM_VARIABLE_PROTOCOL  *mSmmVariable;
 TCG_NVS*mTcgNvs;
 
-/**
-  Software SMI callback for TPM physical presence which is called from ACPI 
method.
-
-  Caution: This 

[edk2-devel] [PATCH v6 4/7] SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst

[Kun Qin]

This change replaced gSmst with gMmst to support broader compatibility
under MM environment for Tcg2Smm driver.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v6:
- Previously reviewed, no change.

v5:
- Previously reviewed, no change.

v4:
- Previously reviewed, no change.

v3:
- Added reviewed-by tag. [Jiewen]

v2:
- Newly added in v2.

 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c   | 4 ++--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h   | 2 +-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
index 91aebb62b8bf..08105c3692ba 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
@@ -870,7 +870,7 @@ InitializeTcgSmm (
   //
   // Get the Sw dispatch protocol and register SMI callback functions.
   //
-  Status = gSmst->SmmLocateProtocol (, NULL, 
(VOID**));
+  Status = gMmst->MmLocateProtocol (, NULL, 
(VOID**));
   ASSERT_EFI_ERROR (Status);
   SwContext.SwSmiInputValue = (UINTN) -1;
   Status = SwDispatch->Register (SwDispatch, PhysicalPresenceCallback, 
, );
@@ -891,7 +891,7 @@ InitializeTcgSmm (
   //
   // Locate SmmVariableProtocol.
   //
-  Status = gSmst->SmmLocateProtocol (, NULL, 
(VOID**));
+  Status = gMmst->MmLocateProtocol (, NULL, 
(VOID**));
   ASSERT_EFI_ERROR (Status);
 
   //
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
index fd19e7dc0553..d7328c8f2ac9 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
@@ -24,7 +24,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
index 2ebf2e05f2ea..872ed27cbe71 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
@@ -50,7 +50,7 @@ [LibraryClasses]
   BaseLib
   BaseMemoryLib
   UefiDriverEntryPoint
-  SmmServicesTableLib
+  MmServicesTableLib
   UefiBootServicesTableLib
   DebugLib
   DxeServicesLib
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v6 3/7] MdeModulePkg: VariableSmmRuntimeDxe: Added request unblock memory interface

[Kun Qin]

This changes added usage of MmUnblockMemoryLib to explicitly request
runtime cache regions(and its indicators) to be accessible from MM
environment when PcdEnableVariableRuntimeCache is enabled. It will bring
in compatibility with architectures that supports full memory blockage
inside MM.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 

Signed-off-by: Kun Qin 
Reviewed-by: Hao A Wu 
---

Notes:
v6:
- Previously reviewed, no change.

v5:
- Previously reviewed, no change.

v4:
- Added reviewed-by tag. [Hao]

v3:
- Removed Dxe prefix to match interface change. [Jiewen]

v2:
- Newly added in v2.

 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c   | 42 

 MdeModulePkg/MdeModulePkg.dsc|  1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf |  1 +
 3 files changed, 44 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
index c47e614d81f4..a166d284dfe4 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -35,6 +35,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -165,6 +166,7 @@ InitVariableCache (
   )
 {
   VARIABLE_STORE_HEADER   *VariableCacheStorePtr;
+  EFI_STATUS  Status;
 
   if (TotalVariableCacheSize == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -186,6 +188,18 @@ InitVariableCache (
   if (*VariableCacheBuffer == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
+
+  //
+  // Request to unblock the newly allocated cache region to be accessible from 
inside MM
+  //
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) (UINTN) *VariableCacheBuffer,
+EFI_SIZE_TO_PAGES (*TotalVariableCacheSize)
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+return Status;
+  }
+
   VariableCacheStorePtr = *VariableCacheBuffer;
   SetMem32 ((VOID *) VariableCacheStorePtr, *TotalVariableCacheSize, (UINT32) 
0x);
 
@@ -1536,6 +1550,34 @@ SendRuntimeVariableCacheContextToSmm (
   SmmRuntimeVarCacheContext->ReadLock = 
   SmmRuntimeVarCacheContext->HobFlushComplete = 
 
+  //
+  // Request to unblock this region to be accessible from inside MM environment
+  // These fields "should" be all on the same page, but just to be on the safe 
side...
+  //
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) ALIGN_VALUE ((UINTN) 
SmmRuntimeVarCacheContext->PendingUpdate - EFI_PAGE_SIZE + 1, EFI_PAGE_SIZE),
+EFI_SIZE_TO_PAGES (sizeof(mVariableRuntimeCachePendingUpdate))
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) ALIGN_VALUE ((UINTN) 
SmmRuntimeVarCacheContext->ReadLock - EFI_PAGE_SIZE + 1, EFI_PAGE_SIZE),
+EFI_SIZE_TO_PAGES (sizeof(mVariableRuntimeCacheReadLock))
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) ALIGN_VALUE ((UINTN) 
SmmRuntimeVarCacheContext->HobFlushComplete - EFI_PAGE_SIZE + 1, EFI_PAGE_SIZE),
+EFI_SIZE_TO_PAGES (sizeof(mHobFlushComplete))
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+goto Done;
+  }
+
   //
   // Send data to SMM.
   //
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 7ca4a1bb3080..9272da89a998 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -100,6 +100,7 @@ [LibraryClasses]
   SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
   
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 
 [LibraryClasses.EBC.PEIM]
   IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
index b6dbc839e023..a0d8b2267e92 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
@@ -60,6 +60,7 @@ [LibraryClasses]
   TpmMeasurementLib
   SafeIntLib
   PcdLib
+  MmUnblockMemoryLib
 
 [Protocols]
   gEfiVariableWriteArchProtocolGuid ## PRODUCES
-- 
2.30.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72473): 

[edk2-devel] [PATCH v6 0/7] Add MmUnblockMemoryLib Interface and Usages

[Kun Qin]

This patch series is a follow up of previous submission:
https://edk2.groups.io/g/devel/message/72442

v6 patches mainly focus on feedback for reviewed commits in v5 patches,
including:
a. Adding "Reviewed-by" and "Acked-by" tags for applicable patch;
b. Updating library class description for newly added interface;

Patch v6 branch: https://github.com/kuqin12/edk2/tree/unblock_mem_v6

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Kun Qin (7):
  MdePkg: MmUnblockMemoryLib: Added definition and null instance
  OvmfPkg: resolve MmUnblockMemoryLib (mainly for VariableSmmRuntimeDxe)
  MdeModulePkg: VariableSmmRuntimeDxe: Added request unblock memory
interface
  SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst
  SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2 modules
  SecurityPkg: Tcg2Smm: Added support for Standalone Mm
  SecurityPkg: Tcg2Acpi: Added unblock memory interface for NVS region

 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c   |  42 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   |  44 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c}   | 362 
-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c|  48 ++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c| 857 

 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c   |  71 ++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c  |  82 ++
 MdeModulePkg/MdeModulePkg.dsc|   1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf |   1 +
 MdePkg/Include/Library/MmUnblockMemoryLib.h  |  44 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf |  34 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni |  21 +
 MdePkg/MdePkg.dec|   5 +
 MdePkg/MdePkg.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.dsc  |   3 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   3 +
 OvmfPkg/OvmfPkgX64.dsc   |   3 +
 SecurityPkg/Include/Guid/TpmNvsMm.h  |  68 ++
 SecurityPkg/SecurityPkg.ci.yaml  |   1 +
 SecurityPkg/SecurityPkg.dec  |   8 +
 SecurityPkg/SecurityPkg.dsc  |  12 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf}   |  35 +-
 SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl|   0
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf  |  43 +
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h| 121 +--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf  |  27 +-
 SecurityPkg/Tcg/Tcg2Smm/{Tcg2Smm.inf => Tcg2StandaloneMm.inf}|  50 +-
 27 files changed, 952 insertions(+), 1035 deletions(-)
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
 copy SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c} (72%)
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c
 create mode 100644 MdePkg/Include/Library/MmUnblockMemoryLib.h
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni
 create mode 100644 SecurityPkg/Include/Guid/TpmNvsMm.h
 copy SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf} (76%)
 rename SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl (100%)
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf
 copy SecurityPkg/Tcg/Tcg2Smm/{Tcg2Smm.inf => Tcg2StandaloneMm.inf} (52%)

-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v6 2/7] OvmfPkg: resolve MmUnblockMemoryLib (mainly for VariableSmmRuntimeDxe)

[Kun Qin]

This change added NULL MmUnblockMemoryLib instance in dsc files of
OvmfPkg to pass CI build. When SMM_REQUIRE flag is set, the library
interface is consumed by VariableSmmRuntimeDxe to better support variable
runtime cache feature.

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 

Signed-off-by: Kun Qin 
Reviewed-by: Laszlo Ersek 
---

Notes:
v6:
- Previously reviewed, no change.

v5:
- Previously reviewed, no change.

v4:
- Updated patch title. [Laszlo]
- Moved this patch before the variable driver change. [Laszlo]
- Added reviewed-by tag. [Laszlo]

v3:
- Newly added in v3. [Hao]

 OvmfPkg/OvmfPkgIa32.dsc| 3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++
 OvmfPkg/OvmfPkgX64.dsc | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 1b8d34052b01..1eaf3e99c6c5 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -347,6 +347,9 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+!if $(SMM_REQUIRE) == TRUE
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 9c1aee87e783..4a5a43014725 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -351,6 +351,9 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+!if $(SMM_REQUIRE) == TRUE
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fabb8b2f29e4..d4d601b44476 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -353,6 +353,9 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+!if $(SMM_REQUIRE) == TRUE
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v6 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null instance

[Kun Qin]

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

This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.

For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.

Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Hao A Wu 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 

Signed-off-by: Kun Qin 
Acked-by: Laszlo Ersek 
Reviewed-by: Liming Gao 
---

Notes:
v6:
- Updated dec file comment. [Liming]
- Added Reviewed-by tag. [Liming]
- Added Acked-by tag. [Laszlo]

v5:
- Downgraded data types from EFI_* to RETURN_*. [Laszlo]

v4:
- Added more commit message [Laszlo]
- Added UNI file [Hao]

v3:
- Move interface to MdePkg [Hao, Liming, Jiewen]
- Remove Dxe prefix [Jiewen]

v2:
- Resend with practical usage. No change [Hao]

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   | 44 

 MdePkg/Include/Library/MmUnblockMemoryLib.h  | 44 

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf | 34 
+++
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni | 21 ++
 MdePkg/MdePkg.dec|  5 +++
 MdePkg/MdePkg.dsc|  1 +
 6 files changed, 149 insertions(+)

diff --git a/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c 
b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
new file mode 100644
index ..b205c9122df8
--- /dev/null
+++ b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
@@ -0,0 +1,44 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an interface to request non-MMRAM pages to be 
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents 
that set up
+  these regions are responsible for invoking this API in order for these 
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain data pages to be accessible 
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer caller requests to 
unblock, the address
+  has to be page aligned.
+  @param  NumberOfPages   The number of pages requested to be 
unblocked from MM
+  environment.
+
+  @retval RETURN_SUCCESS  The request goes through successfully.
+  @retval RETURN_NOT_AVAILABLE_YETThe requested functionality is not 
produced yet.
+  @retval RETURN_UNSUPPORTED  The requested functionality is not 
supported on current platform.
+  @retval RETURN_SECURITY_VIOLATION   The requested address failed to pass 
security check for
+  unblocking.
+  @retval RETURN_INVALID_PARAMETERInput address either NULL pointer or not 
page aligned.
+  @retval RETURN_ACCESS_DENIEDThe request is rejected due to system 
has passed certain boot
+  phase.
+
+**/
+RETURN_STATUS
+EFIAPI
+MmUnblockMemoryRequest (
+  IN PHYSICAL_ADDRESS   UnblockAddress,
+  IN UINT64 NumberOfPages
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
diff --git a/MdePkg/Include/Library/MmUnblockMemoryLib.h 
b/MdePkg/Include/Library/MmUnblockMemoryLib.h
new file mode 100644
index ..00fab530a3bc
--- /dev/null
+++ b/MdePkg/Include/Library/MmUnblockMemoryLib.h
@@ -0,0 +1,44 @@
+/** @file
+  MM Unblock Memory Library Interface.
+
+  This library provides an interface to request non-MMRAM pages to be 
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents 
that set up
+  these regions are responsible for invoking this API in order for these 
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MM_UNBLOCK_MEMORY_LIB_H_
+#define MM_UNBLOCK_MEMORY_LIB_H_

Re: [edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null instance

[Kun Qin]

Thanks, Liming. I will send the updated patches shortly.

Regards,
Kun

From: gaoliming
Sent: Thursday, March 4, 2021 19:15
To: devel@edk2.groups.io; 
ku...@outlook.com; 'Michael D 
Kinney'; 'Zhiguang 
Liu'
Cc: 'Hao A Wu'; 'Jiewen 
Yao'; 'Laszlo Ersek'
Subject: 回复: [edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added 
definition and null instance

Kun:
 I have one minor comment. Please see it.

Thanks
Liming
发件人: devel@edk2.groups.io  代表 Kun Qin
发送时间: 2021年3月5日 8:23
收件人: devel@edk2.groups.io; Michael D Kinney ; 
gaoliming ; Zhiguang Liu 
抄送: Hao A Wu ; Jiewen Yao ; Laszlo 
Ersek 
主题: Re: [edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added 
definition and null instance

Hi Mike/Liming/Zhiguang,

Could you please review this patch and let me know if you have any feedback on 
this patch? Any input is appreciated.

Regards,
Kun

From: Kun Qin
Sent: Thursday, March 4, 2021 10:58
To: devel@edk2.groups.io
Cc: Michael D Kinney; Liming 
Gao; Zhiguang 
Liu; Hao A Wu; Jiewen 
Yao; Laszlo Ersek
Subject: [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null 
instance

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

This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.

For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.

Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.

Cc: Michael D Kinney 
mailto:michael.d.kin...@intel.com>>
Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
Cc: Zhiguang Liu mailto:zhiguang@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Jiewen Yao mailto:jiewen@intel.com>>
Cc: Laszlo Ersek mailto:ler...@redhat.com>>

Signed-off-by: Kun Qin mailto:ku...@outlook.com>>
---

Notes:
v5:
- Downgraded data types from EFI_* to RETURN_*. [Laszlo]

v4:
- Added more commit message [Laszlo]
- Added UNI file [Hao]

v3:
- Move interface to MdePkg [Hao, Liming, Jiewen]
- Remove Dxe prefix [Jiewen]

v2:
- Resend with practical usage. No change [Hao]

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   | 44 

 MdePkg/Include/Library/MmUnblockMemoryLib.h  | 44 

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf | 34 
+++
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni | 21 ++
 MdePkg/MdePkg.dec|  5 +++
 MdePkg/MdePkg.dsc|  1 +
 6 files changed, 149 insertions(+)

diff --git a/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c 
b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
new file mode 100644
index ..b205c9122df8
--- /dev/null
+++ b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
@@ -0,0 +1,44 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an interface to request non-MMRAM pages to be 
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents 
that set up
+  these regions are responsible for invoking this API in order for these 
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain data pages to be accessible 
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer caller requests to 
unblock, the address
+  has to be page aligned.
+  @param  NumberOfPages   The number of pages requested to be 
unblocked from MM
+  environment.
+
+  @retval RETURN_SUCCESS  

[edk2-devel] [PATCH 2/2] OvmfPkg/IntelGvtGopDxe: Enable GVT-g GOP in OvmfPkg DSC & DFD.

[Colin Xu]

Intel GVT-g is already enabled by default in upstream kernel.

Signed-off-by: Colin Xu 
---
 OvmfPkg/OvmfPkgX64.dsc | 4 
 OvmfPkg/OvmfPkgX64.fdf | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fabb8b2f29e4..971fd262151b 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -52,6 +52,7 @@
   DEFINE PVSCSI_ENABLE   = TRUE
   DEFINE MPT_SCSI_ENABLE = TRUE
   DEFINE LSI_SCSI_ENABLE = FALSE
+  DEFINE INTEL_GVT_KVMGT_ENABLE  = TRUE
 
   #
   # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
@@ -808,6 +809,9 @@
 !endif
 !if $(LSI_SCSI_ENABLE) == TRUE
   OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf
+!endif
+!if $(INTEL_GVT_KVMGT_ENABLE) == TRUE
+  OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
 !endif
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index d519f8532822..6d0bcf3fcd31 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -252,6 +252,9 @@ INF  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
 !if $(LSI_SCSI_ENABLE) == TRUE
 INF  OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf
 !endif
+!if $(INTEL_GVT_KVMGT_ENABLE) == TRUE
+INF  OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
+!endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF  
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-- 
2.30.1



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

[edk2-devel] [PATCH 0/2] OvmfPkg/IntelGvtGopDxe: Add Intel GVT-g GOP.

[Colin Xu]

This patch set add Intel GVT-g GOP DXE to OvmfPkg.

Colin Xu (2):
  OvmfPkg/IntelGvtGopDxe: Intel GVT-g GOP Implementation.
  OvmfPkg/IntelGvtGopDxe: Enable GVT-g GOP in OvmfPkg DSC & DFD.

 OvmfPkg/IntelGvtGopDxe/Common.h   |   45 +
 OvmfPkg/IntelGvtGopDxe/DebugHelper.h  |   20 +
 OvmfPkg/IntelGvtGopDxe/Display.c  | 1073 +
 OvmfPkg/IntelGvtGopDxe/Display.h  |  141 +++
 OvmfPkg/IntelGvtGopDxe/GopDriver.c|  478 +
 OvmfPkg/IntelGvtGopDxe/GpuReg.c   |   91 ++
 OvmfPkg/IntelGvtGopDxe/GpuReg.h   |  173 
 OvmfPkg/IntelGvtGopDxe/Gtt.c  |  162 
 OvmfPkg/IntelGvtGopDxe/Gtt.h  |   51 +
 OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf |   59 ++
 OvmfPkg/IntelGvtGopDxe/VbeShim.asm|  343 +++
 OvmfPkg/IntelGvtGopDxe/VbeShim.c  |  258 +
 OvmfPkg/IntelGvtGopDxe/VbeShim.h  |  912 +
 OvmfPkg/IntelGvtGopDxe/VbeShim.sh |   81 ++
 OvmfPkg/IntelGvtGopDxe/VirtualGpu.c   |  400 
 OvmfPkg/IntelGvtGopDxe/VirtualGpu.h   |   52 +
 OvmfPkg/OvmfPkgX64.dsc|4 +
 OvmfPkg/OvmfPkgX64.fdf|3 +
 18 files changed, 4346 insertions(+)
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Common.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/DebugHelper.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Display.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Display.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/GopDriver.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/GpuReg.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/GpuReg.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Gtt.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/Gtt.h
 create mode 100644 OvmfPkg/IntelGvtGopDxe/IntelGvtGopDxe.inf
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.asm
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VbeShim.h
 create mode 100755 OvmfPkg/IntelGvtGopDxe/VbeShim.sh
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VirtualGpu.c
 create mode 100644 OvmfPkg/IntelGvtGopDxe/VirtualGpu.h

-- 
2.30.1



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

[edk2-devel] TianoCore Community Meeting - APAC/NAMO - Thu, 03/04/2021 7:30pm-8:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Community Meeting - APAC/NAMO

*When:* Thursday, 4 March 2021, 7:30pm to 8:30pm, (GMT-08:00) America/Los 
Angeles

*Where:* 
https://intel.webex.com/intel/j.php?MTID=m36627c5ee595f86f0257d9a52bb86044

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

*Organizer:* Soumya Guptha soumya.k.gup...@intel.com ( 
soumya.k.gup...@intel.com?subject=Re:%20Event:%20TianoCore%20Community%20Meeting%20-%20APAC%2FNAMO
 )

*Description:*

- - Do not delete or change any of the following text. --

*When it's time, join your Webex meeting here.*

Meeting number (access code): 130 338 2091

Meeting password: RizGk3WB$57

Join ( 
https://intel.webex.com/intel/j.php?MTID=m36627c5ee595f86f0257d9a52bb86044 )

*Tap to join from a mobile device (attendees only)*
+1-210-795-1110,,1303382091## ( tel:%2B1-210-795-1110,,*01*1303382091%23%23*01* 
) US Toll
+1-866-662-9987,,1303382091## ( tel:%2B1-866-662-9987,,*01*1303382091%23%23*01* 
) US Toll Free

*Join by phone*
+1-210-795-1110 US Toll
+1-866-662-9987 US Toll Free
Global call-in numbers ( 
https://intel.webex.com/intel/globalcallin.php?MTID=m959de820914124cc82ab1a8fe04afbad
 ) | Toll-free calling restrictions ( 
https://e-meetings.verizonbusiness.com/global/pdf/Verizon_Audio_Conferencing_Global_Access_Information_August2017.pdf
 )

*Join from a video system or application*
Dial 1303382...@intel.webex.com ( sip:1303382...@intel.webex.com )
You can also dial 173.243.2.68 and enter your meeting number.

Need help? Go to http://help.webex.com ( http://help.webex.com )


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72465): https://edk2.groups.io/g/devel/message/72465
Mute This Topic: https://groups.io/mt/81095072/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 v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null instance

[gaoliming]

Kun:

 I have one minor comment. Please see it. 

 

Thanks

Liming

发件人: devel@edk2.groups.io  代表 Kun Qin
发送时间: 2021年3月5日 8:23
收件人: devel@edk2.groups.io; Michael D Kinney ;
gaoliming ; Zhiguang Liu 
抄送: Hao A Wu ; Jiewen Yao ;
Laszlo Ersek 
主题: Re: [edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added
definition and null instance

 

Hi Mike/Liming/Zhiguang,

 

Could you please review this patch and let me know if you have any feedback
on this patch? Any input is appreciated.

 

Regards,

Kun

 

From: Kun Qin  
Sent: Thursday, March 4, 2021 10:58
To: devel@edk2.groups.io  
Cc: Michael D Kinney  ; Liming Gao
 ; Zhiguang Liu  ; Hao A Wu  ; Jiewen Yao
 ; Laszlo Ersek  
Subject: [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and
null instance

 

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

This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.

For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.

Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.

Cc: Michael D Kinney mailto:michael.d.kin...@intel.com> >
Cc: Liming Gao mailto:gaolim...@byosoft.com.cn> >
Cc: Zhiguang Liu mailto:zhiguang@intel.com> >
Cc: Hao A Wu mailto:hao.a...@intel.com> >
Cc: Jiewen Yao mailto:jiewen@intel.com> >
Cc: Laszlo Ersek mailto:ler...@redhat.com> >

Signed-off-by: Kun Qin mailto:ku...@outlook.com> >
---

Notes:
v5:
- Downgraded data types from EFI_* to RETURN_*. [Laszlo]

v4:
- Added more commit message [Laszlo]
- Added UNI file [Hao]

v3:
- Move interface to MdePkg [Hao, Liming, Jiewen]
- Remove Dxe prefix [Jiewen]

v2:
- Resend with practical usage. No change [Hao]

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   | 44

 MdePkg/Include/Library/MmUnblockMemoryLib.h  | 44

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf | 34
+++
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni | 21
++
 MdePkg/MdePkg.dec|  5 +++
 MdePkg/MdePkg.dsc|  1 +
 6 files changed, 149 insertions(+)

diff --git a/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
new file mode 100644
index ..b205c9122df8
--- /dev/null
+++ b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
@@ -0,0 +1,44 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an interface to request non-MMRAM pages to be
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents
that set up
+  these regions are responsible for invoking this API in order for these
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain data pages to be accessible
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer caller requests
to unblock, the address
+  has to be page aligned.
+  @param  NumberOfPages   The number of pages requested to be
unblocked from MM
+  environment.
+
+  @retval RETURN_SUCCESS  The request goes through
successfully.
+  @retval RETURN_NOT_AVAILABLE_YETThe requested functionality is not
produced yet.
+  @retval RETURN_UNSUPPORTED  The requested functionality is not
supported on current platform.
+  @retval RETURN_SECURITY_VIOLATION   The requested address failed to pass
security check for
+  unblocking.
+  @retval RETURN_INVALID_PARAMETERInput address either NULL pointer or
not page aligned.
+  @retval RETURN_ACCESS_DENIEDThe request is rejected due to system
has 

[edk2-devel] TianoCore Community Meeting - APAC/NAMO - Thu, 03/04/2021 7:30pm-8:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Community Meeting - APAC/NAMO

*When:* Thursday, 4 March 2021, 7:30pm to 8:30pm, (GMT-08:00) America/Los 
Angeles

*Where:* 
https://intel.webex.com/intel/j.php?MTID=m36627c5ee595f86f0257d9a52bb86044

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

*Organizer:* Soumya Guptha soumya.k.gup...@intel.com ( 
soumya.k.gup...@intel.com?subject=Re:%20Event:%20TianoCore%20Community%20Meeting%20-%20APAC%2FNAMO
 )

*Description:*

- - Do not delete or change any of the following text. --

*When it's time, join your Webex meeting here.*

Meeting number (access code): 130 338 2091

Meeting password: RizGk3WB$57

Join ( 
https://intel.webex.com/intel/j.php?MTID=m36627c5ee595f86f0257d9a52bb86044 )

*Tap to join from a mobile device (attendees only)*
+1-210-795-1110,,1303382091## ( tel:%2B1-210-795-1110,,*01*1303382091%23%23*01* 
) US Toll
+1-866-662-9987,,1303382091## ( tel:%2B1-866-662-9987,,*01*1303382091%23%23*01* 
) US Toll Free

*Join by phone*
+1-210-795-1110 US Toll
+1-866-662-9987 US Toll Free
Global call-in numbers ( 
https://intel.webex.com/intel/globalcallin.php?MTID=m959de820914124cc82ab1a8fe04afbad
 ) | Toll-free calling restrictions ( 
https://e-meetings.verizonbusiness.com/global/pdf/Verizon_Audio_Conferencing_Global_Access_Information_August2017.pdf
 )

*Join from a video system or application*
Dial 1303382...@intel.webex.com ( sip:1303382...@intel.webex.com )
You can also dial 173.243.2.68 and enter your meeting number.

Need help? Go to http://help.webex.com ( http://help.webex.com )


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

Re: [edk2-devel] Question about Smm code / StandaloneMmPkg

[Kun Qin]

Hi Tiger,

Our team has been sending patches to the community to cover Standalone MM 
driver to support x86 arch recently by believing that Standalone MM is the 
direction we are moving to in the long term.

From our experience so far, the Standalone MM core infrastructure is arch 
independent and capable of operations such as dispatching MM drivers and 
managing memory as is. What really is missing would be the StandaloneMmCpu and 
an IPL that can install MM foundation for x86 arch. But I am unaware of any 
public implementation for these 2 components at this moment. As I joined this 
Standalone MM journey relatively recently, maybe other community members will 
have more information in that regards.

Generally from our perspective, we are taking Standalone Mm model as an 
opportunity to provide better isolation between MM and non-MM environment, 
since this model is providing cleaner boundary inside MM without convoluted 
access to non-MM (mostly DXE) environment. If x86 SMM core code will ever be 
added to Standalone MM implemation, I would hope we do not lose advantage on 
that specific point.

Thanks,
Kun

From: Laszlo Ersek
Sent: Thursday, March 4, 2021 12:55
To: devel@edk2.groups.io; 
tiger...@zhaoxin.com; Kinney, Michael 
D; Kun Qin
Subject: Re: [edk2-devel] Question about Smm code / StandaloneMmPkg

Adding Kun Qin; a comment below:

On 03/04/21 09:34, Tiger Liu(BJ-RD) wrote:
> Dear All:
> I have a few questions about Smm code and StandaloneMmPkg.
>
> Take X86 Arch cpu as example:
> 1. Smm infrastructure code is implemented in MdeModulePkg\Core\PiSmmCore
>But it's a traditional smm mode, used launched in UEFI DXE Phase.
>
> A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf
> > This doc introduced a standalone smm mode.
>
> PI Spec introduces a MM concept, it's arch independent.
>
> So, I have below questions:
> 1. Will X86 SMM code implementation be migrated to MM concept code base?
> 2. StandaloneMmPkg is a MM reference implementation, is it arch independent?
> 3. The above doc mentioned launching SMM drivers in PEI,  is it also 
> implemented in StandaloneMmPkg?

Please see (also) the following thread:

  [edk2-rfc] [RFC]
  Support Both MM Traditional and Standalone Drivers with One MM Core

  https://edk2.groups.io/g/rfc/message/430

Thanks
Laszlo


>
> Thanks
>
>
> 保密声明：
> 本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for 
> the sole use of its intended recipient. Any unauthorized review, use, copying 
> or forwarding of this email or the content of this email is strictly 
> prohibited.
>
>
> 
>
>



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

Re: [edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 03/05/2021 #cal-notice

[Dandan Bi]

Thank you, Abner.



Thanks,
Dandan
From: Chang, Abner (HPS SW/FW Technologist) 
Sent: Friday, March 5, 2021 10:11 AM
To: devel@edk2.groups.io; Bi, Dandan 
Cc: Schaefer, Daniel 
Subject: RE: [edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 
03/05/2021 #cal-notice

Hi Dandan,
Below is the information for you to update the table in your slide.

IA32  X64 EBC  ARM ARM64 
AARCH64 RISCV64
CSR R/WNA   NA   NANA  NA   NA  
 YES

Thanks
Abner

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of 
devel@edk2.groups.io Calendar
Sent: Friday, March 5, 2021 9:30 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 03/05/2021 
#cal-notice


TianoCore Design Meeting - APAC/NAMO

When:
Friday, 5 March 2021
9:30am to 10:30am
(GMT+08:00) Asia/Shanghai

Where:
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb

Organizer:
ray...@intel.com

Description:

TOPIC

  *   FilterLib: Filter/Trace Port IO/MMIO/MSR access (Dandan Bi/Intel)

Slides: 
https://edk2.groups.io/g/devel/files/Designs/2021/0305/FilterLib.pdf

For more info, see here: 
https://www.tianocore.org/design-meeting/

Join Webex Meeting

Meeting link: 
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb

Meeting number: 130 603 1757

Password: C3tRPJPV86@

Host key: 991045

More ways to join

Join by video system Dial 
1306031...@intel.webex.com

You can also dial 173.243.2.68 and enter your meeting number. Join by phone

+1-210-795-1110 US Toll

+1-866-662-9987 US Toll Free

Access code: 130 603 1757

(Webex can be downloaded from 
https://www.webex.com/downloads.html/.)



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

Re: [edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 03/05/2021 #cal-notice

[Abner Chang]

Hi Dandan,
Below is the information for you to update the table in your slide.

IA32  X64 EBC  ARM ARM64 
AARCH64 RISCV64
CSR R/WNA   NA   NANA  NA   NA  
 YES

Thanks
Abner

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
devel@edk2.groups.io Calendar
Sent: Friday, March 5, 2021 9:30 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 03/05/2021 
#cal-notice


TianoCore Design Meeting - APAC/NAMO

When:
Friday, 5 March 2021
9:30am to 10:30am
(GMT+08:00) Asia/Shanghai

Where:
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb

Organizer:
ray...@intel.com

Description:

TOPIC

  *   FilterLib: Filter/Trace Port IO/MMIO/MSR access (Dandan Bi/Intel)

Slides: 
https://edk2.groups.io/g/devel/files/Designs/2021/0305/FilterLib.pdf

For more info, see here: 
https://www.tianocore.org/design-meeting/

Join Webex Meeting

Meeting link: 
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb

Meeting number: 130 603 1757

Password: C3tRPJPV86@

Host key: 991045

More ways to join

Join by video system Dial 
1306031...@intel.webex.com

You can also dial 173.243.2.68 and enter your meeting number. Join by phone

+1-210-795-1110 US Toll

+1-866-662-9987 US Toll Free

Access code: 130 603 1757

(Webex can be downloaded from 
https://www.webex.com/downloads.html/.)



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

[edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 03/05/2021 #cal-notice

[devel@edk2.groups.io Calendar]

"TianoCore Design Meeting - APAC/NAMO"

When:  Friday, 5 March 2021
   9:30am to 10:30am
   (GMT+08:00) Asia/Shanghai

Where: 
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb


Organizer: ray...@intel.com 

Description: ## TOPIC

* FilterLib: Filter/Trace Port IO/MMIO/MSR access (Dandan Bi/Intel)

Slides: https://edk2.groups.io/g/devel/files/Designs/2021/0305/FilterLib.pdf

For more info, see here:
https://www.tianocore.org/design-meeting/

## Join Webex Meeting

Meeting link:
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb 

Meeting number:
130 603 1757

Password:
C3tRPJPV86@

Host key:
991045

## More ways to join

Join by video system
Dial 1306031...@intel.webex.com

You can also dial 173.243.2.68 and enter your meeting number.
Join by phone

+1-210-795-1110 US Toll

+1-866-662-9987 US Toll Free

Access code: 130 603 1757

(Webex can be downloaded from https://www.webex.com/downloads.html/.)


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

回复: [edk2-devel] [PATCH v1] MdePkg: Support standalone MM Driver Unload capability

[gaoliming]

That's OK. Reviewed-by: Liming Gao  for this
patch. 

> -邮件原件-
> 发件人: Wu, Jiaxin 
> 发送时间: 2021年3月4日 11:22
> 收件人: gaoliming ; devel@edk2.groups.io
> 抄送: Kinney, Michael D ; Liu, Zhiguang
> ; Fu, Siyuan 
> 主题: RE: [edk2-devel] [PATCH v1] MdePkg: Support standalone MM Driver
> Unload capability
> 
> Hi Liming,
> 
> We internal verified the new added unload logic, works well.
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: gaoliming 
> > Sent: Thursday, March 4, 2021 10:21 AM
> > To: devel@edk2.groups.io; Wu, Jiaxin 
> > Cc: Kinney, Michael D ; Liu, Zhiguang
> > ; Fu, Siyuan 
> > Subject: 回复: [edk2-devel] [PATCH v1] MdePkg: Support standalone MM
> > Driver Unload capability
> >
> > Jiaxin:
> >   Have you created the test case to verify the new added unload logic?
> >
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Wu,
> Jiaxin
> > > 发送时间: 2021年3月3日 16:49
> > > 收件人: devel@edk2.groups.io; Wu, Jiaxin 
> > > 抄送: Kinney, Michael D ; Liming Gao
> > > ; Liu, Zhiguang ;
Fu,
> > > Siyuan 
> > > 主题: Re: [edk2-devel] [PATCH v1] MdePkg: Support standalone MM
> > Driver
> > > Unload capability
> > >
> > > Hi Mike  & Zhiguang & Liming,
> > >
> > > Could you help review this patch?
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of Wu,
> > > > Jiaxin
> > > > Sent: Monday, March 1, 2021 3:44 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Kinney, Michael D ; Liming Gao
> > > > ; Liu, Zhiguang ;
> > Fu,
> > > > Siyuan 
> > > > Subject: [edk2-devel] [PATCH v1] MdePkg: Support standalone MM
> > Driver
> > > > Unload capability
> > > >
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3240
> > > >
> > > > This patch is to support standalone MM Driver Unload capability
> > > > by providing _DriverUnloadHandler() function.
> > > >
> > > > Change-Id: I26cdbfccb7052685c464d6394e472c7579b7b67e
> > > > Cc: Michael D Kinney 
> > > > Cc: Liming Gao 
> > > > Cc: Zhiguang Liu 
> > > > Cc: Siyuan Fu 
> > > > Signed-off-by: Jiaxin Wu 
> > > > ---
> > > >  .../Include/Library/StandaloneMmDriverEntryPoint.h | 25
> ++
> > > >  .../StandaloneMmDriverEntryPoint.c | 56
> > > > +-
> > > >  .../StandaloneMmDriverEntryPoint.inf   |  5 +-
> > > >  3 files changed, 84 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
> > > > b/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
> > > > index 25b2d8d68d..12f7886640 100644
> > > > --- a/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
> > > > +++ b/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
> > > > @@ -16,10 +16,15 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > >  /// Declare the PI Specification Revision that this driver requires
to
> > > execute
> > > >  /// correctly.
> > > >  ///
> > > >  extern CONST UINT32   _gMmRevision;
> > > >
> > > > +///
> > > > +/// Declare the number of unload handler in the image.
> > > > +///
> > > > +extern CONST UINT8
> _gDriverUnloadImageCount;
> > > > +
> > > >  /**
> > > >The entry point of PE/COFF Image for a Standalone MM Driver.
> > > >
> > > >This function is the entry point for a Standalone MM Driver.
> > > >This function must call ProcessLibraryConstructorList() and
> > > > @@ -120,6 +125,26 @@ EFIAPI
> > > >  ProcessModuleEntryPointList (
> > > >IN EFI_HANDLE ImageHandle,
> > > >IN EFI_MM_SYSTEM_TABLE*MmSystemTable
> > > >);
> > > >
> > > > +/**
> > > > +  Autogenerated function that calls a set of module unload
handlers.
> > > > +
> > > > +  This function must be called from the unload handler registered
by
> > > > _ModuleEntryPoint().
> > > > +  This function calls the set of module unload handlers.
> > > > +  This function is autogenerated by build tools and those build
tools
> > are
> > > > responsible
> > > > +  for collecting the module unload handlers and calling them in a
> > specified
> > > > order.
> > > > +
> > > > +  @param  ImageHandle  The image handle of the DXE Driver, DXE
> > > Runtime
> > > > Driver, DXE SMM Driver, or UEFI Driver.
> > > > +
> > > > +  @retval  EFI_SUCCESS  The unload handlers executed normally.
> > > > +  @retval  !EFI_SUCCESS The unload handlers failed to execute
> > > normally.
> > > > +
> > > > +**/
> > > > +EFI_STATUS
> > > > +EFIAPI
> > > > +ProcessModuleUnloadList (
> > > > +  IN EFI_HANDLE  ImageHandle
> > > > +  );
> > > > +
> > > >  #endif
> > > > diff --git
> > > >
> > >
> >
> a/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEnt
> > > > ryPoint.c
> > > >
> > >
> >
> b/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEnt
> > > > ryPoint.c
> > > > index 2c41e23a03..d74c9bdfed 100644
> > > > ---
> > > >
> > >
> >
> a/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEnt
> > > > ryPoint.c
> > > > +++
> > > >
> > >
> >
> 

[edk2-devel] TianoCore Design Meeting - APAC/NAMO - Fri, 03/05/2021 9:30am-10:30am #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Design Meeting - APAC/NAMO

*When:* Friday, 5 March 2021, 9:30am to 10:30am, (GMT+08:00) Asia/Shanghai

*Where:* 
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb

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

*Organizer:* Ray Ni ray...@intel.com ( 
ray...@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO
 )

*Description:*

-
TOPIC
-

* FilterLib: Filter/Trace Port IO/MMIO/MSR access (Dandan Bi/Intel)

Slides: https://edk2.groups.io/g/devel/files/Designs/2021/0305/FilterLib.pdf

For more info, see here: https://www.tianocore.org/design-meeting/

--
Join Webex Meeting
--

Meeting link: 
https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb

Meeting number: 130 603 1757

Password: C3tRPJPV86@

Host key: 991045

-
More ways to join
-

Join by video system Dial 1306031...@intel.webex.com

You can also dial 173.243.2.68 and enter your meeting number. Join by phone

+1-210-795-1110 US Toll

+1-866-662-9987 US Toll Free

Access code: 130 603 1757

(Webex can be downloaded from https://www.webex.com/downloads.html/. )


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

Re: [edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null instance

[Kun Qin]

Hi Mike/Liming/Zhiguang,

Could you please review this patch and let me know if you have any feedback on 
this patch? Any input is appreciated.

Regards,
Kun

From: Kun Qin
Sent: Thursday, March 4, 2021 10:58
To: devel@edk2.groups.io
Cc: Michael D Kinney; Liming 
Gao; Zhiguang 
Liu; Hao A Wu; Jiewen 
Yao; Laszlo Ersek
Subject: [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null 
instance

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

This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.

For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.

Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Hao A Wu 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 

Signed-off-by: Kun Qin 
---

Notes:
v5:
- Downgraded data types from EFI_* to RETURN_*. [Laszlo]

v4:
- Added more commit message [Laszlo]
- Added UNI file [Hao]

v3:
- Move interface to MdePkg [Hao, Liming, Jiewen]
- Remove Dxe prefix [Jiewen]

v2:
- Resend with practical usage. No change [Hao]

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   | 44 

 MdePkg/Include/Library/MmUnblockMemoryLib.h  | 44 

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf | 34 
+++
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni | 21 ++
 MdePkg/MdePkg.dec|  5 +++
 MdePkg/MdePkg.dsc|  1 +
 6 files changed, 149 insertions(+)

diff --git a/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c 
b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
new file mode 100644
index ..b205c9122df8
--- /dev/null
+++ b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
@@ -0,0 +1,44 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an interface to request non-MMRAM pages to be 
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents 
that set up
+  these regions are responsible for invoking this API in order for these 
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain data pages to be accessible 
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer caller requests to 
unblock, the address
+  has to be page aligned.
+  @param  NumberOfPages   The number of pages requested to be 
unblocked from MM
+  environment.
+
+  @retval RETURN_SUCCESS  The request goes through successfully.
+  @retval RETURN_NOT_AVAILABLE_YETThe requested functionality is not 
produced yet.
+  @retval RETURN_UNSUPPORTED  The requested functionality is not 
supported on current platform.
+  @retval RETURN_SECURITY_VIOLATION   The requested address failed to pass 
security check for
+  unblocking.
+  @retval RETURN_INVALID_PARAMETERInput address either NULL pointer or not 
page aligned.
+  @retval RETURN_ACCESS_DENIEDThe request is rejected due to system 
has passed certain boot
+  phase.
+
+**/
+RETURN_STATUS
+EFIAPI
+MmUnblockMemoryRequest (
+  IN PHYSICAL_ADDRESS   UnblockAddress,
+  IN UINT64 NumberOfPages
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
diff --git a/MdePkg/Include/Library/MmUnblockMemoryLib.h 
b/MdePkg/Include/Library/MmUnblockMemoryLib.h
new file mode 100644
index ..00fab530a3bc
--- /dev/null
+++ b/MdePkg/Include/Library/MmUnblockMemoryLib.h
@@ -0,0 +1,44 @@
+/** @file
+  MM Unblock Memory Library Interface.
+
+  This library provides an 

Re: [edk2-devel] [edk2-platforms] [PATCH v1 0/9] IpmiFeaturePkg: Add IPMI transport drivers

[Oram, Isaac W]

Michael,

Thanks for the feedback.

I was torn between aligning with the proprietary version and cleaning it up.
My concern is if we do too much cleanup, it will delay adoption.  

I did the minimum that we know is required for ECC tool to pass coding style 
tool and avoid EFI prefixes.  

I would like delay refactoring and cleaning up until it is in the open where 
people can easily follow the code evolution from proprietary to open source.  I 
am looking to develop some maintainers for this feature package, and the 
cleanup would be a good way to ramp them into active open participation and put 
them on the path to becoming maintainers.

Anyway, your feedback is noted and I will put those on the to do list for 
completing this.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Wednesday, March 3, 2021 11:23 AM
To: devel@edk2.groups.io; Desimone, Nathaniel L 
Cc: Oram, Isaac W ; Chaganty, Rangasai V 
; Liming Gao ; Michael 
Kubacki 
Subject: Re: [edk2-devel] [edk2-platforms] [PATCH v1 0/9] IpmiFeaturePkg: Add 
IPMI transport drivers

Looked over the series at a high-level and the feature structure looks fine. 
For the series:
Acked-by: Michael Kubacki 

I didn't look closely at implementation but there's a few things I noticed.

There's a few typos. I'd suggest running a spell check to clean those up. Some 
quick examples:

ServerManagement.h:

  "Generic Definations for Server Management Header File."

   typedef struct {
 LINERIZATION_TYPE Linearization;  // L

IpmiTransportPei.h:

   "IPMI Ttransport PPI Header File."

There was a mix of function documentation styles though that might be something 
to clean up later.

I saw some globals that did not appear necessary. For example, mIpmiTransport 
in SmmIpmiBaseLib.c seems to be located before every access.

Thanks,
Michael

On 3/1/2021 6:27 PM, Nate DeSimone wrote:
> From: Isaac Oram 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3242
> 
> Implement an open source generic IPMI transport driver.
> Provides the ability to communicate with a BMC over IPMI in 
> MinPlatform board packages.
> 
> New changes:
>1. Added GenericIpmi
>2. Added IPMI base libs
>3. Added transport PPI and protocol
>4. Updated IPMI command request and response data size from
>   UINT8 to UINT32 in IPMI transport layer to be compatible
>   with EDK2 industry standard IPMI commands.
>6. Added the completion code in the first byte of all IPMI
>   response data to be compatible with EDK2 industry standard
>   IPMI commands.
> 
> Cc: Sai Chaganty 
> Cc: Liming Gao 
> Cc: Michael Kubacki 
> Signed-off-by: Isaac Oram 
> Co-authored-by: Nate DeSimone 
> 
> Isaac Oram (9):
>IpmiFeaturePkg: Add IPMI driver Include headers
>IpmiFeaturePkg: Add IpmiBaseLib and IpmiCommandLib
>IpmiFeaturePkg: Add IpmiInit drivers
>IpmiFeaturePkg: Add GenericIpmi driver common code
>IpmiFeaturePkg: Add GenericIpmi PEIM
>IpmiFeaturePkg: Add GenericIpmi DXE Driver
>IpmiFeaturePkg: Add GenericIpmi SMM Driver
>IpmiFeaturePkg: Add IPMI driver build files
>Maintainers.txt: Add IpmiFeaturePkg maintainers
> 
>   .../GenericIpmi/Common/IpmiBmc.c  | 297 +++
>   .../GenericIpmi/Common/IpmiBmc.h  |  44 ++
>   .../GenericIpmi/Common/IpmiBmcCommon.h| 179 +++
>   .../GenericIpmi/Common/IpmiHooks.c|  96 
>   .../GenericIpmi/Common/IpmiHooks.h|  81 +++
>   .../GenericIpmi/Common/IpmiPhysicalLayer.h|  29 ++
>   .../GenericIpmi/Common/KcsBmc.c   | 483 ++
>   .../GenericIpmi/Common/KcsBmc.h   | 236 +
>   .../GenericIpmi/Dxe/GenericIpmi.c |  46 ++
>   .../GenericIpmi/Dxe/GenericIpmi.inf   |  66 +++
>   .../IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c | 452 
>   .../GenericIpmi/Pei/PeiGenericIpmi.c  | 362 +
>   .../GenericIpmi/Pei/PeiGenericIpmi.h  | 138 +
>   .../GenericIpmi/Pei/PeiGenericIpmi.inf|  58 +++
>   .../GenericIpmi/Pei/PeiIpmiBmc.c  | 277 ++
>   .../GenericIpmi/Pei/PeiIpmiBmc.h  |  38 ++
>   .../GenericIpmi/Pei/PeiIpmiBmcDef.h   | 156 ++
>   .../GenericIpmi/Smm/SmmGenericIpmi.c  | 208 
>   .../GenericIpmi/Smm/SmmGenericIpmi.inf|  53 ++
>   .../IpmiFeaturePkg/Include/IpmiFeature.dsc|   9 +-
>   .../Include/Library/IpmiBaseLib.h |  50 ++
>   .../Include/Library/IpmiCommandLib.h  |  19 +-
>   .../Include/Ppi/IpmiTransportPpi.h|  68 +++
>   .../Include/Protocol/IpmiTransportProtocol.h  |  75 +++
>   .../IpmiFeaturePkg/Include/ServerManagement.h | 337 
>   .../IpmiFeaturePkg/Include/SmStatusCodes.h|  98 
>   .../IpmiFeaturePkg/IpmiFeaturePkg.dec |  22 +-
>   .../IpmiFeaturePkg/IpmiInit/DxeIpmiInit.c |   4 +-
>   

Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV

[Laszlo Ersek]

On 03/04/21 21:45, Laszlo Ersek wrote:
> On 03/04/21 10:21, Paolo Bonzini wrote:
>> Hi Tobin,
>>
>> as mentioned in the reply to the QEMU patches posted by Tobin, I
>> think the firmware helper approach is very good, but there are some
>> disadvantages in the idea of auxiliary vCPUs. These are especially
>> true in the VMM, where it's much nicer to have a separate VM that
>> goes through a specialized run loop; however, even in the firmware
>> level there are some complications (as you pointed out) in letting
>> MpService workers run after ExitBootServices.
>>
>> My idea would be that the firmware would start the VM as usual using
>> the same launch data; then, the firmware would detect it was running
>> as a migration helper VM during the SEC or PEI phases (for example
>> via the GHCB or some other unencrypted communication area), and
>> divert execution to the migration helper instead of proceeding to the
>> next boot phase. This would be somewhat similar in spirit to how edk2
>> performs S3 resume, if my memory serves correctly.
> 
> Very cool. You'd basically warm-reboot the virtual machine into a new
> boot mode (cf. BOOT_WITH_FULL_CONFIGURATION vs. BOOT_ON_S3_RESUME in
> OvmfPkg/PlatformPei).
> 
> To me that's much more attractive than a "background job".
> 
> The S3 parallel is great. What I'm missing is:
> 
> - Is it possible to warm-reboot an SEV VM? (I vaguely recall that it's
> not possible for SEV-ES at least.) Because, that's how we'd transfer
> control to the early parts of the firmware again, IIUC your idea, while
> preserving the memory contents.
> 
> - Who would initiate this process? S3 suspend is guest-initiated. (Not
> that we couldn't use the guest agent, if needed.)
> 
> (In case the idea is really about a separate VM, and not about rebooting
> the already running VM, then I don't understand -- how would a separate
> VM access the guest RAM that needs to be migrated?)

Sorry -- I've just caught up with the QEMU thread. Your message there:

  https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01220.html

says:

  Patches were posted recently to the KVM mailing list to create
  secondary VMs sharing the encryption context (ASID) with a primary VM

I did think of VMs sharing memory, but the goal of SEV seemed to be to
prevent exactly that, so I didn't think that was possible. I stand
corrected, and yes, this way I understand -- and welcome -- a completely
separate VM snooping the migration subject VM's memory.

My question would be then whether the migration helper VM would run on
its own memory, and just read out the other VM's memory -- or the MH VM
would run somewhere inside the original VM's memory (which sounds a lot
riskier). But your message explains that too:

  The main advantage would be that the migration VM would not have to
  share the address space with the primary VM

This sounds ideal; it should allow for a completely independent firmware
platform -- we wouldn't even have to call it "OVMF", and it might not
even have to contain the DXE Core and later-phase components. (Of course
if it's more convenient to keep the stuff in OVMF, that works too.)

(For some unsolicited personal information, now I feel less bad about
this idea never occurring to me -- I never knew about the KVM patch set
that would enable encryption context sharing. (TBH I thought that was
prevented, by design, in the SEV hardware...))


A workflow request to Tobin and Dov -- when posting closely interfacing
QEMU and edk2 series, it's best to cross-post both series to both lists,
and to CC everybody on everything. Feel free to use subject prefixes
like [qemu PATCH] and [edk2 PATCH] for clarity. It's been difficult for
me to follow both discussions (it doesn't help that I've been CC'd on
neither).

Thanks!
Laszlo

> 
> NB in the X64 PEI phase of OVMF, only the first 4GB of RAM is mapped, so
> the migration handler would have to build its own page table under this
> approach too.
> 
> Thanks!
> Laszlo
> 



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

Re: [edk2-devel] Question about Smm code / StandaloneMmPkg

[Laszlo Ersek]

Adding Kun Qin; a comment below:

On 03/04/21 09:34, Tiger Liu(BJ-RD) wrote:
> Dear All:
> I have a few questions about Smm code and StandaloneMmPkg.
> 
> Take X86 Arch cpu as example:
> 1. Smm infrastructure code is implemented in MdeModulePkg\Core\PiSmmCore
>But it's a traditional smm mode, used launched in UEFI DXE Phase.
> 
> A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf
> > This doc introduced a standalone smm mode.
> 
> PI Spec introduces a MM concept, it's arch independent.
> 
> So, I have below questions:
> 1. Will X86 SMM code implementation be migrated to MM concept code base?
> 2. StandaloneMmPkg is a MM reference implementation, is it arch independent?
> 3. The above doc mentioned launching SMM drivers in PEI,  is it also 
> implemented in StandaloneMmPkg?

Please see (also) the following thread:

  [edk2-rfc] [RFC]
  Support Both MM Traditional and Standalone Drivers with One MM Core

  https://edk2.groups.io/g/rfc/message/430

Thanks
Laszlo


> 
> Thanks
> 
> 
> 保密声明：
> 本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for 
> the sole use of its intended recipient. Any unauthorized review, use, copying 
> or forwarding of this email or the content of this email is strictly 
> prohibited.
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV

[Laszlo Ersek]

On 03/04/21 10:21, Paolo Bonzini wrote:
> Hi Tobin,
> 
> as mentioned in the reply to the QEMU patches posted by Tobin, I
> think the firmware helper approach is very good, but there are some
> disadvantages in the idea of auxiliary vCPUs. These are especially
> true in the VMM, where it's much nicer to have a separate VM that
> goes through a specialized run loop; however, even in the firmware
> level there are some complications (as you pointed out) in letting
> MpService workers run after ExitBootServices.
> 
> My idea would be that the firmware would start the VM as usual using
> the same launch data; then, the firmware would detect it was running
> as a migration helper VM during the SEC or PEI phases (for example
> via the GHCB or some other unencrypted communication area), and
> divert execution to the migration helper instead of proceeding to the
> next boot phase. This would be somewhat similar in spirit to how edk2
> performs S3 resume, if my memory serves correctly.

Very cool. You'd basically warm-reboot the virtual machine into a new
boot mode (cf. BOOT_WITH_FULL_CONFIGURATION vs. BOOT_ON_S3_RESUME in
OvmfPkg/PlatformPei).

To me that's much more attractive than a "background job".

The S3 parallel is great. What I'm missing is:

- Is it possible to warm-reboot an SEV VM? (I vaguely recall that it's
not possible for SEV-ES at least.) Because, that's how we'd transfer
control to the early parts of the firmware again, IIUC your idea, while
preserving the memory contents.

- Who would initiate this process? S3 suspend is guest-initiated. (Not
that we couldn't use the guest agent, if needed.)

(In case the idea is really about a separate VM, and not about rebooting
the already running VM, then I don't understand -- how would a separate
VM access the guest RAM that needs to be migrated?)

NB in the X64 PEI phase of OVMF, only the first 4GB of RAM is mapped, so
the migration handler would have to build its own page table under this
approach too.

Thanks!
Laszlo



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

Re: [edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null instance

[Laszlo Ersek]

On 03/04/21 19:58, Kun Qin wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3168
> 
> This interface provides an abstration layer to allow MM modules to access
> requested areas that are outside of MMRAM. On MM model that blocks all
> non-MMRAM accesses, areas requested through this API will be mapped or
> unblocked for accessibility inside MM environment.
> 
> For MM modules that need to access regions outside of MMRAMs, the agents
> that set up these regions are responsible for invoking this API in order
> for these memory areas to be accessible from inside MM.
> 
> Example usages:
> 1. To enable runtime cache feature for variable service, Variable MM
> module will need to access the allocated runtime buffer. Thus the agent
> sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
> API to make these regions accessible by Variable MM.
> 2. For TPM ACPI table to communicate to physical presence handler, the
> corresponding NVS region has to be accessible from inside MM. Once the
> NVS region are assigned, it needs to be unblocked thourgh this API.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Hao A Wu 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> 
> Signed-off-by: Kun Qin 
> ---
> 
> Notes:
> v5:
> - Downgraded data types from EFI_* to RETURN_*. [Laszlo]
> 
> v4:
> - Added more commit message [Laszlo]
> - Added UNI file [Hao]
> 
> v3:
> - Move interface to MdePkg [Hao, Liming, Jiewen]
> - Remove Dxe prefix [Jiewen]
> 
> v2:
> - Resend with practical usage. No change [Hao]
> 
>  MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   | 44 
> 
>  MdePkg/Include/Library/MmUnblockMemoryLib.h  | 44 
> 
>  MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf | 34 
> +++
>  MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni | 21 ++
>  MdePkg/MdePkg.dec|  5 +++
>  MdePkg/MdePkg.dsc|  1 +
>  6 files changed, 149 insertions(+)
> 
> diff --git a/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c 
> b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
> new file mode 100644
> index ..b205c9122df8
> --- /dev/null
> +++ b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
> @@ -0,0 +1,44 @@
> +/** @file
> +  Null instance of MM Unblock Page Library.
> +
> +  This library provides an interface to request non-MMRAM pages to be 
> mapped/unblocked
> +  from inside MM environment.
> +
> +  For MM modules that need to access regions outside of MMRAMs, the agents 
> that set up
> +  these regions are responsible for invoking this API in order for these 
> memory areas
> +  to be accessed from inside MM.
> +
> +  Copyright (c) Microsoft Corporation.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +
> +/**
> +  This API provides a way to unblock certain data pages to be accessible 
> inside MM environment.
> +
> +  @param  UnblockAddress  The address of buffer caller requests 
> to unblock, the address
> +  has to be page aligned.
> +  @param  NumberOfPages   The number of pages requested to be 
> unblocked from MM
> +  environment.
> +
> +  @retval RETURN_SUCCESS  The request goes through successfully.
> +  @retval RETURN_NOT_AVAILABLE_YETThe requested functionality is not 
> produced yet.
> +  @retval RETURN_UNSUPPORTED  The requested functionality is not 
> supported on current platform.
> +  @retval RETURN_SECURITY_VIOLATION   The requested address failed to pass 
> security check for
> +  unblocking.
> +  @retval RETURN_INVALID_PARAMETERInput address either NULL pointer or 
> not page aligned.
> +  @retval RETURN_ACCESS_DENIEDThe request is rejected due to system 
> has passed certain boot
> +  phase.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +MmUnblockMemoryRequest (
> +  IN PHYSICAL_ADDRESS   UnblockAddress,
> +  IN UINT64 NumberOfPages
> +  )
> +{
> +  return RETURN_UNSUPPORTED;
> +}
> diff --git a/MdePkg/Include/Library/MmUnblockMemoryLib.h 
> b/MdePkg/Include/Library/MmUnblockMemoryLib.h
> new file mode 100644
> index ..00fab530a3bc
> --- /dev/null
> +++ b/MdePkg/Include/Library/MmUnblockMemoryLib.h
> @@ -0,0 +1,44 @@
> +/** @file
> +  MM Unblock Memory Library Interface.
> +
> +  This library provides an interface to request non-MMRAM pages to be 
> mapped/unblocked
> +  from inside MM environment.
> +
> +  For MM modules that need to access regions outside of MMRAMs, the agents 
> that set up
> +  these regions are responsible for invoking this API in order for these 
> memory areas
> +  to be accessed from inside MM.
> +
> +  Copyright 

Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI runs

[Laszlo Ersek]

On 03/04/21 19:32, Bret Barkelew wrote:

> Can you share the specific PR youre failing so that we can talk in
> concrete terms?

Sure.

In January, I posted the following patch series:

  [edk2-devel] [PATCH 0/8]
  ShellPkg, ArmVirtPkg, OvmfPkg: shell usability improvements

  https://edk2.groups.io/g/devel/message/69590
  https://www.redhat.com/archives/edk2-devel-archive/2021-January/msg00070.html
  Message-Id: 20210104154235.31785-1-ler...@redhat.com

This series cleared my local CI just fine (both Windows and Linux VM),
before I posted it.

When review was done, I attempted to merge the series:

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

Although the PR does not show it now (or at least I cannot make it show
it), the github CI uncovered a real problem in my patch set, one that my
local run missed.

Namely, I had added an OrderedCollectionLib class dependency to the
(singleton) UefiShellCommandLib instance, but failed to resolve the
OrderedCollectionLib class in the EmulatorPkg and UefiPayloadPkg DSC
files. Consequently, those DSC files would no longer build. My local CI
runs didn't extend to these packages, but -- thankfully -- the
github.com-based CI did.

In v2, I added one extra patch for each of EmulatorPkg and
UefiPayloadPkg DSC:

  [edk2-devel] [PATCH v2 00/10]
  multiple packages: shell usability improvements

  https://edk2.groups.io/g/devel/message/70216
  https://www.redhat.com/archives/edk2-devel-archive/2021-January/msg00700.html
  Message-Id: 20210113085453.10168-1-ler...@redhat.com

(What's more, I tracked down the DSC files in edk2-platforms that used
to build the shell, and I resolved the OrderedCollectionLib class in
them as well -- see the links inside the above-referenced blurbs.)

The v2 CI succeded on github (personal, then merge):

  https://github.com/tianocore/edk2/pull/1337
  https://github.com/tianocore/edk2/pull/1370

In summary, the bug (in my local CI usage) was that I didn't cover
EmulatorPkg and UefiPayloadPkg.

So, I'd like if the local test builds determined the affected set of
packages as well -- I'd like to be *unable* to miss EmulatorPkg and
UefiPayloadPkg in the above type of situation.

Thanks!
Laszlo



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

[edk2-devel] [PATCH v5 3/7] MdeModulePkg: VariableSmmRuntimeDxe: Added request unblock memory interface

[Kun Qin]

This changes added usage of MmUnblockMemoryLib to explicitly request
runtime cache regions(and its indicators) to be accessible from MM
environment when PcdEnableVariableRuntimeCache is enabled. It will bring
in compatibility with architectures that supports full memory blockage
inside MM.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 

Signed-off-by: Kun Qin 
Reviewed-by: Hao A Wu 
---

Notes:
v5:
- Previously reviewed, no change.

v4:
- Added reviewed-by tag. [Hao]

v3:
- Removed Dxe prefix to match interface change. [Jiewen]

v2:
- Newly added in v2.

 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c   | 42 

 MdeModulePkg/MdeModulePkg.dsc|  1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf |  1 +
 3 files changed, 44 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
index c47e614d81f4..a166d284dfe4 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -35,6 +35,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -165,6 +166,7 @@ InitVariableCache (
   )
 {
   VARIABLE_STORE_HEADER   *VariableCacheStorePtr;
+  EFI_STATUS  Status;
 
   if (TotalVariableCacheSize == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -186,6 +188,18 @@ InitVariableCache (
   if (*VariableCacheBuffer == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
+
+  //
+  // Request to unblock the newly allocated cache region to be accessible from 
inside MM
+  //
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) (UINTN) *VariableCacheBuffer,
+EFI_SIZE_TO_PAGES (*TotalVariableCacheSize)
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+return Status;
+  }
+
   VariableCacheStorePtr = *VariableCacheBuffer;
   SetMem32 ((VOID *) VariableCacheStorePtr, *TotalVariableCacheSize, (UINT32) 
0x);
 
@@ -1536,6 +1550,34 @@ SendRuntimeVariableCacheContextToSmm (
   SmmRuntimeVarCacheContext->ReadLock = 
   SmmRuntimeVarCacheContext->HobFlushComplete = 
 
+  //
+  // Request to unblock this region to be accessible from inside MM environment
+  // These fields "should" be all on the same page, but just to be on the safe 
side...
+  //
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) ALIGN_VALUE ((UINTN) 
SmmRuntimeVarCacheContext->PendingUpdate - EFI_PAGE_SIZE + 1, EFI_PAGE_SIZE),
+EFI_SIZE_TO_PAGES (sizeof(mVariableRuntimeCachePendingUpdate))
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) ALIGN_VALUE ((UINTN) 
SmmRuntimeVarCacheContext->ReadLock - EFI_PAGE_SIZE + 1, EFI_PAGE_SIZE),
+EFI_SIZE_TO_PAGES (sizeof(mVariableRuntimeCacheReadLock))
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  Status = MmUnblockMemoryRequest (
+(EFI_PHYSICAL_ADDRESS) ALIGN_VALUE ((UINTN) 
SmmRuntimeVarCacheContext->HobFlushComplete - EFI_PAGE_SIZE + 1, EFI_PAGE_SIZE),
+EFI_SIZE_TO_PAGES (sizeof(mHobFlushComplete))
+);
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+goto Done;
+  }
+
   //
   // Send data to SMM.
   //
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 7ca4a1bb3080..9272da89a998 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -100,6 +100,7 @@ [LibraryClasses]
   SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
   
DisplayUpdateProgressLib|MdeModulePkg/Library/DisplayUpdateProgressLibGraphics/DisplayUpdateProgressLibGraphics.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 
 [LibraryClasses.EBC.PEIM]
   IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
index b6dbc839e023..a0d8b2267e92 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
@@ -60,6 +60,7 @@ [LibraryClasses]
   TpmMeasurementLib
   SafeIntLib
   PcdLib
+  MmUnblockMemoryLib
 
 [Protocols]
   gEfiVariableWriteArchProtocolGuid ## PRODUCES
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v5 5/7] SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2 modules

[Kun Qin]

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

This change separated the original Tcg2Smm module into 2 drivers: the
SMM driver that registers callback for physical presence and memory
clear; the Tcg2Acpi driver that patches and publishes ACPI table for
runtime use.

Tcg2Smm introduced an SMI root handler to allow Tcg2Acpi to communicate
the NVS region used by Tpm.asl and exchange the registered SwSmiValue.

Lastly, Tcg2Smm driver will publish gTcg2MmSwSmiRegisteredGuid at the end
of entrypoint to ensure Tcg2Acpi to load after Tcg2Smm is ready to
communicate.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v5:
- Previously reviewed, no change.

v4:
- Previously reviewed, no change.

v3:
- Added review-by tag. [Jiewen]
- Added expected usage in driver header.
- Initialized pointer variables to null at entrypoint.

v2:
- Newly added.

 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c} | 352 
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c  | 853 

 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c|  82 ++
 SecurityPkg/Include/Guid/TpmNvsMm.h|  68 ++
 SecurityPkg/SecurityPkg.dec|   7 +
 SecurityPkg/SecurityPkg.dsc|   1 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf} |  34 +-
 SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl  |   0
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h  | 119 +--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf|  25 +-
 10 files changed, 549 insertions(+), 992 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
similarity index 72%
copy from SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
copy to SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
index 08105c3692ba..9d6bc09bdc0d 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
@@ -1,20 +1,76 @@
 /** @file
-  It updates TPM2 items in ACPI table and registers SMI2 callback
-  functions for Tcg2 physical presence, ClearMemory, and sample
-  for dTPM StartMethod.
+  This driver implements TPM 2.0 definition block in ACPI table and
+  populates registered SMI callback functions for Tcg2 physical presence
+  and MemoryClear to handle the requests for ACPI method. It needs to be
+  used together with Tcg2 MM drivers to exchange information on registered
+  SwSmiValue and allocated NVS region address.
 
   Caution: This module requires additional review when modified.
   This driver will have external input - variable and ACPINvs data in SMM mode.
   This external input must be validated carefully to avoid security issue.
 
-  PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted 
input and do some check.
-
 Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
-#include "Tcg2Smm.h"
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//
+// Physical Presence Interface Version supported by Platform
+//
+#define PHYSICAL_PRESENCE_VERSION_TAG  "$PV"
+#define PHYSICAL_PRESENCE_VERSION_SIZE 4
+
+//
+// PNP _HID for TPM2 device
+//
+#define TPM_HID_TAG""
+#define TPM_HID_PNP_SIZE   8
+#define TPM_HID_ACPI_SIZE  9
+
+#define TPM_PRS_RESL   "RESL"
+#define TPM_PRS_RESS   "RESS"
+#define TPM_PRS_RES_NAME_SIZE  4
+//
+// Minimum PRS resource template size
+//  1 bytefor  BufferOp
+//  1 bytefor  PkgLength
+//  2 bytes   for  BufferSize
+//  12 bytes  for  Memory32Fixed descriptor
+//  5 bytes   for  Interrupt descriptor
+//  2 bytes   for  END Tag
+//
+#define TPM_POS_RES_TEMPLATE_MIN_SIZE  (1 + 1 + 2 
+ 12 + 5 + 2)
+
+//
+// Max Interrupt buffer size for PRS interrupt resource
+// Now support 15 interrupts in maxmum
+//
+#define MAX_PRS_INT_BUF_SIZE   (15*4)
 
 #pragma pack(1)
 
@@ -49,142 +105,8 @@ EFI_TPM2_ACPI_TABLE_V4  mTpm2AcpiTemplate = {
   EFI_TPM2_ACPI_TABLE_START_METHOD_TIS, // StartMethod
 };
 
-EFI_SMM_VARIABLE_PROTOCOL  *mSmmVariable;
 TCG_NVS*mTcgNvs;
 
-/**
-  Software SMI callback for TPM physical presence which is called from ACPI 
method.
-
-  Caution: This function may receive untrusted input.
-  Variable and ACPINvs are 

[edk2-devel] [PATCH v5 7/7] SecurityPkg: Tcg2Acpi: Added unblock memory interface for NVS region

[Kun Qin]

This changes added usage of MmUnblockMemoryLib to explicitly request
allocated NVS region to be accessible from MM environment. It will bring
in compatibility with architectures that supports full memory blockage
inside MM.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v5:
- Previously reviewed, no change.

v4:
- Previously reviewed, no change.

v3:
- Added review-by tag. [Jiewen]
- Remove Dxe prefix to match interface update. [Jiewen]

v2:
- Newly added in v2.

 SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c   | 6 ++
 SecurityPkg/SecurityPkg.dsc   | 1 +
 SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf | 1 +
 3 files changed, 8 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c 
b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
index 9d6bc09bdc0d..db2e56b6122c 100644
--- a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
+++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
@@ -38,6 +38,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 //
 // Physical Presence Interface Version supported by Platform
@@ -147,6 +148,11 @@ AssignOpRegion (
   ZeroMem ((VOID *)(UINTN)MemoryAddress, Size);
   OpRegion->RegionOffset = (UINT32) (UINTN) MemoryAddress;
   OpRegion->RegionLen= (UINT8) Size;
+  // Request to unblock this region from MM core
+  Status = MmUnblockMemoryRequest (MemoryAddress, EFI_SIZE_TO_PAGES 
(Size));
+  if (Status != EFI_UNSUPPORTED && EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+  }
   break;
 }
   }
diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index 74ec42966273..a77665518bdd 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -67,6 +67,7 @@ [LibraryClasses]
   VariableKeyLib|SecurityPkg/Library/VariableKeyLibNull/VariableKeyLibNull.inf
   RpmcLib|SecurityPkg/Library/RpmcLibNull/RpmcLibNull.inf
   
TcgEventLogRecordLib|SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.inf
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 
 [LibraryClasses.ARM]
   #
diff --git a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf 
b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
index 42ddb4bd1f39..f1c6ae5b1cb4 100644
--- a/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
+++ b/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
@@ -57,6 +57,7 @@ [LibraryClasses]
   Tpm2CommandLib
   Tcg2PhysicalPresenceLib
   PcdLib
+  MmUnblockMemoryLib
 
 [Guids]
   gEfiTpmDeviceInstanceTpm20DtpmGuid## PRODUCES
   ## GUID   # TPM device identifier
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v5 6/7] SecurityPkg: Tcg2Smm: Added support for Standalone Mm

[Kun Qin]

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

This change added Standalone MM instance of Tcg2. The notify function for
Standalone MM instance is left empty.

A dependency DXE driver with a Depex of gEfiMmCommunication2ProtocolGuid
was created to indicate the readiness of Standalone MM Tcg2 driver.

Lastly, the support of CI build for Tcg2 Standalone MM module is added.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v5:
- Added reviewed-by tag. [Jiewen]

v4:
- Changed dependency module from anonymous lib to Dxe driver. [Jiewen]

v3:
- No change.

v2:
- Newly added.

 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c   | 48 
 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c  | 71 ++
 SecurityPkg/SecurityPkg.ci.yaml |  1 +
 SecurityPkg/SecurityPkg.dec |  1 +
 SecurityPkg/SecurityPkg.dsc | 10 +++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf | 43 +++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.inf| 77 
 7 files changed, 251 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
new file mode 100644
index ..4f2d7c58ed86
--- /dev/null
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
@@ -0,0 +1,48 @@
+/** @file
+  Runtime DXE part corresponding to StandaloneMM Tcg2 module.
+
+This module installs gTcg2MmSwSmiRegisteredGuid to notify readiness of
+StandaloneMM Tcg2 module.
+
+Copyright (c) 2019 - 2021, Arm Ltd. All rights reserved.
+Copyright (c) Microsoft Corporation.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include 
+#include 
+
+/**
+  The constructor function installs gTcg2MmSwSmiRegisteredGuid to notify
+  readiness of StandaloneMM Tcg2 module.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the Management mode System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+Tcg2MmDependencyDxeEntryPoint (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  EFI_STATUSStatus;
+  EFI_HANDLEHandle;
+
+  Handle = NULL;
+  Status = gBS->InstallProtocolInterface (
+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  NULL
+  );
+  ASSERT_EFI_ERROR (Status);
+  return EFI_SUCCESS;
+}
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
new file mode 100644
index ..9e0095efbc5e
--- /dev/null
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
@@ -0,0 +1,71 @@
+/** @file
+  TCG2 Standalone MM driver that updates TPM2 items in ACPI table and registers
+  SMI2 callback functions for Tcg2 physical presence, ClearMemory, and
+  sample for dTPM StartMethod.
+
+  Caution: This module requires additional review when modified.
+  This driver will have external input - variable and ACPINvs data in SMM mode.
+  This external input must be validated carefully to avoid security issue.
+
+  PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted 
input and do some check.
+
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "Tcg2Smm.h"
+#include 
+
+/**
+  Notify the system that the SMM variable driver is ready.
+**/
+VOID
+Tcg2NotifyMmReady (
+  VOID
+  )
+{
+  // Do nothing
+}
+
+/**
+  This function is an abstraction layer for implementation specific Mm buffer 
validation routine.
+
+  @param Buffer  The buffer start address to be checked.
+  @param Length  The buffer length to be checked.
+
+  @retval TRUE  This buffer is valid per processor architecture and not 
overlap with SMRAM.
+  @retval FALSE This buffer is not valid per processor architecture or overlap 
with SMRAM.
+**/
+BOOLEAN
+IsBufferOutsideMmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  )
+{
+  return MmIsBufferOutsideMmValid (Buffer, Length);
+}
+
+/**
+  The driver's entry point.
+
+  It install callbacks for TPM physical presence and MemoryClear, and locate
+  SMM variable to be used in the callback function.
+
+  @param[in] ImageHandle  The firmware allocated handle for the EFI image.
+  @param[in] SystemTable  A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS The entry point is executed successfully.
+  @retval Others  Some error occurs when executing this entry point.
+
+**/
+EFI_STATUS
+EFIAPI
+InitializeTcgStandaloneMm (
+  IN EFI_HANDLE  ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE *SystemTable
+  )
+{
+  return InitializeTcgCommon ();
+}
diff --git 

[edk2-devel] [PATCH v5 4/7] SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst

[Kun Qin]

This change replaced gSmst with gMmst to support broader compatibility
under MM environment for Tcg2Smm driver.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Signed-off-by: Kun Qin 
Reviewed-by: Jiewen Yao 
---

Notes:
v5:
- Previously reviewed, no change.

v4:
- Previously reviewed, no change.

v3:
- Added reviewed-by tag. [Jiewen]

v2:
- Newly added in v2.

 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c   | 4 ++--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h   | 2 +-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
index 91aebb62b8bf..08105c3692ba 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
@@ -870,7 +870,7 @@ InitializeTcgSmm (
   //
   // Get the Sw dispatch protocol and register SMI callback functions.
   //
-  Status = gSmst->SmmLocateProtocol (, NULL, 
(VOID**));
+  Status = gMmst->MmLocateProtocol (, NULL, 
(VOID**));
   ASSERT_EFI_ERROR (Status);
   SwContext.SwSmiInputValue = (UINTN) -1;
   Status = SwDispatch->Register (SwDispatch, PhysicalPresenceCallback, 
, );
@@ -891,7 +891,7 @@ InitializeTcgSmm (
   //
   // Locate SmmVariableProtocol.
   //
-  Status = gSmst->SmmLocateProtocol (, NULL, 
(VOID**));
+  Status = gMmst->MmLocateProtocol (, NULL, 
(VOID**));
   ASSERT_EFI_ERROR (Status);
 
   //
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
index fd19e7dc0553..d7328c8f2ac9 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
@@ -24,7 +24,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
index 2ebf2e05f2ea..872ed27cbe71 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
@@ -50,7 +50,7 @@ [LibraryClasses]
   BaseLib
   BaseMemoryLib
   UefiDriverEntryPoint
-  SmmServicesTableLib
+  MmServicesTableLib
   UefiBootServicesTableLib
   DebugLib
   DxeServicesLib
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v5 2/7] OvmfPkg: resolve MmUnblockMemoryLib (mainly for VariableSmmRuntimeDxe)

[Kun Qin]

This change added NULL MmUnblockMemoryLib instance in dsc files of
OvmfPkg to pass CI build. When SMM_REQUIRE flag is set, the library
interface is consumed by VariableSmmRuntimeDxe to better support variable
runtime cache feature.

Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 

Signed-off-by: Kun Qin 
Reviewed-by: Laszlo Ersek 
---

Notes:
v5:
- Previously reviewed, no change.

v4:
- Updated patch title. [Laszlo]
- Moved this patch before the variable driver change. [Laszlo]
- Added reviewed-by tag. [Laszlo]

v3:
- Newly added in v3. [Hao]

 OvmfPkg/OvmfPkgIa32.dsc| 3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++
 OvmfPkg/OvmfPkgX64.dsc | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 1b8d34052b01..1eaf3e99c6c5 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -347,6 +347,9 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+!if $(SMM_REQUIRE) == TRUE
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 9c1aee87e783..4a5a43014725 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -351,6 +351,9 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+!if $(SMM_REQUIRE) == TRUE
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fabb8b2f29e4..d4d601b44476 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -353,6 +353,9 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
   
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
+!if $(SMM_REQUIRE) == TRUE
+  
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
2.30.0.windows.1



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

[edk2-devel] [PATCH v5 1/7] MdePkg: MmUnblockMemoryLib: Added definition and null instance

[Kun Qin]

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

This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.

For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.

Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Hao A Wu 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 

Signed-off-by: Kun Qin 
---

Notes:
v5:
- Downgraded data types from EFI_* to RETURN_*. [Laszlo]

v4:
- Added more commit message [Laszlo]
- Added UNI file [Hao]

v3:
- Move interface to MdePkg [Hao, Liming, Jiewen]
- Remove Dxe prefix [Jiewen]

v2:
- Resend with practical usage. No change [Hao]

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   | 44 

 MdePkg/Include/Library/MmUnblockMemoryLib.h  | 44 

 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf | 34 
+++
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni | 21 ++
 MdePkg/MdePkg.dec|  5 +++
 MdePkg/MdePkg.dsc|  1 +
 6 files changed, 149 insertions(+)

diff --git a/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c 
b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
new file mode 100644
index ..b205c9122df8
--- /dev/null
+++ b/MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
@@ -0,0 +1,44 @@
+/** @file
+  Null instance of MM Unblock Page Library.
+
+  This library provides an interface to request non-MMRAM pages to be 
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents 
that set up
+  these regions are responsible for invoking this API in order for these 
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  This API provides a way to unblock certain data pages to be accessible 
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer caller requests to 
unblock, the address
+  has to be page aligned.
+  @param  NumberOfPages   The number of pages requested to be 
unblocked from MM
+  environment.
+
+  @retval RETURN_SUCCESS  The request goes through successfully.
+  @retval RETURN_NOT_AVAILABLE_YETThe requested functionality is not 
produced yet.
+  @retval RETURN_UNSUPPORTED  The requested functionality is not 
supported on current platform.
+  @retval RETURN_SECURITY_VIOLATION   The requested address failed to pass 
security check for
+  unblocking.
+  @retval RETURN_INVALID_PARAMETERInput address either NULL pointer or not 
page aligned.
+  @retval RETURN_ACCESS_DENIEDThe request is rejected due to system 
has passed certain boot
+  phase.
+
+**/
+RETURN_STATUS
+EFIAPI
+MmUnblockMemoryRequest (
+  IN PHYSICAL_ADDRESS   UnblockAddress,
+  IN UINT64 NumberOfPages
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
diff --git a/MdePkg/Include/Library/MmUnblockMemoryLib.h 
b/MdePkg/Include/Library/MmUnblockMemoryLib.h
new file mode 100644
index ..00fab530a3bc
--- /dev/null
+++ b/MdePkg/Include/Library/MmUnblockMemoryLib.h
@@ -0,0 +1,44 @@
+/** @file
+  MM Unblock Memory Library Interface.
+
+  This library provides an interface to request non-MMRAM pages to be 
mapped/unblocked
+  from inside MM environment.
+
+  For MM modules that need to access regions outside of MMRAMs, the agents 
that set up
+  these regions are responsible for invoking this API in order for these 
memory areas
+  to be accessed from inside MM.
+
+  Copyright (c) Microsoft Corporation.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MM_UNBLOCK_MEMORY_LIB_H_
+#define MM_UNBLOCK_MEMORY_LIB_H_
+
+/**
+  This API provides a way to unblock certain data pages to be accessible 
inside MM environment.
+
+  @param  UnblockAddress  The address of buffer 

[edk2-devel] [PATCH v5 0/7] Add MmUnblockMemoryLib Interface and Usages

[Kun Qin]

This patch series is a follow up of previous submission:
https://edk2.groups.io/g/devel/message/72343

The module changes are validated on two different physical platforms and
QEMU based Q35 plastform. Standalone and traditional MM are both tested
to be functional on these systems.

v5 patches mainly focus on feedback for reviewed commits in v4 patches,
including:
a. Adding "Reviewed-by" tags for applicable patch;
b. Downgrade EFI_* data types to RETURN_*;

Patch v5 branch: https://github.com/kuqin12/edk2/tree/unblock_mem_v5

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Qi Zhang 
Cc: Rahul Kumar 

Kun Qin (7):
  MdePkg: MmUnblockMemoryLib: Added definition and null instance
  OvmfPkg: resolve MmUnblockMemoryLib (mainly for VariableSmmRuntimeDxe)
  MdeModulePkg: VariableSmmRuntimeDxe: Added request unblock memory
interface
  SecurityPkg: Tcg2Smm: Switching from gSmst to gMmst
  SecurityPkg: Tcg2Smm: Separate Tcg2Smm into 2 modules
  SecurityPkg: Tcg2Smm: Added support for Standalone Mm
  SecurityPkg: Tcg2Acpi: Added unblock memory interface for NVS region

 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c   |  42 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c   |  44 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c}   | 358 

 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c|  48 ++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c| 857 

 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c   |  71 ++
 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c  |  82 ++
 MdeModulePkg/MdeModulePkg.dsc|   1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf |   1 +
 MdePkg/Include/Library/MmUnblockMemoryLib.h  |  44 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf |  34 +
 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni |  21 +
 MdePkg/MdePkg.dec|   5 +
 MdePkg/MdePkg.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.dsc  |   3 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   3 +
 OvmfPkg/OvmfPkgX64.dsc   |   3 +
 SecurityPkg/Include/Guid/TpmNvsMm.h  |  68 ++
 SecurityPkg/SecurityPkg.ci.yaml  |   1 +
 SecurityPkg/SecurityPkg.dec  |   8 +
 SecurityPkg/SecurityPkg.dsc  |  12 +
 SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf}   |  35 +-
 SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl|   0
 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf  |  43 +
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h| 121 +--
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf  |  27 +-
 SecurityPkg/Tcg/Tcg2Smm/{Tcg2Smm.inf => Tcg2StandaloneMm.inf}|  50 +-
 27 files changed, 950 insertions(+), 1033 deletions(-)
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.c
 copy SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.c => Tcg2Acpi/Tcg2Acpi.c} (72%)
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.c
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2StandaloneMm.c
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2TraditionalMm.c
 create mode 100644 MdePkg/Include/Library/MmUnblockMemoryLib.h
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
 create mode 100644 MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.uni
 create mode 100644 SecurityPkg/Include/Guid/TpmNvsMm.h
 copy SecurityPkg/Tcg/{Tcg2Smm/Tcg2Smm.inf => Tcg2Acpi/Tcg2Acpi.inf} (76%)
 rename SecurityPkg/Tcg/{Tcg2Smm => Tcg2Acpi}/Tpm.asl (100%)
 create mode 100644 SecurityPkg/Tcg/Tcg2Smm/Tcg2MmDependencyDxe.inf
 copy SecurityPkg/Tcg/Tcg2Smm/{Tcg2Smm.inf => Tcg2StandaloneMm.inf} (52%)

-- 
2.30.0.windows.1



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

Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI runs

[Laszlo Ersek]

On 03/04/21 19:20, Bret Barkelew wrote:
> Thinking further, it will skip some tests if you haven’t installed the 
> prerequisites (e.g. spell check). We could potentially add a single script to 
> install the prerequisites, but then there are the prereqs for the prereqs 
> (e.g. Node).
> 
> To more clearly address your question, the “tests” that a GitHub CI is broken 
> up into are arbitrary subdivisions of the tests that run locally (when you 
> run “stuart_ci_build” without parameters) so that the workload can be divided 
> amongst the available worker agents. If you were to compare the individual 
> test logs against your local, monolithic test log, you would find that all 
> cases were covered in both (assuming the aforementioned prereqs are 
> installed).

Thank you -- I hope to test this later.

(1) A question about deps: if a dep is missing, can I force an error
(rather than a silent skip)?

Again, I distinctly remember doing what I then considered "due
diligence" locally, only to see github reject the PR later. If that was
because some deps were missing locally, I'd really like to turn that
scenario into a local error.

A script for installing all dependencies would help of course, but not
as a *replacement* for this kind of deps enforcement -- instead, only
for solving the missing dependency problems. I'd still want the local CI
to break hard if it couldn't offer the exact coverage as github.com.

Another question below:

> 
> - Bret
> 
> From: Bret Barkelew via 
> groups.io
> Sent: Thursday, March 4, 2021 9:57 AM
> To: devel@edk2.groups.io; 
> rebe...@nuviainc.com; 
> ler...@redhat.com
> Cc: Sean Brogan; Kinney, Michael 
> D
> Subject: Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local 
> CI runs
> 
> *An* answer is:
> - There’s a DevOps virtual environment that you can run that will pretend to 
> be a build agent. I played with it years ago, but that was before the CI 
> tooling (and it was years ago) so I don’t know how the capabilities compare.
> 
> My real answer is:
> - If you run the three commands -- setup, update, and build -- without any 
> parameters other than your TOOL_CHAIN_TAG, it should run all tests on all 
> packages for that particular OS/toolchain.

(2) You mention "for that particular OS/toolchain".

How can I make sure that I'm using the exact same toolchain as github would?

I'd like to tell the tooling only the OS (Windows vs. Linux), and then
the toolchain should be auto-selected, same way as it is auto-selected
on github. For example, if I'm in my Windows 10 VM, then I should be
*unable* to request anything else than the latest VS toolchain;
similarly, in the Linux VM, I should be *unable* to ask for (e.g.) the
GCC49 toolchain; only the GCC50 toolchain should be usable.

When I submit a github PR, I'm not asked to pick toolchains for CI; can
we automate the toolchain selection locally too?

(Sorry if I misunderstood your comment above -- if you are saying that
it's permitted, but *not required*, to specify TOOL_CHAIN_TAG, then my
question (2) falls away.)

Thanks!
Laszlo
> 
> - Bret
> 
> From: Rebecca Cran via groups.io
> Sent: Thursday, March 4, 2021 9:45 AM
> To: devel@edk2.groups.io; 
> ler...@redhat.com
> Cc: Sean Brogan; Bret 
> Barkelew; Kinney, Michael 
> D
> Subject: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI 
> runs
> 
> On 3/4/21 10:04 AM, Laszlo Ersek wrote:
>> (Sigh, my address book pulled one over me -- resending to the correct
>> list address now. Please ignore the previous posting that you may have
>> gotten "in private".)
>>
>> Hi All,
>>
>> while I can run specific CI tests locally, using the commands listed at:
>>
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2F.pytooldata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l8WblhD%2B7dpkFaCZ8roSfNUmj1imytHi5eUT%2F%2BKrLCo%3Dreserved=0
>> 

Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI runs

[Bret Barkelew via groups.io]

Digging in even further, it looks like you’re asking about tests across test 
pipelines, including some of the platform pipelines. I don’t believe there’s a 
cohesive way to do that, as some of them require platform-specific parameters 
(such as the --FlashRom parameter for OvmfPkg).

Can you share the specific PR you’re failing so that we can talk in concrete 
terms?

My guess (from experience failing this myself) is that you are failing the 
spell check remotely and not running it locally (because Node, npm, or cspell 
are not installed). It’s possible that we should investigate documenting 
cross-pipeline and cross-package CI dependencies in a central place. Right now 
it’s distributed (e.g. did you follow the steps here: 
https://github.com/tianocore/edk2/tree/master/.pytool#spell-checking---cspell).

- Bret

From: Bret Barkelew via groups.io
Sent: Thursday, March 4, 2021 10:22 AM
To: devel@edk2.groups.io; 
rebe...@nuviainc.com; 
ler...@redhat.com
Cc: Sean Brogan; Kinney, Michael 
D
Subject: Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local 
CI runs

Thinking further, it will skip some tests if you haven’t installed the 
prerequisites (e.g. spell check). We could potentially add a single script to 
install the prerequisites, but then there are the prereqs for the prereqs (e.g. 
Node).

To more clearly address your question, the “tests” that a GitHub CI is broken 
up into are arbitrary subdivisions of the tests that run locally (when you run 
“stuart_ci_build” without parameters) so that the workload can be divided 
amongst the available worker agents. If you were to compare the individual test 
logs against your local, monolithic test log, you would find that all cases 
were covered in both (assuming the aforementioned prereqs are installed).

- Bret

From: Bret Barkelew via groups.io
Sent: Thursday, March 4, 2021 9:57 AM
To: devel@edk2.groups.io; 
rebe...@nuviainc.com; 
ler...@redhat.com
Cc: Sean Brogan; Kinney, Michael 
D
Subject: Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local 
CI runs

*An* answer is:
- There’s a DevOps virtual environment that you can run that will pretend to be 
a build agent. I played with it years ago, but that was before the CI tooling 
(and it was years ago) so I don’t know how the capabilities compare.

My real answer is:
- If you run the three commands -- setup, update, and build -- without any 
parameters other than your TOOL_CHAIN_TAG, it should run all tests on all 
packages for that particular OS/toolchain.

- Bret

From: Rebecca Cran via groups.io
Sent: Thursday, March 4, 2021 9:45 AM
To: devel@edk2.groups.io; 
ler...@redhat.com
Cc: Sean Brogan; Bret 
Barkelew; Kinney, Michael 
D
Subject: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI 
runs

On 3/4/21 10:04 AM, Laszlo Ersek wrote:
> (Sigh, my address book pulled one over me -- resending to the correct
> list address now. Please ignore the previous posting that you may have
> gotten "in private".)
>
> Hi All,
>
> while I can run specific CI tests locally, using the commands listed at:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2F.pytooldata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l8WblhD%2B7dpkFaCZ8roSfNUmj1imytHi5eUT%2F%2BKrLCo%3Dreserved=0
> 

Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI runs

[Bret Barkelew via groups.io]

Thinking further, it will skip some tests if you haven’t installed the 
prerequisites (e.g. spell check). We could potentially add a single script to 
install the prerequisites, but then there are the prereqs for the prereqs (e.g. 
Node).

To more clearly address your question, the “tests” that a GitHub CI is broken 
up into are arbitrary subdivisions of the tests that run locally (when you run 
“stuart_ci_build” without parameters) so that the workload can be divided 
amongst the available worker agents. If you were to compare the individual test 
logs against your local, monolithic test log, you would find that all cases 
were covered in both (assuming the aforementioned prereqs are installed).

- Bret

From: Bret Barkelew via groups.io
Sent: Thursday, March 4, 2021 9:57 AM
To: devel@edk2.groups.io; 
rebe...@nuviainc.com; 
ler...@redhat.com
Cc: Sean Brogan; Kinney, Michael 
D
Subject: Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local 
CI runs

*An* answer is:
- There’s a DevOps virtual environment that you can run that will pretend to be 
a build agent. I played with it years ago, but that was before the CI tooling 
(and it was years ago) so I don’t know how the capabilities compare.

My real answer is:
- If you run the three commands -- setup, update, and build -- without any 
parameters other than your TOOL_CHAIN_TAG, it should run all tests on all 
packages for that particular OS/toolchain.

- Bret

From: Rebecca Cran via groups.io
Sent: Thursday, March 4, 2021 9:45 AM
To: devel@edk2.groups.io; 
ler...@redhat.com
Cc: Sean Brogan; Bret 
Barkelew; Kinney, Michael 
D
Subject: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI 
runs

On 3/4/21 10:04 AM, Laszlo Ersek wrote:
> (Sigh, my address book pulled one over me -- resending to the correct
> list address now. Please ignore the previous posting that you may have
> gotten "in private".)
>
> Hi All,
>
> while I can run specific CI tests locally, using the commands listed at:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2F.pytooldata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l8WblhD%2B7dpkFaCZ8roSfNUmj1imytHi5eUT%2F%2BKrLCo%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FArmVirtPkg%2FPlatformCIdata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8yG7Mro9Li4XeCvfmPhfReBbipz47nyAjUmMKMGfh%2Bo%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FOvmfPkg%2FPlatformCIdata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NUhAJ8zkITwPkvCrUqb7ZogSQTJuBXv0eL6Au0sYC2M%3Dreserved=0
>
> I don't know how I 

Re: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI runs

[Bret Barkelew via groups.io]

*An* answer is:
- There’s a DevOps virtual environment that you can run that will pretend to be 
a build agent. I played with it years ago, but that was before the CI tooling 
(and it was years ago) so I don’t know how the capabilities compare.

My real answer is:
- If you run the three commands -- setup, update, and build -- without any 
parameters other than your TOOL_CHAIN_TAG, it should run all tests on all 
packages for that particular OS/toolchain.

- Bret

From: Rebecca Cran via groups.io
Sent: Thursday, March 4, 2021 9:45 AM
To: devel@edk2.groups.io; 
ler...@redhat.com
Cc: Sean Brogan; Bret 
Barkelew; Kinney, Michael 
D
Subject: [EXTERNAL] Re: [edk2-devel] generating the test matrix for local CI 
runs

On 3/4/21 10:04 AM, Laszlo Ersek wrote:
> (Sigh, my address book pulled one over me -- resending to the correct
> list address now. Please ignore the previous posting that you may have
> gotten "in private".)
>
> Hi All,
>
> while I can run specific CI tests locally, using the commands listed at:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2F.pytooldata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=l8WblhD%2B7dpkFaCZ8roSfNUmj1imytHi5eUT%2F%2BKrLCo%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FArmVirtPkg%2FPlatformCIdata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8yG7Mro9Li4XeCvfmPhfReBbipz47nyAjUmMKMGfh%2Bo%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FOvmfPkg%2FPlatformCIdata=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NUhAJ8zkITwPkvCrUqb7ZogSQTJuBXv0eL6Au0sYC2M%3Dreserved=0
>
> I don't know how I can determine and drive the whole "test plan" locally.
>
> When I submit a PR to github, "something" generates (say) 83 test cases.
> How can I run that "something" locally?
>
> Assume I have the following:
> - a Linux builder VM, with up-to-date tools,
> - a Windows builder VM, with up-to-date tools,
> - a topic branch, on top of "master".
>
> How do I generate and run those same 83 tests, locally?
>
> It has happened to me that all my local CI steps succeeded (meaning both
> the Windows and the Linux builder), but github still rejected the PR --
> the reason was that I failed to think of a particular test that github
> would run. Composing 83 "stuart" command lines isn't something I'd like
> to do manually.

FWIW it looks like people have been looking for similar functionality of
testing a pipeline locally, and not found it.

e.g.:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fazure-pipelines-agent%2Fissues%2F1764data=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=XMxZesyKxVN9Wg3SyRpUbnnmKzojevHCqQhzQ1Pc4%2Bg%3Dreserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopercommunity.visualstudio.com%2Ft%2Fyaml-how-to-test-yaml-locally-before-commit%2F1302759data=04%7C01%7Cbret.barkelew%40microsoft.com%7Ce4e5493578cf45b804c608d8df354b05%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504767278995847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=gwGZAQJAIXIS0LODFpglrCf5Ua2JeMnNm3A3auCrhx8%3Dreserved=0

--
Rebecca Cran







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

Re: [edk2-devel] generating the test matrix for local CI runs

[Rebecca Cran]

On 3/4/21 10:04 AM, Laszlo Ersek wrote:

(Sigh, my address book pulled one over me -- resending to the correct
list address now. Please ignore the previous posting that you may have
gotten "in private".)

Hi All,

while I can run specific CI tests locally, using the commands listed at:

https://github.com/tianocore/edk2/tree/master/.pytool
https://github.com/tianocore/edk2/tree/master/ArmVirtPkg/PlatformCI
https://github.com/tianocore/edk2/tree/master/OvmfPkg/PlatformCI

I don't know how I can determine and drive the whole "test plan" locally.

When I submit a PR to github, "something" generates (say) 83 test cases.
How can I run that "something" locally?

Assume I have the following:
- a Linux builder VM, with up-to-date tools,
- a Windows builder VM, with up-to-date tools,
- a topic branch, on top of "master".

How do I generate and run those same 83 tests, locally?

It has happened to me that all my local CI steps succeeded (meaning both
the Windows and the Linux builder), but github still rejected the PR --
the reason was that I failed to think of a particular test that github
would run. Composing 83 "stuart" command lines isn't something I'd like
to do manually.


FWIW it looks like people have been looking for similar functionality of 
testing a pipeline locally, and not found it.


e.g.:
https://github.com/microsoft/azure-pipelines-agent/issues/1764
https://developercommunity.visualstudio.com/t/yaml-how-to-test-yaml-locally-before-commit/1302759

--
Rebecca Cran


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

Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV

[Laszlo Ersek]

On 03/03/21 19:25, Tobin Feldman-Fitzthum wrote:
>> Laszlo wrote:

>> I'm quite uncomfortable with an attempt to hide a CPU from the OS via
>> ACPI. The OS has other ways to learn (for example, a boot loader could
>> use the MP services itself, stash the information, and hand it to the OS
>> kernel -- this would minimally allow for detecting an inconsistency in
>> the OS). What about "all-but-self" IPIs too -- the kernel might think
>> all the processors it's poking like that were under its control.
> 
> This might be the second most controversial piece. Here's a question: if
> we could successfully hide the MH vCPU from the OS, would it still make
> you uncomfortable? In other words, is the worry that there might be some
> inconsistency or more generally that there is something hidden from the
> OS?

(1) My personal concern is the consistency aspect. In *some* parts of
the firmware, we'd rely on the hidden CPU to behave as a "logical
execution unit" (because we want it to run the MH), but in other parts
of the firmware, we'd expect it to be hidden. (Consider what
EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() should do while the MH is
running!) And then the CPU should be hidden from the OS completely, even
if the OS doesn't rely on ACPI, but massages LAPIC stuff that is
architecturally specified.

In other words, we'd have to treat this processor as a "service
processor", outside of the "normal" (?) processor domain -- basically
what the PSP is right now. I don't have the slightest idea how physical
firmware deals with service processors in general. I'm really scared of
the many possible corner cases (CPU hot(un)plug, NUMA proximity, ...)

(2) I expect kernel developers to have concerns about a firmware-level
"background job" at OS runtime. SMM does something similar (periodic or
otherwise hardware-initiated async SMIs etc), and kernel developers
already dislike those (latency spikes, messing with hardware state...).


> One thing to think about is that the guest owner should generally be
> aware that there is a migration handler running. The way I see it, a
> guest owner of an SEV VM would need to opt-in to migration and should
> then expect that there is an MH running even if they aren't able to see
> it. Of course we need to be certain that the MH isn't going to break the
> OS.

I didn't think of the guest owner, but the developers that work on
(possibly unrelated parts of) the guest kernel.


> 
>> Also, as far as I can tell from patch #7, the AP seems to be
>> busy-looping (with a CpuPause() added in), for the entire lifetime of
>> the OS. Do I understand right? If so -- is it a temporary trait as well?
> 
> In our approach the MH continuously checks for commands from the
> hypervisor. There are potentially ways to optimize this, such as having
> the hypervisor de-schedule the MH vCPU while not migrating. You could
> potentially shut down down the MH on the target after receiving the
> MH_RESET command (when the migration finishes), but what if you want to
> migrate that VM somewhere else?

I have no idea.

In the current world, de-scheduling a particular VCPU for extended
periods of time is a bad idea (stolen time goes up, ticks get lost, ...)
So I guess this would depend on how well you could "hide" the service
processor from the guest kernel.


I'd really like if we could rely on an established "service processor"
methodology, in the guest. Physical platform vendors have used service
processors for ages, the firmwares on those platforms (on the main
boards) do manage the service processors, and the service processors are
hidden from the OS too (beyond specified access methods, if any).

My understanding (or assumption) is that such a service processor is
primarily a separate entity (you cannot talk to them "unintentionally",
for example with an All-But-Self IPI), and that it's reachable only with
specific access methods. I think the AMD PSP itself might follow this
approach (AIUI it's an aarch64 CPU on an otherwise Intel/AMD arch platform).

I'd like us to benefit from a crystallized "service processor"
abstraction, if possible. I apologize that I'm this vague -- I've never
seen such firmware code that deals with a service processor, I just
assume it exists.

Thanks
Laszlo


> 
>>
>> Sorry if my questions are "premature", in the sense that I could get my
>> own answers as well if I actually read the patches in detail -- however,
>> I wouldn't like to do that at once, because then I'll be distracted by
>> many style issues and other "trivial" stuff. Examples for the latter:
> 
> Not premature at all. I think you hit the nail on the head with
> everything you raised.
> 
> -Tobin
> 
>>
>> - patch#1 calls SetMemoryEncDecHypercall3(), but there is no such
>> function in edk2, so minimally it's a patch ordering bug in the series,
>>
>> - in patch#1, there's minimally one whitespace error (no whitespace
>> right after "EFI_SIZE_TO_PAGES")
>>
>> - in patch#1, the alphabetical ordering in the [LibraryClasses] 

[edk2-devel] generating the test matrix for local CI runs

[Laszlo Ersek]

(Sigh, my address book pulled one over me -- resending to the correct
list address now. Please ignore the previous posting that you may have
gotten "in private".)

Hi All,

while I can run specific CI tests locally, using the commands listed at:

https://github.com/tianocore/edk2/tree/master/.pytool
https://github.com/tianocore/edk2/tree/master/ArmVirtPkg/PlatformCI
https://github.com/tianocore/edk2/tree/master/OvmfPkg/PlatformCI

I don't know how I can determine and drive the whole "test plan" locally.

When I submit a PR to github, "something" generates (say) 83 test cases.
How can I run that "something" locally?

Assume I have the following:
- a Linux builder VM, with up-to-date tools,
- a Windows builder VM, with up-to-date tools,
- a topic branch, on top of "master".

How do I generate and run those same 83 tests, locally?

It has happened to me that all my local CI steps succeeded (meaning both
the Windows and the Linux builder), but github still rejected the PR --
the reason was that I failed to think of a particular test that github
would run. Composing 83 "stuart" command lines isn't something I'd like
to do manually.

Thanks
Laszlo



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

[edk2-devel] TianoCore Community Meeting - EMEA / NAMO - Thu, 03/04/2021 9:00am-10:00am #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Community Meeting - EMEA / NAMO

*When:* Thursday, 4 March 2021, 9:00am to 10:00am, (GMT-08:00) America/Los 
Angeles

*Where:* 
https://intel.webex.com/intel/j.php?MTID=m75ff00aa6638139bdae36ef591d290cc

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

*Organizer:* Soumya Guptha soumya.k.gup...@intel.com ( 
soumya.k.gup...@intel.com?subject=Re:%20Event:%20TianoCore%20Community%20Meeting%20-%20EMEA%20%2F%20NAMO
 )

*Description:* 
https://intel.webex.com/intel/j.php?MTID=m75ff00aa6638139bdae36ef591d290cc

*When it's time, join your Webex meeting here.*

Meeting number (access code): 130 687 7985

Meeting password: PptPACG@238

Join ( 
https://intel.webex.com/intel/j.php?MTID=m75ff00aa6638139bdae36ef591d290cc )

*Tap to join from a mobile device (attendees only)*
+1-210-795-1110,,1306877985## ( tel:%2B1-210-795-1110,,*01*1306877985%23%23*01* 
) US Toll
+1-866-662-9987,,1306877985## ( tel:%2B1-866-662-9987,,*01*1306877985%23%23*01* 
) US Toll Free

*Join by phone*
+1-210-795-1110 US Toll
+1-866-662-9987 US Toll Free
Global call-in numbers ( 
https://intel.webex.com/intel/globalcallin.php?MTID=m3862b71fadf3ee4a84d53aec23f13e44
 ) | Toll-free calling restrictions ( 
https://e-meetings.verizonbusiness.com/global/pdf/Verizon_Audio_Conferencing_Global_Access_Information_August2017.pdf
 )

*Join from a video system or application*
Dial 1306877...@intel.webex.com ( sip:1306877...@intel.webex.com )
You can also dial 173.243.2.68 and enter your meeting number.

Need help? Go to http://help.webex.com ( http://help.webex.com )


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72434): https://edk2.groups.io/g/devel/message/72434
Mute This Topic: https://groups.io/mt/81081555/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] TianoCore Community Meeting - EMEA / NAMO - Thu, 03/04/2021 9:00am-10:00am #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Community Meeting - EMEA / NAMO

*When:* Thursday, 4 March 2021, 9:00am to 10:00am, (GMT-08:00) America/Los 
Angeles

*Where:* 
https://intel.webex.com/intel/j.php?MTID=m75ff00aa6638139bdae36ef591d290cc

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

*Organizer:* Soumya Guptha soumya.k.gup...@intel.com ( 
soumya.k.gup...@intel.com?subject=Re:%20Event:%20TianoCore%20Community%20Meeting%20-%20EMEA%20%2F%20NAMO
 )

*Description:* 
https://intel.webex.com/intel/j.php?MTID=m75ff00aa6638139bdae36ef591d290cc

*When it's time, join your Webex meeting here.*

Meeting number (access code): 130 687 7985

Meeting password: PptPACG@238

Join ( 
https://intel.webex.com/intel/j.php?MTID=m75ff00aa6638139bdae36ef591d290cc )

*Tap to join from a mobile device (attendees only)*
+1-210-795-1110,,1306877985## ( tel:%2B1-210-795-1110,,*01*1306877985%23%23*01* 
) US Toll
+1-866-662-9987,,1306877985## ( tel:%2B1-866-662-9987,,*01*1306877985%23%23*01* 
) US Toll Free

*Join by phone*
+1-210-795-1110 US Toll
+1-866-662-9987 US Toll Free
Global call-in numbers ( 
https://intel.webex.com/intel/globalcallin.php?MTID=m3862b71fadf3ee4a84d53aec23f13e44
 ) | Toll-free calling restrictions ( 
https://e-meetings.verizonbusiness.com/global/pdf/Verizon_Audio_Conferencing_Global_Access_Information_August2017.pdf
 )

*Join from a video system or application*
Dial 1306877...@intel.webex.com ( sip:1306877...@intel.webex.com )
You can also dial 173.243.2.68 and enter your meeting number.

Need help? Go to http://help.webex.com ( http://help.webex.com )


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72433): https://edk2.groups.io/g/devel/message/72433
Mute This Topic: https://groups.io/mt/81081296/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] Updated Event: TianoCore Design Meeting - APAC/NAMO - Friday, 5 March 2021 #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:963104 
UID:963104.g7lq.1578029159272351097.u...@groups.io
DTSTAMP:20210304T134031Z
ORGANIZER;CN=Ray Ni:mailto:ray...@intel.com
DTSTART:20210305T013000Z
DTEND:20210305T023000Z
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:## TOPIC\n\n* FilterLib: Filter/Trace Port IO/MMIO/MSR access
  (Dandan Bi/Intel)\n\nSlides: https://edk2.groups.io/g/devel/files/Design
 s/2021/0305/FilterLib.pdf\n\nFor more info\, see here:\nhttps://www.tiano
 core.org/design-meeting/\n\n## Join Webex Meeting\n\nMeeting link:\nhttps
 ://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2ff7502c98cb \n\
 nMeeting number:\n130 603 1757\n\nPassword:\nC3tRPJPV86@\n\nHost key:\n99
 1045\n\n## More ways to join\n\nJoin by video system\nDial 1306031757@int
 el.webex.com\n\nYou can also dial 173.243.2.68 and enter your meeting num
 ber.\nJoin by phone\n\n+1-210-795-1110 US Toll\n\n+1-866-662-9987 US Toll
  Free\n\nAccess code: 130 603 1757\n\n(Webex can be downloaded from https
 ://www.webex.com/downloads.html/.)
LOCATION:https://intel.webex.com/intel/j.php?MTID=me894224717bbf0af843f2f
 f7502c98cb
RECURRENCE-ID:20210305T013000Z
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV

[Paolo Bonzini]

Hi Tobin,

as mentioned in the reply to the QEMU patches posted by Tobin, I think the 
firmware helper approach is very good, but there are some disadvantages in the 
idea of auxiliary vCPUs. These are especially true in the VMM, where it's much 
nicer to have a separate VM that goes through a specialized run loop; however, 
even in the firmware level there are some complications (as you pointed out) in 
letting MpService workers run after ExitBootServices.

My idea would be that the firmware would start the VM as usual using the same 
launch data; then, the firmware would detect it was running as a migration 
helper VM during the SEC or PEI phases (for example via the GHCB or some other 
unencrypted communication area), and divert execution to the migration helper 
instead of proceeding to the next boot phase. This would be somewhat similar in 
spirit to how edk2 performs S3 resume, if my memory serves correctly.

What do you think?

Thanks,

Paolo


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

[edk2-devel] Question about Smm code / StandaloneMmPkg

[Tiger Liu(BJ-RD)]

Dear All:
I have a few questions about Smm code and StandaloneMmPkg.

Take X86 Arch cpu as example:
1. Smm infrastructure code is implemented in MdeModulePkg\Core\PiSmmCore
   But it's a traditional smm mode, used launched in UEFI DXE Phase.

A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf
> This doc introduced a standalone smm mode.

PI Spec introduces a MM concept, it's arch independent.

So, I have below questions:
1. Will X86 SMM code implementation be migrated to MM concept code base?
2. StandaloneMmPkg is a MM reference implementation, is it arch independent?
3. The above doc mentioned launching SMM drivers in PEI,  is it also 
implemented in StandaloneMmPkg?

Thanks


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.


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