date:20231208

Re: [edk2-devel] [PATCH 4/4] ArmVirtPkg: Sync debug level comments in ArmVirt.dsc.inc

2023-12-08 Thread Ard Biesheuvel

On Sat, 9 Dec 2023 at 01:20, Rebecca Cran
 wrote:
>
> Update the debug level comments in ArmVirt.dsc.inc to sync with
> MdePkg/Include/Library/DebugLib.h.
>
> Signed-off-by: Rebecca Cran 

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 42 ++--
>  1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 6bc72f1decbd..9b23ef97ec5f 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -315,26 +315,28 @@ [PcdsFixedAtBuild.common]
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2f
>  !endif
>
> -  #  DEBUG_INIT  0x0001  // Initialization
> -  #  DEBUG_WARN  0x0002  // Warnings
> -  #  DEBUG_LOAD  0x0004  // Load events
> -  #  DEBUG_FS0x0008  // EFI File system
> -  #  DEBUG_POOL  0x0010  // Alloc & Free (pool)
> -  #  DEBUG_PAGE  0x0020  // Alloc & Free (page)
> -  #  DEBUG_INFO  0x0040  // Informational debug messages
> -  #  DEBUG_DISPATCH  0x0080  // PEI/DXE/SMM Dispatchers
> -  #  DEBUG_VARIABLE  0x0100  // Variable
> -  #  DEBUG_BM0x0400  // Boot Manager
> -  #  DEBUG_BLKIO 0x1000  // BlkIo Driver
> -  #  DEBUG_NET   0x4000  // SNP Driver
> -  #  DEBUG_UNDI  0x0001  // UNDI Driver
> -  #  DEBUG_LOADFILE  0x0002  // LoadFile
> -  #  DEBUG_EVENT 0x0008  // Event messages
> -  #  DEBUG_GCD   0x0010  // Global Coherency Database changes
> -  #  DEBUG_CACHE 0x0020  // Memory range cachability changes
> -  #  DEBUG_VERBOSE   0x0040  // Detailed debug messages that may
> -  #  // significantly impact boot performance
> -  #  DEBUG_ERROR 0x8000  // Error
> +  #  DEBUG_INIT   0x0001  // Initialization
> +  #  DEBUG_WARN   0x0002  // Warnings
> +  #  DEBUG_LOAD   0x0004  // Load events
> +  #  DEBUG_FS 0x0008  // EFI File system
> +  #  DEBUG_POOL   0x0010  // Alloc & Free (pool)
> +  #  DEBUG_PAGE   0x0020  // Alloc & Free (page)
> +  #  DEBUG_INFO   0x0040  // Informational debug messages
> +  #  DEBUG_DISPATCH   0x0080  // PEI/DXE/SMM Dispatchers
> +  #  DEBUG_VARIABLE   0x0100  // Variable
> +  #  DEBUG_BM 0x0400  // Boot Manager
> +  #  DEBUG_BLKIO  0x1000  // BlkIo Driver
> +  #  DEBUG_NET0x4000  // Network Io Driver
> +  #  DEBUG_UNDI   0x0001  // UNDI Driver
> +  #  DEBUG_LOADFILE   0x0002  // LoadFile
> +  #  DEBUG_EVENT  0x0008  // Event messages
> +  #  DEBUG_GCD0x0010  // Global Coherency Database changes
> +  #  DEBUG_CACHE  0x0020  // Memory range cachability changes
> +  #  DEBUG_VERBOSE0x0040  // Detailed debug messages that may
> +  #   // significantly impact boot 
> performance
> +  #  DEBUG_MANAGEABILITY  0x0080  // Detailed debug and payload 
> manageability messages
> +  #   // related to modules such as Redfish, 
> IPMI, MCTP etc.
> +  #  DEBUG_ERROR  0x8000  // Error
>  !if $(TARGET) != RELEASE
>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|$(DEBUG_PRINT_ERROR_LEVEL)
>  !endif
> --
> 2.34.1
>


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

Re: [edk2-devel] [PATCH v3] MdePkg: Add a new memory type definition

2023-12-08 Thread Michael D Kinney

Merged: https://github.com/tianocore/edk2/pull/5128


> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, December 8, 2023 12:23 PM
> To: Srinivasan, ManickamX ;
> devel@edk2.groups.io
> Cc: Gao, Liming ; Liu, Zhiguang
> ; T V, Krishnamoorthy
> ; Kinney, Michael D
> 
> Subject: RE: [PATCH v3] MdePkg: Add a new memory type definition
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Srinivasan, ManickamX 
> > Sent: Thursday, December 7, 2023 9:37 PM
> > To: devel@edk2.groups.io
> > Cc: Srinivasan, ManickamX ; Kinney,
> > Michael D ; Gao, Liming
> > ; Liu, Zhiguang ; T
> V,
> > Krishnamoorthy 
> > Subject: [PATCH v3] MdePkg: Add a new memory type definition
> >
> > New memory type as defined in UEFI standard v2.10
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: T V Krishnamoorthy 
> > Signed-off-by: ManickamX Srinivasan 
> > ---
> >  MdePkg/Include/Uefi/UefiSpec.h | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> > b/MdePkg/Include/Uefi/UefiSpec.h
> > index 7dfe35b499..d583ee17d0 100644
> > --- a/MdePkg/Include/Uefi/UefiSpec.h
> > +++ b/MdePkg/Include/Uefi/UefiSpec.h
> > @@ -110,6 +110,21 @@ typedef enum {
> >  //
> >  #define EFI_MEMORY_RUNTIME  0x8000ULL
> >
> > +//
> > +// If this flag is set, the memory region is
> > +// described with additional ISA-specific memory attributes
> > +// as specified in EFI_MEMORY_ISA_MASK.
> > +//
> > +#define EFI_MEMORY_ISA_VALID 0x4000ULL
> > +
> > +//
> > +// Defines the bits reserved for describing optional ISA-specific
> > cacheability
> > +// attributes that are not covered by the standard UEFI Memory
> > Attributes cacheability
> > +// bits (EFI_MEMORY_UC, EFI_MEMORY_WC, EFI_MEMORY_WT, EFI_MEMORY_WB
> and
> > EFI_MEMORY_UCE).
> > +// See Calling Conventions for further ISA-specific enumeration of
> > these bits.
> > +//
> > +#define EFI_MEMORY_ISA_MASK 0x0000ULL
> > +
> >  //
> >  // Attributes bitmasks, grouped by type
> >  //
> > --
> > 2.30.2.windows.1



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

Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg/StandaloneMmHobLib: Remove HOB creation

2023-12-08 Thread Ni, Ray

Nhi,
Thanks for the follow up!

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Nhi Pham 
> Sent: Tuesday, December 5, 2023 9:48 PM
> To: devel@edk2.groups.io
> Cc: Nhi Pham ; Ard Biesheuvel
> ; Ni, Ray ; Sami Mujawar
> ; Oliver Smith-Denny 
> Subject: [PATCH v1 1/1] StandaloneMmPkg/StandaloneMmHobLib: Remove
> HOB creation
> 
> According to the discussion in "StandaloneMmPkg: Fix HOB space and
> heap space conflicted issue" [1], Standalone MM modules should be HOB
> consumers where HOB is read-only. Therefore, this patch removes the
> supported functions for HOB creation in the StandaloneMmHobLib.
> 
> [1] https://edk2.groups.io/g/devel/message/108333
> 
> Cc: Ard Biesheuvel 
> Cc: Ray Ni 
> Cc: Sami Mujawar 
> Cc: Oliver Smith-Denny 
> Signed-off-by: Nhi Pham 
> ---
>  StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c |
> 171 ++--
>  1 file changed, 51 insertions(+), 120 deletions(-)
> 
> diff --git
> a/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> index ee61bdd227d0..bef66d167494 100644
> ---
> a/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> +++
> b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> @@ -1,5 +1,5 @@
>  /** @file
> 
> -  HOB Library implementation for Standalone MM Core.
> 
> +  HOB Library implementation for Standalone MM modules.
> 
> 
> 
>  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> 
>  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
> 
> @@ -250,48 +250,13 @@ GetBootModeHob (
>return HandOffHob->BootMode;
> 
>  }
> 
> 
> 
> -VOID *
> 
> -CreateHob (
> 
> -  IN  UINT16  HobType,
> 
> -  IN  UINT16  HobLength
> 
> -  )
> 
> -{
> 
> -  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHob;
> 
> -  EFI_HOB_GENERIC_HEADER  *HobEnd;
> 
> -  EFI_PHYSICAL_ADDRESSFreeMemory;
> 
> -  VOID*Hob;
> 
> -
> 
> -  HandOffHob = GetHobList ();
> 
> -
> 
> -  HobLength = (UINT16)((HobLength + 0x7) & (~0x7));
> 
> -
> 
> -  FreeMemory = HandOffHob->EfiFreeMemoryTop - HandOffHob-
> >EfiFreeMemoryBottom;
> 
> -
> 
> -  if (FreeMemory < HobLength) {
> 
> -return NULL;
> 
> -  }
> 
> -
> 
> -  Hob= (VOID 
> *)(UINTN)HandOffHob->EfiEndOfHobList;
> 
> -  ((EFI_HOB_GENERIC_HEADER *)Hob)->HobType   = HobType;
> 
> -  ((EFI_HOB_GENERIC_HEADER *)Hob)->HobLength = HobLength;
> 
> -  ((EFI_HOB_GENERIC_HEADER *)Hob)->Reserved  = 0;
> 
> -
> 
> -  HobEnd  = (EFI_HOB_GENERIC_HEADER *)((UINTN)Hob +
> HobLength);
> 
> -  HandOffHob->EfiEndOfHobList = (EFI_PHYSICAL_ADDRESS)(UINTN)HobEnd;
> 
> -
> 
> -  HobEnd->HobType   = EFI_HOB_TYPE_END_OF_HOB_LIST;
> 
> -  HobEnd->HobLength = sizeof (EFI_HOB_GENERIC_HEADER);
> 
> -  HobEnd->Reserved  = 0;
> 
> -  HobEnd++;
> 
> -  HandOffHob->EfiFreeMemoryBottom =
> (EFI_PHYSICAL_ADDRESS)(UINTN)HobEnd;
> 
> -
> 
> -  return Hob;
> 
> -}
> 
> -
> 
>  /**
> 
>Builds a HOB for a loaded PE32 module.
> 
> 
> 
>This function builds a HOB for a loaded PE32 module.
> 
> +  It can only be invoked by Standalone MM Core.
> 
> +  For Standalone MM drivers, it will ASSERT() since HOB is read only for
> Standalone MM drivers.
> 
> +
> 
>If ModuleName is NULL, then ASSERT().
> 
>If there is no additional space for HOB creation, then ASSERT().
> 
> 
> 
> @@ -310,33 +275,19 @@ BuildModuleHob (
>IN EFI_PHYSICAL_ADDRESS  EntryPoint
> 
>)
> 
>  {
> 
> -  EFI_HOB_MEMORY_ALLOCATION_MODULE  *Hob;
> 
> -
> 
> -  ASSERT (
> 
> -((MemoryAllocationModule & (EFI_PAGE_SIZE - 1)) == 0) &&
> 
> -((ModuleLength & (EFI_PAGE_SIZE - 1)) == 0)
> 
> -);
> 
> -
> 
> -  Hob = CreateHob (EFI_HOB_TYPE_MEMORY_ALLOCATION, sizeof
> (EFI_HOB_MEMORY_ALLOCATION_MODULE));
> 
> -
> 
> -  CopyGuid (&(Hob->MemoryAllocationHeader.Name),
> &gEfiHobMemoryAllocModuleGuid);
> 
> -  Hob->MemoryAllocationHeader.MemoryBaseAddress =
> MemoryAllocationModule;
> 
> -  Hob->MemoryAllocationHeader.MemoryLength  = ModuleLength;
> 
> -  Hob->MemoryAllocationHeader.MemoryType= EfiBootServicesCode;
> 
> -
> 
>//
> 
> -  // Zero the reserved space to match HOB spec
> 
> +  // HOB is read only for Standalone MM drivers
> 
>//
> 
> -  ZeroMem (Hob->MemoryAllocationHeader.Reserved, sizeof (Hob-
> >MemoryAllocationHeader.Reserved));
> 
> -
> 
> -  CopyGuid (&Hob->ModuleName, ModuleName);
> 
> -  Hob->EntryPoint = EntryPoint;
> 
> +  ASSERT (FALSE);
> 
>  }
> 
> 
> 
>  /**
> 
>Builds a HOB that describes a chunk of system memory.
> 
> 
> 
>This function builds a HOB that describes a chunk of system memory.
> 
> +  It can only be invoked by Standalone MM Core.
> 
> +  For Standalone MM drivers, it will ASSERT() since HOB is read only for
> Standalone MM drivers.
> 
> +
> 
>If there is no additional space for HOB creation, then ASSERT().
> 
> 
> 
>@param  ResourceTypeThe type of res

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

2023-12-08 Thread Michael D Kinney

Series Reviewed-by: Michael D Kinney 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Rebecca
> Cran via groups.io
> Sent: Friday, December 8, 2023 4:20 PM
> To: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ard
> Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Sami
> Mujawar ; Gerd Hoffmann 
> Cc: Rebecca Cran ; devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level
> comments
> 
> Add the new DEBUG_MANAGEABILITY debug level to MdePkg.dec and
> MdePkg.uni.
> 
> Improve the wording of the description of the DEBUG_MANAGEABILITY level
> in
> DebugLib.h.
> 
> Update the comment block in ArmVirtPkg.dsc.inc with the new list and
> updated
> formatting.
> 
> 
> Rebecca Cran (4):
>   MdePkg: Improve wording of manageability debug level comment
>   MdePkg: Add manageability debug level to PcdFixedDebugPrintErrorLevel
>   MdePkg: Update MdePkg.uni with manageability debug level
>   ArmVirtPkg: Sync debug level comments in ArmVirt.dsc.inc
> 
>  MdePkg/MdePkg.dec |  1 +
>  ArmVirtPkg/ArmVirt.dsc.inc| 42 ++--
>  MdePkg/Include/Library/DebugLib.h |  4 +-
>  MdePkg/MdePkg.uni |  2 +
>  4 files changed, 27 insertions(+), 22 deletions(-)
> 
> --
> 2.34.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

2023-12-08 Thread Rebecca Cran via groups.io


On 12/8/2023 5:19 PM, Rebecca Cran wrote:

Add the new DEBUG_MANAGEABILITY debug level to MdePkg.dec and MdePkg.uni.

Improve the wording of the description of the DEBUG_MANAGEABILITY level in
DebugLib.h.

Update the comment block in ArmVirtPkg.dsc.inc with the new list and updated
formatting.


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

--
Rebecca Cran


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

[edk2-devel] [PATCH 4/4] ArmVirtPkg: Sync debug level comments in ArmVirt.dsc.inc

2023-12-08 Thread Rebecca Cran via groups.io

Update the debug level comments in ArmVirt.dsc.inc to sync with
MdePkg/Include/Library/DebugLib.h.

Signed-off-by: Rebecca Cran 
---
 ArmVirtPkg/ArmVirt.dsc.inc | 42 ++--
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 6bc72f1decbd..9b23ef97ec5f 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -315,26 +315,28 @@ [PcdsFixedAtBuild.common]
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2f
 !endif
 
-  #  DEBUG_INIT  0x0001  // Initialization
-  #  DEBUG_WARN  0x0002  // Warnings
-  #  DEBUG_LOAD  0x0004  // Load events
-  #  DEBUG_FS0x0008  // EFI File system
-  #  DEBUG_POOL  0x0010  // Alloc & Free (pool)
-  #  DEBUG_PAGE  0x0020  // Alloc & Free (page)
-  #  DEBUG_INFO  0x0040  // Informational debug messages
-  #  DEBUG_DISPATCH  0x0080  // PEI/DXE/SMM Dispatchers
-  #  DEBUG_VARIABLE  0x0100  // Variable
-  #  DEBUG_BM0x0400  // Boot Manager
-  #  DEBUG_BLKIO 0x1000  // BlkIo Driver
-  #  DEBUG_NET   0x4000  // SNP Driver
-  #  DEBUG_UNDI  0x0001  // UNDI Driver
-  #  DEBUG_LOADFILE  0x0002  // LoadFile
-  #  DEBUG_EVENT 0x0008  // Event messages
-  #  DEBUG_GCD   0x0010  // Global Coherency Database changes
-  #  DEBUG_CACHE 0x0020  // Memory range cachability changes
-  #  DEBUG_VERBOSE   0x0040  // Detailed debug messages that may
-  #  // significantly impact boot performance
-  #  DEBUG_ERROR 0x8000  // Error
+  #  DEBUG_INIT   0x0001  // Initialization
+  #  DEBUG_WARN   0x0002  // Warnings
+  #  DEBUG_LOAD   0x0004  // Load events
+  #  DEBUG_FS 0x0008  // EFI File system
+  #  DEBUG_POOL   0x0010  // Alloc & Free (pool)
+  #  DEBUG_PAGE   0x0020  // Alloc & Free (page)
+  #  DEBUG_INFO   0x0040  // Informational debug messages
+  #  DEBUG_DISPATCH   0x0080  // PEI/DXE/SMM Dispatchers
+  #  DEBUG_VARIABLE   0x0100  // Variable
+  #  DEBUG_BM 0x0400  // Boot Manager
+  #  DEBUG_BLKIO  0x1000  // BlkIo Driver
+  #  DEBUG_NET0x4000  // Network Io Driver
+  #  DEBUG_UNDI   0x0001  // UNDI Driver
+  #  DEBUG_LOADFILE   0x0002  // LoadFile
+  #  DEBUG_EVENT  0x0008  // Event messages
+  #  DEBUG_GCD0x0010  // Global Coherency Database changes
+  #  DEBUG_CACHE  0x0020  // Memory range cachability changes
+  #  DEBUG_VERBOSE0x0040  // Detailed debug messages that may
+  #   // significantly impact boot performance
+  #  DEBUG_MANAGEABILITY  0x0080  // Detailed debug and payload 
manageability messages
+  #   // related to modules such as Redfish, 
IPMI, MCTP etc.
+  #  DEBUG_ERROR  0x8000  // Error
 !if $(TARGET) != RELEASE
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|$(DEBUG_PRINT_ERROR_LEVEL)
 !endif
-- 
2.34.1



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

[edk2-devel] [PATCH 2/4] MdePkg: Add manageability debug level to PcdFixedDebugPrintErrorLevel

2023-12-08 Thread Rebecca Cran via groups.io

Update MdePkg.dec to add the manageability debug level to
PcdFixedDebugPrintErrorLevel.

Signed-off-by: Rebecca Cran 
---
 MdePkg/MdePkg.dec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index ac54338089e8..bec63f5416e2 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2213,6 +2213,7 @@ [PcdsFixedAtBuild]
   #  BIT20 - Global Coherency Database changes message.
   #  BIT21 - Memory range cachability changes message.
   #  BIT22 - Detailed debug message.
+  #  BIT23 - Manageability debug message.
   #  BIT31 - Error message.
   # @Prompt Fixed Debug Message Print Level.
   
gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x|UINT32|0x30001016
-- 
2.34.1



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

[edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

2023-12-08 Thread Rebecca Cran via groups.io

Add the new DEBUG_MANAGEABILITY debug level to MdePkg.dec and MdePkg.uni.

Improve the wording of the description of the DEBUG_MANAGEABILITY level in
DebugLib.h.

Update the comment block in ArmVirtPkg.dsc.inc with the new list and updated
formatting.


Rebecca Cran (4):
  MdePkg: Improve wording of manageability debug level comment
  MdePkg: Add manageability debug level to PcdFixedDebugPrintErrorLevel
  MdePkg: Update MdePkg.uni with manageability debug level
  ArmVirtPkg: Sync debug level comments in ArmVirt.dsc.inc

 MdePkg/MdePkg.dec |  1 +
 ArmVirtPkg/ArmVirt.dsc.inc| 42 ++--
 MdePkg/Include/Library/DebugLib.h |  4 +-
 MdePkg/MdePkg.uni |  2 +
 4 files changed, 27 insertions(+), 22 deletions(-)

-- 
2.34.1



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

[edk2-devel] [PATCH 3/4] MdePkg: Update MdePkg.uni with manageability debug level

2023-12-08 Thread Rebecca Cran via groups.io

Update MdePkg.uni with the manageability debug level.

Signed-off-by: Rebecca Cran 
---
 MdePkg/MdePkg.uni | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/MdePkg.uni b/MdePkg/MdePkg.uni
index 5c1fa24065c7..75dbc6ffe3c0 100644
--- a/MdePkg/MdePkg.uni
+++ b/MdePkg/MdePkg.uni
@@ -214,6 +214,7 @@

"BIT20 - Global Coherency Database changes message.\n"

"BIT21 - Memory range cacheability changes message.\n"

"BIT22 - Detailed debug message.\n"
+   
"BIT23 - Manageability debug message.\n"

"BIT31 - Error message."
 
 #string STR_gEfiMdePkgTokenSpaceGuid_PcdFixedDebugPrintErrorLevel_PROMPT  
#language en-US "Fixed Debug Message Print Level"
@@ -237,6 +238,7 @@

"BIT20 - Global Coherency Database changes message.\n"

"BIT21 - Memory range cacheability changes message.\n"

"BIT22 - Detailed debug message.\n"
+   
"BIT23 - Manageability debug message.\n"

"BIT31 - Error message."
 
 #string STR_gEfiMdePkgTokenSpaceGuid_PcdReportStatusCodePropertyMask_PROMPT  
#language en-US "Report Status Code Property"
-- 
2.34.1



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

[edk2-devel] [PATCH 1/4] MdePkg: Improve wording of manageability debug level comment

2023-12-08 Thread Rebecca Cran via groups.io

Improve the wording of the comment explaining the DEBUG_MANAGEABILITY
debug level.

Signed-off-by: Rebecca Cran 
---
 MdePkg/Include/Library/DebugLib.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Library/DebugLib.h 
b/MdePkg/Include/Library/DebugLib.h
index f0c9f6448794..40772f2e0f7b 100644
--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -48,8 +48,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #define DEBUG_CACHE 0x0020   // Memory range cachability changes
 #define DEBUG_VERBOSE   0x0040   // Detailed debug messages that may
  // significantly impact boot 
performance
-#define DEBUG_MANAGEABILITY  0x0080  // Detailed debug and payload message 
of manageability
- // related modules, such Redfish, 
IPMI, MCTP and etc.
+#define DEBUG_MANAGEABILITY  0x0080  // Detailed debug and payload 
manageability messages
+ // related to modules such as 
Redfish, IPMI, MCTP etc.
 #define DEBUG_ERROR  0x8000  // Error
 
 //
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112241): https://edk2.groups.io/g/devel/message/112241
Mute This Topic: https://groups.io/mt/103066382/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] MdePkg: Define the DevicePath argument from LoadImage as optional

2023-12-08 Thread Michael D Kinney

Merged: https://github.com/tianocore/edk2/pull/5129


> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, December 8, 2023 12:24 PM
> To: Srinivasan, ManickamX ;
> devel@edk2.groups.io
> Cc: Gao, Liming ; Liu, Zhiguang
> ; T V, Krishnamoorthy
> ; Kinney, Michael D
> 
> Subject: RE: [PATCH v2] MdePkg: Define the DevicePath argument from
> LoadImage as optional
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Srinivasan, ManickamX 
> > Sent: Thursday, December 7, 2023 9:41 PM
> > To: devel@edk2.groups.io
> > Cc: Srinivasan, ManickamX ; Kinney,
> > Michael D ; Gao, Liming
> > ; Liu, Zhiguang ; T
> V,
> > Krishnamoorthy 
> > Subject: [PATCH v2] MdePkg: Define the DevicePath argument from
> > LoadImage as optional
> >
> > Update the EFI LoadImage API in accordance with the
> > UEFI v2.10 specification.
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: T V Krishnamoorthy 
> > Signed-off-by: ManickamX Srinivasan 
> > ---
> >  MdePkg/Include/Uefi/UefiSpec.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> > b/MdePkg/Include/Uefi/UefiSpec.h
> > index 7dfe35b499..e83e14d347 100644
> > --- a/MdePkg/Include/Uefi/UefiSpec.h
> > +++ b/MdePkg/Include/Uefi/UefiSpec.h
> > @@ -898,7 +898,7 @@ EFI_STATUS
> >  (EFIAPI *EFI_IMAGE_LOAD)(
> >IN  BOOLEAN  BootPolicy,
> >IN  EFI_HANDLE   ParentImageHandle,
> > -  IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath,
> > +  IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath   OPTIONAL,
> >IN  VOID *SourceBuffer OPTIONAL,
> >IN  UINTNSourceSize,
> >OUT EFI_HANDLE   *ImageHandle
> > --
> > 2.30.2.windows.1



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

Re: [edk2-devel] [PATCH v2] MdePkg: Define the DevicePath argument from LoadImage as optional

2023-12-08 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Srinivasan, ManickamX 
> Sent: Thursday, December 7, 2023 9:41 PM
> To: devel@edk2.groups.io
> Cc: Srinivasan, ManickamX ; Kinney,
> Michael D ; Gao, Liming
> ; Liu, Zhiguang ; T V,
> Krishnamoorthy 
> Subject: [PATCH v2] MdePkg: Define the DevicePath argument from
> LoadImage as optional
> 
> Update the EFI LoadImage API in accordance with the
> UEFI v2.10 specification.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: T V Krishnamoorthy 
> Signed-off-by: ManickamX Srinivasan 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h
> index 7dfe35b499..e83e14d347 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -898,7 +898,7 @@ EFI_STATUS
>  (EFIAPI *EFI_IMAGE_LOAD)(
>IN  BOOLEAN  BootPolicy,
>IN  EFI_HANDLE   ParentImageHandle,
> -  IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath,
> +  IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath   OPTIONAL,
>IN  VOID *SourceBuffer OPTIONAL,
>IN  UINTNSourceSize,
>OUT EFI_HANDLE   *ImageHandle
> --
> 2.30.2.windows.1



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

Re: [edk2-devel] [PATCH v3] MdePkg: Add a new memory type definition

2023-12-08 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Srinivasan, ManickamX 
> Sent: Thursday, December 7, 2023 9:37 PM
> To: devel@edk2.groups.io
> Cc: Srinivasan, ManickamX ; Kinney,
> Michael D ; Gao, Liming
> ; Liu, Zhiguang ; T V,
> Krishnamoorthy 
> Subject: [PATCH v3] MdePkg: Add a new memory type definition
> 
> New memory type as defined in UEFI standard v2.10
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: T V Krishnamoorthy 
> Signed-off-by: ManickamX Srinivasan 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h
> index 7dfe35b499..d583ee17d0 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -110,6 +110,21 @@ typedef enum {
>  //
>  #define EFI_MEMORY_RUNTIME  0x8000ULL
> 
> +//
> +// If this flag is set, the memory region is
> +// described with additional ISA-specific memory attributes
> +// as specified in EFI_MEMORY_ISA_MASK.
> +//
> +#define EFI_MEMORY_ISA_VALID 0x4000ULL
> +
> +//
> +// Defines the bits reserved for describing optional ISA-specific
> cacheability
> +// attributes that are not covered by the standard UEFI Memory
> Attributes cacheability
> +// bits (EFI_MEMORY_UC, EFI_MEMORY_WC, EFI_MEMORY_WT, EFI_MEMORY_WB and
> EFI_MEMORY_UCE).
> +// See Calling Conventions for further ISA-specific enumeration of
> these bits.
> +//
> +#define EFI_MEMORY_ISA_MASK 0x0000ULL
> +
>  //
>  // Attributes bitmasks, grouped by type
>  //
> --
> 2.30.2.windows.1



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

Re: [edk2-devel] [edk2-platforms PATCH 1/1] Silicon/Marvell/OdysseyPkg: New Marvell Odyssey processor

2023-12-08 Thread Marcin Wojtas via groups.io

Hi Narinder,


czw., 30 lis 2023 o 16:14 Narinder Dhillon  napisał(a):
>
> From: Narinder Dhillon 
>
> This patch adds support for Marvell Odyssey processor.
>
> It contains only the very basic elements needed to boot to EDK2 UiApp.
> - ARM BL31 firmware component copies EDK2 image into memory, so it is
>   always executing from memory
> - There is a SMC library to get system information from BL31
> - There are drivers to get board configuration details from a device
>   tree
> - There is no on-chip RTC, a dummy driver is used
> - Emulated variable storage is used for now
>
> Signed-off-by: Narinder Dhillon 
> ---
>  Platform/Marvell/OdysseyPkg/OdysseyPkg.dsc| 216 ++
>  Platform/Marvell/OdysseyPkg/OdysseyPkg.fdf| 304 +
>  .../Drivers/Fdt/FdtClientDxe/FdtClientDxe.c   | 382 
>  .../Drivers/Fdt/FdtClientDxe/FdtClientDxe.inf |  43 ++
>  .../Drivers/Fdt/FdtPlatformDxe/FdtPlatform.c  | 361 
>  .../Drivers/Fdt/FdtPlatformDxe/FdtPlatform.h  | 102 +
>  .../Fdt/FdtPlatformDxe/FdtPlatformDxe.inf |  60 +++
>  .../Fdt/FdtPlatformDxe/FdtPlatformDxe.uni | 106 +
>  .../Drivers/Fdt/FdtPlatformDxe/README.txt |  69 +++
>  .../Drivers/Fdt/FdtPlatformDxe/ShellDumpFdt.c | 283 
>  .../Marvell/Drivers/Null/RtcNull/RtcNullDxe.c | 281 
>  .../Marvell/Drivers/Null/RtcNull/RtcNullDxe.h |  41 ++
>  .../Drivers/Null/RtcNull/RtcNullDxe.inf   |  46 ++
>  .../Drivers/Wdt/GtiWatchdogDxe/GtiWatchdog.c  | 408 ++
>  .../Wdt/GtiWatchdogDxe/GtiWatchdogDxe.inf |  45 ++
>  .../AArch64/ArmPlatformHelper.S   |  86 
>  .../Library/ArmPlatformLib/ArmPlatformLib.c   |  79 
>  .../Library/ArmPlatformLib/ArmPlatformLib.inf |  55 +++
>  .../ArmPlatformLib/ArmPlatformLibMem.c| 131 ++
>  Silicon/Marvell/Library/SmcLib/SmcLib.c   | 189 
>  Silicon/Marvell/Library/SmcLib/SmcLib.inf |  32 ++
>  .../Include/Library/SmcLib.h  |  71 +++
>  .../Include/Protocol/FdtClient.h  | 180 
>  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   |  19 +
>  Silicon/Marvell/OdysseyPkg/OdysseyPkg.dsc.inc | 394 +
>  .../PrePi/AArch64/ModuleEntryPoint.S  | 136 ++
>  .../ArmPlatformPkg/PrePi/PeiMPCore.inf| 110 +
>  .../Override/ArmPlatformPkg/PrePi/PrePi.c | 238 ++

To ease the review, can you please split this huge commit into several
patches, e.g.:
1. Add FdtPlatfromDxe
2. Add RtcNull
3. Add Wdt
4-6. Add libraries + headers
7. Add ArmPlatformPkg
8. Add OdysseyPkg.dsc.inc
9, Add Platform/Marvell/OdysseyPkg (in the latter you may also add
some README file, see other Marvell/SolidRun platforms for reference)

Thanks,
Marcin


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112237): https://edk2.groups.io/g/devel/message/112237
Mute This Topic: https://groups.io/mt/102895289/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 14/17] Silicon/Marvell/Armada7k8k: Add ImagePropertiesRecordLib Instance

2023-12-08 Thread Marcin Wojtas via groups.io

pt., 1 gru 2023 o 01:34 Taylor Beebe  napisał(a):
>
> ImagePropertiesRecordLib is used by DxeMain and PiSmmCore, so it
> needs to be added to most platforms.
>
> Signed-off-by: Taylor Beebe 
> Cc: Marcin Wojtas 
> Cc: Leif Lindholm 
> ---
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index 9711a8d6a707..ab719f360eda 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -71,6 +71,7 @@
>UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
>
> VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
>
> VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
> +  
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>

Reviewed-by: Marcin Wojtas 

Thanks,
Marcin


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112236): https://edk2.groups.io/g/devel/message/112236
Mute This Topic: https://groups.io/mt/102906519/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] ArmVirt: Allow memory attributes protocol to be disabled on first boot

2023-12-08 Thread Ard Biesheuvel

Thanks for the review.

On Fri, 8 Dec 2023 at 15:34, Laszlo Ersek  wrote:
>
> On 12/7/23 11:06, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel 
> >
> > Shim's PE loader uses the EFI memory attributes protocol in a way that
> > results in an immediate crash when invoking the loaded image, unless the
> > base and size of its executable segment are both aligned to 4k.
> >
> > If this is not the case, it will strip the memory allocation of its
> > executable permissions, but fail to add them back for the executable
> > region, resulting in non-executable code. Unfortunately, the PE loader
> > does not even bother invoking the protocol in this case (as it notices
> > the misalignment), making it very hard for system firmware to work
> > around this by attempting to infer the intent of the caller.
> >
> > So let's introduce a QEMU command line option to indicate that the
> > protocol should not be exposed at all on the first boot, which is when
> > the issue is triggered. (fbaa64.efi is broken but grubaa64.efi boots
> > fine)
> >
> >   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocolOnFirstBoot,string=y
> >
> > Also introduce a fixed boolean PCD that sets the default.
> >
> > Cc: Laszlo Ersek 
> > Cc: Gerd Hoffmann 
> > Cc: Oliver Steffen 
> > Cc: Alexander Graf 
> > Cc: Oliver Smith-Denny 
> > Cc: Taylor Beebe 
> > Cc: Peter Jones 
> > Cc: Leif Lindholm 
> > Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  ArmVirtPkg/ArmVirtPkg.dec|  6 
> > ++
> >  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  7 
> > ++
> >  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 85 
> > 
> >  3 files changed, 98 insertions(+)
> >
> > diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> > index 0f2d7873279f..c55978f75c19 100644
> > --- a/ArmVirtPkg/ArmVirtPkg.dec
> > +++ b/ArmVirtPkg/ArmVirtPkg.dec
> > @@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
> ># Cloud Hypervisor has no other way to pass Rsdp address to the guest 
> > except use a PCD.
> >
> >#
> >
> >
> > gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
> >
> > +
> >
> > +  ##
> >
> > +  # Whether the EFI memory attribus protocol should be uninstalled before
> >
> > +  # invoking the OS loader on the first boot. This may be needed to work 
> > around
> >
> > +  # problematic builds of shim that use the protocol incorrectly.
> >
> > +  
> > gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot|FALSE|BOOLEAN|0x0006
> >
>
> (1) could be a feature PCD (although it couldn't be patchable-in-module
> then, and perhaps we don't consider this a "feature")
>

Is this a general remark on the similarity between feature PCDs and
boolean PCDs?

> (2) typo: "attribus"
>

Ack

> (3) for some reason, I see double line breaks.
>

Yeah :-(

I am struggling with the internal Google 'sendgmr' mailer which
switches to QP transfer encoding for some reason. (I lost the hosting
venue for my ThunderX2 workstation so I am now relying on Google
infrastructure to host my development system). I am working on this,

> > diff --git 
> > a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> > b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > index 997eb1a4429f..5d119af6a3b3 100644
> > --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > @@ -16,6 +16,7 @@ [Defines]
> >MODULE_TYPE= DXE_DRIVER
> >
> >VERSION_STRING = 1.0
> >
> >LIBRARY_CLASS  = PlatformBootManagerLib|DXE_DRIVER
> >
> > +  CONSTRUCTOR= PlatformBootManagerLibConstructor
> >
> >
> >
> >  #
> >
> >  # The following information is for reference only and not required by the 
> > build tools.
> >
> > @@ -46,6 +47,7 @@ [LibraryClasses]
> >PcdLib
> >
> >PlatformBmPrintScLib
> >
> >QemuBootOrderLib
> >
> > +  QemuFwCfgSimpleParserLib
> >
> >QemuLoadImageLib
> >
> >ReportStatusCodeLib
> >
> >TpmPlatformHierarchyLib
> >
> > @@ -55,6 +57,7 @@ [LibraryClasses]
> >UefiRuntimeServicesTableLib
> >
> >
> >
> >  [FixedPcd]
> >
> > +  gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot
> >
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
> >
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
> >
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
> >
> > @@ -73,5 +76,9 @@ [Guids]
> >  [Protocols]
> >
> >gEfiFirmwareVolume2ProtocolGuid
> >
> >gEfiGraphicsOutputProtocolGuid
> >
> > +  gEfiMemoryAttributeProtocolGuid
> >
> >gEfiPciRootBridgeIoProtocolGuid
> >
> >gVirtioDeviceProtocolGuid
> >
> > +
> >
> > +[Depex]
> >
> > +  gEfiVariableArchProtocolGuid
> >
>
> I've made an effort to read through the v1 discussion (exhausting). So

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

2023-12-08 Thread Laszlo Ersek

On 12/8/23 15:34, Laszlo Ersek wrote:

> (7) Tying back to my point (4) -- I understand this is a hack anyway,
> but I'm still uncomfortable with platform BDS uninstalling a protocol
> that is owned by / provided by the CPU driver. Feels like a significant
> layering violation.
> 
> Can we modify the CPU driver instead, to listen to a new event group,
> upon which being signaled, the CPU driver would uninstall the protocol
> (and close the listening event)?
> 
> This PlatformBootManagerLib instance would act more or less the same
> (I'd suggest signaling the event group from within AfterConsole, in case
> the PCD default and/or the fw_cfg knob dictated that), but the protocol
> uninstallation would occur in "ArmPkg/Drivers/CpuDxe".
> 
> In more technical terms, the layering violation IMO is that we mess with
> CpuDxe's "mCpuHandle" and "mMemoryAttribute" static variables from
> within BDS. Adding the new event group requires more boiler-plate code
> for sure, but there's a small code-size benefit as well: we'd not have
> to look up either the handle (with LocateHandle) or the protocol
> interface (with HandleProtocol), as CpuDxe inherently knows those
> (mCpuHandle, mMemoryAttribute).

Or maybe avoid modifying PlatformBootManagerLib completely; instead,
move the logic into CpuDxe, into a ready-to-boot event handler?

At that time, variable services should be available to CpuDxe as well
(for the BootOrder UEFI var check).

Laszlo



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

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

2023-12-08 Thread Laszlo Ersek

On 12/7/23 11:06, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> Shim's PE loader uses the EFI memory attributes protocol in a way that
> results in an immediate crash when invoking the loaded image, unless the
> base and size of its executable segment are both aligned to 4k.
> 
> If this is not the case, it will strip the memory allocation of its
> executable permissions, but fail to add them back for the executable
> region, resulting in non-executable code. Unfortunately, the PE loader
> does not even bother invoking the protocol in this case (as it notices
> the misalignment), making it very hard for system firmware to work
> around this by attempting to infer the intent of the caller.
> 
> So let's introduce a QEMU command line option to indicate that the
> protocol should not be exposed at all on the first boot, which is when
> the issue is triggered. (fbaa64.efi is broken but grubaa64.efi boots
> fine)
> 
>   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocolOnFirstBoot,string=y
> 
> Also introduce a fixed boolean PCD that sets the default.
> 
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Alexander Graf 
> Cc: Oliver Smith-Denny 
> Cc: Taylor Beebe 
> Cc: Peter Jones 
> Cc: Leif Lindholm 
> Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtPkg.dec|  6 ++
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  7 ++
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 85 
> 
>  3 files changed, 98 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index 0f2d7873279f..c55978f75c19 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
># Cloud Hypervisor has no other way to pass Rsdp address to the guest 
> except use a PCD.
> 
>#
> 
>gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
> 
> +
> 
> +  ##
> 
> +  # Whether the EFI memory attribus protocol should be uninstalled before
> 
> +  # invoking the OS loader on the first boot. This may be needed to work 
> around
> 
> +  # problematic builds of shim that use the protocol incorrectly.
> 
> +  
> gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot|FALSE|BOOLEAN|0x0006
> 

(1) could be a feature PCD (although it couldn't be patchable-in-module
then, and perhaps we don't consider this a "feature")

(2) typo: "attribus"

(3) for some reason, I see double line breaks.

> diff --git 
> a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 997eb1a4429f..5d119af6a3b3 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -16,6 +16,7 @@ [Defines]
>MODULE_TYPE= DXE_DRIVER
> 
>VERSION_STRING = 1.0
> 
>LIBRARY_CLASS  = PlatformBootManagerLib|DXE_DRIVER
> 
> +  CONSTRUCTOR= PlatformBootManagerLibConstructor
> 
>  
> 
>  #
> 
>  # The following information is for reference only and not required by the 
> build tools.
> 
> @@ -46,6 +47,7 @@ [LibraryClasses]
>PcdLib
> 
>PlatformBmPrintScLib
> 
>QemuBootOrderLib
> 
> +  QemuFwCfgSimpleParserLib
> 
>QemuLoadImageLib
> 
>ReportStatusCodeLib
> 
>TpmPlatformHierarchyLib
> 
> @@ -55,6 +57,7 @@ [LibraryClasses]
>UefiRuntimeServicesTableLib
> 
>  
> 
>  [FixedPcd]
> 
> +  gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot
> 
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
> 
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
> 
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
> 
> @@ -73,5 +76,9 @@ [Guids]
>  [Protocols]
> 
>gEfiFirmwareVolume2ProtocolGuid
> 
>gEfiGraphicsOutputProtocolGuid
> 
> +  gEfiMemoryAttributeProtocolGuid
> 
>gEfiPciRootBridgeIoProtocolGuid
> 
>gVirtioDeviceProtocolGuid
> 
> +
> 
> +[Depex]
> 
> +  gEfiVariableArchProtocolGuid
> 

I've made an effort to read through the v1 discussion (exhausting). Some
quetions remain:

(4) Why the change from an explicit call from AfterConsole to a
constructor? Was AfterConsole too late somehow?

I think constructors should be the last resort.

(5) Is the depex really necessary? BDS is supposed to start when all
drivers have been dispatched, and so by that time, all of the UEFI
architectural protocols should be available. (BDS will launch UEFI
drivers, and all the UEFI drivers have an implicit depex on all the
architectural protocols.)

> diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 85c01351b09d..5306d9ea0a05 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerL

Re: [edk2-devel] [PATCH] Maintainers.txt: add Aaron Young as MptScsi and PvScsi reviewer

2023-12-08 Thread Laszlo Ersek

On 11/21/23 17:14, Aaron Young via groups.io wrote:
> Thanks Laszlo. Yes, ajyoung-oracle is my github user ID.
> 
> Reviewed-by: Aaron Young 

Merged as commit 2cd9d5f6fa71, via
.

Laszlo



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

Re: [edk2-devel] [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, Ovmf, UefiCpu Pkg "M"

2023-12-08 Thread Laszlo Ersek

On 11/16/23 22:50, Laszlo Ersek wrote:
> I'm offering to restore a subset of my earlier ArmVirtPkg and OvmfPkg
> maintainer responsibilities.
> 
> I'm both offering and requesting an escalation of my earlier UefiCpuPkg
> role.
> 
> The commit messages contain lists of files and directories that I intend
> to assist with.
> 
> Under ArmVirtPkg, my focus is the ArmVirtQemu platform.
> 
> Under OvmfPkg and UefiCpuPkg, my focus is the traditional three OVMF
> platforms (IA32, IA32X64, X64) and their dependencies; in particular I
> refrain from Confidential Computing technologies. Under OvmfPkg, I may
> also not be the primary reviewer of those nontrivial device drivers and
> libraries that I neither wrote nor reviewed.
> 
> Finally, I'm interested in reviewing patches for most of the edk2 core,
> and patches for the RISC-V architecture; but it's too early to formalize
> those interests even as some "R" lines.
> 
> Cc: Andrew Fish 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Cc: Sami Mujawar 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (3):
>   Maintainers.txt: add Laszlo Ersek as an ArmVirtPkg maintainer
>   Maintainers.txt: add Laszlo Ersek as an OvmfPkg maintainer
>   Maintainers.txt: add Laszlo Ersek as a UefiCpuPkg maintainer
> 
>  Maintainers.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> 
> base-commit: 3db76e6476e493d3cda45b81bba99a645180cf35

Merged as commit range e8c23d1e27f7..ff22700fc0e7, via
.

Laszlo



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

Re: [edk2-devel] [PATCH v2] OvmfPkg/MemEncryptSevLib: Fix address overflow during PVALIDATE

2023-12-08 Thread Laszlo Ersek

On 11/16/23 10:01, Gerd Hoffmann wrote:
> On Wed, Nov 15, 2023 at 11:51:53AM -0600, Michael Roth wrote:
>> The struct used for GHCB-based page-state change requests uses a 40-bit
>> bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
>> 64-bit address. However, anything beyond 40-bits simply gets shifted off
>> when doing this, which will cause issues when dealing with 1TB+
>> addresses. Fix this by casting the 40-bit GFN values to 64-bit ones
>> prior to shifting it by PAGE_SHIFT.
>>
>> Fixes: ade62c18f474 ("OvmfPkg/MemEncryptSevLib: add support to validate 
>> system RAM")
>> Signed-off-by: Michael Roth 
> 
> Reviewed-by: Gerd Hoffmann 

Merged as commit e8c23d1e27f70dcb2e59010ded6df32374eaa84a, via
.

Laszlo



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

Re: [edk2-devel] [PATCH v2 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

2023-12-08 Thread Laszlo Ersek

On 11/20/23 13:42, Wu, Jiaxin wrote:
> For core id in cpu features library, I agree it should be not easy or
> simple change to 0x1f.
> 
>  
> 
> But in SMM CPU, there is no usage case depends on the number of cores
> retrieved from cupid 0x0b return value, only PackageId will be used. So,
> this patch doesn’t do bad things, should no regression issue. I agree
> with Ray’s explanation that  “CPUID.0B.PackageId == CPUID.1F.PackageId”,
> thus no need update for the PackageId update.
> 
>  
> 
> I checked the latest SDM:
> 
>  
> 
> “The sub-leaves of CPUID leaf 0BH describe an ordered hierarchy of
> logical processors starting from the smallest-scoped domain of a Logical
> Processor (sub-leaf index 0) to the Core domain (sub-leaf index 1) to
> the largest-scoped domain (the last valid sub-leaf index) **that is
> implicitly subordinate to the unenumerated highest-scoped domain of the
> processor package (socket)**”
> 
>  
> 
> Looks it already updated to indicate the largest-scoped domain is package.
> 
>  
> 
> With all above, I agree to drop this path, but other 2 patches in this
> set should be ok. Thanks Ray help clarify this.

Merged the first two patches in the series as commits
ad0b1cc144b56fcbd8d369eaff6eaf5f3020efe7 and
7eb504060787c9c37d5b3c33f5d65021d553ea3f, via
.

Laszlo



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

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: Fix typos

2023-12-08 Thread Laszlo Ersek

On 11/13/23 02:01, Gao, Zhichao wrote:
> Reviewed-by: Zhichao Gao 
> 
> Thanks,
> Zhichao

merged as commit fe2abc9b74b9b869e29f0ebc6dfaa54001b53e9b via




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

Re: [edk2-devel] [PATCH v2] OvmfPkg/MemEncryptSevLib: Fix address overflow during PVALIDATE

2023-12-08 Thread Laszlo Ersek

On 11/20/23 08:55, Gerd Hoffmann wrote:
> On Fri, Nov 17, 2023 at 10:39:13PM +0100, Laszlo Ersek wrote:
>> On 11/17/23 12:42, Gerd Hoffmann wrote:
>>> On Fri, Nov 17, 2023 at 10:16:10AM +0100, Laszlo Ersek wrote:
 (+Liming +Mike)

 On 11/16/23 10:01, Gerd Hoffmann wrote:
> On Wed, Nov 15, 2023 at 11:51:53AM -0600, Michael Roth wrote:
>> The struct used for GHCB-based page-state change requests uses a 40-bit
>> bit-field for the GFN, which is shifted by PAGE_SHIFT to generate a
>> 64-bit address. However, anything beyond 40-bits simply gets shifted off
>> when doing this, which will cause issues when dealing with 1TB+
>> addresses. Fix this by casting the 40-bit GFN values to 64-bit ones
>> prior to shifting it by PAGE_SHIFT.
>>
>> Fixes: ade62c18f474 ("OvmfPkg/MemEncryptSevLib: add support to validate 
>> system RAM")
>> Signed-off-by: Michael Roth 
>
> Reviewed-by: Gerd Hoffmann 
>
> take care,
>   Gerd

 Is this hard feature freeze material?
>>>
>>> It is a clear bugfix, so IMHO it qualifies.
>>>
 Also, the patch looks garbled to me on-list (superfluous line breaks).
>>>
>>> Patch applies fine here.  I see mutt breaking the long line, but
>>> that is just the local display rendering, the mail good.
>>
>> Can you check the raw message? I did that and it seems broken.
>> Superfluous newlines. I see *double* CRLFs.
> 
> Hmm, everything looks fine here, and 'git am' accepts the mail without
> problems.  Pushed a branch:
> 
> https://github.com/kraxel/edk2/commits/b4/v2-20231115-michael-roth-ovmfpkg-memencryptsevlib-fix-address-overflow-during-pvalidate

This branch contains whitespace damage. The new lines coming from the
patch are terminated with LF, not CRLF.

(Doesn't matter much, just wanted to clarify that mutt wasn't doing the
right thing on your end. The patch, as posted, does contain multiple
CRLFs, and while mutt seems to mitigate that for you, it overshoots.

Anyway, I'm picking this up now; I've cleaned up the double CRLFs manually.)

Laszlo



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

Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

2023-12-08 Thread Gerd Hoffmann

On Thu, Dec 07, 2023 at 05:16:10PM +0100, Ard Biesheuvel wrote:
> Hi Gerd,
> 
> On Thu, 7 Dec 2023 at 10:44, Gerd Hoffmann  wrote:
> >
> > Extend the ValidateFvHeader function, additionally to the header checks
> > walk over the list of variables and sanity check them.
> >
> > In case we find inconsistencies indicating variable store corruption
> > return EFI_NOT_FOUND so the variable store will be re-initialized.
> >
> > Signed-off-by: Gerd Hoffmann 
> 
> This seems like a good idea to me, and the change looks generally
> fine, except for one nit below:

> > +  case VAR_HEADER_VALID_ONLY:
> > +VarState = "header-ok";
> > +VarName  = L"";
> > +break;
> > +  case VAR_ADDED:
> > +VarState = "ok";
> > +break;
> > +  case VAR_ADDED &VAR_IN_DELETED_TRANSITION:
> 
> This looks odd, so please add a comment explaining why these constants
> are constructed this way.

The VAR_HEADER_VALID_ONLY and VAR_ADDED states are applied using an
assignment, i.e. "State = VAR_...".

The other two are used to clear bits, i.e. "State &= VAR_...".

So the usual livecycle for the State field is:

  (1) 0x7f (VAR_HEADER_VALID_ONLY)
  (2) 0x3f (VAR_ADDED)
  (3) 0x3e (VAR_ADDED & VAR_IN_DELETED_TRANSITION)
  (4) 0x3c (VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED)

Seems it can also happen that variable entries jump directly from (2) to
(4), resulting in 0x3d (VAR_ADDED & VAR_DELETED) being an possible
alternative value for (4).

I'm not fully sure what happens to VAR_HEADER_VALID_ONLY entries, i.e.
whenever they go through the (3) + (4) deletion cycles too or whenever
they are garbage-collected in some other way.  I suspect the latter,
given that the reclaim logic in the variable driver looks at the
variable names, but VAR_HEADER_VALID_ONLY entries don't have a valid
variable name.

BTW: Is there any good documentation on the design of the variable
driver and the fault tolerant flash writes?  Is the variable flash
supposed to be in a consistent state at any given time, even if
interrupted in the middle of some update operation?

The qemu flash emulation is a bit sloppy, specifically block writes can
be half-completed when a reset happens in the middle of the operation.
Which maybe is the root cause for varstore corruption.

On the other hand the edk2 flash code does not look like it carefully
chooses blocks when updating flash, so I'm not sure it actually depends
on atomic block updates to ensure consistency.

take care,
  Gerd

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112226): https://edk2.groups.io/g/devel/message/112226
Mute This Topic: https://groups.io/mt/103031342/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] ArmVirt: Allow memory attributes protocol to be disabled on first boot

2023-12-08 Thread Ard Biesheuvel

On Thu, 7 Dec 2023 at 11:06, Ard Biesheuvel  wrote:
>
> From: Ard Biesheuvel 
>
> Shim's PE loader uses the EFI memory attributes protocol in a way that
> results in an immediate crash when invoking the loaded image, unless the
> base and size of its executable segment are both aligned to 4k.
>
> If this is not the case, it will strip the memory allocation of its
> executable permissions, but fail to add them back for the executable
> region, resulting in non-executable code. Unfortunately, the PE loader
> does not even bother invoking the protocol in this case (as it notices
> the misalignment), making it very hard for system firmware to work
> around this by attempting to infer the intent of the caller.
>
> So let's introduce a QEMU command line option to indicate that the
> protocol should not be exposed at all on the first boot, which is when
> the issue is triggered. (fbaa64.efi is broken but grubaa64.efi boots
> fine)
>
>   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocolOnFirstBoot,string=y
>
> Also introduce a fixed boolean PCD that sets the default.
>
> Cc: Laszlo Ersek 
> Cc: Gerd Hoffmann 
> Cc: Oliver Steffen 
> Cc: Alexander Graf 
> Cc: Oliver Smith-Denny 
> Cc: Taylor Beebe 
> Cc: Peter Jones 
> Cc: Leif Lindholm 
> Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
> Signed-off-by: Ard Biesheuvel 

OK, if nobody has problems with this approach, I intend to merge it
and give a snapshot build to the lima folks to incorporate in their
scripts.


> ---
>  ArmVirtPkg/ArmVirtPkg.dec|  6 ++
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  7 ++
>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 85 
> 
>  3 files changed, 98 insertions(+)
>
> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index 0f2d7873279f..c55978f75c19 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
># Cloud Hypervisor has no other way to pass Rsdp address to the guest 
> except use a PCD.
>
>#
>
>gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
>
> +
>
> +  ##
>
> +  # Whether the EFI memory attribus protocol should be uninstalled before
>
> +  # invoking the OS loader on the first boot. This may be needed to work 
> around
>
> +  # problematic builds of shim that use the protocol incorrectly.
>
> +  
> gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot|FALSE|BOOLEAN|0x0006
>
> diff --git 
> a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 997eb1a4429f..5d119af6a3b3 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -16,6 +16,7 @@ [Defines]
>MODULE_TYPE= DXE_DRIVER
>
>VERSION_STRING = 1.0
>
>LIBRARY_CLASS  = PlatformBootManagerLib|DXE_DRIVER
>
> +  CONSTRUCTOR= PlatformBootManagerLibConstructor
>
>
>
>  #
>
>  # The following information is for reference only and not required by the 
> build tools.
>
> @@ -46,6 +47,7 @@ [LibraryClasses]
>PcdLib
>
>PlatformBmPrintScLib
>
>QemuBootOrderLib
>
> +  QemuFwCfgSimpleParserLib
>
>QemuLoadImageLib
>
>ReportStatusCodeLib
>
>TpmPlatformHierarchyLib
>
> @@ -55,6 +57,7 @@ [LibraryClasses]
>UefiRuntimeServicesTableLib
>
>
>
>  [FixedPcd]
>
> +  gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot
>
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
>
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
>
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
>
> @@ -73,5 +76,9 @@ [Guids]
>  [Protocols]
>
>gEfiFirmwareVolume2ProtocolGuid
>
>gEfiGraphicsOutputProtocolGuid
>
> +  gEfiMemoryAttributeProtocolGuid
>
>gEfiPciRootBridgeIoProtocolGuid
>
>gVirtioDeviceProtocolGuid
>
> +
>
> +[Depex]
>
> +  gEfiVariableArchProtocolGuid
>
> diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 85c01351b09d..5306d9ea0a05 100644
> --- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
>
>  #include 
>
> +#include 
>
>  #include 
>
>  #include 
>
>  #include 
>
> @@ -1274,3 +1275,87 @@ PlatformBootManagerUnableToBoot (
>  EfiBootManagerBoot (&BootManagerMenu);
>
>}
>
>  }
>
> +
>
> +/**
>
> +  Uninstall the EFI memory attribute protocol if it exists.
>
> +**/
>
> +STATIC
>
> +VOID
>
> +UninstallEfiMemoryAttributesProtocol (
>
> +  VOID
>
> +  )
>
> +{
>
> +  EFI_STATUS  Status;
>
> +  EFI_HANDLE  Handle;
>
> +  UINTN   Size;
>
> +  VOID*MemoryAttributeProtocol;
>
> +

[edk2-devel] [Patch V3 6/6] UefiCpuPkg: Avoid assuming only one smmbasehob

2023-12-08 Thread duntan

Modify the gSmmBaseHobGuid consumption code to
remove the asuumption that there is only one
gSmmBaseHobGuid. If the CPU number is big enough,
there will be more than one SmmBaseHob in the
HOB list.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Reviewed-by: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 181 
+
 1 file changed, 149 insertions(+), 32 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index 53f67d544d..209a2e4810 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -586,6 +586,132 @@ SmmReadyToLockEventNotify (
   return EFI_SUCCESS;
 }
 
+/**
+  Function to compare 2 SMM_BASE_HOB_DATA pointer based on ProcessorIndex.
+
+  @param[in] Buffer1pointer to SMM_BASE_HOB_DATA poiner to compare
+  @param[in] Buffer2pointer to second SMM_BASE_HOB_DATA pointer to 
compare
+
+  @retval 0 Buffer1 equal to Buffer2
+  @retval <0Buffer1 is less than Buffer2
+  @retval >0Buffer1 is greater than Buffer2
+**/
+INTN
+EFIAPI
+SmBaseHobCompare (
+  IN  CONST VOID  *Buffer1,
+  IN  CONST VOID  *Buffer2
+  )
+{
+  if ((*(SMM_BASE_HOB_DATA **)Buffer1)->ProcessorIndex > (*(SMM_BASE_HOB_DATA 
**)Buffer2)->ProcessorIndex) {
+return 1;
+  } else if ((*(SMM_BASE_HOB_DATA **)Buffer1)->ProcessorIndex < 
(*(SMM_BASE_HOB_DATA **)Buffer2)->ProcessorIndex) {
+return -1;
+  }
+
+  return 0;
+}
+
+/**
+  Extract SmBase for all CPU from SmmBase HOB.
+
+  @param[in]  MaxNumberOfCpus   Max NumberOfCpus.
+
+  @retval SmBaseBuffer  Pointer to SmBase Buffer.
+  @retval NULL  gSmmBaseHobGuid was not been created.
+**/
+UINTN *
+GetSmBase (
+  IN  UINTN  MaxNumberOfCpus
+  )
+{
+  UINTN  HobCount;
+  EFI_HOB_GUID_TYPE  *GuidHob;
+  SMM_BASE_HOB_DATA  *SmmBaseHobData;
+  UINTN  NumberOfProcessors;
+  SMM_BASE_HOB_DATA  **SmBaseHobs;
+  UINTN  *SmBaseBuffer;
+  UINTN  HobIndex;
+  UINTN  SortBuffer;
+  UINTN  ProcessorIndex;
+  UINT64 PrevProcessorIndex;
+  EFI_HOB_GUID_TYPE  *FirstSmmBaseGuidHob;
+
+  SmmBaseHobData = NULL;
+  HobIndex   = 0;
+  ProcessorIndex = 0;
+  HobCount   = 0;
+  NumberOfProcessors = 0;
+
+  FirstSmmBaseGuidHob = GetFirstGuidHob (&gSmmBaseHobGuid);
+  if (FirstSmmBaseGuidHob == NULL) {
+return NULL;
+  }
+
+  GuidHob = FirstSmmBaseGuidHob;
+  while (GuidHob != NULL) {
+HobCount++;
+SmmBaseHobData  = GET_GUID_HOB_DATA (GuidHob);
+NumberOfProcessors += SmmBaseHobData->NumberOfProcessors;
+
+if (NumberOfProcessors >= MaxNumberOfCpus) {
+  break;
+}
+
+GuidHob = GetNextGuidHob (&gSmmBaseHobGuid, GET_NEXT_HOB (GuidHob));
+  }
+
+  ASSERT (NumberOfProcessors == MaxNumberOfCpus);
+  if (NumberOfProcessors != MaxNumberOfCpus) {
+CpuDeadLoop ();
+  }
+
+  SmBaseHobs = AllocatePool (sizeof (SMM_BASE_HOB_DATA *) * HobCount);
+  ASSERT (SmBaseHobs != NULL);
+  if (SmBaseHobs == NULL) {
+return NULL;
+  }
+
+  //
+  // Record each SmmBaseHob pointer in the SmBaseHobs.
+  // The FirstSmmBaseGuidHob is to speed up this while-loop
+  // without needing to look for SmBaseHob from beginning.
+  //
+  GuidHob = FirstSmmBaseGuidHob;
+  while (HobIndex < HobCount) {
+SmBaseHobs[HobIndex++] = GET_GUID_HOB_DATA (GuidHob);
+GuidHob= GetNextGuidHob (&gSmmBaseHobGuid, GET_NEXT_HOB 
(GuidHob));
+  }
+
+  SmBaseBuffer = (UINTN *)AllocatePool (sizeof (UINTN) * (MaxNumberOfCpus));
+  ASSERT (SmBaseBuffer != NULL);
+  if (SmBaseBuffer == NULL) {
+FreePool (SmBaseHobs);
+return NULL;
+  }
+
+  QuickSort (SmBaseHobs, HobCount, sizeof (SMM_BASE_HOB_DATA *), 
(BASE_SORT_COMPARE)SmBaseHobCompare, &SortBuffer);
+  PrevProcessorIndex = 0;
+  for (HobIndex = 0; HobIndex < HobCount; HobIndex++) {
+//
+// Make sure no overlap and no gap in the CPU range covered by each HOB
+//
+ASSERT (SmBaseHobs[HobIndex]->ProcessorIndex == PrevProcessorIndex);
+
+//
+// Cache each SmBase in order.
+//
+for (ProcessorIndex = 0; ProcessorIndex < 
SmBaseHobs[HobIndex]->NumberOfProcessors; ProcessorIndex++) {
+  SmBaseBuffer[PrevProcessorIndex + ProcessorIndex] = 
(UINTN)SmBaseHobs[HobIndex]->SmBase[ProcessorIndex];
+}
+
+PrevProcessorIndex += SmBaseHobs[HobIndex]->NumberOfProcessors;
+  }
+
+  FreePool (SmBaseHobs);
+  return SmBaseBuffer;
+}
+
 /**
   Function to compare 2 MP_INFORMATION2_HOB_DATA pointer based on 
ProcessorIndex.
 
@@ -743,27 +869,22 @@ PiCpuSmmEntry (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
-  EFI_STATUS Status;
-  UINTN  Index;
-  VOID   *Buffe

[edk2-devel] [Patch V3 3/6] UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe

2023-12-08 Thread duntan

Consume MpInfo2Hob in PiSmmCpuDxe driver to get
NumberOfProcessors, MaxNumberOfCpus and
EFI_PROCESSOR_INFORMATION for all CPU from the
MpInformation2 HOB.
This can avoid calling MP service.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Reviewed-by: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 209 
+++--
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
 3 files changed, 168 insertions(+), 51 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index 1d022a7051..53f67d544d 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -99,8 +99,8 @@ UINTN  mSmmStackSize;
 UINTNmSmmShadowStackSize;
 BOOLEAN  mCetSupported = TRUE;
 
-UINTN  mMaxNumberOfCpus = 1;
-UINTN  mNumberOfCpus= 1;
+UINTN  mMaxNumberOfCpus = 0;
+UINTN  mNumberOfCpus= 0;
 
 //
 // SMM ready to lock flag
@@ -586,6 +586,146 @@ SmmReadyToLockEventNotify (
   return EFI_SUCCESS;
 }
 
+/**
+  Function to compare 2 MP_INFORMATION2_HOB_DATA pointer based on 
ProcessorIndex.
+
+  @param[in] Buffer1pointer to MP_INFORMATION2_HOB_DATA poiner to 
compare
+  @param[in] Buffer2pointer to second MP_INFORMATION2_HOB_DATA 
pointer to compare
+
+  @retval 0 Buffer1 equal to Buffer2
+  @retval <0Buffer1 is less than Buffer2
+  @retval >0Buffer1 is greater than Buffer2
+**/
+INTN
+EFIAPI
+MpInformation2HobCompare (
+  IN  CONST VOID  *Buffer1,
+  IN  CONST VOID  *Buffer2
+  )
+{
+  if ((*(MP_INFORMATION2_HOB_DATA **)Buffer1)->ProcessorIndex > 
(*(MP_INFORMATION2_HOB_DATA **)Buffer2)->ProcessorIndex) {
+return 1;
+  } else if ((*(MP_INFORMATION2_HOB_DATA **)Buffer1)->ProcessorIndex < 
(*(MP_INFORMATION2_HOB_DATA **)Buffer2)->ProcessorIndex) {
+return -1;
+  }
+
+  return 0;
+}
+
+/**
+  Extract NumberOfCpus, MaxNumberOfCpus and EFI_PROCESSOR_INFORMATION for all 
CPU from MpInformation2 HOB.
+
+  @param[out] NumberOfCpus   Pointer to NumberOfCpus.
+  @param[out] MaxNumberOfCpusPointer to MaxNumberOfCpus.
+
+  @retval ProcessorInfo  Pointer to EFI_PROCESSOR_INFORMATION 
buffer.
+**/
+EFI_PROCESSOR_INFORMATION *
+GetMpInformation (
+  OUT UINTN  *NumberOfCpus,
+  OUT UINTN  *MaxNumberOfCpus
+  )
+{
+  EFI_HOB_GUID_TYPE  *GuidHob;
+  EFI_HOB_GUID_TYPE  *FirstMpInfo2Hob;
+  MP_INFORMATION2_HOB_DATA   *MpInformation2HobData;
+  UINTN  HobCount;
+  UINTN  HobIndex;
+  MP_INFORMATION2_HOB_DATA   **MpInfo2Hobs;
+  UINTN  SortBuffer;
+  UINTN  ProcessorIndex;
+  UINT64 PrevProcessorIndex;
+  MP_INFORMATION2_ENTRY  *MpInformation2Entry;
+  EFI_PROCESSOR_INFORMATION  *ProcessorInfo;
+
+  GuidHob   = NULL;
+  MpInformation2HobData = NULL;
+  FirstMpInfo2Hob   = NULL;
+  MpInfo2Hobs   = NULL;
+  HobIndex  = 0;
+  HobCount  = 0;
+
+  FirstMpInfo2Hob = GetFirstGuidHob (&gMpInformationHobGuid2);
+  ASSERT (FirstMpInfo2Hob != NULL);
+  GuidHob = FirstMpInfo2Hob;
+  while (GuidHob != NULL) {
+MpInformation2HobData = GET_GUID_HOB_DATA (GuidHob);
+
+//
+// This is the last MpInformationHob in the HOB list.
+//
+if (MpInformation2HobData->NumberOfProcessors == 0) {
+  ASSERT (HobCount != 0);
+  break;
+}
+
+HobCount++;
+*NumberOfCpus += MpInformation2HobData->NumberOfProcessors;
+GuidHob= GetNextGuidHob (&gMpInformationHobGuid2, GET_NEXT_HOB 
(GuidHob));
+  }
+
+  ASSERT (*NumberOfCpus <= PcdGet32 (PcdCpuMaxLogicalProcessorNumber));
+
+  //
+  // If support CPU hot plug, we need to allocate resources for possibly 
hot-added processors
+  //
+  if (FeaturePcdGet (PcdCpuHotPlugSupport)) {
+*MaxNumberOfCpus = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
+  } else {
+*MaxNumberOfCpus = *NumberOfCpus;
+  }
+
+  MpInfo2Hobs = AllocatePool (sizeof (MP_INFORMATION2_HOB_DATA *) * HobCount);
+  ASSERT (MpInfo2Hobs != NULL);
+  if (MpInfo2Hobs == NULL) {
+return NULL;
+  }
+
+  //
+  // Record each MpInformation2Hob pointer in the MpInfo2Hobs.
+  // The FirstMpInfo2Hob is to speed up this while-loop without
+  // needing to look for MpInfo2Hob from beginning.
+  //
+  GuidHob = FirstMpInfo2Hob;
+  while (HobIndex < HobCount) {
+MpInfo2Hobs[HobIndex++] = GET_GUID_HOB_DATA (GuidHob);
+GuidHob = GetNextGuidHob (&gMpInformationHobGuid2, 
GET_NEXT_HOB (GuidHob));
+  }
+
+  ProcessorInfo = (EFI_PROCESSOR_INFORMATION *)AllocatePool (sizeof 
(EFI_PROCESSOR_INFORMATION) * (*MaxNumberOfCpus));
+  ASSERT (

[edk2-devel] [Patch V3 2/6] UefiCpuPkg: Build MpInfo2HOB in CpuMpPei

2023-12-08 Thread duntan

Build MpInfo2HOB in CpuMpPei module so that later
PiSmmCpuDxe or other StandaloneMm module can consume
the HOB.
Since there might be more one gMpInformationHobGuid2
in HOB list, CpuMpPei create a gMpInformationHobGuid2
with 0 value NumberOfProcessors field in the end of the
process to indicate it's the last MP_INFORMATION2_HOB.

Signed-off-by: Dun Tan 
Cc: Eric Dong 
Reviewed-by: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 91 
+++
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |  4 +++-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |  3 ++-
 3 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
index b504bea3cf..e96a76c9a5 100644
--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
@@ -541,6 +541,92 @@ InitializeMpExceptionStackSwitchHandlers (
   FreePages (SwitchStackData, EFI_SIZE_TO_PAGES (NumberOfProcessors * sizeof 
(EXCEPTION_STACK_SWITCH_CONTEXT)));
 }
 
+/**
+  Create gMpInformationHobGuid2.
+**/
+VOID
+BuildMpInformationHob (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  UINTN ProcessorIndex;
+  UINTN NumberOfProcessors;
+  UINTN NumberOfEnabledProcessors;
+  UINTN NumberOfProcessorsInHob;
+  UINTN MaxProcessorsPerHob;
+  MP_INFORMATION2_HOB_DATA  *MpInformation2HobData;
+  MP_INFORMATION2_ENTRY *MpInformation2Entry;
+  UINTN Index;
+
+  ProcessorIndex= 0;
+  MpInformation2HobData = NULL;
+  MpInformation2Entry   = NULL;
+
+  Status = MpInitLibGetNumberOfProcessors (&NumberOfProcessors, 
&NumberOfEnabledProcessors);
+  ASSERT_EFI_ERROR (Status);
+  MaxProcessorsPerHob = ((MAX_UINT16 & ~7) - sizeof (EFI_HOB_GUID_TYPE) - 
sizeof (MP_INFORMATION2_HOB_DATA)) / sizeof (MP_INFORMATION2_ENTRY);
+  NumberOfProcessorsInHob = MaxProcessorsPerHob;
+
+  //
+  // Create MP_INFORMATION2_HOB. when the max HobLength 0xFFF8 is not enough, 
there
+  // will be a MP_INFORMATION2_HOB series in the HOB list.
+  // In the HOB list, there is a gMpInformationHobGuid2 with 0 value 
NumberOfProcessors
+  // fields to indicate it's the last MP_INFORMATION2_HOB.
+  //
+  while (NumberOfProcessorsInHob != 0) {
+NumberOfProcessorsInHob = MIN (NumberOfProcessors - ProcessorIndex, 
MaxProcessorsPerHob);
+MpInformation2HobData   = BuildGuidHob (
+&gMpInformationHobGuid2,
+sizeof (MP_INFORMATION2_HOB_DATA) + sizeof 
(MP_INFORMATION2_ENTRY) * NumberOfProcessorsInHob
+);
+ASSERT (MpInformation2HobData != NULL);
+
+MpInformation2HobData->Version= MP_INFORMATION2_HOB_REVISION;
+MpInformation2HobData->ProcessorIndex = ProcessorIndex;
+MpInformation2HobData->NumberOfProcessors = 
(UINT16)NumberOfProcessorsInHob;
+MpInformation2HobData->EntrySize  = sizeof (MP_INFORMATION2_ENTRY);
+
+DEBUG ((DEBUG_INFO, "Creating MpInformation2 HOB...\n"));
+
+for (Index = 0; Index < NumberOfProcessorsInHob; Index++) {
+  MpInformation2Entry = &MpInformation2HobData->Entry[Index];
+  Status  = MpInitLibGetProcessorInfo (
+  (Index + ProcessorIndex) | 
CPU_V2_EXTENDED_TOPOLOGY,
+  &MpInformation2Entry->ProcessorInfo,
+  NULL
+  );
+  ASSERT_EFI_ERROR (Status);
+  DEBUG ((
+DEBUG_INFO,
+"  Processor[%04d]: ProcessorId = 0x%lx, StatusFlag = 0x%x\n",
+Index + ProcessorIndex,
+MpInformation2Entry->ProcessorInfo.ProcessorId,
+MpInformation2Entry->ProcessorInfo.StatusFlag
+));
+  DEBUG ((
+DEBUG_INFO,
+"Location = Package:%d Core:%d Thread:%d\n",
+MpInformation2Entry->ProcessorInfo.Location.Package,
+MpInformation2Entry->ProcessorInfo.Location.Core,
+MpInformation2Entry->ProcessorInfo.Location.Thread
+));
+  DEBUG ((
+DEBUG_INFO,
+"Location2 = Package:%d Die:%d Tile:%d Module:%d Core:%d 
Thread:%d\n",
+
MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Package,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Die,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Tile,
+
MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Module,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Core,
+MpInformation2Entry->ProcessorInfo.ExtendedInformation.Location2.Thread
+));
+}
+
+ProcessorIndex += NumberOfProcessorsInHob;
+  }
+}
+
 /**
   Initializes MP and exceptions handlers.
 
@@ -602,6 +688,11 @@ InitializeCpuMpWorker (
   Status = PeiServicesInstallPpi (mPeiCpuMpPpiList);

[edk2-devel] [Patch V3 0/6] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

2023-12-08 Thread duntan

In the V3 patch set,
In patch "UefiCpuPkg: Build MpInfo2HOB in CpuMpPei", the DEBUG message format 
is modified
In patch "UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe", remove unneccesary 
assert check.
In patch "UefiCpuPkg: Avoid assuming only one smmbasehob", free allocated 
buffer when error returning case happen.

Dun Tan (6):
  UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg
  UefiCpuPkg: Build MpInfo2HOB in CpuMpPei
  UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe
  UefiCpuPkg: Add a new field in MpInfo2 HOB
  UefiCpuPkg: Cache core type in MpInfo2 HOB
  UefiCpuPkg: Avoid assuming only one smmbasehob

 UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 146 
++
 UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   6 +-
 UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   3 ++-
 UefiCpuPkg/Include/Guid/MpInformation2.h |  58 
++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 354 
++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
 UefiCpuPkg/UefiCpuPkg.dec|   3 +++
 8 files changed, 513 insertions(+), 67 deletions(-)
 create mode 100644 UefiCpuPkg/Include/Guid/MpInformation2.h

-- 
2.31.1.windows.1



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

2023-12-08 Thread Ni, Ray

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Tan, Dun 
> Sent: Thursday, December 7, 2023 3:33 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Gerd Hoffmann 
> Subject: [Patch V2 6/6] UefiCpuPkg: Avoid assuming only one smmbasehob
> 
> Modify the gSmmBaseHobGuid consumption code to
> remove the asuumption that there is only one
> gSmmBaseHobGuid. If the CPU number is big enough,
> there will be more than one SmmBaseHob in the
> HOB list.
> 
> Signed-off-by: Dun Tan 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 179
> ++
> ++
> +++
>  1 file changed, 147 insertions(+), 32 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> index b729f8ee63..fab2fed286 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> @@ -586,6 +586,132 @@ SmmReadyToLockEventNotify (
>return EFI_SUCCESS;
>  }
> 
> +/**
> +  Function to compare 2 SMM_BASE_HOB_DATA pointer based on
> ProcessorIndex.
> +
> +  @param[in] Buffer1pointer to SMM_BASE_HOB_DATA
> poiner to compare
> +  @param[in] Buffer2pointer to second
> SMM_BASE_HOB_DATA pointer to compare
> +
> +  @retval 0 Buffer1 equal to Buffer2
> +  @retval <0Buffer1 is less than Buffer2
> +  @retval >0Buffer1 is greater than Buffer2
> +**/
> +INTN
> +EFIAPI
> +SmBaseHobCompare (
> +  IN  CONST VOID  *Buffer1,
> +  IN  CONST VOID  *Buffer2
> +  )
> +{
> +  if ((*(SMM_BASE_HOB_DATA **)Buffer1)->ProcessorIndex >
> (*(SMM_BASE_HOB_DATA **)Buffer2)->ProcessorIndex) {
> +return 1;
> +  } else if ((*(SMM_BASE_HOB_DATA **)Buffer1)->ProcessorIndex <
> (*(SMM_BASE_HOB_DATA **)Buffer2)->ProcessorIndex) {
> +return -1;
> +  }
> +
> +  return 0;
> +}
> +
> +/**
> +  Extract SmBase for all CPU from SmmBase HOB.
> +
> +  @param[in]  MaxNumberOfCpus   Max NumberOfCpus.
> +
> +  @retval SmBaseBuffer  Pointer to SmBase Buffer.
> +  @retval NULL  gSmmBaseHobGuid was not been
> created.
> +**/
> +UINTN *
> +GetSmBase (
> +  IN  UINTN  MaxNumberOfCpus
> +  )
> +{
> +  UINTN  HobCount;
> +  EFI_HOB_GUID_TYPE  *GuidHob;
> +  SMM_BASE_HOB_DATA  *SmmBaseHobData;
> +  UINTN  NumberOfProcessors;
> +  SMM_BASE_HOB_DATA  **SmBaseHobs;
> +  UINTN  *SmBaseBuffer;
> +  UINTN  HobIndex;
> +  UINTN  SortBuffer;
> +  UINTN  ProcessorIndex;
> +  UINT64 PrevProcessorIndex;
> +  EFI_HOB_GUID_TYPE  *FirstSmmBaseGuidHob;
> +
> +  SmmBaseHobData = NULL;
> +  HobIndex   = 0;
> +  ProcessorIndex = 0;
> +  HobCount   = 0;
> +  NumberOfProcessors = 0;
> +
> +  FirstSmmBaseGuidHob = GetFirstGuidHob (&gSmmBaseHobGuid);
> +  if (FirstSmmBaseGuidHob == NULL) {
> +return NULL;
> +  }
> +
> +  GuidHob = FirstSmmBaseGuidHob;
> +  while (GuidHob != NULL) {
> +HobCount++;
> +SmmBaseHobData = GET_GUID_HOB_DATA (GuidHob);
> +
> +if (NumberOfProcessors >= MaxNumberOfCpus) {
> +  break;
> +}
> +
> +NumberOfProcessors += SmmBaseHobData->NumberOfProcessors;
> +GuidHob = GetNextGuidHob (&gSmmBaseHobGuid,
> GET_NEXT_HOB (GuidHob));
> +  }
> +
> +  ASSERT (NumberOfProcessors == MaxNumberOfCpus);
> +  if (NumberOfProcessors != MaxNumberOfCpus) {
> +CpuDeadLoop ();
> +  }
> +
> +  SmBaseHobs = AllocatePool (sizeof (SMM_BASE_HOB_DATA *) *
> HobCount);
> +  ASSERT (SmBaseHobs != NULL);
> +  if (SmBaseHobs == NULL) {
> +return NULL;
> +  }
> +
> +  //
> +  // Record each SmmBaseHob pointer in the SmBaseHobs.
> +  // The FirstSmmBaseGuidHob is to speed up this while-loop
> +  // without needing to look for SmBaseHob from beginning.
> +  //
> +  GuidHob = FirstSmmBaseGuidHob;
> +  while (HobIndex < HobCount) {
> +SmBaseHobs[HobIndex++] = GET_GUID_HOB_DATA (GuidHob);
> +GuidHob= GetNextGuidHob (&gSmmBaseHobGuid,
> GET_NEXT_HOB (GuidHob));
> +  }
> +
> +  SmBaseBuffer = (UINTN *)AllocatePool (sizeof (UINTN) *
> (MaxNumberOfCpus));
> +  ASSERT (SmBaseBuffer != NULL);
> +  if (SmBaseBuffer == NULL) {
> +FreePool (SmBaseHobs);
> +return NULL;
> +  }
> +
> +  QuickSort (SmBaseHobs, HobCount, sizeof (SMM_BASE_HOB_DATA *),
> (BASE_SORT_COMPARE)SmBaseHobCompare, &SortBuffer);
> +  PrevProcessorIndex = 0;
> +  for (HobIndex = 0; HobIndex < HobCount; HobIndex++) {
> +//
> +// Make sure no overlap and no gap in the CPU range covered by each
> HOB
> +//
> +ASSERT (SmBaseHobs[HobIndex]->ProcessorIndex ==
> PrevProcessorIndex);
> +
> +//
> +// Cache each SmBase in order.
> +//
> +for (ProcessorIndex = 0; Pr

Re: [edk2-devel] [Patch V2 1/6] UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg

2023-12-08 Thread Ni, Ray

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Tan, Dun 
> Sent: Thursday, December 7, 2023 3:32 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Gerd Hoffmann 
> Subject: [Patch V2 1/6] UefiCpuPkg: Create gMpInformationHobGuid2 in
> UefiCpuPkg
> 
> Create gMpInformationHobGuid2 in UefiCpuPkg.
> 
> Currently, there is a gMpInformationHobGuid defined,
> created and consumed only in StandaloneMmPkg. The HOB
> contains the EFI_PROCESSOR_INFORMATION structure for
> each CPU and the number of processors. This is the same
> as the information that PiSmmCpuDxeSmm uses MpService
> Protocol to get.
> 
> This new gMpInformationHobGuid2 also contains the
> NumberOfProcessors and the EFI_PROCESSOR_INFORMATION
> for each CPU. Also the HOB is extended to support the
> case that the maximum HOB length is not enough for all
> CPU. So there might be more than one HOB instance in the
> HOB list. Each HOB describes the corresponding CPU index
> range.
> 
> The plan is to create gMpInformationHob2Guid in CpuMpPei
> module(implemented in next commit). Then PiSmmCpuDxeSmm
> and other MM_STANDALONE modules can consume the hob. This
> can avoid calling MpService Protocol in PiSmmCpuDxeSmm.
> Also the issue that one gMpInformationHobGuid might be not
> enough when CPU number is 1~2000 or bigger can be solved.
> 
> Signed-off-by: Dun Tan 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Include/Guid/MpInformation2.h | 56
> 
>  UefiCpuPkg/UefiCpuPkg.dec|  3 +++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/UefiCpuPkg/Include/Guid/MpInformation2.h
> b/UefiCpuPkg/Include/Guid/MpInformation2.h
> new file mode 100644
> index 00..7a25fcc2f3
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Guid/MpInformation2.h
> @@ -0,0 +1,56 @@
> +/** @file
> +  EFI MP information protocol provides a lightweight
> MP_SERVICES_PROTOCOL.
> +
> +  MP information protocol only provides static information of MP processor.
> +
> +  If SwitchBSP or Enable/DisableAP in MP service is called between the HOB
> +  production and HOB consumption,
> EFI_PROCESSOR_INFORMATION.StatusFlag field
> +  in this HOB may be invalidated.
> +
> +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef MP_INFORMATION2_H_
> +#define MP_INFORMATION2_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +#define MP_INFORMATION2_HOB_REVISION  1
> +
> +#define MP_INFORMATION2_GUID \
> +  { \
> +0x417a7f64, 0xf4e9, 0x4b32, {0x84, 0x6a, 0x5c, 0xc4, 0xd8, 0x62, 0x18,
> 0x79}  \
> +  }
> +
> +typedef struct {
> +  EFI_PROCESSOR_INFORMATIONProcessorInfo;
> +  //
> +  // Add more fields in future
> +  //
> +} MP_INFORMATION2_ENTRY;
> +
> +typedef struct {
> +  UINT16   NumberOfProcessors;
> +  UINT16   EntrySize;
> +  UINT8Version;
> +  UINT8Reserved[3];
> +  UINT64   ProcessorIndex;
> +  MP_INFORMATION2_ENTRYEntry[0];
> +} MP_INFORMATION2_HOB_DATA;
> +
> +//
> +// Producer of MP_INFORMATION2_HOB_DATA should assign sizeof
> (MP_INFORMATION2_ENTRY) to MP_INFORMATION2_HOB_DATA.EntrySize
> +// Consumer of MP_INFORMATION2_HOB_DATA should use below macro or
> similar logic to get the individual entry
> +// as the entry structure might be updated to include more information.
> +//
> +#define GET_MP_INFORMATION_ENTRY(MpInfoHobData, Index) \
> +(MP_INFORMATION2_ENTRY
> *)((UINTN)&((MP_INFORMATION2_HOB_DATA *)(MpInfoHobData))->Entry +
> (MpInfoHobData)->EntrySize * Index)
> +
> +extern EFI_GUID  gMpInformationHobGuid2;
> +
> +#endif
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index 0b5431dbf7..61bd34ef17 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -85,6 +85,9 @@
>## Include/Guid/SmmBaseHob.h
>gSmmBaseHobGuid  = { 0xc2217ba7, 0x03bb, 0x4f63, {0xa6, 0x47,
> 0x7c, 0x25, 0xc5, 0xfc, 0x9d, 0x73 }}
> 
> +  ## Include/Guid/MpInformation2.h
> +  gMpInformationHobGuid2 = { 0x417a7f64, 0xf4e9, 0x4b32,
> {0x84, 0x6a, 0x5c, 0xc4, 0xd8, 0x62, 0x18, 0x79 }}
> +
>  [Protocols]
>## Include/Protocol/SmmCpuService.h
>gEfiSmmCpuServiceProtocolGuid   = { 0x1d202cab, 0xc8ab, 0x4d5c,
> { 0x94, 0xf7, 0x3c, 0xfc, 0xc0, 0xd3, 0xd3, 0x35 }}
> --
> 2.31.1.windows.1



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

Re: [edk2-devel] [Patch V2 3/6] UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe

2023-12-08 Thread Ni, Ray

> +  GuidHob = FirstMpInfo2Hob;
> +  ASSERT (GuidHob != NULL);

1. this is not needed.

Reviewed-by: Ray Ni  with above assertion removal.


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

Re: [edk2-devel] [Patch V2 5/6] UefiCpuPkg: Cache core type in MpInfo2 HOB

2023-12-08 Thread Ni, Ray

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Tan, Dun 
> Sent: Thursday, December 7, 2023 3:32 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Gerd Hoffmann 
> Subject: [Patch V2 5/6] UefiCpuPkg: Cache core type in MpInfo2 HOB
> 
> Cache core type in MpInfo2 HOB by CpuMpPei module.
> 
> Signed-off-by: Dun Tan 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c | 59
> +--
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h |  2 ++
>  2 files changed, 59 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> index 8cacf4ddf5..7e2d7efb6b 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -541,6 +541,30 @@ InitializeMpExceptionStackSwitchHandlers (
>FreePages (SwitchStackData, EFI_SIZE_TO_PAGES (NumberOfProcessors *
> sizeof (EXCEPTION_STACK_SWITCH_CONTEXT)));
>  }
> 
> +/**
> +  Get CPU core type.
> +
> +  @param[in, out] Buffer  Argument of the procedure.
> +**/
> +VOID
> +EFIAPI
> +GetProcessorCoreType (
> +  IN OUT VOID  *Buffer
> +  )
> +{
> +  EFI_STATUS   Status;
> +  UINT8*CoreTypes;
> +  CPUID_NATIVE_MODEL_ID_AND_CORE_TYPE_EAX
> NativeModelIdAndCoreTypeEax;
> +  UINTNProcessorIndex;
> +
> +  Status = MpInitLibWhoAmI (&ProcessorIndex);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  CoreTypes = (UINT8 *)Buffer;
> +  AsmCpuidEx (CPUID_HYBRID_INFORMATION,
> CPUID_HYBRID_INFORMATION_MAIN_LEAF,
> &NativeModelIdAndCoreTypeEax.Uint32, NULL, NULL, NULL);
> +  CoreTypes[ProcessorIndex] =
> (UINT8)NativeModelIdAndCoreTypeEax.Bits.CoreType;
> +}
> +
>  /**
>Create gMpInformationHobGuid2.
>  **/
> @@ -558,13 +582,36 @@ BuildMpInformationHob (
>MP_INFORMATION2_HOB_DATA  *MpInformation2HobData;
>MP_INFORMATION2_ENTRY *MpInformation2Entry;
>UINTN Index;
> +  UINT8 *CoreTypes;
> +  UINT32CpuidMaxInput;
> +  UINTN CoreTypePages;
> 
>ProcessorIndex= 0;
>MpInformation2HobData = NULL;
>MpInformation2Entry   = NULL;
> +  CoreTypes = NULL;
> +  CoreTypePages = 0;
> 
>Status = MpInitLibGetNumberOfProcessors (&NumberOfProcessors,
> &NumberOfEnabledProcessors);
>ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Get Processors CoreType
> +  //
> +  AsmCpuid (CPUID_SIGNATURE, &CpuidMaxInput, NULL, NULL, NULL);
> +  if (CpuidMaxInput >= CPUID_HYBRID_INFORMATION) {
> +CoreTypePages = EFI_SIZE_TO_PAGES (sizeof (UINT8) *
> NumberOfProcessors);
> +CoreTypes = AllocatePages (CoreTypePages);
> +ASSERT (CoreTypes != NULL);
> +
> +Status = MpInitLibStartupAllCPUs (
> +   GetProcessorCoreType,
> +   0,
> +   (VOID *)CoreTypes
> +   );
> +ASSERT_EFI_ERROR (Status);
> +  }
> +
>MaxProcessorsPerHob = ((MAX_UINT16 & ~7) - sizeof
> (EFI_HOB_GUID_TYPE) - sizeof (MP_INFORMATION2_HOB_DATA)) / sizeof
> (MP_INFORMATION2_ENTRY);
>NumberOfProcessorsInHob = MaxProcessorsPerHob;
> 
> @@ -597,12 +644,16 @@ BuildMpInformationHob (
>NULL
>);
>ASSERT_EFI_ERROR (Status);
> +
> +  MpInformation2Entry->CoreType = (CoreTypes != NULL) ?
> CoreTypes[Index + ProcessorIndex] : 0;
> +
>DEBUG ((
>  DEBUG_INFO,
> -"  Processor[%04d]: ProcessorId = 0x%lx, StatusFlag = 0x%x\n",
> +"  Processor[%04d]: ProcessorId = 0x%lx, StatusFlag = 0x%x,
> CoreType = 0x%x\n",
>  Index + ProcessorIndex,
>  MpInformation2Entry->ProcessorInfo.ProcessorId,
> -MpInformation2Entry->ProcessorInfo.StatusFlag
> +MpInformation2Entry->ProcessorInfo.StatusFlag,
> +MpInformation2Entry->CoreType
>  ));
>DEBUG ((
>  DEBUG_INFO,
> @@ -625,6 +676,10 @@ BuildMpInformationHob (
> 
>  ProcessorIndex += NumberOfProcessorsInHob;
>}
> +
> +  if (CoreTypes != NULL) {
> +FreePages (CoreTypes, CoreTypePages);
> +  }
>  }
> 
>  /**
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> index a40fd2c077..e7d07ffd64 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> @@ -32,6 +32,8 @@
> 
>  #include 
> 
> +#include 
> +
>  extern EFI_PEI_PPI_DESCRIPTOR  mPeiCpuMpPpiDesc;
> 
>  /**
> --
> 2.31.1.windows.1



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

Re: [edk2-devel] [PATCH 4/4] ArmVirtPkg: Sync debug level comments in ArmVirt.dsc.inc

Re: [edk2-devel] [PATCH v3] MdePkg: Add a new memory type definition

Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg/StandaloneMmHobLib: Remove HOB creation

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

[edk2-devel] [PATCH 4/4] ArmVirtPkg: Sync debug level comments in ArmVirt.dsc.inc

[edk2-devel] [PATCH 2/4] MdePkg: Add manageability debug level to PcdFixedDebugPrintErrorLevel

[edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

[edk2-devel] [PATCH 3/4] MdePkg: Update MdePkg.uni with manageability debug level

[edk2-devel] [PATCH 1/4] MdePkg: Improve wording of manageability debug level comment

Re: [edk2-devel] [PATCH v2] MdePkg: Define the DevicePath argument from LoadImage as optional

Re: [edk2-devel] [PATCH v2] MdePkg: Define the DevicePath argument from LoadImage as optional

Re: [edk2-devel] [PATCH v3] MdePkg: Add a new memory type definition

Re: [edk2-devel] [edk2-platforms PATCH 1/1] Silicon/Marvell/OdysseyPkg: New Marvell Odyssey processor

Re: [edk2-devel] [PATCH v1 14/17] Silicon/Marvell/Armada7k8k: Add ImagePropertiesRecordLib Instance

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

Re: [edk2-devel] [PATCH] Maintainers.txt: add Aaron Young as MptScsi and PvScsi reviewer

Re: [edk2-devel] [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, Ovmf, UefiCpu Pkg "M"

Re: [edk2-devel] [PATCH v2] OvmfPkg/MemEncryptSevLib: Fix address overflow during PVALIDATE

Re: [edk2-devel] [PATCH v2 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Use processor extended information

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg: Fix typos

Re: [edk2-devel] [PATCH v2] OvmfPkg/MemEncryptSevLib: Fix address overflow during PVALIDATE

Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[edk2-devel] [Patch V3 6/6] UefiCpuPkg: Avoid assuming only one smmbasehob

[edk2-devel] [Patch V3 3/6] UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe

[edk2-devel] [Patch V3 2/6] UefiCpuPkg: Build MpInfo2HOB in CpuMpPei

[edk2-devel] [Patch V3 0/6] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

Re: [edk2-devel] [Patch V2 6/6] UefiCpuPkg: Avoid assuming only one smmbasehob

Re: [edk2-devel] [Patch V2 1/6] UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg

Re: [edk2-devel] [Patch V2 3/6] UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe

Re: [edk2-devel] [Patch V2 5/6] UefiCpuPkg: Cache core type in MpInfo2 HOB

34 matches

Site Navigation

Mail list logo

Footer information