Re: [edk2-devel] VS2019 and AARCH64 with current EDKII mainline code.

2024-03-19 Thread Adam Liu
I got the same issue and already submit a patch.
https://edk2.groups.io/g/devel/topic/patch_v2_1_1/105038588?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105038588,previd%3D1710905523338626613,nextid%3D1710847665703537227=1710905523338626613=1710847665703537227
Hope it got accepted and push to master soon.

Regards,
Adam


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




Re: [edk2-devel] [PATCH] MdePkg: Add PciVenNameLib to get vendor name.

2024-03-19 Thread Simon Wang via groups.io
The original intention is using the string data for firmware manufacturer of 
SMBIOS type 45 record which associated to PCI device. Moving to ShellPkg would 
limit the usage for other purpose.


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




[edk2-devel] [PATCH v2 1/1] MdePkg/BaseLib: Fix AARCH64 compilation error

2024-03-19 Thread Adam Liu
Declare InternalAssertJumpBuffer as EXTERN

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Shun Cheng Liu 
Reviewed-by: levi.yun 
---
 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S   | 1 +
 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm | 1 +
 2 files changed, 2 insertions(+)

diff --git a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S 
b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S
index 3e58119b25d2..505d3765c522 100644
--- a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S
+++ b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S
@@ -9,6 +9,7 @@
 
 GCC_ASM_EXPORT(SetJump)
 GCC_ASM_EXPORT(InternalLongJump)
+GCC_ASM_IMPORT(InternalAssertJumpBuffer)
 
 #define GPR_LAYOUT \
 REG_PAIR (x19, x20,  0);   \
diff --git a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm 
b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
index 6ec8f35f2c9f..fa161e25f517 100644
--- a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
+++ b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
@@ -7,6 +7,7 @@
 
   EXPORT SetJump
   EXPORT InternalLongJump
+  EXTERN InternalAssertJumpBuffer
   AREA BaseLib_LowLevel, CODE, READONLY
 
 #define GPR_LAYOUT  \
-- 
2.25.1



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




[edk2-devel] [PATCH v2 0/1] MdePkg/BaseLib: Fix AARCH64 compilation error

2024-03-19 Thread Adam Liu
Declare InternalAssertJumpBuffer to fix build error. 

Shun Cheng Liu (1):
  MdePkg/BaseLib: Fix AARCH64 compilation error

 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S   | 1 +
 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm | 1 +
 2 files changed, 2 insertions(+)

-- 
2.25.1



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




Re: [edk2-devel] reg: HTTP Proxy Support

2024-03-19 Thread Saloni Kasbekar
Still waiting for the new UEFI Specification to be released. Plan to send out 
the edk2 patches as soon as it is released.

From: Vivian Shi (石丽) 
Sent: Tuesday, March 19, 2024 12:01 AM
To: Kasbekar, Saloni ; Sivaraman Nainar 
; devel@edk2.groups.io
Cc: Dhanaraj V ; Clark-williams, Zachary 
; Hunter Qi (戚硕) ; Ivan Gu 
(顾鸣磊) ; Joybird Gu (顾哲鹤) 
Subject: RE: [EXTERNAL] RE: reg: HTTP Proxy Support

Hi Saloni,

Sorry for the drop in.
Is there any schedule for pull in the HTTP Proxy changes from edk2-staging to 
edk2?

Thanks a lot!
Best Regards
Vivian Shi

American Megatrends Information Technology (Kunshan) Co., Ltd.

Tel: +86-512-57360204 #259

From: Vivian Shi (石丽)
Sent: Tuesday, January 30, 2024 9:19 AM
To: Kasbekar, Saloni 
mailto:saloni.kasbe...@intel.com>>; Sivaraman Nainar 
mailto:sivaram...@ami.com>>; 
devel@edk2.groups.io
Cc: Dhanaraj V mailto:vdhana...@ami.com>>; Clark-williams, 
Zachary 
mailto:zachary.clark-willi...@intel.com>>; 
Hunter Qi (戚硕) mailto:hunte...@ami.com>>; Ivan Gu (顾鸣磊) 
mailto:iva...@ami.com>>; Joybird Gu (顾哲鹤) 
mailto:joybir...@ami.com>>
Subject: RE: [EXTERNAL] RE: reg: HTTP Proxy Support

Cc more.

Thanks a lot!
Best Regards
Vivian Shi

American Megatrends Information Technology (Kunshan) Co., Ltd.

Tel: +86-512-57360204 #259

From: Kasbekar, Saloni 
mailto:saloni.kasbe...@intel.com>>
Sent: Tuesday, January 30, 2024 2:03 AM
To: Sivaraman Nainar mailto:sivaram...@ami.com>>; 
devel@edk2.groups.io
Cc: Dhanaraj V mailto:vdhana...@ami.com>>; Vivian Shi (石丽) 
mailto:vivian...@ami.com>>; Clark-williams, Zachary 
mailto:zachary.clark-willi...@intel.com>>
Subject: [EXTERNAL] RE: reg: HTTP Proxy Support


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

The changes for HTTP Proxy in edk2-staging are part of the code first process 
since they are dependent on corresponding changes in the UEFI spec.
As a part of the code first process once the next version of UEFI spec is 
released, we can pull in the changes from edk2-staging to edk2.

Thanks,
Saloni

From: Sivaraman Nainar mailto:sivaram...@ami.com>>
Sent: Sunday, January 28, 2024 9:59 PM
To: Kasbekar, Saloni 
mailto:saloni.kasbe...@intel.com>>; 
devel@edk2.groups.io
Cc: Dhanaraj V mailto:vdhana...@ami.com>>; Vivian Shi (石丽) 
mailto:vivian...@ami.com>>; Clark-williams, Zachary 
mailto:zachary.clark-willi...@intel.com>>
Subject: reg: HTTP Proxy Support

Hello Saloni,

Update Code First markdown file for specification text changes · 
tianocore/edk2-staging@b8816aa · 
GitHub

This branch has support for HTTP Proxy. Do we have any plan to bring to to 
master tree?

Thanks
Siva
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


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




[edk2-devel] VS2019 and AARCH64 with current EDKII mainline code.

2024-03-19 Thread Ken Taylor
Hi all,

I've been trying to build the latest 2023 release of EDKII with AARCH64 using 
VS2019, and I'm encountering an issue with line 51 of 
MdePkg\Library\BaseLib\AArch64\SetJumpLongJump.asm.

Specifically, there's no EXTERN for InternalAssertJumpBuffer and the 64 bit ARM 
cross assembler that comes with VS2019 does not support /D or -D so there's no 
way to set a flag that properly defines MDEPKG_NDEBUG.  -PreDefine 
"MDEPKG_NDEBUG SETx blah" doesn't work either, because it doesn't declare 
MDEPKG_NDEBUG in a context that the assembler's preprocessor recognizes.

How is this supposed to work, exactly?  For now, I'm using my own version of 
BaseLib, so I can remove that code block from SetJumpLongJump.asm, or add the 
EXTERN, but that's far from ideal since I'd like to avoid maintaining my own 
copy of BaseLib just to fix a single build error.

Regards,
-Ken Taylor


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




[edk2-devel] [PATCH v2 3/3] ShellPkg: UefiShellDebug1CommandsLib: Conformance Profiles in Dmem.c

2024-03-19 Thread Sam Kaynor
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352

Implemented dumping of the UEFI Conformance Profiles Table using Dmem.c
Additionally added the base support for the table with new
header file ConformanceProfiles.h (Cc'd maintainers of MdePkg for this)

Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Sam Kaynor 
---
 MdePkg/MdePkg.dec  |  
7 ++
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf |  
3 +
 MdePkg/Include/Guid/ConformanceProfiles.h  | 
57 
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 
69 
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni |  
5 ++
 5 files changed, 141 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 0459418906f8..0ce45973dd3e 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -740,6 +740,13 @@ [Guids]
   ## Include/Protocol/SerilaIo.h
   gEfiSerialTerminalDeviceTypeGuid = { 0x6AD9A60F, 0x5815, 0x4C7C, { 0x8A, 
0x10, 0x50, 0x53, 0xD2, 0xBF, 0x7A, 0x1B }}
 
+  # GUIDs defined in UEFI 2.10
+  #
+  ## Include/Guid/ConformanceProfiles.h
+  gEfiConfProfilesTableGuid= { 0x36122546, 0xf7e7, 0x4c8f, { 0xbd, 
0x9b, 0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b }}
+  gEfiConfProfilesUefiSpecGuid = { 0x523c91af, 0xa195, 0x4382, { 0x81, 
0x8d, 0x29, 0x5f, 0xe4, 0x00, 0x64, 0x65 }}
+  gEfiConfProfilesEbbrSpecGuid = { 0xcce33c35, 0x74ac, 0x4087, { 0xbc, 
0xe7, 0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27 }}
+
   #
   # GUID defined in PI1.0
   #
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
index 3741dac5d94c..172ac2862ba1 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
@@ -139,3 +139,6 @@ [Guids]
   gEfiJsonConfigDataTableGuid ## SOMETIMES_CONSUMES ## SystemTable
   gEfiJsonCapsuleDataTableGuid## SOMETIMES_CONSUMES ## SystemTable
   gEfiJsonCapsuleResultTableGuid  ## SOMETIMES_CONSUMES ## SystemTable
+  gEfiConfProfilesTableGuid   ## SOMETIMES_CONSUMES ## SystemTable
+  gEfiConfProfilesUefiSpecGuid## SOMETIMES_CONSUMES ## GUID
+  gEfiConfProfilesEbbrSpecGuid## SOMETIMES_CONSUMES ## GUID
diff --git a/MdePkg/Include/Guid/ConformanceProfiles.h 
b/MdePkg/Include/Guid/ConformanceProfiles.h
new file mode 100644
index ..88517eaaad25
--- /dev/null
+++ b/MdePkg/Include/Guid/ConformanceProfiles.h
@@ -0,0 +1,57 @@
+/** @file
+  Legal information
+
+**/
+
+#ifndef __CONFORMANCE_PROFILES_TABLE_GUID_H__
+#define __CONFORMANCE_PROFILES_TABLE_GUID_H__
+
+
+//
+// (This is copied straight from the 2.10 spec, to be modified)
+// This table allows the platform to advertise its UEFI specification 
conformance
+// in the form of pre-defined profiles. Each profile is identified by a GUID, 
with
+// known profiles listed in the section below.
+// The absence of this table shall indicate that the platform implementation is
+// conformant with the UEFI specification requirements, as defined in Section 
2.6.
+// This is equivalent to publishing this configuration table with the
+// EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile.
+//
+#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \
+  { \
+0x36122546, 0xf7e7, 0x4c8f, { 0xbd, 0x9b, 0xeb, 0x85, 0x25, 0xb5, 0x0c, 
0x0b } \
+  }
+
+#pragma pack(1)
+
+typedef struct {
+  ///
+  /// Version of the table must be 0x1
+  ///
+  UINT16 Version;
+  ///
+  /// The number of profiles GUIDs present in ConformanceProfiles
+  ///
+  UINT16 NumberOfProfiles;
+  ///
+  /// An array of conformance profile GUIDs that are supported by this system.
+  /// EFI_GUIDConformanceProfiles[];
+  ///
+} EFI_CONFORMANCE_PROFILES_TABLE;
+
+#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 0x1
+
+//
+// GUID defined in spec.
+//
+#define EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID \
+{ 0x523c91af, 0xa195, 0x4382, \
+{ 0x81, 0x8d, 0x29, 0x5f, 0xe4, 0x00, 0x64, 0x65 }}
+#define EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID \
+{ 0xcce33c35, 0x74ac, 0x4087, \
+{ 0xbc, 0xe7, 0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27 }}
+
+extern EFI_GUID  gEfiConfProfilesTableGuid;
+extern EFI_GUID  gEfiConfProfilesUefiSpecGuid;
+
+#endif
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
index 2eaf768030cf..2a1961895dbd 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
   Make a printable character.
@@ -271,7 +272,67 @@ DisplayImageExecutionEntries (
   return (ShellStatus);
 }
 
+/**
+  Display the ConformanceProfileTable entries
 
+  

[edk2-devel] [PATCH v2 2/3] ShellPkg: UefiShellDebug1CommandsLib: Image Execution Table in Dmem.c

2024-03-19 Thread Sam Kaynor
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352

Implemented dumping of the Image Execution Table using Dmem.c

Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Sam Kaynor 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 
138 
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni |   
3 +
 2 files changed, 141 insertions(+)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
index 1ae7b1f3d85c..2eaf768030cf 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
@@ -138,6 +138,141 @@ DisplayRtProperties (
   return (ShellStatus);
 }
 
+/**
+  Retrieve the ImageExecutionTable Entry ImageName from Device Path
+
+  @param[in] AddressThe pointer to the ImageExecutionTable.
+**/
+EFI_STATUS
+GetBaseName (
+  IN  CHAR16  *FileName,
+  OUT CHAR16  **BaseName
+  )
+{
+  UINT32  StrLen;
+  CHAR16  *StrTail;
+
+  StrLen = StrSize(FileName);
+
+  for (StrTail = FileName + StrLen - 1; StrTail != FileName && *StrTail != 
L'\\'; StrTail--) {
+  }
+
+  if (StrTail == FileName) {
+return EFI_NOT_FOUND;
+  }
+  *BaseName = StrTail+1;
+
+  return EFI_SUCCESS;
+}
+
+/**
+  Retrieve the ImageExecutionTable entries
+
+  @param[in] AddressThe pointer to the ImageExecutionTable.
+**/
+EFI_STATUS
+GetImageExecutionInfo (
+  IN UINT64 Address
+  )
+{
+  EFI_STATUS Status;
+  EFI_IMAGE_EXECUTION_INFO_TABLE *ExecInfoTablePtr;
+  EFI_IMAGE_EXECUTION_INFO   *InfoPtr;
+  VOID   *ptr;
+  CHAR16 *ImagePath;
+  CHAR16 *ImageName;
+  UINTN  *NumberOfImages;
+  CHAR16 *ActionType;
+
+  Status = EfiGetSystemConfigurationTable (, 
);
+
+  NumberOfImages = ExecInfoTablePtr->NumberOfImages;
+
+  ptr = (VOID *)(ExecInfoTablePtr + 1);
+
+  for (int Image = 0; Image < *NumberOfImages; Image++, ptr += 
InfoPtr->InfoSize) {
+InfoPtr = ptr;
+ImagePath = (CHAR16)(InfoPtr + 1);
+
+GetBaseName(ImagePath,);
+
+switch(InfoPtr->Action) {
+  case EFI_IMAGE_EXECUTION_AUTHENTICATION:
+ActionType = L"AUTHENTICATION";
+break;
+  case EFI_IMAGE_EXECUTION_AUTH_UNTESTED:
+ActionType = L"AUTHENTICATION UNTESTED";
+break;
+  case EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED:
+ActionType = L"AUTHENTICATION SIGNATURE FAILED";
+break;
+  case EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED:
+ActionType = L"AUTHENTICATION SIGNATURE PASSED";
+break;
+  case EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND:
+ActionType = L"AUTHENTICATION SIGNATURE NOT FOUND";
+break;
+  case EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND:
+ActionType = L"AUTHENTICATION SIGNATURE FOUND";
+break;
+  case EFI_IMAGE_EXECUTION_POLICY_FAILED:
+ActionType = L"POILCY FAILED";
+break;
+  case EFI_IMAGE_EXECUTION_INITIALIZED:
+ActionType = L"INITIALIZED";
+break;
+  default:
+ActionType = L"invalid action";
+}
+
+ShellPrintHiiEx(
+  -1,
+  -1,
+  NULL,
+  STRING_TOKEN (STR_DMEM_IMG_EXE_ENTRY),
+  gShellDebug1HiiHandle,
+  ImageName,
+  ActionType
+);
+  }
+
+  return Status;
+}
+
+/**
+  Display the ImageExecutionTable entries
+
+  @param[in] AddressThe pointer to the ImageExecutionTable.
+**/
+SHELL_STATUS
+DisplayImageExecutionEntries (
+  IN UINT64 Address
+  )
+{
+  EFI_IMAGE_EXECUTION_INFO_TABLE *ImageExecutionTable;
+  SHELL_STATUSShellStatus;
+  EFI_STATUS  Status;
+
+  ShellStatus = SHELL_SUCCESS;
+
+  if (Address != 0) {
+Status = EfiGetSystemConfigurationTable (, 
(VOID **));
+if (EFI_ERROR (Status)) {
+  ShellStatus = SHELL_NOT_FOUND;
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DMEM_ERR_GET_FAIL), 
gShellDebug1HiiHandle, L"ImageExecutionTable");
+} else {
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DMEM_IMG_EXE_TABLE), 
gShellDebug1HiiHandle);
+  Status = GetImageExecutionInfo(Address);
+}
+  } else {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DMEM_ERR_NOT_FOUND), 
gShellDebug1HiiHandle, L"ImageExecutionTable");
+  }
+
+  return (ShellStatus);
+}
+
+
+
 STATIC CONST SHELL_PARAM_ITEM  ParamList[] = {
   { L"-mmio", TypeFlag },
   { L"-verbose", TypeFlag },
@@ -368,6 +503,9 @@ ShellCommandRunDmem (
   if (ShellStatus == SHELL_SUCCESS) {
 ShellStatus = DisplayRtProperties (RtPropertiesTableAddress);
   }
+  if (ShellStatus == SHELL_SUCCESS) {
+ShellStatus = DisplayImageExecutionEntries 
(ImageExecutionTableAddress);
+  }
 }
 
   } else {
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni 

[edk2-devel] [PATCH v2 1/3] ShellPkg: UefiShellDebug1CommandsLib: Dumping RT Properties in Dmem.c

2024-03-19 Thread Sam Kaynor
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352

Implemented the dumping of the UEFI RT Properties Table using Dmem.c

Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Sam Kaynor 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 
62 
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni | 
22 ++-
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
index a609971f345e..1ae7b1f3d85c 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
@@ -84,8 +84,63 @@ DisplayMmioMemory (
   return (ShellStatus);
 }
 
+/**
+  Display the RtPropertiesTable entries
+
+  @param[in] AddressThe pointer to the RtPropertiesTable.
+**/
+SHELL_STATUS
+DisplayRtProperties (
+  IN UINT64 Address
+  )
+{
+  EFI_RT_PROPERTIES_TABLE *RtPropertiesTable;
+  UINT32  RtServices;
+  SHELL_STATUSShellStatus;
+  EFI_STATUS  Status;
+
+  ShellStatus = SHELL_SUCCESS;
+
+  if (Address != 0) {
+Status = EfiGetSystemConfigurationTable (, (VOID 
**));
+if (EFI_ERROR (Status)) {
+  ShellStatus = SHELL_NOT_FOUND;
+  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DMEM_ERR_GET_FAIL), 
gShellDebug1HiiHandle, L"RtPropertiesTable");
+} else {
+  RtServices = (UINT32)RtPropertiesTable->RuntimeServicesSupported;
+  ShellPrintHiiEx (
+-1,
+-1,
+NULL,
+STRING_TOKEN (STR_DMEM_RT_PROPERTIES),
+gShellDebug1HiiHandle,
+EFI_RT_PROPERTIES_TABLE_VERSION,
+(RtServices & EFI_RT_SUPPORTED_GET_TIME) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_SET_TIME) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_GET_WAKEUP_TIME) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_SET_WAKEUP_TIME) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_GET_VARIABLE) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_SET_VARIABLE) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_CONVERT_POINTER) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_RESET_SYSTEM) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_UPDATE_CAPSULE) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES) ? 1 : 0,
+(RtServices & EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO) ? 1 : 0
+);
+}
+  } else {
+ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_DMEM_ERR_NOT_FOUND), 
gShellDebug1HiiHandle, L"RtPropertiesTable");
+  }
+
+  return (ShellStatus);
+}
+
 STATIC CONST SHELL_PARAM_ITEM  ParamList[] = {
   { L"-mmio", TypeFlag },
+  { L"-verbose", TypeFlag },
   { NULL, TypeMax  }
 };
 
@@ -308,6 +363,13 @@ ShellCommandRunDmem (
 ConformanceProfileTableAddress
 );
 }
+
+if (ShellCommandLineGetFlag (Package, L"-verbose")) {
+  if (ShellStatus == SHELL_SUCCESS) {
+ShellStatus = DisplayRtProperties (RtPropertiesTableAddress);
+  }
+}
+
   } else {
 ShellStatus = DisplayMmioMemory (Address, (UINTN)Size);
   }
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
index 4041f0cd483e..299b0ba44f31 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
@@ -126,8 +126,26 @@
   "Memory Range Capsule
  %016LX\r\n"
   "Hii Database Export Buffer  
  %016LX\r\n"
   "Conformance Profile Table   
  %016LX\r\n"
-
-
+#string STR_DMEM_RT_PROPERTIES#language en-US "\r\nRT Properties Table\r\n"
+  
"\r\n"
+  "Version   
0x%01LX\r\n"
+  "Runtime Services 
Supported:\r\n"
+  "  GET_TIME  
   %d\r\n"
+  "  GET_WAKEUP_TIME   
   %d\r\n"
+  "  SET_TIME  
   %d\r\n"
+  "  SET_WAKEUP_TIME   
   %d\r\n"
+  "  GET_VARIABLE  
   %d\r\n"
+  "  GET_NEXT_VARIABLE_NAME
   %d\r\n"
+  

[edk2-devel] [PATCH v2 0/3] Adding support for verbose UEFI Table dumping to Dmem.c

2024-03-19 Thread Sam Kaynor
v1->v2:
- Changed how the Conformance Profile Table is iterated
- Changed how the Image Execution Table is iterated

Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Sam Kaynor 

Sam Kaynor (3):
  ShellPkg: UefiShellDebug1CommandsLib: Dumping RT Properties in Dmem.c
  ShellPkg: UefiShellDebug1CommandsLib: Image Execution Table in Dmem.c
  ShellPkg: UefiShellDebug1CommandsLib: Conformance Profiles in Dmem.c

 MdePkg/MdePkg.dec  |   
7 +
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf |   
3 +
 MdePkg/Include/Guid/ConformanceProfiles.h  |  
57 +
 ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 
269 
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni |  
30 ++-
 5 files changed, 364 insertions(+), 2 deletions(-)
 create mode 100644 MdePkg/Include/Guid/ConformanceProfiles.h

-- 
2.34.1



[edk2-devel] Refactoring the UEFI shell

2024-03-19 Thread Benjamin Doron
Hi all,
We're planning to refactor the shell into a library so that shell apps
possibly used in the field for testing can be easily adapted for automation.

Our plan is:

   - Refactor ShellInfoObject into base internals and interactive elements
   - Migrate functions that imply interactivity into a new library class,
   and write some stubs in a LibNull
   - Refactor last shell app files (file interface, shell env var) into
   another (or same) library
   - Implement non-interactive functions, as required
   - Write an example implementation in MdeModulePkg/Application/


We're looking for thoughts and ideas on our approach, as well as opinions
on the concept.

Best regards,
Benjamin


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




Re: [edk2-devel] [PATCH edk2-platforms v7 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

2024-03-19 Thread Ard Biesheuvel
On Tue, 19 Mar 2024 at 14:50, Marcin Juszkiewicz
 wrote:
>
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
>
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
>
> Values are read from TF-A using platform specific SMC calls.
>
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
>  .../SbsaQemuHardwareInfoLib.inf  | 31 +++
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 17 +++-
>  .../Include/Library/SbsaQemuHardwareInfoLib.h| 45 +
>  .../SbsaQemuHardwareInfoLib.c| 96 
> 
>  5 files changed, 187 insertions(+), 5 deletions(-)
>
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..07cb3490f4cf 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ [LibraryClasses.common]
>
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..e621c422bd40
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,31 @@
> +#/* @file
> +#
> +#  Copyright (c) 2024, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = ArmPlatformLib
> +

Please define a suitable library class and add it to the
Silicon/Qemu/SbsaQemu/SbsaQemu.dec, as I mentioned in the previous
round of review.

Thanks,
Ard.


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




Re: [edk2-devel] [PATCH v4 3/4] UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension

2024-03-19 Thread Tuan Phan
Hi Sunil,

On Mon, Mar 18, 2024 at 6:00 AM Sunil V L  wrote:

> Hi Tuan,
>
> On Thu, Mar 14, 2024 at 01:19:16PM -0700, Tuan Phan wrote:
> > The GCD EFI_MEMORY_UC and EFI_MEMORY_WC memory attributes will be
> > supported when Svpbmt extension available.
> >
> > Cc: Gerd Hoffmann 
> > Cc: Laszlo Ersek 
> > Cc: Rahul Kumar 
> > Cc: Ray Ni 
> > Signed-off-by: Tuan Phan 
> > ---
> >  .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 106 ++
> >  .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |   1 +
> >  2 files changed, 86 insertions(+), 21 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> > index 46ba4b4709b1..34300dca5c34 100644
> > --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> > +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> > @@ -36,6 +36,11 @@
> >  #define PTE_PPN_SHIFT 10
> >  #define RISCV_MMU_PAGE_SHIFT  12
> >
> > +#define RISCV_CPU_FEATURE_PBMT_BITMASK  BIT2
> > +#define PTE_PBMT_NC BIT61
> > +#define PTE_PBMT_IO BIT62
> > +#define PTE_PBMT_MASK   (PTE_PBMT_NC | PTE_PBMT_IO)
> > +
> >  STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> SATP_MODE_SV39, SATP_MODE_OFF };
> >  STATIC UINTN  mMaxRootTableLevel;
> >  STATIC UINTN  mBitPerLevel;
> > @@ -487,32 +492,82 @@ UpdateRegionMapping (
> >  /**
> >Convert GCD attribute to RISC-V page attribute.
> >
> > -  @param  GcdAttributes The GCD attribute.
> > +  @param  GcdAttributes   The GCD attribute.
> > +  @param  RiscVAttributes The pointer of RISC-V page attribute.
> >
> > -  @return   The RISC-V page attribute.
> > +  @retval EFI_INVALID_PARAMETER   The RiscVAttributes is NULL or cache
> type mask not valid.
> > +  @retval EFI_SUCCESS The operation succesfully.
> >
> >  **/
> >  STATIC
> > -UINT64
> > +EFI_STATUS
> >  GcdAttributeToPageAttribute (
> > -  IN UINT64  GcdAttributes
> > +  IN UINT64   GcdAttributes,
> > +  OUT UINT64  *RiscVAttributes
> >)
> >  {
> > -  UINT64  RiscVAttributes;
> > +  UINT64   CacheTypeMask;
> > +  BOOLEAN  PmbtExtEnabled;
> >
> Why not read the PCD once and save in a static variable?
>
I can put it into a static variable if you think it is more clean.

>
> > -  RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
> > +  if (RiscVAttributes == NULL) {
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> > +  *RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
> > +
> > +  PmbtExtEnabled = FALSE;
> > +  if ((PcdGet64 (PcdRiscVFeatureOverride) &
> RISCV_CPU_FEATURE_PBMT_BITMASK) != 0) {
> > +PmbtExtEnabled = TRUE;
> > +  }
> >
> >// Determine protection attributes
> >if ((GcdAttributes & EFI_MEMORY_RO) != 0) {
> > -RiscVAttributes &= ~(UINT64)(RISCV_PG_W);
> > +*RiscVAttributes &= ~(UINT64)(RISCV_PG_W);
> >}
> >
> >// Process eXecute Never attribute
> >if ((GcdAttributes & EFI_MEMORY_XP) != 0) {
> > -RiscVAttributes &= ~(UINT64)RISCV_PG_X;
> > +*RiscVAttributes &= ~(UINT64)RISCV_PG_X;
> > +  }
> > +
> > +  CacheTypeMask = GcdAttributes & EFI_CACHE_ATTRIBUTE_MASK;
> > +  if ((CacheTypeMask != 0) &&
> > +  (((CacheTypeMask - 1) & CacheTypeMask) != 0))
> > +  {
> > +DEBUG ((
> > +  DEBUG_ERROR,
> > +  "%a: More than one bit set in cache type mask (0x%LX)\n",
> > +  __func__,
> > +  CacheTypeMask
> > +  ));
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> > +  switch (CacheTypeMask) {
> > +case EFI_MEMORY_UC:
> > +  if (PmbtExtEnabled) {
> > +*RiscVAttributes |= PTE_PBMT_IO;
> > +  }
> > +
> > +  break;
> > +case EFI_MEMORY_WC:
> > +  if (PmbtExtEnabled) {
> > +*RiscVAttributes |= PTE_PBMT_NC;
> > +  } else {
> > +DEBUG ((
> > +  DEBUG_VERBOSE,
> > +  "%a: EFI_MEMORY_WC set but Pmbt extension not available\n",
> > +  __func__
> > +  ));
> > +  }
> > +
> > +  break;
> > +default:
> > +  // Default PMA mode
> > +  break;
> >}
> >
> > -  return RiscVAttributes;
> > +  return EFI_SUCCESS;
> >  }
> >
> >  /**
> > @@ -535,29 +590,38 @@ RiscVSetMemoryAttributes (
> >IN UINT64Attributes
> >)
> >  {
> > -  UINT64  PageAttributesSet;
> > +  UINT64  PageAttributesSet;
> > +  UINT64  PageAttributesClear;
> > +  EFI_STATUS  Status;
> >
> > -  PageAttributesSet = GcdAttributeToPageAttribute (Attributes);
> > +  Status = GcdAttributeToPageAttribute (Attributes, );
> > +  if (EFI_ERROR (Status)) {
> > +return Status;
> > +  }
> >
> Is there a reason to do this prior to checking RiscVMmuEnabled()?
>
Only reason is return error due to invalid parameter before return
EFI_SUCCESS if Mmu not enabled.

>
> >if (!RiscVMmuEnabled ()) {
> >  return EFI_SUCCESS;
> >}
> >
> > -  DEBUG (
> > -(
> > - DEBUG_VERBOSE,
> > - "%a: Set %llX page attribute 0x%X\n",
> > 

Re: [edk2-devel] [PATCH 1/3] CryptoPkg/BaseCryptLib: add additional RSAEP-OAEP crypto functions

2024-03-19 Thread Chris Ruffin via groups.io


Hi Yi, thanks for  your email.  I created a Bugzilla ticket for this, see 
Bugzilla ID #4732: https://bugzilla.tianocore.org/show_bug.cgi?id=4732.  The 
Pkcs1v2Encrypt() API is maintained but the implementation is refactored.  There 
is currently no Pkcs1v2Decrypt(), this is also a newly implemented API but the 
converse of Pkcs1v2Encypt().  Pkcs1v2Encrypt() (existing) and Pkcs1v2Decrypt() 
(new) both take they keys from DER-encoded certificates/keys.  RsaOaepEncrypt() 
and RsaOaepDecrypt() both take keys from RsaContext.  The internal functions 
use a common ENV_PKEY.

More from the Bugzilla:

BasecryptLib currently only provides RSAES-OAEP encryption capability with 
Pkcs1v2Encrypt() which takes as input a DER encoded x.509 certificate.  A DXE 
application which needs access to RSAES-OAEP encryption and decryption 
capabilities currently only has the option of statically linking OpensslLib and 
using functions such as RSA_public_encrypt() and RSA_private_decrypt().  These 
applications would benefit from an expanded access to RSAES-OAEP encryption / 
decryption capability in BaseCryptLib so that the shared crypto driver can be 
used and the applciation can be migrated away from RSA_public_decrypt() and 
RSA_private_decrypt() which are deprecated in Openssl 3.

There is the following challenges with migrating to BaseCryptLib interfaces:

1) BaseCryptLib Pkcs1v2Encrypt() requires the use of an X.509 
DER-encoded certificate to pass the public key.  This interface is dissimilar 
from the rest of the RSA APIs in BasecryptLib.  Applications that have used 
other RSA APIs from BaseCryptLib for key generation and management such as 
RsaGenerateKey() and RsaSetKey() will not have such a structure available.
2) BaseCryptLib currently exposes no decryption capability.

This feature provides an easy migration path for drivers/applications which 
need access to RSAES-OAEP encryption / decryption and that are currently using 
an RsaContext structure to pass key components to OpensslLib. These 
applications can be easily migrated to one of the new APIs to remove the direct 
dependency on OpensslLib, migrate away from deprecated interfaces, take 
advantage of CryptoPkg/Driver, and get BasecryptLib access to RSAES-OAEP 
decryption.

Key changes proposed:
InternalPkcs1v2Encrypt(): New internal-only function created from refactoring 
of Pkcs1v2Encrypt().  Takes key input from an ENV_PKEY and is used by both 
public functions Pkcs1v2Encrypt() and RsaOaepEncrypt().

Pkcs1v2Encrypt(): has been refactored to create InternalPkcs1v2Encrypt() but 
the public interface is maintained.

RsaOaepEncrypt(): New function takes key input from an RsaContext, creates an 
ENV_PKEY, and calls InternalPkcs1v2Encrypt()

InternalPkcs1v2Decrypt(): New internal-only function InternalPkcs1v2Decrypt() 
takes key input from an ENV_PKEY and provides the RSAES-OAEP decryption 
capability to Pkcs1v2Decrypt() and RsaOaepDecrypt().

Pkcs1v2Decrypt(): New public function Pkcs1v2Decrypt() takes a DER-encoded 
private key, creates an ENV_PKEY, and calls InternalPkcs1v2Decrypt()

RsaOaepDecrypt(): New public function RsaOaepDecrypt() takes a pointer to 
RsaContext, creates an ENV_PKEY, and calls InternalPkcs1v2Decrypt()

Thanks,

Chris


-Original Message-
From: Li, Yi1  
Sent: Monday, March 18, 2024 11:52 PM
To: Chris Ruffin ; devel@edk2.groups.io
Cc: Chris Ruffin ; Yao, Jiewen 
; Hou, Wenxing 
Subject: RE: [PATCH 1/3] CryptoPkg/BaseCryptLib: add additional RSAEP-OAEP 
crypto functions

[You don't often get email from yi1...@intel.com. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

Hi Chris,

1. Please create a feature request BugZilla to introduce the background of the 
new API, such as purpose and application scenarios.
2. I took a quick look, the new API will make Pkcs1v2De/Encrypt support 
RsaContext input and the rest is same as old API right?

Regards,
Yi

-Original Message-
From: Chris Ruffin 
Sent: Tuesday, March 19, 2024 5:52 AM
To: devel@edk2.groups.io
Cc: Chris Ruffin ; Yao, Jiewen 
; Li, Yi1 ; Hou, Wenxing 

Subject: [PATCH 1/3] CryptoPkg/BaseCryptLib: add additional RSAEP-OAEP crypto 
functions

From: Chris Ruffin 

Expand the availability of the RSAEP-OAEP crypto capability in BaseCryptLib.  
Applications using RSA crypto functions directly from OpensslLib can transition 
to BaseCryptLib to take advantage of the shared crypto feature in CryptoDxe.

Pkcs1v2Decrypt(): decryption using DER-encoded private key
RsaOaepEncrypt(): encryption using RSA contexts
RsaOaepDecrypt(): decryption using RSA contexts

Signed-off-by: Chris Ruffin 
Cc: Jiewen Yao 
Cc: Yi Li 
Cc: Wenxing Hou 
---
 CryptoPkg/Include/Library/BaseCryptLib.h  | 102 
 .../Library/BaseCryptLib/Pk/CryptPkcs1Oaep.c  | 506 --
 .../BaseCryptLib/Pk/CryptPkcs1OaepNull.c  | 114 
 .../BaseCryptLibNull/Pk/CryptPkcs1OaepNull.c  | 114 
 4 files changed, 789 insertions(+), 47 deletions(-)


[edk2-devel] [PATCH edk2-platforms v7 4/4] Platform/SbsaQemu: get the information of memory via SMC calls

2024-03-19 Thread Marcin Juszkiewicz
From: Xiong Yining 

Provide functions to check for memory information:

- amount of memory nodes
- memory address
- NUMA node id for memory

Values are read from TF-A using platform specific SMC calls.

Signed-off-by: Xiong Yining 
Signed-off-by: Chen Baozi 
Signed-off-by: Marcin Juszkiewicz 
---
 .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  |  2 +
 .../Include/Library/SbsaQemuHardwareInfoLib.h| 28 ++
 .../SbsaQemuHardwareInfoLib.c| 50 ++
 .../Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c  | 54 +---
 4 files changed, 93 insertions(+), 41 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
index 2317c1f0ae69..e3092007d27d 100644
--- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
@@ -16,6 +16,8 @@
 #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
 #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
 #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
+#define SIP_SVC_GET_MEMORY_NODE_COUNT SMC_SIP_FUNCTION_ID(300)
+#define SIP_SVC_GET_MEMORY_NODE SMC_SIP_FUNCTION_ID(301)
 
 /*
  *  SMCC does not define return codes for SiP functions.
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
index 2654bc823e07..c896c6a77436 100644
--- a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
@@ -9,6 +9,12 @@
 #ifndef SBSA_QEMU_HARDWARE_INFO_
 #define SBSA_QEMU_HARDWARE_INFO_
 
+typedef struct{
+  UINT32  NodeId;
+  UINT64  AddressBase;
+  UINT64  AddressSize;
+} MemoryInfo;
+
 /**
   Get CPU count from information passed by Qemu.
 
@@ -42,4 +48,26 @@ SbsaQemuGetCpuNumaNode (
   IN UINTN  CpuId
   );
 
+/**
+  Get the number of memory node from device tree passed by Qemu.
+
+  @retval   the number of memory nodes.
+**/
+UINT32
+SbsaQemuGetMemNodeCount (
+  VOID
+  );
+
+/**
+  Get memory infomation(node-id, addressbase, addresssize) for a given memory 
node from device tree passed by Qemu.
+
+  @param [in]   MemoryIdIndex of memory to retrieve memory information.
+
+  @retval   memory infomation for given memory node.
+**/
+MemoryInfo
+SbsaQemuGetMemInfo (
+  IN UINTN   MemoryId
+  );
+
 #endif /* SBSA_QEMU_HARDWARE_INFO_ */
diff --git 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
index a1c208647818..a94fdcb55bb9 100644
--- 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
+++ 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
@@ -94,3 +94,53 @@ SbsaQemuGetCpuNumaNode (
 
   return Arg0;
 }
+
+UINT32
+SbsaQemuGetMemNodeCount (
+  VOID
+  )
+{
+  UINTNSmcResult;
+  UINTNArg0;
+
+  SmcResult = ArmCallSmc0 (SIP_SVC_GET_MEMORY_NODE_COUNT, , NULL, NULL);
+  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_MEMORY_NODE_COUNT call failed. We 
have no memory information.\n", __FUNCTION__));
+ResetShutdown ();
+  }
+
+  DEBUG (( DEBUG_INFO, "%a: The number of the memory nodes is %ld\n", 
__FUNCTION__, Arg0));
+  return (UINT32)Arg0;
+}
+
+MemoryInfo
+SbsaQemuGetMemInfo (
+  IN UINTN   MemoryId
+  )
+{
+  UINTN   SmcResult;
+  UINTN   Arg0;
+  UINTN   Arg1;
+  UINTN   Arg2;
+  MemoryInfo  MemInfo;
+
+  Arg0 = MemoryId;
+
+  SmcResult = ArmCallSmc1 (SIP_SVC_GET_MEMORY_NODE, , , );
+  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_MEMORY_NODE call failed. We have no 
memory information.\n", __FUNCTION__));
+ResetShutdown ();
+  } else {
+MemInfo.NodeId = Arg0;
+MemInfo.AddressBase = Arg1;
+MemInfo.AddressSize = Arg2;
+  }
+
+  DEBUG(( DEBUG_INFO, "%a: NUMA node for System RAM:%d = 0x%lx - 0x%lx\n",
+  __FUNCTION__,
+  MemInfo.NodeId,
+  MemInfo.AddressBase,
+  MemInfo.AddressBase + MemInfo.AddressSize -1 ));
+
+  return MemInfo;
+}
diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
index 8c2eb0b6a028..5a418a461174 100644
--- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
+++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 // Number of Virtual Memory Map Descriptors
 #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  4
@@ -23,53 +23,25 @@ SbsaQemuLibConstructor (
   VOID
   )
 {
-  VOID  *DeviceTreeBase;
-  INT32 Node, Prev;
   UINT64NewBase, CurBase;
   UINT64NewSize, CurSize;
-  CONST CHAR8   *Type;

[edk2-devel] [PATCH edk2-platforms v7 3/4] Platform/SbsaQemu: drop FdtHandlerLib

2024-03-19 Thread Marcin Juszkiewicz
There is no need for EDK2 to know that there is DeviceTree around.
All hardware information is read using functions from
SbsaQemuHardwareInfoLib library.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  1 -
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf   | 33 ---
 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h | 36 ---
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c | 98 
 4 files changed, 168 deletions(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 07cb3490f4cf..bde61651da2e 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -126,7 +126,6 @@ [LibraryClasses.common]
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
-  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
   OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
   
SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
 
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
deleted file mode 100644
index 9c059f3e5851..
--- a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
+++ /dev/null
@@ -1,33 +0,0 @@
-#/** @file
-#
-#  Component description file for FdtHelperLib module
-#
-#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-#
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-#**/
-
-[Defines]
-  INF_VERSION= 1.29
-  BASE_NAME  = FdtHelperLib
-  FILE_GUID  = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = FdtHelperLib
-
-[Sources.common]
-  FdtHelperLib.c
-
-[Packages]
-  EmbeddedPkg/EmbeddedPkg.dec
-  MdePkg/MdePkg.dec
-  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
-
-[LibraryClasses]
-  DebugLib
-  FdtLib
-  PcdLib
-
-[FixedPcd]
-  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
deleted file mode 100644
index ea9159857215..
--- a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/** @file
-*  FdtHelperLib.h
-*
-*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-*
-*  SPDX-License-Identifier: BSD-2-Clause-Patent
-*
-**/
-
-#ifndef FDT_HELPER_LIB_
-#define FDT_HELPER_LIB_
-
-/**
-  Get MPIDR for a given cpu from device tree passed by Qemu.
-
-  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
-
-  @retvalMPIDR value of CPU at index 
-**/
-UINT64
-FdtHelperGetMpidr (
-  IN UINTN   CpuId
-  );
-
-/** Walks through the Device Tree created by Qemu and counts the number
-of CPUs present in it.
-
-@return The number of CPUs present.
-**/
-EFIAPI
-UINT32
-FdtHelperCountCpus (
-  VOID
-  );
-
-#endif /* FDT_HELPER_LIB_ */
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
deleted file mode 100644
index 7fdfb055db76..
--- a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
+++ /dev/null
@@ -1,98 +0,0 @@
-/** @file
-*  FdtHelperLib.c
-*
-*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
-*
-*  SPDX-License-Identifier: BSD-2-Clause-Patent
-*
-**/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-STATIC INT32 mFdtFirstCpuOffset;
-STATIC INT32 mFdtCpuNodeSize;
-
-/**
-  Get MPIDR for a given cpu from device tree passed by Qemu.
-
-  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
-
-  @retvalMPIDR value of CPU at index 
-**/
-UINT64
-FdtHelperGetMpidr (
-  IN UINTN   CpuId
-  )
-{
-  VOID   *DeviceTreeBase;
-  CONST UINT64   *RegVal;
-  INT32  Len;
-
-  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
-  ASSERT (DeviceTreeBase != NULL);
-
-  RegVal = fdt_getprop (DeviceTreeBase,
- mFdtFirstCpuOffset + (CpuId * mFdtCpuNodeSize),
- "reg",
- );
-  if (!RegVal) {
-DEBUG ((DEBUG_ERROR, "Couldn't find reg property for CPU:%d\n", CpuId));
-return 0;
-  }
-
-  return (fdt64_to_cpu (ReadUnaligned64 (RegVal)));
-}
-
-/** Walks through the Device Tree created by Qemu and counts the number
-of CPUs present in it.
-
-@return The number of CPUs present.
-**/
-EFIAPI
-UINT32
-FdtHelperCountCpus (
-  VOID
-  )
-{
-  VOID   *DeviceTreeBase;
-  INT32  Node;
-  INT32  Prev;
-  INT32  CpuNode;
-  UINT32 CpuCount;
-
-  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
-  ASSERT (DeviceTreeBase != NULL);
-
-  // Make sure we have a valid device tree blob
-  ASSERT 

[edk2-devel] [PATCH edk2-platforms v7 2/4] Platform/SbsaQemu: use SbsaQemuHardwareInfoLib for cpu information

2024-03-19 Thread Marcin Juszkiewicz
We have SbsaQemuHardwareInfoLib to ask for hardware details. No need to
parse DeviceTree anymore.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  6 ++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  5 ++---
 .../SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf |  4 ++--
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 11 +-
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 21 +++-
 5 files changed, 18 insertions(+), 29 deletions(-)

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
index a34f54d431d4..b09ccf93fa63 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
@@ -3,7 +3,7 @@
 #
 #Copyright (c) 2021, NUVIA Inc. All rights reserved.
 #Copyright (c) 2018, Hisilicon Limited. All rights reserved.
-#Copyright (c) 2018, Linaro Limited. All rights reserved.
+#Copyright (c) 2018-2024, Linaro Ltd. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -29,10 +29,9 @@ [Packages]
 
 [LibraryClasses]
   BaseMemoryLib
-  FdtLib
-  FdtHelperLib
   IoLib
   PcdLib
+  SbsaQemuHardwareInfoLib
 
 [Guids]
   gZeroGuid
@@ -40,7 +39,6 @@ [Guids]
 [Pcd]
   gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
   gArmTokenSpaceGuid.PcdSystemBiosRelease
-  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
 
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemSerialNumber
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 291743b19115..fded56c3f17e 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  This driver modifies ACPI tables for the Qemu SBSA platform
 #
-#  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+#  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -35,16 +35,15 @@ [LibraryClasses]
   BaseLib
   DebugLib
   DxeServicesLib
-  FdtHelperLib
   PcdLib
   PrintLib
+  SbsaQemuHardwareInfoLib
   UefiDriverEntryPoint
   UefiLib
   UefiRuntimeServicesTableLib
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
-  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdClusterCount
 
   gArmTokenSpaceGuid.PcdGicDistributorBase
diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
index c067a80cc715..07e6bc4e9b11 100644
--- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
+++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
@@ -1,6 +1,6 @@
 #/* @file
 #
-#  Copyright (c) 2019, Linaro Limited. All rights reserved.
+#  Copyright (c) 2019-2024, Linaro Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -32,9 +32,9 @@ [LibraryClasses]
   ArmLib
   BaseMemoryLib
   DebugLib
-  FdtLib
   MemoryAllocationLib
   PcdLib
+  SbsaQemuHardwareInfoLib
 
 [Pcd]
   gArmTokenSpaceGuid.PcdSystemMemoryBase
diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
index c38f2851904f..2cfd2a7c6469 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
@@ -2,7 +2,7 @@
 *  OemMiscLib.c
 *
 *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -12,14 +12,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 
 /** Returns whether the specified processor is present or not.
 
@@ -33,7 +32,7 @@ OemIsProcessorPresent (
   UINTN ProcessorIndex
   )
 {
-  if (ProcessorIndex < FdtHelperCountCpus ()) {
+  if (ProcessorIndex < SbsaQemuGetCpuCount ()) {
 return TRUE;
   }
 
@@ -76,7 +75,7 @@ OemGetProcessorInformation (
 {
   UINT16 ProcessorCount;
 
-  ProcessorCount = FdtHelperCountCpus ();
+  ProcessorCount = SbsaQemuGetCpuCount ();
 
   if (ProcessorIndex < ProcessorCount) {
 ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
@@ -121,7 +120,7 @@ OemGetMaxProcessors (
   VOID
   )
 {
-  return FdtHelperCountCpus ();
+  return SbsaQemuGetCpuCount ();
 }
 
 /** Gets information about the cache at the specified cache level.
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 9fb17151d7b8..54f00ae83672 100644
--- 

[edk2-devel] [PATCH edk2-platforms v7 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

2024-03-19 Thread Marcin Juszkiewicz
This library provides functions to check for hardware information.
For now it covers CPU ones:

- amount of cpu cores
- MPIDR value for cpu core
- NUMA node id for cpu core

Values are read from TF-A using platform specific SMC calls.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
 .../SbsaQemuHardwareInfoLib.inf  | 31 +++
 .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 17 +++-
 .../Include/Library/SbsaQemuHardwareInfoLib.h| 45 +
 .../SbsaQemuHardwareInfoLib.c| 96 
 5 files changed, 187 insertions(+), 5 deletions(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 378600050df9..07cb3490f4cf 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -1,6 +1,6 @@
 #
 #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-#  Copyright (c) 2019, Linaro Limited. All rights reserved.
+#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -128,6 +128,7 @@ [LibraryClasses.common]
 
   FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
   OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
+  
SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
 
   # Debug Support
   
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
diff --git 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
new file mode 100644
index ..e621c422bd40
--- /dev/null
+++ 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
@@ -0,0 +1,31 @@
+#/* @file
+#
+#  Copyright (c) 2024, Linaro Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#*/
+
+[Defines]
+  INF_VERSION= 0x0001001c
+  BASE_NAME  = SbsaQemuHardwareInfoLib
+  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmPlatformLib
+
+[Sources]
+  SbsaQemuHardwareInfoLib.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
+
+[LibraryClasses]
+  ArmSmcLib
+  BaseMemoryLib
+  DebugLib
+  ResetSystemLib
diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
index 7934875e4aba..2317c1f0ae69 100644
--- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
+*  Copyright (c) 2023-2024, Linaro Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -11,8 +11,17 @@
 
 #include 
 
-#define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
-#define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
-#define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
+#define SIP_SVC_VERSIONSMC_SIP_FUNCTION_ID(1)
+#define SIP_SVC_GET_GICSMC_SIP_FUNCTION_ID(100)
+#define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
+#define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
+#define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
+
+/*
+ *  SMCC does not define return codes for SiP functions.
+ *  We use Architecture ones then.
+ */
+
+#define SMC_SIP_CALL_SUCCESS  SMC_ARCH_CALL_SUCCESS
 
 #endif /* SBSA_QEMU_SMC_H_ */
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
new file mode 100644
index ..2654bc823e07
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
@@ -0,0 +1,45 @@
+/** @file
+*
+*  Copyright (c) 2024, Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#ifndef SBSA_QEMU_HARDWARE_INFO_
+#define SBSA_QEMU_HARDWARE_INFO_
+
+/**
+  Get CPU count from information passed by Qemu.
+
+**/
+UINT32
+SbsaQemuGetCpuCount (
+  VOID
+  );
+
+/**
+  Get MPIDR for a given cpu from device tree passed by Qemu.
+
+  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
+
+  @retvalMPIDR value of CPU at index 
+**/
+UINT64
+SbsaQemuGetMpidr (
+  IN UINTN  CpuId
+  );
+
+/**
+  Get NUMA node id for a given cpu from device tree passed by Qemu.
+
+  @param [in]   CpuIdIndex of cpu to retrieve NUMA node id for.
+
+  @retvalNUMA node id for CPU at index 
+**/
+UINT64
+SbsaQemuGetCpuNumaNode (
+  IN UINTN  CpuId
+  );
+
+#endif /* SBSA_QEMU_HARDWARE_INFO_ */
diff 

[edk2-devel] [PATCH edk2-platforms v7 0/4] get rid of DeviceTree from SbsaQemu

2024-03-19 Thread Marcin Juszkiewicz
We want to stop parsing DeviceTree to gather hardware information.

Instead we ask TF-A for those details using SMC calls. On real hardware
platform it could be asking on-board Embedded Controller.

Hardware information (CPU, Memory) is now in SbsaQemuHardwareInfoLib
together with new code for handling SMC stuff. There is no DT parsing
anywhere.

TF-A part is merged already (and we have it in edk2-non-osi):
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/25707

Patch 4 needs work to pass MemInfo as reference.

Signed-off-by: Marcin Juszkiewicz 
---
Changes in v7:
- dropped CoreCount Pcd - code calls SbsaQemuGetCpuCount() instead
- dropped DT fallbacks - we have up-to-date TF-A in edk2-non-osi
- system shutdowns when there is no cpu or memory information
- SbsaQemuHardwareInfoLib debug calls show function names
- Link to v6: 
https://openfw.io/edk2-devel/20240306-no-dt-for-cpu-v6-0-acd8727a1...@linaro.org

Changes in v6 (Marcin Juszkiewicz):
- patch 5 now shutdowns system in case of no CPU information

Changes in v5 (Xiong Yining):
- added missing patch
- Link to v5: 
https://openfw.io/edk2-devel/20240131132400.3022662-1-xiongyining1...@phytium.com.cn/

Changes in v4 (Xiong Yining):
- patch 6 add the support for getting the hardware information of memory via 
SMC calls.
- patch 7 add the callback of DeviceTree when SMC calls defined on patch 6 
failled.
- replace FdtHelperGetMpidr() with SbsaQemuGetMpidr() on patch 4 to compile 
successfully.
- Link to v4: 
https://openfw.io/edk2-devel/20240131100027.2538549-1-xiongyining1...@phytium.com.cn/

Changes in v3:
- added SMC_SIP_CALL_SUCCESS
- on SMC call fail tell that SMC call failed instead of blaming TF-A
- hang when there is no cpu information (TODO: shutdown instead)
- Link to v3: 
https://openfw.io/edk2-devel/20240124-no-dt-for-cpu-v3-0-5375fcf09...@linaro.org/

---
Marcin Juszkiewicz (3):
  Platform/SbsaQemu: add SbsaQemuHardwareInfoLib
  Platform/SbsaQemu: use SbsaQemuHardwareInfoLib for cpu information
  Platform/SbsaQemu: drop FdtHandlerLib

Xiong Yining (1):
  Platform/SbsaQemu: get the information of memory via SMC calls

 Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   4 +-
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf|   6 +-
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   5 +-
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf  |  33 -
 .../SbsaQemuHardwareInfoLib.inf |  31 +
 .../SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf|   4 +-
 .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h |  19 ++-
 .../Qemu/SbsaQemu/Include/Library/FdtHelperLib.h|  36 -
 .../Include/Library/SbsaQemuHardwareInfoLib.h   |  73 ++
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c  |  11 +-
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |  21 +--
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c|  98 -
 .../SbsaQemuHardwareInfoLib.c   | 146 
 .../Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c |  54 ++--
 14 files changed, 298 insertions(+), 243 deletions(-)
---
base-commit: 80ee8b861edb6a8b02a100f63bbb435499f8741a
change-id: 20240115-no-dt-for-cpu-2c511393df93

Best regards,
-- 
Marcin Juszkiewicz 



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




Re: [edk2-devel] [PATCH edk2-non-osi 1/1] Qemu/Sbsa: update TF-A binaries to get needed SMC calls

2024-03-19 Thread Ard Biesheuvel
On Thu, 14 Mar 2024 at 15:21, Marcin Juszkiewicz
 wrote:
>
> W dniu 14.03.2024 o 15:17, Marcin Juszkiewicz via groups.io pisze:
> > We want to stop parsing DeviceTree (in EDK2) to gather hardware information.
> >
> > Instead we ask TF-A for those details using SMC calls. On real hardware
> > platform it could be asking on-board Embedded Controller.
> >
> > Hardware information (CPU, Memory) is now in SbsaQemuHardwareInfoLib 
> > together
> > with new code for handling SMC stuff. If TF-A answer to SMC call would be 
> > not
> > success then we go back to parsing DeviceTree data directly. There is no DT
> > parsing elsewhere.
> >
> > This change brings TF-A with all changes needed for it.
>
> Signed-off-by: Marcin Juszkiewicz 
>

Pushed as  476d087..0544808

Thanks,


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




Re: [edk2-devel] [PATCH] NetworkPkg:Resolved Consecutive Pxe-Http Boot Issue

2024-03-19 Thread Sivaraman Nainar via groups.io
@Saloni Kasbekar,

Can you please comment on the changes?

Thanks
Siva
-Original Message-
From: Sivaraman Nainar
Sent: Monday, February 26, 2024 4:01 PM
To: devel@edk2.groups.io; Sivaraman Nainar ; Laszlo Ersek 
; Santhosh Kumar V ; Saloni Kasbekar 
; Zachary Clark-williams 

Cc: Raj V Akilan ; Soundharia R 
Subject: RE: [EXTERNAL] Re: [edk2-devel] [PATCH] NetworkPkg:Resolved 
Consecutive Pxe-Http Boot Issue

@Saloni Kasbekar, @Zachary Clark-williams,

Could you please add your feedback on the changes proposed?

Thanks
Siva
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Sivaraman Nainar 
via groups.io
Sent: Thursday, February 22, 2024 7:33 AM
To: Laszlo Ersek ; devel@edk2.groups.io; Santhosh Kumar V 
; Saloni Kasbekar ; Zachary 
Clark-williams 
Cc: Raj V Akilan ; Soundharia R 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH] NetworkPkg:Resolved Consecutive 
Pxe-Http Boot Issue


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

Laszlo:

Thanks for the detailed feedback on the changes for this issue. Since we are 
not sure if this change are valid / violate some purpose of SNP driver, it 
mentioned as Workaround.

@Saloni Kasbekar and @Clark-williams, Zachary can add more on these changes.

As you recommended, we can have PCD which controls these changes till the 
changes are addressed in grub.

@Santhosh Kumar V is this issue can be seen only in SLES 15 or it can be found 
in any OS having Grub 2.x?

Thanks
Siva
-Original Message-
From: Laszlo Ersek 
Sent: Thursday, February 22, 2024 5:15 AM
To: devel@edk2.groups.io; Santhosh Kumar V 
Cc: Sivaraman Nainar ; Raj V Akilan ; 
Soundharia R ; Saloni Kasbekar 
; Zachary Clark-williams 

Subject: [EXTERNAL] Re: [edk2-devel] [PATCH] NetworkPkg:Resolved Consecutive 
Pxe-Http Boot Issue


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

On 2/21/24 18:15, Santhosh Kumar V via groups.io wrote:
> The customer has a server environment where PXE and HTTP service run in same 
> Linux Server. In this environment a SUT trying to boot to SLES 15 OS via PXE 
> from the Boot Menu. After PXE Boot file downloaded and grub Loaded without 
> continuing for installation Exit is pressed and control back to Setup.
> Now the HTTP boot to SLES 15 OS tried in the same environment and failed to 
> download the file. If there is a reconnect -r performed before this HTTP Boot 
> then boot file download and installation is getting success.
> Root cause of the issue is, when Exit from grub performed, boot Loader Stops 
> the SNP Driver and starts the same.

This sentence feels like the key one.

Are you saying that grub calls Snp->Start() just before it exits?

If so, am I right to suspect that that's a grub bug? It sounds like a resource 
leak, after all.

Can you perhaps include a grub source code location / pointer in the commit 
message?

> During this process SNP is in Initialized State. When HTTP boot is performed 
> immediately after PXE Failure, the MNP configure method initiates the SNP 
> Start again. Since the SNP already started by grub it returns 
> EFI_ALREADY_STARTED and none of the upper Layer drivers are getting started.
> As a work around in MNPConfigure(), if the SNP Start failed with Already 
> Started and in Initialized state we can return success so that rest of the 
> drivers can be loaded and HTTP boot can work.
>
>
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
>
> Signed-off-by: SanthoshKumar 
> ---
>  NetworkPkg/MnpDxe/MnpConfig.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/MnpDxe/MnpConfig.c
> b/NetworkPkg/MnpDxe/MnpConfig.c index 93587d53aa..0f2df28d73 100644
> --- a/NetworkPkg/MnpDxe/MnpConfig.c
> +++ b/NetworkPkg/MnpDxe/MnpConfig.c
> @@ -1120,7 +1120,9 @@ MnpStartSnp (
>// Start the simple network.
>
>//
>
>Status = Snp->Start (Snp);
>
> -
>
> +  if ((Status == EFI_ALREADY_STARTED ) && (Snp->Mode->State ==
> + EfiSimpleNetworkInitialized)) {
>
> +  return EFI_SUCCESS;
>
> +  }
>
>if (!EFI_ERROR (Status)) {
>
>  //
>
>  // Initialize the simple network.
>

The commit message does say this is a workaround, and I don't immediately any 
see why this workaround (in the code) would be problematic in practice, but it 
still leaves a bad taste in my mouth.

Consider: the call path is the following:

MnpConfigure()   [NetworkPkg/MnpDxe/MnpConfig.c] -- public .Configure() 
protocol member function
  MnpConfigureInstance() [NetworkPkg/MnpDxe/MnpConfig.c]
MnpStart()   [NetworkPkg/MnpDxe/MnpConfig.c]
  // see notes!
  MnpStartSnp()  [NetworkPkg/MnpDxe/MnpConfig.c]

Notes: the MnpStartSnp() call in MnpStart() is conditional on two circumstances 
(at the same time):
- "If it's not a configuration update, increase the configured children 

Re: [edk2-devel] [PATCH edk2-platforms v6 2/7] Platform/SbsaQemu: read amount of cpus during init

2024-03-19 Thread Marcin Juszkiewicz

W dniu 19.03.2024 o 12:02, Ard Biesheuvel pisze:

EDK2 starts and one of the first DXE called is SbsaQemuPlatformDxe one:


How is this guaranteed? DXE are generally dispatched in the order in
which they appear in the FDF, but only if all DEPEX dependencies are
satisfied. DEPEXes are compiled from the DXE .inf along with all its
[recursive] library dependencies, so upstream changes could affect the
DEPEX of SbsaQemuPlatformDxe, and therefore where it appears in the
dispatch order.


OK. Than it will be safer to call SbsaQemuGetCpuCount() in each place 
which needs CoreCount. Will adapt code. Thanks.



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




Re: [edk2-devel] [PATCH edk2-platforms v6 2/7] Platform/SbsaQemu: read amount of cpus during init

2024-03-19 Thread Ard Biesheuvel
On Tue, 19 Mar 2024 at 11:25, Marcin Juszkiewicz
 wrote:
>
> W dniu 15.03.2024 o 12:49, Marcin Juszkiewicz pisze:
> > W dniu 14.03.2024 o 16:13, Ard Biesheuvel pisze:
>
> >> How is it guaranteed that other components will only see the correct
> >> core count? DXE dispatch is ordered using a dependency graph, so all
> >> users of this PCD should never execute before this driver.
> >
> > SbsaQemuPlatformDxe is a DXE, right? So it is called on platform init.
> >
> > At the end of initialization it calls SbsaQemuGetCpuCount() from
> > SbsaQemuHardwareInfoLib to SET this PCD. It does not use it during
> > platform init cause it does not require this information. But calls
> > function to make sure that amount of cpus is known to whatever will be
> > called later.
> >
> > Sure, maybe SbsaQemuHardwareInfoLib should be something else (DXE,
> > Protocol or other EDK2 magic thing) but it is set of functions to be
> > called from other places of EDK2.
>
> EDK2 starts and one of the first DXE called is SbsaQemuPlatformDxe one:
>

How is this guaranteed? DXE are generally dispatched in the order in
which they appear in the FDF, but only if all DEPEX dependencies are
satisfied. DEPEXes are compiled from the DXE .inf along with all its
[recursive] library dependencies, so upstream changes could affect the
DEPEX of SbsaQemuPlatformDxe, and therefore where it appears in the
dispatch order.

None of the below is relevant, really. If you want to rely on dynamic
PCDs in DXE, the only safe way to set them is from the PEI phase.


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




Re: [edk2-devel] [PATCH edk2-platforms v6 2/7] Platform/SbsaQemu: read amount of cpus during init

2024-03-19 Thread Marcin Juszkiewicz

W dniu 15.03.2024 o 12:49, Marcin Juszkiewicz pisze:

W dniu 14.03.2024 o 16:13, Ard Biesheuvel pisze:



How is it guaranteed that other components will only see the correct
core count? DXE dispatch is ordered using a dependency graph, so all
users of this PCD should never execute before this driver.


SbsaQemuPlatformDxe is a DXE, right? So it is called on platform init.

At the end of initialization it calls SbsaQemuGetCpuCount() from 
SbsaQemuHardwareInfoLib to SET this PCD. It does not use it during 
platform init cause it does not require this information. But calls 
function to make sure that amount of cpus is known to whatever will be 
called later.


Sure, maybe SbsaQemuHardwareInfoLib should be something else (DXE, 
Protocol or other EDK2 magic thing) but it is set of functions to be 
called from other places of EDK2.


EDK2 starts and one of the first DXE called is SbsaQemuPlatformDxe one:

InitializeSbsaQemuPlatformDxe: InitializeSbsaQemuPlatformDxe called

InitializeSbsaQemuPlatformDxe: Got platform AHCI 6010 65536

INFO:SMC call: (0xc201) (function id: 1)

INFO:Platform version requested

Platform version: 0.3

INFO:SMC call: (0xc264) (function id: 100)

GICD base: 0x4006

GICR base: 0x4008

INFO:SMC call: (0xc265) (function id: 101)

GICI base: 0x44081000

InitializeSbsaQemuPlatformDxe: Got platform XHCI 6011 65536

INFO:SMC call: (0xc2c8) (function id: 200)

We have 4 cpus.


It does:

- AHCI init
- Platform version
- GIC addresses
- GIC ITS address
- XHCI init
- CPU count

Then system boot continues with 
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount being set to proper 
value.


If replacing use of Pcd with calls to SbsaQemuGetCpuCount() look better 
then I can change code to make it happen.



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




Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib

2024-03-19 Thread Gerd Hoffmann
On Tue, Mar 19, 2024 at 05:10:39PM +0800, Chao Li wrote:
> He Gerd,
> 
> > Speaking of this series: maybe split it into two?  The first part
> > of this series with the Mde*Pkg + UefiPkg changes looks almost ready
> > to merge to me, so maybe we can get that in while still sorting out
> > the remaining issues in the OvmfPkg patches ...
> 
> This series does not include changes to Mde*Pkg , so if the patches are
> separated,

Oh, right, Mde*Pkg was splitted before and is merged already.

> I think it might be two series, one is the UefiCpuPkg series, and
> other is OvmfPkg.

Agree.

> I tend to split patches into two series.



take care,
  Gerd



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




Re: [edk2-devel] [PATCH v2 1/6] uefi-sct/SctPkg: TCG2 Protocol: add header with TCG2 protocol definitions

2024-03-19 Thread G Edhaya Chandran
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/49620fa0bb9757bce13f41f604001114ea6c40de


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




Re: [edk2-devel] [PATCH v2 2/6] uefi-sct/SctPkg: TCG2 Protocol: add test infrastructure and GetCapability Test

2024-03-19 Thread G Edhaya Chandran
The patch is upstreamed by the commit:

https://github.com/tianocore/edk2-test/commit/ff8a146ace642cadc83b58cd4382181ec2dac633


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




Re: [edk2-devel] [PATCH v2 3/6] uefi-sct/SctPkg: TCG2 Protocol: add GetActivePcrBanks test

2024-03-19 Thread G Edhaya Chandran
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/bebabc28d9471de17b9dbebf83d4dfb54624ac0c


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




Re: [edk2-devel] [PATCH v2 4/6] uefi-sct/SctPkg: TCG2 Protocol: add HashLogExtendEvent test

2024-03-19 Thread G Edhaya Chandran
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/244ebf6954c43496ca173e9091de92b061e0957e


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




Re: [edk2-devel] [PATCH v2 5/6] uefi-sct/SctPkg: TCG2 Protocol: add GetEventLog test

2024-03-19 Thread G Edhaya Chandran
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/7ec35ffac51d0682c1368041ca1e599189a58223


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




Re: [edk2-devel] [PATCH v2 6/6] uefi-sct/SctPkg: TCG2 Protocol: add SubmitCommand test

2024-03-19 Thread G Edhaya Chandran
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/ee928b21d8df70c5729a6ae470366d3c6a6fd84b


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




Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib

2024-03-19 Thread Chao Li

He Gerd,


Thanks,
Chao
On 2024/3/19 16:03, Gerd Hoffmann wrote:

   Hi,


I can't tell the implementation scheme of the current lib and existing
lib implementation scheme which one is better, Could you give we some
advice?

I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
it is not really loongarch-specific.

If you want try switch aarch64 to use the same code that'll be great,
but sorting that out later is also fine with me.

If you think this design is looks better, then I'm prepare to commit this
change under the OvmfPkg/Library as a public library. And I will enable it
in aarch64 after merging this change, because I think it may be tweaked and
validated in aarch64 for many platforms. Do you think that is good?

The VirtNorFlashDxe is optimized for qemu-emulated pflash.  It tries to
avoid switching between read and write mode much, because that operation
has a significant overhead in virtualization.  So it's really only used
by ArmVirtPkg and not lots of other arm platforms.

Doing it separate from this patch series makes sense nevertheless.

Speaking of this series: maybe split it into two?  The first part
of this series with the Mde*Pkg + UefiPkg changes looks almost ready
to merge to me, so maybe we can get that in while still sorting out
the remaining issues in the OvmfPkg patches ...


This series does not include changes to Mde*Pkg , so if the patches are 
separated, I think it might be two series, one is the UefiCpuPkg series, 
and other is OvmfPkg. Just like you saied, if this series is split into 
two, and the series 1 finds some bugs when we sorting out the OvmfPkg, 
then we have to submit other pathes to fix them.


So what do you think? I think each plan has it's own benefits. I tend to 
split patches into two series.




take care,
   Gerd








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




[edk2-devel] [PATCH] REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4647

2024-03-19 Thread Nayana Patel
Clear out the variable SmmCommunicateVerifyPassword which contains password 
before goto Exit.
To avoid vulnerability.

Signed-off-by: Nayana Patel 
---
 .../UserAuthenticationDxeSmm/UserAuthenticationSmm.c| 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
index 98f40c1812..ba01d599e0 100644
--- 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
+++ 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
@@ -555,6 +555,7 @@ SmmPasswordHandler (
 if (PasswordLen == sizeof(SmmCommunicateVerifyPassword.Password)) {
   DEBUG ((DEBUG_ERROR, "SmmPasswordHandler: Password invalid!\n"));
   Status = EFI_INVALID_PARAMETER;
+  ZeroMem (, sizeof 
(SmmCommunicateVerifyPassword));
   goto EXIT;
 }
 if (!IsPasswordVerified (UserGuid, SmmCommunicateVerifyPassword.Password, 
PasswordLen + 1)) {
@@ -565,6 +566,7 @@ SmmPasswordHandler (
   } else {
 Status = EFI_SECURITY_VIOLATION;
   }
+  ZeroMem (, sizeof 
(SmmCommunicateVerifyPassword));
   goto EXIT;
 }
 mPasswordVerified = TRUE;
-- 
2.39.1.windows.1



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




[edk2-devel] [PATCH] REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4645

2024-03-19 Thread Nayana Patel
Clear out the variable SmmCommunicateSetPassword which contains password before 
goto Exit.
To avoid vulnerability.

Signed-off-by: Nayana Patel 
---
 .../UserAuthenticationDxeSmm/UserAuthenticationSmm.c| 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
index 98f40c1812..ba01d599e0 100644
--- 
a/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
+++ 
b/Features/Intel/UserInterface/UserAuthFeaturePkg/UserAuthenticationDxeSmm/UserAuthenticationSmm.c
@@ -555,6 +555,7 @@ SmmPasswordHandler (
 if (PasswordLen == sizeof(SmmCommunicateVerifyPassword.Password)) {
   DEBUG ((DEBUG_ERROR, "SmmPasswordHandler: Password invalid!\n"));
   Status = EFI_INVALID_PARAMETER;
+  ZeroMem (, sizeof 
(SmmCommunicateVerifyPassword));
   goto EXIT;
 }
 if (!IsPasswordVerified (UserGuid, SmmCommunicateVerifyPassword.Password, 
PasswordLen + 1)) {
@@ -565,6 +566,7 @@ SmmPasswordHandler (
   } else {
 Status = EFI_SECURITY_VIOLATION;
   }
+  ZeroMem (, sizeof 
(SmmCommunicateVerifyPassword));
   goto EXIT;
 }
 mPasswordVerified = TRUE;
-- 
2.39.1.windows.1



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




Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib

2024-03-19 Thread Gerd Hoffmann
  Hi,

> > > I can't tell the implementation scheme of the current lib and existing
> > > lib implementation scheme which one is better, Could you give we some
> > > advice?
> > I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
> > it is not really loongarch-specific.
> > 
> > If you want try switch aarch64 to use the same code that'll be great,
> > but sorting that out later is also fine with me.
> 
> If you think this design is looks better, then I'm prepare to commit this
> change under the OvmfPkg/Library as a public library. And I will enable it
> in aarch64 after merging this change, because I think it may be tweaked and
> validated in aarch64 for many platforms. Do you think that is good?

The VirtNorFlashDxe is optimized for qemu-emulated pflash.  It tries to
avoid switching between read and write mode much, because that operation
has a significant overhead in virtualization.  So it's really only used
by ArmVirtPkg and not lots of other arm platforms.

Doing it separate from this patch series makes sense nevertheless.

Speaking of this series: maybe split it into two?  The first part
of this series with the Mde*Pkg + UefiPkg changes looks almost ready
to merge to me, so maybe we can get that in while still sorting out
the remaining issues in the OvmfPkg patches ...

take care,
  Gerd



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




[edk2-devel] [PATCH] CryptoPkg: BaseCryptLib: ASN1_get_object() function return value is not checked properly in CryptX509.c.

2024-03-19 Thread Sountharya N via groups.io
Added Inf variable, and the error case returned value was checked properly.
---
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 1182323b63..ac05441383 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
@@ -839,17 +839,17 @@ X509GetTBSCert (
   Length = 0;

   Inf= ASN1_get_object (, (long *), (int *), (int 
*), (long)CertSize);



-  if (((Inf & 0x80) == 0x00) && (Asn1Tag != V_ASN1_SEQUENCE)) {

+  if (((Inf & 0x80) == 0x80) && (Asn1Tag != V_ASN1_SEQUENCE)) {

 return FALSE;

   }



   *TBSCert = (UINT8 *)Temp;



-  ASN1_get_object (, (long *), (int *), (int *), 
(long)Length);

+  Inf= ASN1_get_object (, (long *), (int *), (int 
*), (long)Length);

   //

   // Verify the parsed TBSCertificate is one correct SEQUENCE data.

   //

-  if (((Inf & 0x80) == 0x00) && (Asn1Tag != V_ASN1_SEQUENCE)) {

+  if (((Inf & 0x80) == 0x80) && (Asn1Tag != V_ASN1_SEQUENCE)) {

 return FALSE;

   }



--
2.35.1.windows.2
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


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