Date   

Re: [PATCH v3 3/5] GenFv: Arm: support images entered in Thumb mode

Sami Mujawar
 

Hi Etienne,

Thank you for this patch.

Reviewed-by: Sami Mujawar <sami.mujawar@...>

Regards,

Sami Mujawar


On 17/05/2021 08:40 AM, Etienne Carriere wrote:
Change GenFv for Arm architecture to generate a specific jump
instruction as image entry instruction, when the target entry label
is assembled with Thumb instruction set. This is possible since
SecCoreEntryAddress value fetched from the PE32 has its LSBit set when
the entry instruction executes in Thumb mode.

Cc: Bob Feng <bob.c.feng@...>
Cc: Liming Gao <gaoliming@...>
Cc: Achin Gupta <achin.gupta@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sughosh Ganu <sughosh.ganu@...>
Signed-off-by: Etienne Carriere <etienne.carriere@...>
---
Changes since v2:
- Fix missing parentheses in expression.

Changes since v1:
- Fix typos in commit log and inline comments
- Change if() test operand to be an explicit boolean
---
 BaseTools/Source/C/GenFv/GenFvInternalLib.c | 38 +++++++++++++++-----
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
index 6e296b8ad6..6cf9c84e73 100644
--- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c
+++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
@@ -34,9 +34,27 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include "FvLib.h"
 #include "PeCoffLib.h"
 
-#define ARMT_UNCONDITIONAL_JUMP_INSTRUCTION       0xEB000000
 #define ARM64_UNCONDITIONAL_JUMP_INSTRUCTION      0x14000000
 
+/*
+ * Arm instruction to jump to Fv entry instruction in Arm or Thumb mode.
+ * From ARM Arch Ref Manual versions b/c/d, section A8.8.25 BL, BLX (immediate)
+ * BLX (encoding A2) branches to offset in Thumb instruction set mode.
+ * BL (encoding A1) branches to offset in Arm instruction set mode.
+ */
+#define ARM_JUMP_OFFSET_MAX        0xffffff
+#define ARM_JUMP_TO_ARM(Offset)    (0xeb000000 | ((Offset - 8) >> 2))
+
+#define _ARM_JUMP_TO_THUMB(Imm32)  (0xfa000000 | \
+                                    (((Imm32) & (1 << 1)) << (24 - 1)) | \
+                                    (((Imm32) >> 2) & 0x7fffff))
+#define ARM_JUMP_TO_THUMB(Offset)  _ARM_JUMP_TO_THUMB((Offset) - 8)
+
+/*
+ * Arm instruction to retrun from exception (MOVS PC, LR)
+ */
+#define ARM_RETURN_FROM_EXCEPTION  0xE1B0F07E
+
 BOOLEAN mArm = FALSE;
 BOOLEAN mRiscV = FALSE;
 STATIC UINT32   MaxFfsAlignment = 0;
@@ -2203,23 +2221,25 @@ Returns:
     // if we found an SEC core entry point then generate a branch instruction
     // to it and populate a debugger SWI entry as well
     if (UpdateVectorSec) {
+      UINT32                    EntryOffset;
 
       VerboseMsg("UpdateArmResetVectorIfNeeded updating ARM SEC vector");
 
-      // B SecEntryPoint - signed_immed_24 part +/-32MB offset
-      // on ARM, the PC is always 8 ahead, so we're not really jumping from the base address, but from base address + 8
-      ResetVector[0] = (INT32)(SecCoreEntryAddress - FvInfo->BaseAddress - 8) >> 2;
+      EntryOffset = (INT32)(SecCoreEntryAddress - FvInfo->BaseAddress);
 
-      if (ResetVector[0] > 0x00FFFFFF) {
-        Error(NULL, 0, 3000, "Invalid", "SEC Entry point must be within 32MB of the start of the FV");
+      if (EntryOffset > ARM_JUMP_OFFSET_MAX) {
+          Error(NULL, 0, 3000, "Invalid", "SEC Entry point offset above 1MB of the start of the FV");
         return EFI_ABORTED;
       }
 
-      // Add opcode for an unconditional branch with no link. i.e.: " B SecEntryPoint"
-      ResetVector[0] |= ARMT_UNCONDITIONAL_JUMP_INSTRUCTION;
+      if ((SecCoreEntryAddress & 1) != 0) {
+        ResetVector[0] = ARM_JUMP_TO_THUMB(EntryOffset);
+      } else {
+        ResetVector[0] = ARM_JUMP_TO_ARM(EntryOffset);
+      }
 
       // SWI handler movs   pc,lr. Just in case a debugger uses SWI
-      ResetVector[2] = 0xE1B0F07E;
+      ResetVector[2] = ARM_RETURN_FROM_EXCEPTION;
 
       // Place holder to support a common interrupt handler from ROM.
       // Currently not supported. For this to be used the reset vector would not be in this FV


Re: [PATCH v3 2/5] ArmPkg: prepare 32bit ARM build of StandaloneMmPkg

Sami Mujawar
 

Hi Etienne,

This patch looks good to me.

Reviewed-by: Sami Mujawar <sami.mujawar@...>

Regards,

Sami Mujawar


On 17/05/2021 08:40 AM, Etienne Carriere wrote:
Changes in ArmPkg to prepare building StandaloneMm firmware for
32bit Arm architectures.

Adds MmCommunicationDxe driver and ArmMmuPeiLib and
ArmmmuStandaloneMmLib libraries to the list of the standard
components build for ArmPkg on when ARM architectures.

Changes path of source file AArch64/ArmMmuStandaloneMmLib.c
and compile it for both 32bit and 64bit architectures.

Cc: Achin Gupta <achin.gupta@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sughosh Ganu <sughosh.ganu@...>
Signed-off-by: Etienne Carriere <etienne.carriere@...>
---
No change since v2
No change since v1
---
 ArmPkg/ArmPkg.dec                                                       |  2 +-
 ArmPkg/ArmPkg.dsc                                                       |  2 +-
 ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c                     |  2 +-
 ArmPkg/Library/StandaloneMmMmuLib/{AArch64 => }/ArmMmuStandaloneMmLib.c | 15 ++++++++-------
 ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf             |  6 +++---
 5 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 214b2f5892..6ed51edd03 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -137,7 +137,7 @@
   # hardware coherency (i.e., no virtualization or cache coherent DMA)
   gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride|FALSE|BOOLEAN|0x00000043
 
-[PcdsFeatureFlag.AARCH64]
+[PcdsFeatureFlag.AARCH64, PcdsFeatureFlag.ARM]
   ## Used to select method for requesting services from S-EL1.<BR><BR>
   #   TRUE  - Selects FF-A calls for communication between S-EL0 and SPMC.<BR>
   #   FALSE - Selects SVC calls for communication between S-EL0 and SPMC.<BR>
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 926986cf7f..4c79dadf9e 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -158,7 +158,7 @@
   ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
   ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
 
-[Components.AARCH64]
+[Components.AARCH64, Components.ARM]
   ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
   ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
   ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
index b1e3095809..4ae38a9f22 100644
--- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
+++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
@@ -125,7 +125,7 @@ MmCommunication2Communicate (
   }
 
   // SMC Function ID
-  CommunicateSmcArgs.Arg0 = ARM_SMC_ID_MM_COMMUNICATE_AARCH64;
+  CommunicateSmcArgs.Arg0 = ARM_SMC_ID_MM_COMMUNICATE;
 
   // Cookie
   CommunicateSmcArgs.Arg1 = 0;
diff --git a/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.c
similarity index 92%
rename from ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
rename to ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.c
index dd014beec8..20f873e680 100644
--- a/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib.c
+++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.c
@@ -2,6 +2,7 @@
   File managing the MMU for ARMv8 architecture in S-EL0
 
   Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.<BR>
+  Copyright (c) 2021, Linaro Limited
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
@@ -62,7 +63,7 @@ SendMemoryPermissionRequest (
     // for other Direct Request calls which are not atomic
     // We therefore check only for Direct Response by the
     // callee.
-    if (SvcArgs->Arg0 == ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH64) {
+    if (SvcArgs->Arg0 == ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP) {
       // A Direct Response means FF-A success
       // Now check the payload for errors
       // The callee sends back the return value
@@ -164,13 +165,13 @@ GetMemoryPermissions (
   ZeroMem (&SvcArgs, sizeof (ARM_SVC_ARGS));
   if (FeaturePcdGet (PcdFfaEnable)) {
     // See [2], Section 10.2 FFA_MSG_SEND_DIRECT_REQ.
-    SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64;
+    SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ;
     SvcArgs.Arg1 = ARM_FFA_DESTINATION_ENDPOINT_ID;
     SvcArgs.Arg2 = 0;
-    SvcArgs.Arg3 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
+    SvcArgs.Arg3 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES;
     SvcArgs.Arg4 = BaseAddress;
   } else {
-    SvcArgs.Arg0 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
+    SvcArgs.Arg0 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES;
     SvcArgs.Arg1 = BaseAddress;
     SvcArgs.Arg2 = 0;
     SvcArgs.Arg3 = 0;
@@ -219,15 +220,15 @@ RequestMemoryPermissionChange (
   ZeroMem (&SvcArgs, sizeof (ARM_SVC_ARGS));
   if (FeaturePcdGet (PcdFfaEnable)) {
     // See [2], Section 10.2 FFA_MSG_SEND_DIRECT_REQ.
-    SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64;
+    SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ;
     SvcArgs.Arg1 = ARM_FFA_DESTINATION_ENDPOINT_ID;
     SvcArgs.Arg2 = 0;
-    SvcArgs.Arg3 = ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
+    SvcArgs.Arg3 = ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES;
     SvcArgs.Arg4 = BaseAddress;
     SvcArgs.Arg5 = EFI_SIZE_TO_PAGES (Length);
     SvcArgs.Arg6 = Permissions;
   } else {
-    SvcArgs.Arg0 = ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
+    SvcArgs.Arg0 = ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES;
     SvcArgs.Arg1 = BaseAddress;
     SvcArgs.Arg2 = EFI_SIZE_TO_PAGES (Length);
     SvcArgs.Arg3 = Permissions;
diff --git a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
index 6c71fe0023..ff20e58980 100644
--- a/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
+++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
@@ -16,14 +16,14 @@
   LIBRARY_CLASS                  = StandaloneMmMmuLib
   PI_SPECIFICATION_VERSION       = 0x00010032
 
-[Sources.AARCH64]
-  AArch64/ArmMmuStandaloneMmLib.c
+[Sources]
+  ArmMmuStandaloneMmLib.c
 
 [Packages]
   ArmPkg/ArmPkg.dec
   MdePkg/MdePkg.dec
 
-[FeaturePcd.AARCH64]
+[FeaturePcd.ARM, FeaturePcd.AARCH64]
   gArmTokenSpaceGuid.PcdFfaEnable
 
 [LibraryClasses]


Re: [PATCH v3 1/5] ArmPkg/IndustryStandard: 32b/64b agnostic FF-A, Mm SVC and Std SMC IDs

Sami Mujawar
 

Hi Etienne,

Thank you for this patch.

These changes look good to me.

Reviewed-by: Sami Mujawar <sami.mujawar@...>

Regards,

Sami Mujawar

On 17/05/2021 08:40 AM, Etienne Carriere wrote:
Defines ARM_SVC_ID_FFA_* and ARM_SVC_ID_SP_* identifiers for 32bit
function IDs as per SMCCC specification. Defines also generic ARM
SVC identifier macros to wrap 32bit or 64bit identifiers upon target
built architecture.

Cc: Achin Gupta <achin.gupta@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sughosh Ganu <sughosh.ganu@...>
Signed-off-by: Etienne Carriere <etienne.carriere@...>
---
No change since v2

Changes since v1:
- Define ARM_SMC_ID_MM_COMMUNICATE 32b/64b agnostic helper ID in
ArmStdSmc.h, as expected by few following commits in this series.
---
ArmPkg/Include/IndustryStandard/ArmFfaSvc.h | 12 ++++++++++++
ArmPkg/Include/IndustryStandard/ArmMmSvc.h | 15 +++++++++++++++
ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 8 ++++++++
3 files changed, 35 insertions(+)

diff --git a/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h b/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
index 65b8343ade..ebcb54b28b 100644
--- a/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
+++ b/ArmPkg/Include/IndustryStandard/ArmFfaSvc.h
@@ -17,9 +17,21 @@
#define ARM_FFA_SVC_H_
#define ARM_SVC_ID_FFA_VERSION_AARCH32 0x84000063
+#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH32 0x8400006F
+#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH32 0x84000070
#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64 0xC400006F
#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH64 0xC4000070
+/* Generic IDs when using AArch32 or AArch64 execution state */
+#ifdef MDE_CPU_AARCH64
+#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64
+#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH64
+#endif
+#ifdef MDE_CPU_ARM
+#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH32
+#define ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH32
+#endif
+
#define SPM_MAJOR_VERSION_FFA 1
#define SPM_MINOR_VERSION_FFA 0
diff --git a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
index 33d60ccf17..deb3bc99d2 100644
--- a/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
+++ b/ArmPkg/Include/IndustryStandard/ArmMmSvc.h
@@ -15,10 +15,25 @@
* privileged operations on its behalf.
*/
#define ARM_SVC_ID_SPM_VERSION_AARCH32 0x84000060
+#define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH32 0x84000061
+#define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH32 0x84000064
+#define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH32 0x84000065
#define ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64 0xC4000061
#define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64 0xC4000064
#define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64 0xC4000065
+/* Generic IDs when using AArch32 or AArch64 execution state */
+#ifdef MDE_CPU_AARCH64
+#define ARM_SVC_ID_SP_EVENT_COMPLETE ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH64
+#define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64
+#define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64
+#endif
+#ifdef MDE_CPU_ARM
+#define ARM_SVC_ID_SP_EVENT_COMPLETE ARM_SVC_ID_SP_EVENT_COMPLETE_AARCH32
+#define ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH32
+#define ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH32
+#endif
+
#define SET_MEM_ATTR_DATA_PERM_MASK 0x3
#define SET_MEM_ATTR_DATA_PERM_SHIFT 0
#define SET_MEM_ATTR_DATA_PERM_NO_ACCESS 0
diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
index 67afb0ea2d..9116a291da 100644
--- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
+++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
@@ -49,6 +49,14 @@
#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32 0x84000041
#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64 0xC4000041
+/* Generic ID when using AArch32 or AArch64 execution state */
+#ifdef MDE_CPU_AARCH64
+#define ARM_SMC_ID_MM_COMMUNICATE ARM_SMC_ID_MM_COMMUNICATE_AARCH64
+#endif
+#ifdef MDE_CPU_ARM
+#define ARM_SMC_ID_MM_COMMUNICATE ARM_SMC_ID_MM_COMMUNICATE_AARCH32
+#endif
+
/* MM return error codes */
#define ARM_SMC_MM_RET_SUCCESS 0
#define ARM_SMC_MM_RET_NOT_SUPPORTED -1


Re: [PATCH v1 2/3] MdeModulePkg/PciBusDxe: Fix possible uninitialized use

Wu, Hao A
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sergei
Dmitrouk
Sent: Tuesday, May 18, 2021 12:23 AM
To: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>
Subject: Re: [edk2-devel] [PATCH v1 2/3] MdeModulePkg/PciBusDxe: Fix
possible uninitialized use

If the function gets invalid value for the `ResizableBarOp` parameter and
asserts are disabled, `Bit` can be used uninitialized.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Ray Ni <ray.ni@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---

Notes:
v2:
- simplify if-statement to avoid unused branches

Hello,

Since the V1 is a patch series, I would suggest to send the whole series for V2 changes (even if other patches are unchanged).

With this handled:
Reviewed-by: Hao A Wu <hao.a.wu@...>

Best Regards,
Hao Wu


MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
index 6bba28367165..4caac56f1dcd 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
@@ -1778,10 +1778,9 @@ PciProgramResizableBar (

if (ResizableBarOp == PciResizableBarMax) {
Bit = HighBitSet64(Capabilities);
- } else if (ResizableBarOp == PciResizableBarMin) {
+ } else {
+ ASSERT (ResizableBarOp == PciResizableBarMin);
Bit = LowBitSet64(Capabilities);
- } else {
- ASSERT ((ResizableBarOp == PciResizableBarMax) || (ResizableBarOp ==
PciResizableBarMin));
}

ASSERT (Bit >= 0);
--
2.17.6





Re: [PATCH] UefiCpuPkg/PiSmmCpu: Remove hardcode 48 address size limitation

Ni, Ray
 

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Sunday, May 16, 2021 9:39 AM
To: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/PiSmmCpu: Remove hardcode 48 address size limitation

On 05/15/21 02:04, Ni, Ray wrote:
Laszlo,
Do you think that another API is also needed: GetPhysicalAddressWidth() that returns number 36/52?
No. The GetPhysicalAddressBits() function that I proposed already returns this information. It has three outputs: the number of
bits (that is, the width), as return value, and the two optional output parameters.

So if you only need the the bit count, call

GetPhysicalAddressBits (NULL, NULL);

These calculations are so cheap and small that keeping them in a single function makes a lot of sense in my opinion.
I wasn't aware of the return value of the API. with your API, there is no need for another API to retrieve the address size.

For a critical bugfix, I would prefer not mixing the actual fix with the introduction of the symbolic names. Your patch currently
fixes three things at the same time: (1) coding style (it replaces magic constants with macros / type names), (2) a bug in
calculation, (3) a missing CPUID "maximum function" check.

Maybe writing a separate patch for each of these is unjustified, but I was really unhappy to see that the commit message said
nothing about (1) and (3), and I had to hunt down (2) between the other changes.

The minimal fix -- that is, the fix for (2) -- would be just one line:

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index fd6583f9d172..4592b76fe595 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1920,7 +1920,7 @@ InitializeMpServiceData (
//
AsmCpuid (0x80000008, (UINT32*)&Index, NULL, NULL, NULL);
gPhyMask = LShiftU64 (1, (UINT8)Index) - 1;
- gPhyMask &= (1ull << 48) - EFI_PAGE_SIZE;
+ gPhyMask &= 0xfffffffffffff000ULL;

//
// Create page tables


I don't like that the patch currently does three things but only documents one.
Thanks for explaining why you don't think it's a good patch. I thought anytime changing a code,
I should try to make it better, functional better, looks better.

I will follow your suggestion next time for bug fixes.


That said, if you are out of time, feel free to go ahead with Eric's R-b.
Indeed. thanks for the understanding.


Thanks
Laszlo









Re: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible uninitialized use

Wang, Jian J
 

Ard,

Patch 1&2 haven't got r-b. I'm not sure we can merge patch 3 separately.

Regards,
Jian

-----Original Message-----
From: Ard Biesheuvel <ardb@...>
Sent: Tuesday, May 18, 2021 3:27 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Liming Gao (Byosoft address)
<gaoliming@...>
Cc: sergei@...; Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Please merge this fix asap. Our CI is broken because of it, and we are
in the soft freeze so we need the CI up and running to catch potential
issues before the release.

Thanks,
Ard.

On Tue, 18 May 2021 at 02:59, gaoliming <gaoliming@...> wrote:

Sergei:
Yes. GCC49 is LTO disable GCC tool chain. GCC5 is LTO enable tool chain.
They both work on the different GCC version, such as gcc5, gcc6..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844 mentions
-ffat-lto-objects option that can trig the warning with LTO option. Do you
try it?

If this option works, we can update GCC5 tool chain definition in
tools_def.txt, then this issue can be detected in CI GCC5 build.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sergei
Dmitrouk
发送时间: 2021年5月15日 21:01
收件人: devel@edk2.groups.io; jiewen.yao@...
抄送: Wang, Jian J <jian.j.wang@...>; Lu, XiaoyuX
<xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>
主题: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Hello Jiewen,

I get the error only for GCC49 and not for GCC5 toolchain. CI uses GCC5.

So I compared build commands and this seems to depend on LTO. Adding
`-flto`
impedes compiler's ability to detect such simple issues.

I've found relevant bug report, there is even fix suggestion from last
month:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

Regards,
Sergei

On Sat, May 15, 2021 at 12:30:44AM +0000, Yao, Jiewen wrote:
Hi Sergei
Thank you very much for the fix.
Reviewed-by: Jiewen Yao <Jiewen.yao@...>

I am a little surprised why it is not caught before. It is an obvious
logic issue.

Do you think we can do anything on CI, to catch it during pre-check-in
in the
future?
I just feel it is burden to make it post-check-in fix.


Thank you
Yao Jiewen

-----Original Message-----
From: Sergei Dmitrouk <sergei@...>
Sent: Friday, May 14, 2021 8:17 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>;
Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized
use

`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c | 1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
index 4009d37d5f91..0b2960f06c4c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
@@ -82,6 +82,7 @@ RsaPssVerify (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
index b66b6f7296ad..ece765f9ae0a 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
@@ -97,6 +97,7 @@ RsaPssSign (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
--
2.17.6









Re: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible uninitialized use

Ard Biesheuvel
 

Please merge this fix asap. Our CI is broken because of it, and we are
in the soft freeze so we need the CI up and running to catch potential
issues before the release.

Thanks,
Ard.

On Tue, 18 May 2021 at 02:59, gaoliming <gaoliming@...> wrote:

Sergei:
Yes. GCC49 is LTO disable GCC tool chain. GCC5 is LTO enable tool chain.
They both work on the different GCC version, such as gcc5, gcc6..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844 mentions
-ffat-lto-objects option that can trig the warning with LTO option. Do you
try it?

If this option works, we can update GCC5 tool chain definition in
tools_def.txt, then this issue can be detected in CI GCC5 build.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sergei
Dmitrouk
发送时间: 2021年5月15日 21:01
收件人: devel@edk2.groups.io; jiewen.yao@...
抄送: Wang, Jian J <jian.j.wang@...>; Lu, XiaoyuX
<xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>
主题: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Hello Jiewen,

I get the error only for GCC49 and not for GCC5 toolchain. CI uses GCC5.

So I compared build commands and this seems to depend on LTO. Adding
`-flto`
impedes compiler's ability to detect such simple issues.

I've found relevant bug report, there is even fix suggestion from last
month:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

Regards,
Sergei

On Sat, May 15, 2021 at 12:30:44AM +0000, Yao, Jiewen wrote:
Hi Sergei
Thank you very much for the fix.
Reviewed-by: Jiewen Yao <Jiewen.yao@...>

I am a little surprised why it is not caught before. It is an obvious
logic issue.

Do you think we can do anything on CI, to catch it during pre-check-in
in the
future?
I just feel it is burden to make it post-check-in fix.


Thank you
Yao Jiewen

-----Original Message-----
From: Sergei Dmitrouk <sergei@...>
Sent: Friday, May 14, 2021 8:17 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>;
Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized
use

`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c | 1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
index 4009d37d5f91..0b2960f06c4c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
@@ -82,6 +82,7 @@ RsaPssVerify (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
index b66b6f7296ad..ece765f9ae0a 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
@@ -97,6 +97,7 @@ RsaPssSign (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
--
2.17.6









[PATCH EDK2 v1 1/1] MdeModulePkg/HiiDatabaseDxe: remove dead code

wenyi,xie
 

Outer condition is 'BlockData->Name==NULL' and inner
condition is 'BlockData->Name!=NULL', Opposite 'if'
condition leads to a dead code block.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: Eric Dong <eric.dong@...>
Signed-off-by: Wenyi Xie <xiewenyi2@...>
---
MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 3 ---
1 file changed, 3 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index d492b769d51c..17a914208c6d 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -2871,9 +2871,6 @@ ParseIfrData (
//
if ((BlockData->Name == NULL) && ((BlockData->Offset + BlockData->Width) > VarStorageData->Size)) {
Status = EFI_INVALID_PARAMETER;
- if (BlockData->Name != NULL) {
- FreePool (BlockData->Name);
- }
FreePool (BlockData);
goto Done;
}
--
2.20.1.windows.1


[PATCH EDK2 v1 0/1] MdeModulePkg/HiiDatabaseDxe: remove dead code

wenyi,xie
 

Main Changes :
Remove dead code.

Wenyi Xie (1):
MdeModulePkg/HiiDatabaseDxe: remove dead code

MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 3 ---
1 file changed, 3 deletions(-)

--
2.20.1.windows.1


Re: [PATCH v3] IntelFsp2Pkg: YAML script bug fix

Chiu, Chasel
 

Pushed: 1fbf5e30ae8eb725f4e10984f7b0a208f78abbd0

Thanks,
Chasel

-----Original Message-----
From: Loo, Tung Lun <tung.lun.loo@...>
Sent: Monday, May 17, 2021 12:04 PM
To: devel@edk2.groups.io
Cc: Loo, Tung Lun <tung.lun.loo@...>; Ma, Maurice
<maurice.ma@...>; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; Zeng, Star <star.zeng@...>; Chiu,
Chasel <chasel.chiu@...>
Subject: [PATCH v3] IntelFsp2Pkg: YAML script bug fix

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

This patch fixes the issue observed during BSF file to YAML file conversion. It
also addresses the issue during multibyte array data conversion check, for
example the data representation of 0xFFFF instead of 0xFF, 0xFF would be
thrown exception "Array size is not proper" without this patch.

Cc: Maurice Ma <maurice.ma@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Star Zeng <star.zeng@...>
Cc: Chasel Chiu <chasel.chiu@...>
Signed-off-by: Loo Tung Lun <tung.lun.loo@...>
---
IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py | 11 +++++++++--
IntelFsp2Pkg/Tools/GenCfgOpt.py | 3 ++-
2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
b/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
index cad9b60e73..d2ca7145ae 100644
--- a/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
+++ b/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
@@ -46,6 +46,13 @@ def Bytes2Val(Bytes):
return reduce(lambda x, y: (x << 8) | y, Bytes[::-1]) +def Str2Bytes(Value,
Blen):+ Result = bytearray(Value[1:-1], 'utf-8') # Excluding quotes+ if
len(Result) < Blen:+ Result.extend(b'\x00' * (Blen - len(Result)))+ return
Result++ class CFspBsf2Dsc: def __init__(self, bsf_file):@@ -108,7 +115,8
@@ class CFspBsf2Dsc:
cfg_item['find'] = prefix cfg_item['cname'] = 'Signature'
cfg_item['length'] = len(finds[0][1])- cfg_item['value'] = '0x%X' %
Bytes2Val(finds[0][1].encode('UTF-8'))+ str2byte = Str2Bytes("'" +
finds[0][1] + "'", len(finds[0][1]))+ cfg_item['value'] = '0x%X' %
Bytes2Val(str2byte) cfg_list.append(dict(cfg_item)) cfg_item =
dict(cfg_temp) find_list.pop(0)@@ -291,7 +299,6 @@ class
CFspDsc2Yaml():
raise Exception('DSC variable creation error !') else: raise
Exception('Unsupported file "%s" !' % file_name)-
gen_cfg_data.UpdateDefaultValue() self.gen_cfg_data = gen_cfg_data
def print_dsc_line(self):diff --git a/IntelFsp2Pkg/Tools/GenCfgOpt.py
b/IntelFsp2Pkg/Tools/GenCfgOpt.py
index 660824b740..714b2d8b1a 100644
--- a/IntelFsp2Pkg/Tools/GenCfgOpt.py
+++ b/IntelFsp2Pkg/Tools/GenCfgOpt.py
@@ -708,7 +708,8 @@ EndList
for Page in PageList: Page = Page.strip()
Match = re.match("(\w+):\"(.+)\"", Page)-
self._CfgPageDict[Match.group(1)] = Match.group(2)+ if
Match != None:+ self._CfgPageDict[Match.group(1)] =
Match.group(2) Match =
re.match("(?:^|.+\s+)BLOCK:{NAME:\"(.+)\"\s*,\s*VER:\"(.+)\"\s*}", Remaining)
if Match:--
2.28.0.windows.1


Re: 回复: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for RiscV64

Daniel Schaefer
 

On 5/18/21 9:04 AM, gaoliming wrote:
Daniel:
Seemly, this API is missing in BaseLib for RiscV64 arch. How do you detect
this issue?
What do you mean it's missing?
Yes MemoryFence() for RiscV64 is missing currently, that's why I'm adding it here.

Maybe you mean that it's not currently used? That's also true.
I'm enabling the generic QEMU virt machine (like OVMF or ArmVirtPkg) for RISC-V.
At least QemuFwCfgLib and VirtioLib need it.
That's why I have the need to add this implementation now.

Does that clear it up?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Daniel
Schaefer
发送时间: 2021年5月16日 2:13
收件人: devel@edk2.groups.io
抄送: Abner Chang <abner.chang@...>; Michael D Kinney
<michael.d.kinney@...>; Liming Gao <gaoliming@...>;
Zhiguang Liu <zhiguang.liu@...>; Leif Lindholm <leif@...>
主题: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for
RiscV64

Cc: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/RiscV64/MemoryFence.S | 33
++++++++++++++++++++
2 files changed, 34 insertions(+)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index b76f3af380ea..b7ab5f632366 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -399,6 +399,7 @@
RiscV64/DisableInterrupts.c


RiscV64/EnableInterrupts.c


RiscV64/CpuPause.c


+ RiscV64/MemoryFence.S | GCC


RiscV64/RiscVSetJumpLongJump.S | GCC


RiscV64/RiscVCpuBreakpoint.S | GCC


RiscV64/RiscVCpuPause.S | GCC


diff --git a/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
new file mode 100644
index 000000000000..283df9356a9a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
@@ -0,0 +1,33 @@
+##-------------------------------------------------------------------------
-----


+#


+# MemoryFence() for RiscV64


+


+# Copyright (c) 2021, Hewlett Packard Enterprise Development. All rights
reserved.


+#


+# SPDX-License-Identifier: BSD-2-Clause-Patent


+#


+##-------------------------------------------------------------------------
-----


+


+.text


+.p2align 2


+


+ASM_GLOBAL ASM_PFX(MemoryFence)


+


+


+#/**


+# Used to serialize load and store operations.


+#


+# All loads and stores that proceed calls to this function are
guaranteed to
be


+# globally visible when this function returns.


+#


+#**/


+#VOID


+#EFIAPI


+#MemoryFence (


+# VOID


+# );


+#


+ASM_PFX(MemoryFence):


+ // Fence on all memory and I/O


+ fence


+ ret


--
2.30.1











Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, 18 May 2021 #cal-cancelled

devel@edk2.groups.io Calendar <noreply@...>
 

Cancelled: TianoCore Bug Triage - APAC / NAMO

This event has been cancelled.

When:
Tuesday, 18 May 2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

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

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: [edk2-platforms PATCH] Platform/ARM: Update Readme.md

Chris Jones
 

Hi Rebecca,

Thank you for your patch.

It functionally looks good however I noticed one small grammatical error to fix, noted below.

Reviewed-by: Chris Jones <christopher.jones@...>


Thanks,
Chris

The repo with the Visual Studio support no longer exists.
fiptool from the prebuilt_tools repo doesn't work due to a missing
dependency on libcrypto.so.1.0.0, so tell users to build it from the
trusted-firmware-a repo instead.
There's a newer version of fvp-uefi.zip that was released in 2020.

Signed-off-by: Rebecca Cran <rebecca@...>
---
Platform/ARM/Readme.md | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Platform/ARM/Readme.md b/Platform/ARM/Readme.md
index e1a405b700..afc9ad3646 100644
--- a/Platform/ARM/Readme.md
+++ b/Platform/ARM/Readme.md
@@ -8,10 +8,8 @@ can be found here:
=0D
##Requirements=0D
- A 32-bit or 64-bit Linux host machine.=0D
-- Visual Studio is not officially supported, experimental support can be f=
ound here:=0D
-[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=3Daarch64-vs]=
=0D
=0D
-# Build EDK2 Tianocore=0D
+# Build EDK2 TianoCore=0D
=0D
`build -a AARCH64 -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc =
-t GCC5`=0D
=0D
@@ -26,7 +24,7 @@ prebuilt edk2 image.
=0D
We will also rely on the "run_model" script that comes with the prebuilts,=
it=0D
is entirely possible to run the model without this but would require quite=
a bit=0D
[CHRIS] This does not make sense, instead I suggest:
"of knowledge regarding the arguments of the ARM fastmodel (documentation can be f=
ound here:=0D".
Note: while this was not introduced by you it would be nice to fix now.
-of knowledge regarding the areguments ARM fastmodel (documentation can be =
found here:=0D
+of knowledge regarding the arguments ARM fastmodel (documentation can be f=
ound here:=0D

[https://developer.arm.com/docs/100966/1101/programming-reference-for-base=
-fvps/base-platform-revc-features])=0D
however the manual set of the FVP is outside the scope of this document. I=
f you are interested=0D
please consult the documentation.=0D
@@ -40,16 +38,18 @@ the binaries in the same directory.
- Select Armv8-A Base Platform FVP based on Fast Models 11.4=0D
- It has a click through license but is free.=0D
=0D
-2. Download the 18.10 Linaro ARM Landing Team release for FVP booting UEFI=
=0D
-https://releases.linaro.org/members/arm/platforms/18.10/fvp-uefi.zip=0D
+2. Download the 20.01 Linaro ARM Landing Team release for FVP booting UEFI=
=0D
+https://releases.linaro.org/members/arm/platforms/20.01/fvp-uefi.zip=0D
=0D
-3. Download the prebuilt fiptool from https://git.linaro.org/landing-teams=
/working/arm/prebuilt_tools.git=0D
+3. Clone the trusted firmware repo from https://git.trustedfirmware.org/TF=
-A/trusted-firmware-a.git=0D
=0D
-4. Update the fip.bin image from fvp-uefi.zip by running the following com=
mand:=0D
+4. Build fiptool: `make -C trusted-firmware-a/tools/fiptool`=0D
=0D
- `fiptool update --nt-fw=3D[path to binary built above] fip.bin`=0D
+5. Update the fip.bin image from fvp-uefi.zip by running the following com=
mand:=0D
=0D
-5. Execute the FVP run_model.sh script from fvp-uefi.zip and provide a pat=
h to the FVP binaries=0D
+ `./trusted-firmware-a/tools/fiptool/fiptool update --nt-fw=3D[path to bin=
ary built above] fip.bin`=0D
+=0D
+6. Execute the FVP run_model.sh script from fvp-uefi.zip and provide a pat=
h to the FVP binaries=0D
downloaded in step 1):=0D
=0D
`MODEL=3D[path to FVP binary] ./run_model.sh`=0D
--=20
2.31.1


回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 05/18/2021 6:30pm-7:30pm #cal-reminder

gaoliming
 

Few new issue is submitted this week. Let’s cancel the meeting this week.

 

3394

EDK2

Code

unassigned@...

UNCO

Add APIs for CPU physical address mask calculation

Fri 20:02

ray.ni@...

3393

Tianocor

Code

unassigned@...

UNCO

Add firmware support for Cloud Hypervisor on arm64

Fri 05:07

jianyong.wu@...

3392

EDK2

Code

unassigned@...

UNCO

Null pointers referenced in SecureBoot LoadSignattureData() and LoadSignatureList()

Thu 21:54

Allen_Wynn@...

3388

EDK2

Code

unassigned@...

UNCO

About the efficiency of Shell command

Thu 08:57

ptabckimo@...

3367

EDK2

Document

unassigned@...

UNCO

URL links | HTTP redirected to HTTPS or non-secure TLS version

Wed 05:09

ricky.tigg@...

3390

EDK2 Tes

UEFI-SCT

xypron.glpk@...

UNCO

uefi-sct: Incorrect test of EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.SetState()

Wed 03:49

xypron.glpk@...

3362

EDK2

Code

unassigned@...

UNCO

Changes required for STR_SMBIOSVIEW_PRINTINFO_BITS_48_64 to be STR_SMBIOSVIEW_PRINTINFO_BITS_48_63 in smbiosviewstrings.uni

2021-05-12

saidurgab@...

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io>
发送时间: 2021518 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 05/18/2021 6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 18 May 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

View Event

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

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

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


TianoCore Bug Triage - APAC / NAMO - Tue, 05/18/2021 6:30pm-7:30pm #cal-reminder

devel@edk2.groups.io Calendar <devel@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 18 May 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

View Event

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

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

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


回复: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for RiscV64

gaoliming
 

Daniel:
Seemly, this API is missing in BaseLib for RiscV64 arch. How do you detect
this issue?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Daniel
Schaefer
发送时间: 2021年5月16日 2:13
收件人: devel@edk2.groups.io
抄送: Abner Chang <abner.chang@...>; Michael D Kinney
<michael.d.kinney@...>; Liming Gao <gaoliming@...>;
Zhiguang Liu <zhiguang.liu@...>; Leif Lindholm <leif@...>
主题: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for
RiscV64

Cc: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/RiscV64/MemoryFence.S | 33
++++++++++++++++++++
2 files changed, 34 insertions(+)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index b76f3af380ea..b7ab5f632366 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -399,6 +399,7 @@
RiscV64/DisableInterrupts.c


RiscV64/EnableInterrupts.c


RiscV64/CpuPause.c


+ RiscV64/MemoryFence.S | GCC


RiscV64/RiscVSetJumpLongJump.S | GCC


RiscV64/RiscVCpuBreakpoint.S | GCC


RiscV64/RiscVCpuPause.S | GCC


diff --git a/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
new file mode 100644
index 000000000000..283df9356a9a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
@@ -0,0 +1,33 @@
+##-------------------------------------------------------------------------
-----


+#


+# MemoryFence() for RiscV64


+


+# Copyright (c) 2021, Hewlett Packard Enterprise Development. All rights
reserved.


+#


+# SPDX-License-Identifier: BSD-2-Clause-Patent


+#


+##-------------------------------------------------------------------------
-----


+


+.text


+.p2align 2


+


+ASM_GLOBAL ASM_PFX(MemoryFence)


+


+


+#/**


+# Used to serialize load and store operations.


+#


+# All loads and stores that proceed calls to this function are
guaranteed to
be


+# globally visible when this function returns.


+#


+#**/


+#VOID


+#EFIAPI


+#MemoryFence (


+# VOID


+# );


+#


+ASM_PFX(MemoryFence):


+ // Fence on all memory and I/O


+ fence


+ ret


--
2.30.1





回复: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible uninitialized use

gaoliming
 

Sergei:
Yes. GCC49 is LTO disable GCC tool chain. GCC5 is LTO enable tool chain.
They both work on the different GCC version, such as gcc5, gcc6..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844 mentions
-ffat-lto-objects option that can trig the warning with LTO option. Do you
try it?

If this option works, we can update GCC5 tool chain definition in
tools_def.txt, then this issue can be detected in CI GCC5 build.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sergei
Dmitrouk
发送时间: 2021年5月15日 21:01
收件人: devel@edk2.groups.io; jiewen.yao@...
抄送: Wang, Jian J <jian.j.wang@...>; Lu, XiaoyuX
<xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>
主题: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Hello Jiewen,

I get the error only for GCC49 and not for GCC5 toolchain. CI uses GCC5.

So I compared build commands and this seems to depend on LTO. Adding
`-flto`
impedes compiler's ability to detect such simple issues.

I've found relevant bug report, there is even fix suggestion from last
month:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

Regards,
Sergei

On Sat, May 15, 2021 at 12:30:44AM +0000, Yao, Jiewen wrote:
Hi Sergei
Thank you very much for the fix.
Reviewed-by: Jiewen Yao <Jiewen.yao@...>

I am a little surprised why it is not caught before. It is an obvious
logic issue.

Do you think we can do anything on CI, to catch it during pre-check-in
in the
future?
I just feel it is burden to make it post-check-in fix.


Thank you
Yao Jiewen

-----Original Message-----
From: Sergei Dmitrouk <sergei@...>
Sent: Friday, May 14, 2021 8:17 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>;
Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized
use

`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c | 1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
index 4009d37d5f91..0b2960f06c4c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
@@ -82,6 +82,7 @@ RsaPssVerify (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
index b66b6f7296ad..ece765f9ae0a 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
@@ -97,6 +97,7 @@ RsaPssSign (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
--
2.17.6



回复: [edk2-devel] [PATCH] EmulatorPkg: Update lldbefi.py to work with current lldb which uses python3

gaoliming
 

Rebecca:
This change supports python2 & python3 both. So, I think this is a good fix. Reviewed-by: Liming Gao <gaoliming@...>

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Rebecca Cran
发送时间: 2021年5月17日 21:29
收件人: devel@edk2.groups.io; Andrew Fish <afish@...>; Ray Ni
<ray.ni@...>
主题: Re: [edk2-devel] [PATCH] EmulatorPkg: Update lldbefi.py to work with
current lldb which uses python3

Could someone review this please?

Thanks.
Rebecca Cran

On 5/9/21 1:26 PM, Rebecca Cran wrote:
The version of lldb shipping with macOS Big Sur is lldb-1205.0.27.3, and
it uses python3. Update lldbefi.py to work with it, including removing
the unused 'commands' import and fixing the print statements.

Signed-off-by: Rebecca Cran <rebecca@...>
---
EmulatorPkg/Unix/lldbefi.py | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/EmulatorPkg/Unix/lldbefi.py b/EmulatorPkg/Unix/lldbefi.py
index c3fb2675cb..952f8bf982 100755
--- a/EmulatorPkg/Unix/lldbefi.py
+++ b/EmulatorPkg/Unix/lldbefi.py
@@ -10,7 +10,6 @@ import lldb
import os
import uuid
import string
-import commands
import optparse
import shlex

@@ -389,7 +388,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc ,
internal_dict):

FileName = frame.thread.process.ReadCStringFromMemory
(FileNamePtr, FileNameLen, Error)
if not Error.Success():
- print "!ReadCStringFromMemory() did not find a %d byte C string
at %x" % (FileNameLen, FileNamePtr)
+ print("!ReadCStringFromMemory() did not find a %d byte C string
at %x" % (FileNameLen, FileNamePtr))
# make breakpoint command continue
return False

@@ -398,7 +397,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc ,
internal_dict):
LoadAddress = frame.FindVariable
("LoadAddress").GetValueAsUnsigned() - 0x240

debugger.HandleCommand ("target modules add %s" %
FileName)
- print "target modules load --slid 0x%x %s" % (LoadAddress,
FileName)
+ print("target modules load --slid 0x%x %s" % (LoadAddress,
FileName))
debugger.HandleCommand ("target modules load --slide 0x%x
--file %s" % (LoadAddress, FileName))
else:
target = debugger.GetSelectedTarget()
@@ -408,7 +407,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc ,
internal_dict):
if FileName == ModuleName or FileName ==
SBModule.GetFileSpec().GetFilename():
target.ClearModuleLoadAddress (SBModule)
if not target.RemoveModule (SBModule):
- print "!lldb.target.RemoveModule (%s) FAILED" %
SBModule
+ print("!lldb.target.RemoveModule (%s) FAILED" %
SBModule)

# make breakpoint command continue
return False
@@ -490,15 +489,15 @@ def efi_guid_command(debugger, command,
result, dict):

if len(args) >= 1:
if GuidStr in guid_dict:
- print "%s = %s" % (guid_dict[GuidStr], GuidStr)
- print "%s = %s" % (guid_dict[GuidStr], GuidToCStructStr
(GuidStr))
+ print("%s = %s" % (guid_dict[GuidStr], GuidStr))
+ print("%s = %s" % (guid_dict[GuidStr], GuidToCStructStr
(GuidStr)))
else:
- print GuidStr
+ print(GuidStr)
else:
# dump entire dictionary
width = max(len(v) for k,v in guid_dict.iteritems())
for value in sorted(guid_dict, key=guid_dict.get):
- print '%-*s %s %s' % (width, guid_dict[value], value,
GuidToCStructStr(value))
+ print('%-*s %s %s' % (width, guid_dict[value], value,
GuidToCStructStr(value)))

return

@@ -538,4 +537,4 @@ def __lldb_init_module (debugger, internal_dict):
if Breakpoint.GetNumLocations() == 1:
# Set the emulator breakpoints, if we are in the emulator
debugger.HandleCommand("breakpoint command add -s
python -F lldbefi.LoadEmulatorEfiSymbols {id}".format(id=Breakpoint.GetID()))
- print 'Type r to run emulator. SecLldbScriptBreak armed. EFI
modules should now get source level debugging in the emulator.'
+ print('Type r to run emulator. SecLldbScriptBreak armed. EFI
modules should now get source level debugging in the emulator.')





Google Summer of Code (GSoC) 2021 Projects Announced!

Nate DeSimone
 

Hi Everyone,

 

Google has announced this year’s Summer of Code students. TianoCore is mentoring 7 students this year, which is more than 3 times larger than our previous high of 2 students! The list of projects is available here: https://summerofcode.withgoogle.com/organizations/6376892141142016/

 

Big shout out to all our students and mentors! I’m looking forward to a very busy, and fun summer!

 

Thanks!

Nate


Re: [PATCH v2 05/13] MdePkg/Register/Amd: define GHCB macro for the Page State Change

Erdem Aktas
 

I verified that the values align with the GHCB spec publication:
#56421 Revision: 2.00

Reviewed-by: Erdem Aktas <erdemaktas@...>

On Wed, May 12, 2021 at 4:46 PM Brijesh Singh <brijesh.singh@...> wrote:

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

The Page State Change NAE exit will be used by the SEV-SNP guest to
request a page state change using the GHCB protocol. See the GHCB
spec section 4.1.6 and 2.3.1 for more detail on the structure
definitions.

Cc: James Bottomley <jejb@...>
Cc: Min Xu <min.m.xu@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Tom Lendacky <thomas.lendacky@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Erdem Aktas <erdemaktas@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Reviewed-by: Laszlo Ersek <lersek@...>
Reviewed-by: Liming Gao <gaoliming@...>
Signed-off-by: Brijesh Singh <brijesh.singh@...>
---
MdePkg/Include/Register/Amd/Fam17Msr.h | 15 ++++++++++++
MdePkg/Include/Register/Amd/Ghcb.h | 33 ++++++++++++++++++++++++++
2 files changed, 48 insertions(+)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h b/MdePkg/Include/Register/Amd/Fam17Msr.h
index 542e4cdf4782..62014854d9b7 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -58,6 +58,19 @@ typedef union {
UINT64 GuestFrameNumber:52;
} GhcbGpaRegister;

+ struct {
+ UINT64 Function:12;
+ UINT64 GuestFrameNumber:40;
+ UINT64 Operation:4;
+ UINT64 Reserved:8;
+ } SnpPageStateChangeRequest;
+
+ struct {
+ UINT32 Function:12;
+ UINT32 Reserved:20;
+ UINT32 ErrorCode;
+ } SnpPageStateChangeResponse;
+
VOID *Ghcb;

UINT64 GhcbPhysicalAddress;
@@ -69,6 +82,8 @@ typedef union {
#define GHCB_INFO_CPUID_RESPONSE 5
#define GHCB_INFO_GHCB_GPA_REGISTER_REQUEST 18
#define GHCB_INFO_GHCB_GPA_REGISTER_RESPONSE 19
+#define GHCB_INFO_SNP_PAGE_STATE_CHANGE_REQUEST 20
+#define GHCB_INFO_SNP_PAGE_STATE_CHANGE_RESPONSE 21
#define GHCB_HYPERVISOR_FEATURES_REQUEST 128
#define GHCB_HYPERVISOR_FEATURES_RESPONSE 129
#define GHCB_INFO_TERMINATE_REQUEST 256
diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h
index ec232ebd3807..029904b1c63a 100644
--- a/MdePkg/Include/Register/Amd/Ghcb.h
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -54,6 +54,7 @@
#define SVM_EXIT_NMI_COMPLETE 0x80000003ULL
#define SVM_EXIT_AP_RESET_HOLD 0x80000004ULL
#define SVM_EXIT_AP_JUMP_TABLE 0x80000005ULL
+#define SVM_EXIT_SNP_PAGE_STATE_CHANGE 0x80000010ULL
#define SVM_EXIT_HYPERVISOR_FEATURES 0x8000FFFDULL
#define SVM_EXIT_UNSUPPORTED 0x8000FFFFULL

@@ -162,4 +163,36 @@ typedef union {
#define GHCB_HV_FEATURES_SNP_AP_CREATE (GHCB_HV_FEATURES_SNP | BIT1)
#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION (GHCB_HV_FEATURES_SNP_AP_CREATE | BIT2)
#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION_TIMER (GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION | BIT3)
+
+//
+// SNP Page State Change.
+//
+// Note that the PSMASH and UNSMASH operations are not supported when using the MSR protocol.
+//
+#define SNP_PAGE_STATE_PRIVATE 1
+#define SNP_PAGE_STATE_SHARED 2
+#define SNP_PAGE_STATE_PSMASH 3
+#define SNP_PAGE_STATE_UNSMASH 4
+
+typedef struct {
+ UINT64 CurrentPage:12;
+ UINT64 GuestFrameNumber:40;
+ UINT64 Operation:4;
+ UINT64 PageSize:1;
+ UINT64 Reserved:7;
+} SNP_PAGE_STATE_ENTRY;
+
+typedef struct {
+ UINT16 CurrentEntry;
+ UINT16 EndEntry;
+ UINT32 Reserved;
+} SNP_PAGE_STATE_HEADER;
+
+#define SNP_PAGE_STATE_MAX_ENTRY 253
+
+typedef struct {
+ SNP_PAGE_STATE_HEADER Header;
+ SNP_PAGE_STATE_ENTRY Entry[SNP_PAGE_STATE_MAX_ENTRY];
+} SNP_PAGE_STATE_CHANGE_INFO;
+
#endif
--
2.17.1

17141 - 17160 of 92312