Re: [edk2-devel] [edk2-redfish-client][PATCH] RedfishClientPkg: rename x-uefi-redfish to x-UEFI-redfish

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Nickle Wang 
> Sent: Friday, May 3, 2024 9:57 AM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Igor Kulchytskyy
> ; Nick Ramirez 
> Subject: [edk2-redfish-client][PATCH] RedfishClientPkg: rename x-uefi-redfish
> to x-UEFI-redfish
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Rename x-uefi-redfish to x-UEFI-redfish to match the format of
> UEFI configuration namespace prefix.
>
> RFC: https://edk2.groups.io/g/rfc/message/849
>
> Signed-off-by: Jeff Brasen 
> Co-authored-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> Cc: Nick Ramirez 
> ---
>  .../Features/Bios/v1_0_9/Common/BiosCommon.h  |  2 +-
>  .../v1_0_4/Common/BootOptionCommon.h  |  2 +-
>  .../v1_13_0/Common/ComputerSystemCommon.h |  2 +-
>  .../v1_5_0/Common/ComputerSystemCommon.h  |  2 +-
>  .../Memory/V1_7_1/Common/MemoryCommon.h   |  2 +-
>  .../HiiToRedfishBootDxe/HiiToRedfishBootDxe.h |  2 +-
>  .../EdkIIRedfishResourceConfigInternal.h  |  2 +-
>  .../RedfishFeatureUtilityInternal.h   |  2 +-
>  .../HiiToRedfishBootDxe/HiiToRedfishBootDxe.c |  4 +-
>  .../Media/RedfishClientDriverStack.svg|  2 +-
>  .../HiiToRedfishBiosDxeMap.uni| 16 +++---
>  .../HiiToRedfishBootDxeMap.uni| 32 +--
>  .../HiiToRedfishMemoryDxeMap.uni  | 56 +--
>  RedfishClientPkg/Readme.md| 41 +++---
>  14 files changed, 84 insertions(+), 83 deletions(-)
>
> diff --git a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
> b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
> index 9a6f9684b..50772d5da 100644
> --- a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
> +++ b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
> @@ -24,7 +24,7 @@
>  #define RESOURCE_SCHEMA_VERSION  "v1_0_9"
>  #define REDPATH_ARRAY_PATTERNL"/Bios/.*"
>  #define REDPATH_ARRAY_PREFIX L"/Bios/"
> -#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-Bios.v1_0_9"
> +#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-Bios.v1_0_9"
>  #define REDFISH_SCHEMA_NAME  "ComputerSystem"
>
>  #endif
> diff --git
> a/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCom
> mon.h
> b/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCom
> mon.h
> index 83babf16f..9293d22cd 100644
> ---
> a/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCom
> mon.h
> +++
> b/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCom
> mon.h
> @@ -27,7 +27,7 @@
>  #define RESOURCE_SCHEMA_VERSION  "v1_0_4"
>  #define REDPATH_ARRAY_PATTERNL"/BootOptions/\\{.*\\}/"
>  #define REDPATH_ARRAY_PREFIX L"/BootOptions/"
> -#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-BootOption.v1_0_4"
> +#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-
> BootOption.v1_0_4"
>  #define REDFISH_BOOT_OPTION_PARAMETERL"?name="
>  #define REDFISH_BOOT_OPTION_DEBUG_TRACE  DEBUG_INFO
>  #endif
> diff --git
> a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/Compute
> rSystemCommon.h
> b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/Compute
> rSystemCommon.h
> index 7b83d2939..b5e3fa919 100644
> ---
> a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/Compute
> rSystemCommon.h
> +++
> b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/Compute
> rSystemCommon.h
> @@ -24,6 +24,6 @@
>  #define RESOURCE_SCHEMA_VERSION  "v1_13_0"
>  #define REDPATH_ARRAY_PATTERNL"/Systems/\\{.*\\}/"
>  #define REDPATH_ARRAY_PREFIX L"/Systems/"
> -#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-
> ComputerSystem.v1_13_0"
> +#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-
> ComputerSystem.v1_13_0"
>
>  #endif
> diff --git
> a/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/Computer
> SystemCommon.h
> b/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/Computer
> SystemCommon.h
> index a0eb41b8b..24a484d18 100644
> ---
> a/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/Computer
> SystemCommon.h
> +++
> b/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/Computer
> SystemCommon.h
> @@ -22,6 +22,6 @@
>  #define RESOURCE_SCHEMA_VERSION  "v1_5_0"
>  #define REDPATH_ARRAY_PATTERNL"/Systems/\\{.*\\}/"
>  #define REDPATH_ARRAY_PREFIX L"/Systems/"
> -#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-
> ComputerSystem.v1_5_0"
> +#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-
> ComputerSystem.v1_5_0"
>
>  #endif
> diff --git
> a/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.
> h
> b/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.
> h
> index c857868ea..2120dc0e4 100644
> ---
> a/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.
> h
> +++
> b/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.
> h
> @@ 

Re: [edk2-devel] [PATCH] RedfishPkg: Rename x-uefi-redfish to x-UEFI-redfish

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Nickle Wang 
> Sent: Friday, May 3, 2024 9:56 AM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Igor Kulchytskyy
> ; Nick Ramirez 
> Subject: [PATCH] RedfishPkg: Rename x-uefi-redfish to x-UEFI-redfish
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Rename x-uefi-redfish to x-UEFI-redfish to match the format of
> UEFI configuration namespace prefix.
>
> RFC: https://edk2.groups.io/g/rfc/message/849
>
> Signed-off-by: Jeff Brasen 
> Co-authored-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> Cc: Nick Ramirez 
> ---
>  RedfishPkg/RedfishPkg.dec |  6 +-
>  .../Library/RedfishPlatformConfigLib.h|  4 +-
>  .../Protocol/EdkIIRedfishPlatformConfig.h |  4 +-
>  .../RedfishPlatformConfigDxe.h|  2 +-
>  .../RedfishPlatformConfigImpl.h   | 16 ++--
>  .../RedfishPlatformConfigLib.c|  4 +-
>  .../RedfishPlatformConfigDxe.c|  4 +-
>  .../RedfishPlatformConfigImpl.c   | 86 +--
>  8 files changed, 63 insertions(+), 63 deletions(-)
>
> diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
> index c048e43f53..54318527fe 100644
> --- a/RedfishPkg/RedfishPkg.dec
> +++ b/RedfishPkg/RedfishPkg.dec
> @@ -195,10 +195,10 @@
>
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDebugCategory|0|UINT64|0x000
> 01012
>#
># Redfish RedfishPlatformConfigDxe Debug Properties
> -  #   0x0001  x-uefi-redfish string database message enabled
> +  #   0x0001  x-UEFI-redfish string database message enabled
>#   0x0002  Debug Message for dumping formset
> -  #   0x0004  Debug Message for x-uefi-redfish searching result
> -  #   0x0008  Debug Message for x-uefi-redfish Regular Expression
> searching result
> +  #   0x0004  Debug Message for x-UEFI-redfish searching result
> +  #   0x0008  Debug Message for x-UEFI-redfish Regular Expression
> searching result
>#
>
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishPlatformConfigDebugProperty|0|
> UINT32|0x1013
>#
> diff --git a/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
> b/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
> index 51a1861639..b6e60635ea 100644
> --- a/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
> +++ b/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
> @@ -2,7 +2,7 @@
>Definitions of RedfishPlatformConfigLib
>
>(C) Copyright 2021 Hewlett Packard Enterprise Development LP
> -  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +  Copyright (c) 2022-2024, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -82,7 +82,7 @@ RedfishPlatformConfigGetConfigureLang (
>Get the list of supported Redfish schema from platform configuration.
>
>@param[out]  SupportedSchema The supported schema list which is
> separated by ';'.
> -   For example: 
> "x-uefi-redfish-Memory.v1_7_1;x-uefi-
> redfish-Boot.v1_0_1"
> +   For example: 
> "x-UEFI-redfish-Memory.v1_7_1;x-UEFI-
> redfish-Boot.v1_0_1"
> The SupportedSchema is allocated by the 
> callee. It's caller's
> responsibility to free this buffer using 
> FreePool().
>
> diff --git a/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
> b/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
> index d20b2c980e..a1d5592c7e 100644
> --- a/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
> +++ b/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
> @@ -2,7 +2,7 @@
>This file defines the EDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL
> interface.
>
>(C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
> -  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +  Copyright (c) 2022-2024, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -227,7 +227,7 @@ EFI_STATUS
>
>@param[in]   ThisPointer to
> EDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL instance.
>@param[out]  SupportedSchema The supported schema list which is
> separated by ';'.
> -   For example: 
> "x-uefi-redfish-Memory.v1_7_1;x-uefi-
> redfish-Boot.v1_0_1"
> +   For example: 
> "x-UEFI-redfish-Memory.v1_7_1;x-UEFI-
> redfish-Boot.v1_0_1"
> The SupportedSchema is allocated by the 
> callee. It's caller's
> responsibility to free this buffer using 
> FreePool().
>
> diff --git
> a/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.h
> b/RedfishPkg/RedfishPlatfor

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

[Nhi Pham via groups.io]

On 5/2/2024 4:31 AM, Oliver Smith-Denny via groups.io wrote:

Hi folks, returning to this thread because I noticed that HOB
creation still exists in StandaloneMmCore for ARM:

https://github.com/tianocore/edk2/blob/5d4c5253e8bbc0baa8837fcd868925212df85201/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c

As far as I can tell, there is only this one file that creates 6
HOBs from StandaloneMmCore. Per our earlier discussion that led to
disabling HOB creation in StandaloneMm, I think that this falls into
the case where StandaloneMm is a HOB consumer phase, not a producer
phase and so it should not be creating these HOBs. On the x64 side,
all of the StandaloneMm HOB creation functions ASSERT with the
comment that StandaloneMm is a HOB consumer phase and should not
be creating HOBs.


The HOB creation in StandaloneMmCoreEntryPoint is exclusively consumed 
by the MM_CORE_STANDALONE module 
(StandaloneMmPkg/Core/StandaloneMmCore.inf), not a MM_STANDALONE module. 
Per my understanding earlier, the MM_CORE_STANDALONE is a producer and 
other MM_STANDALONE modules are consumers. So we removed the HOB 
creation in the StandaloneMmHobLib which is consumed by MM_STANDALONE 
modules.


Also, we still retain the HOB creation in the 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib library instance.


Regards,
Nhi



On ARM this is more complicated, as all of this information would
seem to originate from TF-A and so we would need TF-A to produce
these HOBs to tell StandaloneMm the information it needs to
operate. Today TF-A already has to communicate this information, the
HOBs are just created in StandaloneMmCore instead of in TF-A.

Curious to get other folks thoughts here on this paradigm.

Thanks,
Oliver

On 12/5/2023 5:47 AM, Nhi Pham wrote:

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_ADDRESS    FreeMemory;

-  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->MemoryAl

[edk2-devel] Event: TianoCore Community Meeting - APAC/NAMO - Thursday, May 2, 2024 #cal-reminder

[Group Notification]

*Reminder: TianoCore Community Meeting - APAC/NAMO*

*When:*
Thursday, May 2, 2024
7:30pm to 8:30pm
(UTC-07:00) America/Los Angeles

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

*Organizer:*
Miki Demeter

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

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

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

Meeting ID: 283 318 374 436
Passcode: 633zLo

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 119 493 012 8

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1194930128&ivr=teams&d=conf.intel.com&test=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2@thread.v2&messageId=0&language=en-US
 )




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

[edk2-devel] [edk2-redfish-client][PATCH] RedfishClientPkg: rename x-uefi-redfish to x-UEFI-redfish

[Nickle Wang via groups.io]

Rename x-uefi-redfish to x-UEFI-redfish to match the format of
UEFI configuration namespace prefix.

RFC: https://edk2.groups.io/g/rfc/message/849

Signed-off-by: Jeff Brasen 
Co-authored-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 .../Features/Bios/v1_0_9/Common/BiosCommon.h  |  2 +-
 .../v1_0_4/Common/BootOptionCommon.h  |  2 +-
 .../v1_13_0/Common/ComputerSystemCommon.h |  2 +-
 .../v1_5_0/Common/ComputerSystemCommon.h  |  2 +-
 .../Memory/V1_7_1/Common/MemoryCommon.h   |  2 +-
 .../HiiToRedfishBootDxe/HiiToRedfishBootDxe.h |  2 +-
 .../EdkIIRedfishResourceConfigInternal.h  |  2 +-
 .../RedfishFeatureUtilityInternal.h   |  2 +-
 .../HiiToRedfishBootDxe/HiiToRedfishBootDxe.c |  4 +-
 .../Media/RedfishClientDriverStack.svg|  2 +-
 .../HiiToRedfishBiosDxeMap.uni| 16 +++---
 .../HiiToRedfishBootDxeMap.uni| 32 +--
 .../HiiToRedfishMemoryDxeMap.uni  | 56 +--
 RedfishClientPkg/Readme.md| 41 +++---
 14 files changed, 84 insertions(+), 83 deletions(-)

diff --git a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h 
b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
index 9a6f9684b..50772d5da 100644
--- a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
+++ b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.h
@@ -24,7 +24,7 @@
 #define RESOURCE_SCHEMA_VERSION  "v1_0_9"
 #define REDPATH_ARRAY_PATTERNL"/Bios/.*"
 #define REDPATH_ARRAY_PREFIX L"/Bios/"
-#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-Bios.v1_0_9"
+#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-Bios.v1_0_9"
 #define REDFISH_SCHEMA_NAME  "ComputerSystem"
 
 #endif
diff --git 
a/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.h 
b/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.h
index 83babf16f..9293d22cd 100644
--- a/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.h
+++ b/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.h
@@ -27,7 +27,7 @@
 #define RESOURCE_SCHEMA_VERSION  "v1_0_4"
 #define REDPATH_ARRAY_PATTERNL"/BootOptions/\\{.*\\}/"
 #define REDPATH_ARRAY_PREFIX L"/BootOptions/"
-#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-BootOption.v1_0_4"
+#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-BootOption.v1_0_4"
 #define REDFISH_BOOT_OPTION_PARAMETERL"?name="
 #define REDFISH_BOOT_OPTION_DEBUG_TRACE  DEBUG_INFO
 #endif
diff --git 
a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.h
 
b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.h
index 7b83d2939..b5e3fa919 100644
--- 
a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.h
+++ 
b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.h
@@ -24,6 +24,6 @@
 #define RESOURCE_SCHEMA_VERSION  "v1_13_0"
 #define REDPATH_ARRAY_PATTERNL"/Systems/\\{.*\\}/"
 #define REDPATH_ARRAY_PREFIX L"/Systems/"
-#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-ComputerSystem.v1_13_0"
+#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-ComputerSystem.v1_13_0"
 
 #endif
diff --git 
a/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/ComputerSystemCommon.h 
b/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/ComputerSystemCommon.h
index a0eb41b8b..24a484d18 100644
--- 
a/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/ComputerSystemCommon.h
+++ 
b/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Common/ComputerSystemCommon.h
@@ -22,6 +22,6 @@
 #define RESOURCE_SCHEMA_VERSION  "v1_5_0"
 #define REDPATH_ARRAY_PATTERNL"/Systems/\\{.*\\}/"
 #define REDPATH_ARRAY_PREFIX L"/Systems/"
-#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-ComputerSystem.v1_5_0"
+#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-ComputerSystem.v1_5_0"
 
 #endif
diff --git a/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.h 
b/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.h
index c857868ea..2120dc0e4 100644
--- a/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.h
+++ b/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.h
@@ -22,6 +22,6 @@
 #define RESOURCE_SCHEMA_VERSION  "v1_7_1"
 #define REDPATH_ARRAY_PATTERNL"/Memory/\\{.*\\}/"
 #define REDPATH_ARRAY_PREFIX L"/Memory/"
-#define RESOURCE_SCHEMA_FULL "x-uefi-redfish-Memory.v1_7_1"
+#define RESOURCE_SCHEMA_FULL "x-UEFI-redfish-Memory.v1_7_1"
 
 #endif
diff --git a/RedfishClientPkg/HiiToRedfishBootDxe/HiiToRedfishBootDxe.h 
b/RedfishClientPkg/HiiToRedfishBootDxe/HiiToRedfishBootDxe.h
index 40a41d01b..455140536 100644
--- a/RedfishClientPkg/HiiToRedfishBootDxe/HiiToRedfishBootDxe.h
+++ b/RedfishClientPkg/HiiToRedfishBootDxe/HiiToRedfishBootDxe.h
@@ -36,7 +36,7 @@
 
 extern UINT8  HiiToRedfishBootVfrBin[];
 
-#define COMPUTER_SYSTEM_SCHEMA_VERSION  "x-uefi-redfi

[edk2-devel] [PATCH] RedfishPkg: Rename x-uefi-redfish to x-UEFI-redfish

[Nickle Wang via groups.io]

Rename x-uefi-redfish to x-UEFI-redfish to match the format of
UEFI configuration namespace prefix.

RFC: https://edk2.groups.io/g/rfc/message/849

Signed-off-by: Jeff Brasen 
Co-authored-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishPkg/RedfishPkg.dec |  6 +-
 .../Library/RedfishPlatformConfigLib.h|  4 +-
 .../Protocol/EdkIIRedfishPlatformConfig.h |  4 +-
 .../RedfishPlatformConfigDxe.h|  2 +-
 .../RedfishPlatformConfigImpl.h   | 16 ++--
 .../RedfishPlatformConfigLib.c|  4 +-
 .../RedfishPlatformConfigDxe.c|  4 +-
 .../RedfishPlatformConfigImpl.c   | 86 +--
 8 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index c048e43f53..54318527fe 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -195,10 +195,10 @@
   gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDebugCategory|0|UINT64|0x1012
   #
   # Redfish RedfishPlatformConfigDxe Debug Properties
-  #   0x0001  x-uefi-redfish string database message enabled
+  #   0x0001  x-UEFI-redfish string database message enabled
   #   0x0002  Debug Message for dumping formset
-  #   0x0004  Debug Message for x-uefi-redfish searching result
-  #   0x0008  Debug Message for x-uefi-redfish Regular Expression 
searching result
+  #   0x0004  Debug Message for x-UEFI-redfish searching result
+  #   0x0008  Debug Message for x-UEFI-redfish Regular Expression 
searching result
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishPlatformConfigDebugProperty|0|UINT32|0x1013
   #
diff --git a/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h 
b/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
index 51a1861639..b6e60635ea 100644
--- a/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
+++ b/RedfishPkg/Include/Library/RedfishPlatformConfigLib.h
@@ -2,7 +2,7 @@
   Definitions of RedfishPlatformConfigLib
 
   (C) Copyright 2021 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+  Copyright (c) 2022-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -82,7 +82,7 @@ RedfishPlatformConfigGetConfigureLang (
   Get the list of supported Redfish schema from platform configuration.
 
   @param[out]  SupportedSchema The supported schema list which is 
separated by ';'.
-   For example: 
"x-uefi-redfish-Memory.v1_7_1;x-uefi-redfish-Boot.v1_0_1"
+   For example: 
"x-UEFI-redfish-Memory.v1_7_1;x-UEFI-redfish-Boot.v1_0_1"
The SupportedSchema is allocated by the 
callee. It's caller's
responsibility to free this buffer using 
FreePool().
 
diff --git a/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h 
b/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
index d20b2c980e..a1d5592c7e 100644
--- a/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
+++ b/RedfishPkg/Include/Protocol/EdkIIRedfishPlatformConfig.h
@@ -2,7 +2,7 @@
   This file defines the EDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL interface.
 
   (C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+  Copyright (c) 2022-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -227,7 +227,7 @@ EFI_STATUS
 
   @param[in]   ThisPointer to 
EDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL instance.
   @param[out]  SupportedSchema The supported schema list which is 
separated by ';'.
-   For example: 
"x-uefi-redfish-Memory.v1_7_1;x-uefi-redfish-Boot.v1_0_1"
+   For example: 
"x-UEFI-redfish-Memory.v1_7_1;x-UEFI-redfish-Boot.v1_0_1"
The SupportedSchema is allocated by the 
callee. It's caller's
responsibility to free this buffer using 
FreePool().
 
diff --git a/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.h 
b/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.h
index 8eb7b0dc2a..e3e185a03b 100644
--- a/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.h
+++ b/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.h
@@ -111,7 +111,7 @@ typedef struct {
 
 #define REDFISH_PLATFORM_CONFIG_PRIVATE_FROM_THIS(a)  BASE_CR (a, 
REDFISH_PLATFORM_CONFIG_PRIVATE, Protocol)
 #define REGULAR_EXPRESSION_INCLUDE_ALL   L".*"
-#define CONFIGURE_LANGUAGE_PREFIX"x-uefi-redfish-"
+#define CONFIGURE_LANGUAGE_PREFIX"x-UEFI-redfish-"
 #define REDFISH_PLATFORM_CONFIG_VERSION  0x0001
 
 #define REDFISH_MENU_PATH_SIZE  8
diff --git a/Redfi

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Rebecca Cran]

On 5/2/2024 9:14 AM, Michael Kubacki wrote:
[2] https://github.com/tianocore/edk2/pull/4835 


I can't believe there's no UI for this, but in case anyone else is 
wondering: the diff can be downloaded by adding ".diff" or ".patch" onto 
the end of the URL - e.g. https://github.com/tianocore/edk2/pull/4835.diff


Also, there's a command-line interface available via the 'gh' command - 
https://cli.github.com/ (see https://cli.github.com/manual/gh_pr for the 
PR related commands).



--
Rebecca Cran



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

Re: [edk2-devel] [PATCH] IntelFsp2Pkg/PatchFv.py: FIX for GCC 32BIT build error

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: Duggapu, Chinni B 
> Sent: Monday, April 22, 2024 9:03 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Duggapu, Chinni B
> ; S, Ashraf Ali ; Kuo,
> Ted 
> Subject: [PATCH] IntelFsp2Pkg/PatchFv.py: FIX for GCC 32BIT build error
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4762
> 
> Map file generating 8 byte address offset is not matched with the pattern
> defined in patchFv tool resulting build error.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Duggapu Chinni B 
> Cc: Ashraf Ali S 
> Cc: Ted Kuo 
> 
> Signed-off-by: Duggapu Chinni B 
> ---
>  IntelFsp2Pkg/Tools/PatchFv.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelFsp2Pkg/Tools/PatchFv.py b/IntelFsp2Pkg/Tools/PatchFv.py
> index bd9aa71e3c..d35aa1dc9f 100644
> --- a/IntelFsp2Pkg/Tools/PatchFv.py
> +++ b/IntelFsp2Pkg/Tools/PatchFv.py
> @@ -432,7 +432,7 @@ class Symbols:
>  if reportLine.strip().find("Archive member included") != -1:
>  #GCC
>  #0x1d55IoRead8
> -patchMapFileMatchString = 
> r"\s+(0x[0-9a-fA-F]{16})\s+([^\s][^0x][_a-zA-Z0-9\-]+)\s"
> +patchMapFileMatchString = 
> r"\s+(0x[0-9a-fA-F]{8,16})\s+([^\s][^0x][_a-zA-Z0-9\-]+)\s"
>  matchKeyGroupIndex = 2
>  matchSymbolGroupIndex  = 1
>  prefix = '_'
> -- 
> 2.44.0.windows.1


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

Re: [edk2-devel] [PATCH] PACKAGE_GUID duplication in Intel silicon folders

[Nate DeSimone]

Pushed as d97a14d

> -Original Message-
> From: Hsueh, DoraX 
> Sent: Wednesday, May 1, 2024 11:21 PM
> To: devel@edk2.groups.io
> Cc: Hsueh, DoraX ; Chaganty, Rangasai V 
> ; Chuang, Rosen 
> ; Kasbekar, Saloni 
> ; Desimone, Nathaniel L 
> ; Lohr, Paul A 
> Subject: [PATCH] PACKAGE_GUID duplication in Intel silicon folders
> 
> From: DoraX Hsueh 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=4759
> 
> Modify PACKAGE_GUID duplication in Intel silicon folders.
> 
> Cc: Sai Chaganty 
> Cc: Rosen Chuang 
> Cc: Saloni Kasbekar 
> Cc: Nate DeSimone 
> Cc: Paul Lohr 
> Signed-off-by: DoraX Hsueh 
> ---
>  Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec  | 2 +-  
> Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec | 2 +-
>  Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec   | 2 +-
>  Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec  | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec
> index aafce7a6..d6dc6eb9 100644
> --- a/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec
> @@ -10,7 +10,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME = SiPkg
>  PACKAGE_VERSION = 0.1
> -PACKAGE_GUID = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID = 1CAF6538-7B9C-4188-B928-17F7DD953DCF
>  
>  [Includes.Common.Private]
>  
> diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
> index ca3e83bd..d96ff820 100644
> --- a/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
> @@ -11,7 +11,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME  = SiPkg
>  PACKAGE_VERSION   = 0.1
> -PACKAGE_GUID  = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID  = CA5148B1-3BB0-4D2D-AC3F-5497C8FEFB3D
>  
>  [Includes]
>Include
> diff --git a/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
> index 6c9af567..83c4beb4 100644
> --- a/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
> @@ -12,7 +12,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME = SiPkg
>  PACKAGE_VERSION = 0.1
> -PACKAGE_GUID = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID = 3043D26F-2A8C-441F-AFD9-8E80B7D65C7A
>  
>  
>  [Includes]
> diff --git a/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec
> index 991ca155..5fc4099f 100644
> --- a/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec
> @@ -11,7 +11,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME = SiPkg
>  PACKAGE_VERSION = 0.1
> -PACKAGE_GUID = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID = 0DEADE0D-B5F7-45D0-915F-77DB2497D270
>  
>  [Includes.Common.Private]
>  
> --
> 2.26.2.windows.1


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

Re: [edk2-devel] [PATCH] PACKAGE_GUID duplication in Intel silicon folders

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: Hsueh, DoraX 
> Sent: Wednesday, May 1, 2024 11:21 PM
> To: devel@edk2.groups.io
> Cc: Hsueh, DoraX ; Chaganty, Rangasai V
> ; Chuang, Rosen ;
> Kasbekar, Saloni ; Desimone, Nathaniel L
> ; Lohr, Paul A 
> Subject: [PATCH] PACKAGE_GUID duplication in Intel silicon folders
> 
> From: DoraX Hsueh 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=4759
> 
> Modify PACKAGE_GUID duplication in Intel silicon folders.
> 
> Cc: Sai Chaganty 
> Cc: Rosen Chuang 
> Cc: Saloni Kasbekar 
> Cc: Nate DeSimone 
> Cc: Paul Lohr 
> Signed-off-by: DoraX Hsueh 
> ---
>  Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec  | 2 +-
>  Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec | 2 +-
>  Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec   | 2 +-
>  Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec  | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec
> index aafce7a6..d6dc6eb9 100644
> --- a/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/AlderlakeSiliconPkg/SiPkg.dec
> @@ -10,7 +10,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME = SiPkg
>  PACKAGE_VERSION = 0.1
> -PACKAGE_GUID = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID = 1CAF6538-7B9C-4188-B928-17F7DD953DCF
>  
>  [Includes.Common.Private]
>  
> diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
> index ca3e83bd..d96ff820 100644
> --- a/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
> @@ -11,7 +11,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME  = SiPkg
>  PACKAGE_VERSION   = 0.1
> -PACKAGE_GUID  = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID  = CA5148B1-3BB0-4D2D-AC3F-5497C8FEFB3D
>  
>  [Includes]
>Include
> diff --git a/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
> index 6c9af567..83c4beb4 100644
> --- a/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec
> @@ -12,7 +12,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME = SiPkg
>  PACKAGE_VERSION = 0.1
> -PACKAGE_GUID = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID = 3043D26F-2A8C-441F-AFD9-8E80B7D65C7A
>  
>  
>  [Includes]
> diff --git a/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec 
> b/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec
> index 991ca155..5fc4099f 100644
> --- a/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec
> +++ b/Silicon/Intel/TigerlakeSiliconPkg/SiPkg.dec
> @@ -11,7 +11,7 @@
>  DEC_SPECIFICATION = 0x00010017
>  PACKAGE_NAME = SiPkg
>  PACKAGE_VERSION = 0.1
> -PACKAGE_GUID = F245E276-44A0-46b3-AEB5-9898BBCF008D
> +PACKAGE_GUID = 0DEADE0D-B5F7-45D0-915F-77DB2497D270
>  
>  [Includes.Common.Private]
>  
> -- 
> 2.26.2.windows.1


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

Re: [edk2-devel] [PATCH] AlderlakeOpenBoardPkg: Halt the TCO timer.

[Nate DeSimone]

Pushed as 0eb01a2

> -Original Message-
> From: Hsueh, DoraX 
> Sent: Monday, April 22, 2024 1:40 AM
> To: devel@edk2.groups.io
> Cc: Hsueh, DoraX ; Chaganty, Rangasai V
> ; Chuang, Rosen ;
> Kasbekar, Saloni ; Tang, Haoyu
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [PATCH] AlderlakeOpenBoardPkg: Halt the TCO timer.
> 
> From: DoraX Hsueh 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=4761
> 
> Halt the TCO timer to fix release mode hang.
> 
> Cc: Sai Chaganty 
> Cc: Rosen Chuang 
> Cc: Saloni Kasbekar 
> Cc: Haoyu Tang 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: DoraX Hsueh 
> ---
>  .../AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc  | 3 ++-
>  .../Library/SecFspWrapperPlatformSecLib/PlatformInit.c| 8 
>  .../SecFspWrapperPlatformSecLib.inf   | 1 +
>  3 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc 
> b/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc
> index 59350f06..ea92ec75 100644
> --- a/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc
> +++ b/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc
> @@ -233,8 +233,9 @@
>  
>  [LibraryClasses.X64.DXE_SMM_DRIVER]
>  
> -!if $(TARGET) == DEBUG
>
> SpiFlashCommonLib|IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlashCommonLib.inf
> +
> +!if $(TARGET) == DEBUG
>
> TestPointCheckLib|$(PLATFORM_PACKAGE)/Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf
>
> TestPointCheckLib|$(PLATFORM_PACKAGE)/Test/Library/TestPointCheckLibNull/TestPointCheckLibNull.inf
>  !endif
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
>  
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
> index f7ec4f9e..e930c9c7 100644
> --- 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
> +++ 
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
> @@ -12,6 +12,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /**
>Platform initialization.
> @@ -28,6 +30,12 @@ PlatformInit (
>IN VOID *EndOfRange
>)
>  {
> +
> +  ///
> +  /// Halt the TCO timer as early as possible
> +  ///
> +  IoWrite16 (PcdGet16 (PcdTcoBaseAddress) + R_TCO_IO_TCO1_CNT, 
> B_TCO_IO_TCO1_CNT_TMR_HLT);
> +
>//
>// Platform initialization
>// Enable Serial port here
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
>  
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
> index 3e51cb36..abc84057 100644
> --- 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
> +++ 
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
> @@ -89,6 +89,7 @@
>gIntelFsp2WrapperTokenSpaceGuid.PcdFsptBaseAddress  ## 
> CONSUMES
>gIntelFsp2PkgTokenSpaceGuid.PcdFspTemporaryRamSize  ## 
> CONSUMES
>gMinPlatformPkgTokenSpaceGuid.PcdSecSerialPortDebugEnable   ## 
> CONSUMES
> +  gSiPkgTokenSpaceGuid.PcdTcoBaseAddress  ## 
> CONSUMES
>  
>  [FixedPcd]
>gMinPlatformPkgTokenSpaceGuid.PcdFlashFvMicrocodeBase   ## 
> CONSUMES
> -- 
> 2.26.2.windows.1


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

Re: [edk2-devel] [PATCH] AlderlakeOpenBoardPkg: Halt the TCO timer.

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

> -Original Message-
> From: Hsueh, DoraX 
> Sent: Monday, April 22, 2024 1:40 AM
> To: devel@edk2.groups.io
> Cc: Hsueh, DoraX ; Chaganty, Rangasai V
> ; Chuang, Rosen ;
> Kasbekar, Saloni ; Tang, Haoyu
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [PATCH] AlderlakeOpenBoardPkg: Halt the TCO timer.
> 
> From: DoraX Hsueh 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=4761
> 
> Halt the TCO timer to fix release mode hang.
> 
> Cc: Sai Chaganty 
> Cc: Rosen Chuang 
> Cc: Saloni Kasbekar 
> Cc: Haoyu Tang 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: DoraX Hsueh 
> ---
>  .../AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc  | 3 ++-
>  .../Library/SecFspWrapperPlatformSecLib/PlatformInit.c| 8 
>  .../SecFspWrapperPlatformSecLib.inf   | 1 +
>  3 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc 
> b/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc
> index 59350f06..ea92ec75 100644
> --- a/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc
> +++ b/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/OpenBoardPkg.dsc
> @@ -233,8 +233,9 @@
>  
>  [LibraryClasses.X64.DXE_SMM_DRIVER]
>  
> -!if $(TARGET) == DEBUG
>
> SpiFlashCommonLib|IntelSiliconPkg/Library/SmmSpiFlashCommonLib/SmmSpiFlashCommonLib.inf
> +
> +!if $(TARGET) == DEBUG
>
> TestPointCheckLib|$(PLATFORM_PACKAGE)/Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf
>
> TestPointCheckLib|$(PLATFORM_PACKAGE)/Test/Library/TestPointCheckLibNull/TestPointCheckLibNull.inf
>  !endif
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
>  
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
> index f7ec4f9e..e930c9c7 100644
> --- 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
> +++ 
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/PlatformInit.c
> @@ -12,6 +12,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /**
>Platform initialization.
> @@ -28,6 +30,12 @@ PlatformInit (
>IN VOID *EndOfRange
>)
>  {
> +
> +  ///
> +  /// Halt the TCO timer as early as possible
> +  ///
> +  IoWrite16 (PcdGet16 (PcdTcoBaseAddress) + R_TCO_IO_TCO1_CNT, 
> B_TCO_IO_TCO1_CNT_TMR_HLT);
> +
>//
>// Platform initialization
>// Enable Serial port here
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
>  
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
> index 3e51cb36..abc84057 100644
> --- 
> a/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
> +++ 
> b/Platform/Intel/AlderlakeOpenBoardPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
> @@ -89,6 +89,7 @@
>gIntelFsp2WrapperTokenSpaceGuid.PcdFsptBaseAddress  ## 
> CONSUMES
>gIntelFsp2PkgTokenSpaceGuid.PcdFspTemporaryRamSize  ## 
> CONSUMES
>gMinPlatformPkgTokenSpaceGuid.PcdSecSerialPortDebugEnable   ## 
> CONSUMES
> +  gSiPkgTokenSpaceGuid.PcdTcoBaseAddress  ## 
> CONSUMES
>  
>  [FixedPcd]
>gMinPlatformPkgTokenSpaceGuid.PcdFlashFvMicrocodeBase   ## 
> CONSUMES
> -- 
> 2.26.2.windows.1


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

Re: [edk2-devel] [PATCH] AlderlakeOpenBoardPkg: Fix BootStage 5 can't install Windows11.

[Nate DeSimone]

Hi Dora,

Feedback below.

Thanks,
Nate

> -Original Message-
> From: Hsueh, DoraX 
> Sent: Monday, April 22, 2024 1:37 AM
> To: devel@edk2.groups.io
> Cc: Hsueh, DoraX ; Chaganty, Rangasai V
> ; Chuang, Rosen ;
> Kasbekar, Saloni ; Tang, Haoyu
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [PATCH] AlderlakeOpenBoardPkg: Fix BootStage 5 can't install
> Windows11.
> 
> From: DoraX Hsueh 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=4665
> 
> 1. Since installing windows does not meet the minimum system requirements,
>Added TPM related code to meet the requirements.
> 2. Support stage 6, add FvAdvancedPreMemory.
> 
> Cc: Sai Chaganty 
> Cc: Rosen Chuang 
> Cc: Saloni Kasbekar 
> Cc: Haoyu Tang 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: DoraX Hsueh 
> ---
>  .../Include/Fdf/FlashMapInclude.fdf   | 26 +++--
>  .../AlderlakePRvp/OpenBoardPkg.dsc|  1 +
>  .../AlderlakePRvp/OpenBoardPkg.fdf| 37 +--
>  .../AlderlakePRvp/OpenBoardPkgPcd.dsc | 10 -
>  4 files changed, 57 insertions(+), 17 deletions(-)
> 
> diff --git 
> a/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/Include/Fdf/FlashMapInclude.fdf
>  
> b/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/Include/Fdf/FlashMapInclude.fdf
> index 03c198c0..3e515d4e 100644
> --- 
> a/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/Include/Fdf/FlashMapInclude.fdf
> +++ 
> b/Platform/Intel/AlderlakeOpenBoardPkg/AlderlakePRvp/Include/Fdf/FlashMapInclude.fdf
> @@ -26,27 +26,29 @@ SET 
> gMinPlatformPkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareOffset = 0x000300
>  SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize  = 
> 0x0003  #
>  
>  SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedOffset= 
> 0x000E  # Flash addr (0xFF0E)
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedSize  = 
> 0x0031  #
> -SET gBoardModuleTokenSpaceGuid.PcdFlashFvOptionalOffset   = 
> 0x003F  # Flash addr (0xFF40)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedSize  = 
> 0x002E  #
> +SET gBoardModuleTokenSpaceGuid.PcdFlashFvOptionalOffset   = 
> 0x003C  # Flash addr (0xFF3C)
>  SET gBoardModuleTokenSpaceGuid.PcdFlashFvOptionalSize = 
> 0x0036  #
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvSecurityOffset= 
> 0x0075  # Flash addr (0xFF76)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvSecurityOffset= 
> 0x0072  # Flash addr (0xFF72)
>  SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvSecuritySize  = 
> 0x0009  #
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvOsBootOffset  = 
> 0x007E  # Flash addr (0xFF7F)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvOsBootOffset  = 
> 0x007B  # Flash addr (0xFF7B)
>  SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvOsBootSize= 
> 0x000A  #
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvUefiBootOffset= 
> 0x0088  # Flash addr (0xFF86)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvUefiBootOffset= 
> 0x0085  # Flash addr (0xFF85)
>  SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvUefiBootSize  = 
> 0x0018  #
>  
> -SET gBoardModuleTokenSpaceGuid.PcdFlashFvFirmwareBinariesOffset   = 
> 0x00A0  # Flash addr (0xFFA0)
> +SET gBoardModuleTokenSpaceGuid.PcdFlashFvFirmwareBinariesOffset   = 
> 0x009D  # Flash addr (0xFF9D)
>  SET gBoardModuleTokenSpaceGuid.PcdFlashFvFirmwareBinariesSize = 
> 0x0008  # Keep 0x8 or larger
> -SET gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvOffset  = 
> 0x00A8  # Flash addr (0xFFA8)
> +SET gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvOffset  = 
> 0x00A5  # Flash addr (0xFFA5)
>  SET gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvSize= 
> 0x0023  #
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvPostMemoryOffset  = 
> 0x00CB  # Flash addr (0xFFCB)
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvPostMemorySize= 
> 0x0004  #
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspSOffset= 
> 0x00CF  # Flash addr (0xFFCF)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvPostMemoryOffset  = 
> 0x00C8  # Flash addr (0xFFC8)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvPostMemorySize= 
> 0x0006  #
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspSOffset= 
> 0x00CE  # Flash addr (0xFFCE)
>  SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspSSize  = 
> 0x000A
> -SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspMOffset= 
> 0x00D9  # Flash addr (0xFFD9)
> +SET gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspMOffset= 
> 0x00D8  # Flash addr (0xFFD8)
>  SET gMinPlatformPkgTo

Re: [edk2-devel] [PATCH] Readme.md: Update AlderlakeOpenBoardPkg known limitations.

[Nate DeSimone]

Hi Dora,

Feedback below.

Thanks,
Nate

> -Original Message-
> From: Hsueh, DoraX 
> Sent: Monday, April 22, 2024 1:39 AM
> To: devel@edk2.groups.io
> Cc: Hsueh, DoraX ; Chaganty, Rangasai V
> ; Chuang, Rosen ;
> Kasbekar, Saloni ; Tang, Haoyu
> ; Desimone, Nathaniel L
> ; Chiu, Chasel 
> Subject: [PATCH] Readme.md: Update AlderlakeOpenBoardPkg known
> limitations.
> 
> From: DoraX Hsueh 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4667
> 
> Updates Alderlake P Rvp details to the Readme.md.
> 
> Cc: Sai Chaganty 
> Cc: Rosen Chuang 
> Cc: Saloni Kasbekar 
> Cc: Haoyu Tang 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Signed-off-by: DoraX Hsueh 
> ---
>  Platform/Intel/Readme.md | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md
> index d29a9072..652b4ec5 100644
> --- a/Platform/Intel/Readme.md
> +++ b/Platform/Intel/Readme.md
> @@ -410,7 +410,9 @@ For PurleyOpenBoardPkg (TiogaPass)
>  
>  **AlderlakeOpenBoardPkg**
>  1. This firmware project has been tested booting to Microsoft Windows 11 x64 
> with M2 SSD Disk and Integrated Graphic Device.
> -2. AlderlakeOpenBoardPkg/Acpi/MinDsdt has been modified from 
> MinPlatformPkg/Acpi/MinDsdt to avoid hang on boot to Microsoft Windows 11 x64.
> +2. Since the FSP binary is incompatible with the latest Edk2 version, a 
> working edk2 version needs to be kept
> +   EDK2 SHA-1: e10f1f5a043a402fb2daf2091b8f725fd2951743
> +   EDK2-Platforms SHA-1: fc6e3523d868650ad4f8aaac0ccdd8f138370341

It is non-sense to list a required SHA for edk2-platforms when you are 
modifying a package that is inside edk2-platforms. This act of modification 
will result in a different SHA for edk2-platforms.

>  
>  **WhitleyOpenBoardPkg**
>  1. This firmware project has been tested booting to UEFI shell with headless 
> serial console
> -- 
> 2.26.2.windows.1


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

Re: [edk2-devel] [PATCH] PACKAGE_GUID duplication in Intel silicon folders

[Giri Mudusuru via groups.io]

Reviewed-By: Giri Mudusuru 


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

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of Pedro Falcato
> Sent: Thursday, May 2, 2024 10:51 AM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: r...@edk2.groups.io; Leif Lindholm ; Andrew Fish
> (af...@apple.com) 
> Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> Review from email to GitHub Pull Requests on 5-24-2024
> 
> On Wed, May 1, 2024 at 6:44 PM Michael D Kinney via groups.io
>  wrote:
> >
> > Hello,
> >
> > I would like to propose that TianoCore move all code review from email
> > based code reviews to GitHub Pull Requests based code reviews.
> >
> > The proposed date to switch would be immediately after the next stable
> > tag which is currently scheduled for May 24, 2024.
> >
> > Updates to the following Wiki page would be required to describe the
> > required process when using GitHub Pull Requests for all code review
> > related activity.
> >
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> Development-Process
> >
> > A couple examples of the changes that would need to be documented are:
> >
> > * All contributors, maintainers, and reviewers must have GitHub IDs.
> > * The commit message would no longer require Cc:, Reviewed-by:, Acked-
> by:
> >   or Tested-by: tags.  The only required tag would be Signed-off-by.
> 
> I'd just like to note that losing the CC:, Reviewed-by:, etc is a big
> loss. Gerrit auto-adds Rb's, github PR's do not (I'd guess there's a
> way to pull that off with github actions, but I haven't looked). It'll
> be a mess if I have to go through online GH PR backlogs just to find
> who to CC/add-to-review. It kills the decentralized bit off of git too
> :)
> 

Can you provide more details on the impact of the loss?

I am curious how other GitHub projects handle this topic. I see it
is possible with squash and merge to amend the commit message, but
I do not see any features that allow all the commits in a series to
be amended.  TianoCore does not use squash and merge.

The main reason to remove this edit of the commit messages is that
the commit message edits look like a new version of the series to 
git/GitHub and requires review again.  This extra edit is also a
manual process and there is a history of maintainers missing who
did the reviews and acks.  The state in the GitHub PR is always
accurate.

> > * The Pull Request submitter is required to invite the required
> >   maintainers and reviewers to the pull request. This is the same
> >   set of maintainers and reviewers that are required to be listed in
> >   Cc: tags in today's process.
> > * Maintainers are responsible for verifying that all conversations in
> >   the code review are resolved and that all review approvals from the
> >   required set of maintainers are present before setting the 'push'
> label.
> >
> >
> > Please provide feedback
> > 1) If you are not in favor of this change.
> 
> It is sad that we're moving to PRs after I finally got a nice and
> sane(ish!) email workflow (openfw.io + b4). Otherwise, no objections,
> it's better than edk2.git's half-email half-PR frankenprocess.
> I'd guess this change only encompasses edk2.git? How about the other
> repos? Any timeline for those?

The plan is to apply this to all repos, one at a time.  Need to get the
revised process documented and working in one repo before applying to all.

> 
> --
> Pedro
> 
> 
> 
> 



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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Pedro Falcato]

On Wed, May 1, 2024 at 6:44 PM Michael D Kinney via groups.io
 wrote:
>
> Hello,
>
> I would like to propose that TianoCore move all code review from email
> based code reviews to GitHub Pull Requests based code reviews.
>
> The proposed date to switch would be immediately after the next stable
> tag which is currently scheduled for May 24, 2024.
>
> Updates to the following Wiki page would be required to describe the
> required process when using GitHub Pull Requests for all code review
> related activity.
>
> 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
>
> A couple examples of the changes that would need to be documented are:
>
> * All contributors, maintainers, and reviewers must have GitHub IDs.
> * The commit message would no longer require Cc:, Reviewed-by:, Acked-by:
>   or Tested-by: tags.  The only required tag would be Signed-off-by.

I'd just like to note that losing the CC:, Reviewed-by:, etc is a big
loss. Gerrit auto-adds Rb's, github PR's do not (I'd guess there's a
way to pull that off with github actions, but I haven't looked). It'll
be a mess if I have to go through online GH PR backlogs just to find
who to CC/add-to-review. It kills the decentralized bit off of git too
:)

> * The Pull Request submitter is required to invite the required
>   maintainers and reviewers to the pull request. This is the same
>   set of maintainers and reviewers that are required to be listed in
>   Cc: tags in today's process.
> * Maintainers are responsible for verifying that all conversations in
>   the code review are resolved and that all review approvals from the
>   required set of maintainers are present before setting the 'push' label.
>
>
> Please provide feedback
> 1) If you are not in favor of this change.

It is sad that we're moving to PRs after I finally got a nice and
sane(ish!) email workflow (openfw.io + b4). Otherwise, no objections,
it's better than edk2.git's half-email half-PR frankenprocess.
I'd guess this change only encompasses edk2.git? How about the other
repos? Any timeline for those?

-- 
Pedro


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

Re: [edk2-devel] Call or topics for May TianoCore Community Meeting

[Michael D Kinney]

There are 2 meeting times to accommodate time zones.

We can discuss in the meeting later today

Mike

> -Original Message-
> From: Oliver Smith-Denny 
> Sent: Thursday, May 2, 2024 10:04 AM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Subject: Re: [edk2-devel] Call or topics for May TianoCore Community
> Meeting
> 
> Hi Mike,
> 
> Perhaps having a discussion on the PR transition would be good here?
> It would be ideal if we can have a meeting time that is friendly to
> folks on the thread about that (obviously can't accommodate every
> time zone).
> 
> Thanks,
> Oliver
> 
> On 5/1/2024 9:45 AM, Michael D Kinney wrote:
> > Please let me know if you have any topics for the TianoCore Community
> > Meeting this month.
> >
> > Thanks,
> >
> > Mike
> >
> >
> > 
> >


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

Re: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex & wrmsr_ex functions to read/write cpu specific msrs

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Jayaprakash, N 
> Sent: Wednesday, April 24, 2024 11:14 AM
> To: devel@edk2.groups.io; Jayaprakash, N ;
> Kinney, Michael D 
> Cc: Rebecca Cran 
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex &
> wrmsr_ex functions to read/write cpu specific msrs
> 
> Hi Mike,
> 
> I have sent an updated patch v2 for review which uses the MP Services
> protocol API StarupThisAP() to read / write MSRs specific to CPU cores.
> Please review and do the needful.
> 
> Regards,
> JP
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Jayaprakash, N
> Sent: Thursday, April 18, 2024 11:49 AM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Rebecca Cran 
> Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex &
> wrmsr_ex functions to read/write cpu specific msrs
> 
> Thanks Mike. I shall make necessary changes and submit the PR again for
> review.
> 
> Regards,
> JP
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, April 18, 2024 10:46 AM
> To: Jayaprakash, N ; devel@edk2.groups.io
> Cc: Rebecca Cran ; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex &
> wrmsr_ex functions to read/write cpu specific msrs
> 
> Please use MP Services Protocol APIs StartupAllAPs() or StarupThisAP()
> to read/write MSRs on other logical processors.
> 
> There and many examples of this in the UefiCpuPkg to programming MSRs on
> all the logical processors.
> 
> Mike
> 
> > -Original Message-
> > From: Jayaprakash, N 
> > Sent: Wednesday, April 17, 2024 8:16 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io
> > Cc: Rebecca Cran 
> > Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex
> > & wrmsr_ex functions to read/write cpu specific msrs
> >
> > In the validation and debug scenarios, engineers tend to read MSRs and
> > write to MSRs of different CPUs.
> > So we are providing a simple mechanism through these APIs to enable
> > them to do these operations.
> >
> > These APIs will be part of the edk2 module of the Python interpreter
> > and will be used during the validation and debug scenarios only.
> >
> > This is not for switching the BSP for OS boot. This is only used
> > during the validation and debug use cases.
> >
> > Regards,
> > JP
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Thursday, April 18, 2024 12:08 AM
> > To: Jayaprakash, N ; devel@edk2.groups.io
> > Cc: Rebecca Cran ; Kinney, Michael D
> > 
> > Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex
> > & wrmsr_ex functions to read/write cpu specific msrs
> >
> > Hi JP,
> >
> > Is there a reason switch BSP is being used.  That is not a common
> > operation and is typically used if the current BSP is not stable or
> > there is a good reason to switch the BSP for OS boot.
> >
> > The MP Services can be used to execute a C function on APs to execute
> > MSR related instructions.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Jayaprakash, N 
> > > Sent: Sunday, April 14, 2024 10:33 PM
> > > To: devel@edk2.groups.io; Jayaprakash, N 
> > > Cc: Rebecca Cran ; Kinney, Michael D
> > > 
> > > Subject: RE: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add
> > rdmsr_ex
> > > & wrmsr_ex functions to read/write cpu specific msrs
> > >
> > > + Rebecca and Mike,
> > >
> > > Would you be able to review this PR?
> > >
> > > Regards,
> > > JP
> > >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of
> > > Jayaprakash, N
> > > Sent: Wednesday, April 10, 2024 11:49 AM
> > > To: devel@edk2.groups.io
> > > Cc: Jayaprakash, N ; Rebecca Cran
> > > ; Kinney, Michael D 
> > > Subject: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc:add rdmsr_ex &
> > > wrmsr_ex functions to read/write cpu specific msrs
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4746
> > >
> > > The rdmsr_ex and wrmsr_ex are extension APIs to the rdmsr and wrmsr
> > > APIs supported in edk2 module. These extension APIs makes it
> > possible
> > > to read / write MSRs from specific processors and fills an existing
> > > gap in this area.
> > >
> > > Cc: Rebecca Cran 
> > > Cc: Michael D Kinney 
> > > Cc: Jayaprakash N 
> > > Signed-off-by: Jayaprakash N 
> > > ---
> > >  .../PyMod-3.6.8/Modules/edk2module.c  | 159
> > > +-
> > >  .../Python/Python-3.6.8/Python368.inf |   3 +
> > >  2 files changed, 158 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> > > 3.6.8/Modules/edk2module.c b/AppPkg/Applications/Python/Python-
> > > 3.6.8/PyMod-3.6.8/Modules/edk2module.c
> > > index d6af8da..f1b13a6 100644
> > > --- a/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> > > 3.6.8/Modules/edk2module.c
> > > +++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-
> > > 3.6.8/Modules/edk2mo
> > > +++ dule.c
> > > @@ -3,7 +3,7 @@
> > >   

Re: [edk2-devel] Call or topics for May TianoCore Community Meeting

[Oliver Smith-Denny]

Hi Mike,

Perhaps having a discussion on the PR transition would be good here?
It would be ideal if we can have a meeting time that is friendly to
folks on the thread about that (obviously can't accommodate every
time zone).

Thanks,
Oliver

On 5/1/2024 9:45 AM, Michael D Kinney wrote:

Please let me know if you have any topics for the TianoCore Community
Meeting this month.

Thanks,

Mike







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

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

[Oliver Smith-Denny]

Hi Sami,

Great! It's always a good day when the thing you are looking at is
already being worked on :). Looking forward to seeing the patches.

Thanks,
Oliver

On 5/2/2024 7:52 AM, Sami Mujawar wrote:

Hi Oliver,

We are working on a solution to remove the HOB creation logic from StandaloneMm 
for Arm, and this involves implementing the Firmware handoff specification 
(https://github.com/FirmwareHandoff/firmware_handoff/releases/download/v0.9/firmware_handoff.pdf).

As you rightly mentioned this also requires changes in TF-A, and this work is 
in progress.

Levi (Yeo) is currently working on this feature and will post the patches to 
the mailing list once we have the necessary components ready.

Regards,

Sami Mujawar

On 01/05/2024, 22:32, "Oliver Smith-Denny" mailto:o...@linux.microsoft.com>> wrote:


Hi folks, returning to this thread because I noticed that HOB
creation still exists in StandaloneMmCore for ARM:


https://github.com/tianocore/edk2/blob/5d4c5253e8bbc0baa8837fcd868925212df85201/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
 



As far as I can tell, there is only this one file that creates 6
HOBs from StandaloneMmCore. Per our earlier discussion that led to
disabling HOB creation in StandaloneMm, I think that this falls into
the case where StandaloneMm is a HOB consumer phase, not a producer
phase and so it should not be creating these HOBs. On the x64 side,
all of the StandaloneMm HOB creation functions ASSERT with the
comment that StandaloneMm is a HOB consumer phase and should not
be creating HOBs.


On ARM this is more complicated, as all of this information would
seem to originate from TF-A and so we would need TF-A to produce
these HOBs to tell StandaloneMm the information it needs to
operate. Today TF-A already has to communicate this information, the
HOBs are just created in StandaloneMmCore instead of in TF-A.


Curious to get other folks thoughts here on this paradigm.


Thanks,
Oliver


On 12/5/2023 5:47 AM, Nhi Pham wrote:

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 mailto:ardb+tianoc...@kernel.org>>
Cc: Ray Ni mailto:ray...@intel.com>>
Cc: Sami Mujawar mailto:sami.muja...@arm.com>>
Cc: Oliver Smith-Denny mailto:o...@linux.microsoft.com>>
Signed-off-by: Nhi Pham mailto:nhipham...@gmail.com>>
---
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_ADDRESS FreeMemory;

- 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().

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

> -Original Message-
> From: Leif Lindholm 
> Sent: Thursday, May 2, 2024 3:57 AM
> To: devel@edk2.groups.io; mikub...@linux.microsoft.com; Kinney, Michael
> D ; r...@edk2.groups.io
> Cc: Andrew Fish (af...@apple.com) 
> Subject: Re: [edk2-devel] Proposal to switch TianoCore Code Review from
> email to GitHub Pull Requests on 5-24-2024
> 
> On 2024-05-02 04:08, Michael Kubacki wrote:
> > Thank you for this proposal. We've been anticipating this change for
> > years and are excited to help support it.
> >
> > Here's some items we'd like to raise for feedback that we could help
> > implement. Many could likely be done in time for the transition.
> >
> > 1. Automate reviewers - We've discussed CODEOWNERS in the past.
> However,
> > a simpler approach (in maintaining/syncing less files) would be to use
> > Maintainers.txt directly with a GitHub workflow since the file already
> > contains GitHub IDs.
> 
> That would be ideal. I know Mike worked on autogenerating CODEOWNERS
> from Maintainers.txt, but ultimately the latter supports more flexible
> use of wildcards (things like */AArch64/ currently requires reconciling
> against the repo contents).

I have a python script that can verify if there are any differences 
Between CODEOWNERS and Maintainers.txt.  I do not any tools that can
convert Maintainers.txt to CODEOWNERS.  That has been a manual process.

I recommend we identify a plan to switch to CODEOWNERS and drop 
Maintainers.txt. May take a while for everyone to get used to the
differences.

> 
> > 2. Make PR completion contingent on a GitHub review from at least one
> > package maintainer/reviewer for each package in the PR.
> 
> Yes.
> 
> > 3. Dependabot is already used today to automatically create PRs when
> > dependencies like pip modules have updates. To allow this to more
> > effectively keep dependencies up-to-date, allow dependabot PRs to be
> > completed (after normal acceptance criteria like CI and review
> > requirements) without a separate human creating a duplicate PR.
> 
> I am not sure what this means in practice :)
> This doesn't sound like one we need to worry about before switchover
> though.
> 
> > 4. Potentially warn users (with an automated comment on the PR) if
> they
> > add a push label to a PR that is less than 24 hours old.
> 
> That sounds good.
> Is there any way to prevent force-pushes within 24h of previous push?
> That would make setting up a transitional review-scraper less lossy.
> 
> > 5. Leave reminder comments on PRs with absolutely no activity after
> some
> > agreed upon time so reviewers are notified to review the PR without
> the
> > submitter having to watch it and send notifications.
> 
> Yes. But should take priority below 1, 2, and 4. Unless you have a
> pre-cooked thing to drop in of course.
> 
> > 6. Leave reminder comments on PRs that meet all requirements to be
> > completed (all reviews accounted for and status checks pass) but are
> > still open so those on the PR are notified to complete it without the
> > submitter having to manually watch and send reminders.
> 
> Not a response to this, but triggered by reading this:
> Is there any way to approve changes within a PR on a commit by commit
> basis?

Unfortunately, this is not supported.  The approval is al the PR level.
What this means in practice is if there is a single PR with changes
across multiple packages or maintainer responsibility, then the PR
will need approvals from all the required maintainers, and the 
maintainers that wants to apply the 'push' label to merge must
review the set of approvals and make sure all the required ones 
are present.

This check could be automated in the future.

> 
> > 7. We are happy to help with process documentation.
> 
> Always appreciated,thanks.
> 
> Regards,
> 
> Leif



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

Re: [edk2-devel] [RESEND PATCH v4 5/5] DynamicTablesPkg: Adds X64 arch MADT Table generator

[PierreGondois]

Hello Abdul,
some comments on the patch:

On 4/29/24 08:03, Abdul Lateef Attar wrote:

Adds X64 architecture specific MADT/APIC Table generator.
Register/Deregister MADT table.
Adds X64 architecture namespace objects.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
  DynamicTablesPkg/DynamicTables.dsc.inc|   6 +
  .../Include/ConfigurationManagerObject.h  |   1 +
  .../Include/X64NameSpaceObjects.h |  48 +++
  .../X64/AcpiMadtLibX64/AcpiMadtLibX64.inf |  27 ++
  .../Acpi/X64/AcpiMadtLibX64/MadtGenerator.c   | 375 ++
  5 files changed, 457 insertions(+)
  create mode 100644 DynamicTablesPkg/Include/X64NameSpaceObjects.h
  create mode 100644 
DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/AcpiMadtLibX64.inf
  create mode 100644 
DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/MadtGenerator.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index fc2ac5962e..19034e6f65 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -39,6 +39,11 @@
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
  
  [Components.IA32, Components.X64]

+  #
+  # Generators
+  #
+  DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/AcpiMadtLibX64.inf
+
#
# Dynamic Table Factory Dxe
#
@@ -48,6 +53,7 @@
NULL|DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
NULL|DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
NULL|DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
+  NULL|DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/AcpiMadtLibX64.inf
}
  
  [Components.ARM, Components.AARCH64]

diff --git a/DynamicTablesPkg/Include/ConfigurationManagerObject.h 
b/DynamicTablesPkg/Include/ConfigurationManagerObject.h
index f2cfadf3d4..31197eb019 100644
--- a/DynamicTablesPkg/Include/ConfigurationManagerObject.h
+++ b/DynamicTablesPkg/Include/ConfigurationManagerObject.h
@@ -110,6 +110,7 @@ typedef enum ObjectNameSpaceID {
EObjNameSpaceStandard,  ///< Standard Objects Namespace
EObjNameSpaceArm,   ///< ARM Objects Namespace
EObjNameSpaceArch,  ///< Arch Objects Namespace
+  EObjNameSpaceX64,   ///< X64 Objects Namespace
EObjNameSpaceOem = 0x8, ///< OEM Objects Namespace
EObjNameSpaceMax
  } EOBJECT_NAMESPACE_ID;
diff --git a/DynamicTablesPkg/Include/X64NameSpaceObjects.h 
b/DynamicTablesPkg/Include/X64NameSpaceObjects.h
new file mode 100644
index 00..cd5c1ff43c
--- /dev/null
+++ b/DynamicTablesPkg/Include/X64NameSpaceObjects.h
@@ -0,0 +1,48 @@
+/** @file
+
+  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+- X64- X64 processor architecture
+  **/
+
+#ifndef X64_NAMESPACE_OBJECT_H_
+#define X64_NAMESPACE_OBJECT_H_
+
+/** The EX64_OBJECT_ID enum describes the Object IDs
+in the X64 Namespace
+*/
+typedef enum X64ObjectID {
+  EX64ObjReserved, ///<  0 - Reserved
+  EX64ObjMadtLocalInterruptInfo,   ///<  1 - MADT Local Interrupt 
Information
+  EX64ObjMadtProcessorLocalApicX2ApicInfo, ///<  2 - MADT Local APIC/x2APIC 
Controller Information
+  EX64ObjMadtIoApicInfo,   ///<  3 - MADT IOAPIC Information
+  EX64ObjMadtLocalApicX2ApicNmiInfo,   ///<  4 - MADT Local APIC/x2APIC 
NMI Information
+  EX64ObjMadtInterruptSourceOverrideInfo,  ///<  5 - MADT Interrupt Override 
Information
+  EX64ObjMax
+} E_X64_OBJECT_ID;
+
+/** A structure that describes the
+MADT Local Interrupt Information for the Platform.
+
+ID: EX64ObjMadtLocalInterruptInfo
+*/
+typedef struct CmX64MadtLocalInterruptInfo {
+  UINT32LocalApicAddress; ///< Local Interrupt Controller Address
+  UINT32Flags;///< Flags
+} CM_X64_MADT_LOCAL_INTERRUPT_INFO;
+
+/** A structure that describes the
+MADT Interrupt controller type information for the platform.
+
+ID: EX64ObjMadtInterruptControllerTypeInfo
+*/
+typedef struct CmX64MadtInterruptControllerTypeInfo {
+  VOID *InterruptControllerTypeInfo; ///< Interrupt Controller Type 
Information


Cf. the comment in:
   [PATCH v4 2/5] DynamicTablesPkg: Adds ACPI HPET Table generator
the information should be stored in CmObj, as (for instance):
{
   UINT32   InterruptNumber;
   UINT32   Flags;
   UINT64   BaseAddress;
   ...
}

Here you are kind of bypassing the framework by using a VOID* pointer.
The interest of storing the information in objects is that this information
can be re-used at multiple places.
For instance for Arm, GicC information is used to generate the MADT table,
but also used for to generate the PPTT, SRAT, SSDT topology tables.

If the information is generic, multiple IDs can correspond to on CM_OBJ
structure as you did, but fields containing real data shou

Re: [edk2-devel] [RESEND PATCH v4 4/5] DynamicTablesPkg: Adds ACPI SSDT HPET Table generator

[PierreGondois]

Hello Abdul,
some comments on the patch:

On 4/29/24 08:03, Abdul Lateef Attar wrote:

Adds generic ACPI SSDT HPET table generator library.
Register/Deregister HPET table.
Adds ACPI namespace object for HPET device.
Adds Address space for HPET device.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
  DynamicTablesPkg/DynamicTables.dsc.inc|   2 +
  DynamicTablesPkg/Include/AcpiTableGenerator.h |   2 +
  .../Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf  |  32 ++
  .../Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c  | 295 ++
  4 files changed, 331 insertions(+)
  create mode 100644 
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
  create mode 100644 
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index 477dc6b6a9..fc2ac5962e 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -36,6 +36,7 @@
DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
+  DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf


Same comment as in:
[PATCH v4 2/5] DynamicTablesPkg: Adds ACPI HPET Table generator
about:
[Components.IA32, Components.X64]
also if the table is Intel specific, maybe the generator should be placed under:
   DynamicTablesPkg/Library/Acpi/X64/
   (or a better folder name)
also I think the CmObject should be moved to:
   X64NameSpaceObjects.h

  
  [Components.IA32, Components.X64]

#
@@ -46,6 +47,7 @@
NULL|DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
NULL|DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
NULL|DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
+  NULL|DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
}
  
  [Components.ARM, Components.AARCH64]

diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h


[snip]


+
+  Status = AmlCodeGenNameInteger ("_HID", EisaId, HpetNode, NULL);
+  if (EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+goto exit_handler;
+  }
+
+  Status = AmlCodeGenNameInteger ("_UID", 0x00, HpetNode, NULL);


In case there as multiple HPET,
I think this should be set to HpetBaseAddress->HpetNumber


+  if (EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+goto exit_handler;
+  }
+
+  Status = AmlCodeGenNameResourceTemplate ("_CRS", HpetNode, &CrsNode);
+  if (EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+goto exit_handler;
+  }
+
+  Status = AmlCodeGenRdMemory32Fixed (FALSE, 
(UINT32)HpetBaseAddress->BaseAddress, SIZE_1KB, CrsNode, NULL);


Will this always be readonly ? Or could it be a ReadWrite parameter ?
If unsure, this shouldn't be too hard to patch in the future.


+  if (EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+goto exit_handler;
+  }
+


[snip]


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

Re: [edk2-devel] [RESEND PATCH v4 3/5] DynamicTablesPkg: Adds ACPI WSMT Table generator

[PierreGondois]

Hello Abdul,
some comments on the patch:

On 4/29/24 08:03, Abdul Lateef Attar wrote:

Adds generic ACPI WSMT table generator library.
Register/Deregister WSMT table.
Update the WSMT table during boot as per specification.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
  DynamicTablesPkg/DynamicTables.dsc.inc|   2 +
  DynamicTablesPkg/Include/AcpiTableGenerator.h |   1 +
  .../Include/ArchNameSpaceObjects.h|  11 +
  .../Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf  |  30 +++
  .../Library/Acpi/AcpiWsmtLib/WsmtGenerator.c  | 243 ++
  5 files changed, 287 insertions(+)
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index b2ef36eb8a..477dc6b6a9 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -35,6 +35,7 @@
#
DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
+  DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf


Same comment as in:
[PATCH v4 2/5] DynamicTablesPkg: Adds ACPI HPET Table generator
about:
[Components.IA32, Components.X64]
also if the table is Intel specific, maybe the generator should be placed under:
   DynamicTablesPkg/Library/Acpi/X64/
   (or a better folder name)
also I think the CmObject should be moved to:
   X64NameSpaceObjects.h

  
  [Components.IA32, Components.X64]

#
@@ -44,6 +45,7 @@
  
NULL|DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
NULL|DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
+  NULL|DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
}
  
  [Components.ARM, Components.AARCH64]

diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h
index 18b5f99f47..a32ef46ecb 100644
--- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
+++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
@@ -100,6 +100,7 @@ typedef enum StdAcpiTableId {
EStdAcpiTableIdSsdtPciExpress,///< SSDT Pci Express 
Generator
EStdAcpiTableIdPcct,  ///< PCCT Generator
EStdAcpiTableIdHpet,  ///< HPET Generator
+  EStdAcpiTableIdWsmt,  ///< WSMT Generator
EStdAcpiTableIdMax
  } ESTD_ACPI_TABLE_ID;
  
diff --git a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h

index b90e573a88..8b16056ba1 100644
--- a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
@@ -40,6 +40,7 @@ typedef enum ArchObjectID {
EArchObjFadtHypervisorVendorId, ///< 12 - Hypervisor vendor identity 
information
EArchObjFadtMiscInfo,   ///< 13 - Legacy fields; RTC, latency, 
flush stride, etc
EArchObjHpetBaseAddress,///< 14 - HPET Base Address
+  EArchObjWsmtProtectionFlags,///< 15 - WSMT protection flags
EArchObjMax
  } E_ARCH_OBJECT_ID;
  
@@ -223,4 +224,14 @@ typedef struct CmArchFadtMiscInfo {

  typedef struct CmArchHpetBaseAddress {
UINT64BaseAddress;
  } CM_ARCH_HPET_BASE_ADDRESS;
+
+/** A structure that describes the
+protection flags for the WSMT fields information.
+
+ID: EArchObjWsmtProtectionFlags
+*/
+typedef struct CmArchWsmtProtectionFlags {
+  UINT32ProtectionFlags;
+} CM_ARCH_WSMT_PROTECTION_FLAGS;
+
  #endif
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf 
b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
new file mode 100644
index 00..80ddaf0ab4
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
@@ -0,0 +1,30 @@
+## @file
+#  WSMT Table Generator
+#
+#  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 1.27
+  BASE_NAME  = AcpiWsmtLib
+  FILE_GUID  = D6C34086-C914-4F8E-B56A-08329B4D1271
+  VERSION_STRING = 1.0
+  MODULE_TYPE= DXE_DRIVER
+  LIBRARY_CLASS  = NULL|DXE_DRIVER
+  CONSTRUCTOR= AcpiWsmtLibConstructor
+  DESTRUCTOR = AcpiWsmtLibDestructor
+
+[Sources]
+  WsmtGenerator.c
+
+[Packages]
+  DynamicTablesPkg/DynamicTablesPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
new file mode 100644
index 00..a63b4b4859
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
@@ -0,0 +1,243 @@
+/** @file
+  WSMT Table Generator
+
+  Copyright (c) 2017 - 2023, Arm Limited. All rights reserved.
+  Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserv

Re: [edk2-devel] [RESEND PATCH v4 2/5] DynamicTablesPkg: Adds ACPI HPET Table generator

[PierreGondois]

Hello Abdul,
some comments on the patch:

On 4/29/24 08:03, Abdul Lateef Attar wrote:

Adds generic ACPI HPET table generator library.
Register/Deregister HPET table.
Update the HPET table during boot as per specification.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Signed-off-by: Abdul Lateef Attar 
---
  DynamicTablesPkg/DynamicTables.dsc.inc|   2 +
  DynamicTablesPkg/Include/AcpiTableGenerator.h |   1 +
  .../Include/ArchNameSpaceObjects.h|   9 +
  .../Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf  |  31 +++
  .../Library/Acpi/AcpiHpetLib/HpetGenerator.c  | 246 ++
  5 files changed, 289 insertions(+)
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index 92f3a138e4..b2ef36eb8a 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -34,6 +34,7 @@
# Generators
#
DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
+  DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf


I think this should be moved to the following section if the table if for Intel 
arch.
Like this it would allow avoiding to build the generator for other archs.

[Components.IA32, Components.X64]
 #
 # Generators
 #
...

also if the table is Intel specific, maybe the generator should be placed under:
   DynamicTablesPkg/Library/Acpi/X64/
   (or a better folder name)
also I think the CmObject should be moved to:
   X64NameSpaceObjects.h

  
  [Components.IA32, Components.X64]

#
@@ -42,6 +43,7 @@
DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf {
  
NULL|DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
+  NULL|DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
}
  
  [Components.ARM, Components.AARCH64]

diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h
index d0eda011c3..18b5f99f47 100644
--- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
+++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
@@ -99,6 +99,7 @@ typedef enum StdAcpiTableId {
EStdAcpiTableIdSsdtCpuTopology,   ///< SSDT Cpu Topology
EStdAcpiTableIdSsdtPciExpress,///< SSDT Pci Express 
Generator
EStdAcpiTableIdPcct,  ///< PCCT Generator
+  EStdAcpiTableIdHpet,  ///< HPET Generator
EStdAcpiTableIdMax
  } ESTD_ACPI_TABLE_ID;
  
diff --git a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h

index b421c4cd29..b90e573a88 100644
--- a/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArchNameSpaceObjects.h
@@ -39,6 +39,7 @@ typedef enum ArchObjectID {
EArchObjFadtArmBootArch,///< 11 - ARM boot arch information
EArchObjFadtHypervisorVendorId, ///< 12 - Hypervisor vendor identity 
information
EArchObjFadtMiscInfo,   ///< 13 - Legacy fields; RTC, latency, 
flush stride, etc
+  EArchObjHpetBaseAddress,///< 14 - HPET Base Address
EArchObjMax
  } E_ARCH_OBJECT_ID;
  
@@ -214,4 +215,12 @@ typedef struct CmArchFadtMiscInfo {

UINT8 Century;
  } CM_ARCH_FADT_MISC_INFO;
  
+/** A structure that describes the

+HPET Base Address.
+
+ID: EArchObjHpetBaseAddress
+*/
+typedef struct CmArchHpetBaseAddress {
+  UINT64BaseAddress;
+} CM_ARCH_HPET_BASE_ADDRESS;


Would it make sense to have these fields for the CmObj ?
typedef struct CmArchHpetBaseAddress {
 UINT32EventTimerBlockId;
 UINT32BaseAddressLower32Bit;
 UINT8 HpetNumber;
 UINT16MainCounterMinimumClockTickInPeriodicMode;
 UINT8 PageProtectionAndOemAttribute;
} CM_ARCH_HPET_BASE_ADDRESS;

The reason being that:
- Ideally the DynamicTables generators should just generate ACPI tables
 from the CmObject they are given. The ConfigurationManager being a
 database providing information.
 Doing Mmio accesses to populate the ACPI tables breaks a bit the design:
 the generators would also become a source of information.
- If the Mmio accesses are possible from the generator, they should also
 be possible from the ConfigurationManager.
- Imagining a platform with an invalid value for the 
MainCounterMinimumClockTickInPeriodicMode,
 as the generator is generic to all platforms, it becomes hard to patch 
this.
 The ConfigurationManager is supposed to be platform specific, so if
 the MainCounterMinimumClockTickInPeriodicMode register is invalid,
 it is easy to patch this specific ConfigurationManager and keep a generic
 HPET generator.

(I am refering to MmioRead32 accesses from [1])


  #endif
diff --git a/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf 
b/DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf

Re: [edk2-devel] [RESEND PATCH v4 0/5] DynamicTablesPkg: Adds FADT, HPET, WSMT and MADT Table generators

[PierreGondois]

Hello Abdul,
I added some comments.
I think that:
a. patches related to HPET/WSMT should require little work
b. MADT patch needs to redefine the CmObjects it uses,
   but it seems ok otherwise (just need to have the right properties
   in the right objects),
c. FADT patch is re-defining CmObjects that are already existing
   in ArmNameSpaceObjects.h. So there is going to be a clash with
   ongoing DynamicTables objects reorganization...

I think that a. could be sent separately and should quickly go in,
b. might require a bit more checking/reviewing, and c. might need
to wait for the re-org to be finished, unless Sami thinks it's ok
to take the patch,

Regards,
Pierre


On 4/29/24 08:03, Abdul Lateef Attar wrote:

PR: https://github.com/tianocore/edk2/pull/5500/
V4: delta changes
   Added X64 arch specific MADT table generator.
V3: delta changes
   Restructure the code as the review comments.
   Added sanity check for WSMT flags.
   Added CM object for HPET base address.
V2: delta changes
   Addressed review comments
   Adds ACPI HPET table to add HPET to ACPI namespace
V1:
Adds new space for ArchNameSpaceObjects.
Adds generic FADT table generator.
Adds generic HPET table generator.
Adds generic WSMT table generator.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Cc: Abdul Lateef Attar 

Abdul Lateef Attar (5):
   DynamicTablesPkg: Adds ACPI FADT Table generator
   DynamicTablesPkg: Adds ACPI HPET Table generator
   DynamicTablesPkg: Adds ACPI WSMT Table generator
   DynamicTablesPkg: Adds ACPI SSDT HPET Table generator
   DynamicTablesPkg: Adds X64 arch MADT Table generator

  DynamicTablesPkg/DynamicTables.dsc.inc|  22 +-
  DynamicTablesPkg/DynamicTablesPkg.ci.yaml |   4 +-
  DynamicTablesPkg/Include/AcpiTableGenerator.h |   4 +
  .../Include/ArchNameSpaceObjects.h| 237 ++
  .../Include/ConfigurationManagerObject.h  |   7 +
  .../Include/X64NameSpaceObjects.h |  48 ++
  .../Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf  |  36 +
  .../Library/Acpi/AcpiFadtLib/Arm/FadtUpdate.c |  39 +
  .../Library/Acpi/AcpiFadtLib/FadtGenerator.c  | 745 ++
  .../Library/Acpi/AcpiFadtLib/FadtUpdate.h |  26 +
  .../Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c |  32 +
  .../Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf  |  31 +
  .../Library/Acpi/AcpiHpetLib/HpetGenerator.c  | 246 ++
  .../Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf  |  32 +
  .../Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c  | 295 +++
  .../Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf  |  30 +
  .../Library/Acpi/AcpiWsmtLib/WsmtGenerator.c  | 243 ++
  .../X64/AcpiMadtLibX64/AcpiMadtLibX64.inf |  27 +
  .../Acpi/X64/AcpiMadtLibX64/MadtGenerator.c   | 375 +
  19 files changed, 2477 insertions(+), 2 deletions(-)
  create mode 100644 DynamicTablesPkg/Include/ArchNameSpaceObjects.h
  create mode 100644 DynamicTablesPkg/Include/X64NameSpaceObjects.h
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/Arm/FadtUpdate.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtGenerator.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtUpdate.h
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c
  create mode 100644 
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
  create mode 100644 
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
  create mode 100644 
DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/AcpiMadtLibX64.inf
  create mode 100644 
DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/MadtGenerator.c




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

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of Brian J.
> Johnson
> Sent: Thursday, May 2, 2024 8:59 AM
> To: devel@edk2.groups.io; dionnagl...@google.com;
> quic_llind...@quicinc.com
> Cc: Kinney, Michael D ; r...@edk2.groups.io;
> Andrew Fish (af...@apple.com) 
> Subject: Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code
> Review from email to GitHub Pull Requests on 5-24-2024
> 
> On 5/1/24 18:19, Dionna Glaze via groups.io wrote:
> > On Wed, May 1, 2024 at 11:12 AM Leif Lindholm via groups.io
> >  wrote:
> >>
> >> On 2024-05-01 18:43, Michael D Kinney wrote:
> >>> Hello,
> >>>
> >>> I would like to propose that TianoCore move all code review from
> email
> >>> based code reviews to GitHub Pull Requests based code reviews.
> >>>
> >>> The proposed date to switch would be immediately after the next
> stable
> >>> tag which is currently scheduled for May 24, 2024.
> >>
> >> Thanks Mike.
> >>
> >> I'm in favour of this change, and the date.
> >>
> >> I still want us to try to figure out how to retain review history
> beyond
> >> what github decides we need, but I don't think it justifies
> indefinitely
> >> delaying the switchover. And frankly, it will be easier to experiment
> >> with what works and not after the switch.
> >
> > +1. UI-based interactions don't export well for archival-permalinking
> > reasons, and Github archive behavior is for repositories only, not the
> > reviews.
> > But yes, wouldn't want to delay for a bot to echo conversations to
> > devel@edk2.groups.io or some other solution.
> >
> 
> +1 from me as well.  We need to maintain review history in some fairly
> permanent manner, both the reviewed code and review comments.
> 
> >>
> >> /
> >>   Leif
> >>
> >>> Updates to the following Wiki page would be required to describe the
> >>> required process when using GitHub Pull Requests for all code review
> >>> related activity.
> >>>
> >>>   https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> Development-Process
> >>>
> >>> A couple examples of the changes that would need to be documented
> are:
> >>>
> >>> * All contributors, maintainers, and reviewers must have GitHub IDs.
> >
> > It looks like this is already resolved for the existing
> > Maintainers.txt with the `[username]` syntax, but I don't see any
> > explanation of that expectation. Seems fine to me.
> >
> >>> * The commit message would no longer require Cc:, Reviewed-by:,
> Acked-by:
> >>> or Tested-by: tags.  The only required tag would be Signed-off-
> by.
> 
> Would those tags be optional?  Test and ack info can be helpful when
> researching a change, to find people who may be knowledgeable about it.
> 
> Similarly, the Reviewed-by info is nice to have in the history, without
> having to dig it out of archives.  But it's a bit awkward to add on
> github:  you have to push new commits with the Reviewed-by tags, but
> that changes the SHAs, so it's not obvious that the commits you're
> merging have the same code as the ones which were reviewed.  For the
> email flow, we trust maintainers to get this right.  For the github
> flow, are we deciding to rely exclusively on the PR archives?
> 
> What if a maintainer decides to tweak a commit before merging it, eg. to
> fix a trivial typo?  With the email flow they just go ahead and do it.
> With the github flow, would they need to post another PR, so it could
> make it through the process and be merged?
> 

Editing commit messages after reviews is something we want to avoid so
the PR does not need to be re-reviewed to be merged.  GitHub has history
of who did the reviews and the conversations that can include information
on testing and review activity.

Yes.  Even trivial changes to the code would require the PR to be updated
and re-reviewed.  It is a different process than email where we allowed
maintainers to make minor changes.  However, even a maintainer making a 
minor change could break things in unexpected ways.  It seems better to
have stricter control over changes and all changes are reviewed and go 
through CI.

> >>> * The Pull Request submitter is required to invite the required
> >>> maintainers and reviewers to the pull request. This is the same
> >>> set of maintainers and reviewers that are required to be listed
> in
> >>> Cc: tags in today's process.
> >
> > This is not configured on tianocore/edk2 at the moment. I have no way
> > to invite a reviewer. Is this a planned fix?
> >
> >>> * Maintainers are responsible for verifying that all conversations
> in
> >>> the code review are resolved and that all review approvals from
> the
> >>> required set of maintainers are present before setting the
> 'push' label.
> 
> Will there be documentation on how to use the conversation resolution
> feature?  It's unclear to me whether the PR owner or the reviewer is
> responsible for marking a conversation "resolved."

Please help with proposals for the updated documentation that covers 
this topic.

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael D Kinney]

Hi Michael,

I have a version of the auto assignment working, but needs to be 
migrated to TianoCore and synced with the latest Maintainers.txt.

My experience getting this running even as a POC was that it took a lot
of effort to make sure the best security practices were followed and
to configure the empty GitHub App with tokens and permissions. Anytime
custom actions are added, resources to implement, validate, and 
support if they ever fail must be in place.

My question is if there is a manual process that can be used to 
start and these type of automations can be added over time as 
dedicated resources are identified.

Dionna's feedback about contributors not being able to add reviewers
to a PR is correct.  Contributors that are not members of the 
EDK II Maintainers or EDK II Reviewers teams will either need to wait
for a Maintainer or Reviewer to add reviewers, or the contributor must
be added as an "outside collaborator" by an admin. For a manual process
this would require Maintainers to monitor new PRs and make sure the
correct set of Maintainers and Reviewers are added. Perhaps the 
contributor can include @GitHubId mentions in the PR for the required
maintainers/reviewers so there are email notifications.

Details on the auto assignment POC
==
It uses CODEOWNERS so maintainers are auto assigned and can use GitHub
features to prevent merges without maintainer approval.  The idea is to
minimize the custom behavior and use as many built-in GitHub features as
possible.  It then reuses the CODEOWNERS syntax for a new file called
REVIEWERS along with some GitHub Actions to auto assign reviewers.  The
actions are run by a registered empty GitHub application so it has a
TianoCore organization bot that is executing the actions with TianoCore
org permissions instead of an individual TianoCore member permissions. 
Example PR with the bot with the name "tianocore-assign-reviewers" 
performing assignments:
https://github.com/tianocore/edk2-codereview/pull/91

It was activated on this repo to run experiments:
https://github.com/tianocore/edk2-codereview/tree/master/.github

Example CODEOWNERS file:
https://github.com/tianocore/edk2-codereview/blob/master/.github/CODEOWNERS

Example REVIEWERS file using same format as CODEOWNERS
https://github.com/tianocore/edk2-codereview/blob/master/.github/REVIEWERS

Action to assign reviewers from REVIEWERS file:

https://github.com/tianocore/edk2-codereview/blob/master/.github/workflows/AssignReviewers.yml

Depends on: https://github.com/mdkinney/github-action-assign-reviewers

Action to verify that all files in a repo have CODEOWNES coverage

https://github.com/tianocore/edk2-codereview/blob/master/.github/workflows/CheckCodeOwnerFiles.yml

Action to verify that Maintainers.txt, CODEOWNERS, and REVIEWERS are synced.
This is to support transition from using Maintainers.txt to using CODEOWNERS
and REVIEWERS and can be dropped when Maintainers.txt is removed.

https://github.com/tianocore/edk2-codereview/blob/master/.github/workflows/CheckCodeOwnerMaintainers.yml

Depends on: 
https://github.com/mdkinney/github-action-check-codeowners-maintainers

Thanks,

Mike

> -Original Message-
> From: Michael Kubacki 
> Sent: Thursday, May 2, 2024 8:21 AM
> To: devel@edk2.groups.io; quic_llind...@quicinc.com;
> marcin.juszkiew...@linaro.org; Kinney, Michael D
> ; r...@edk2.groups.io
> Cc: Leif Lindholm ; Andrew Fish (af...@apple.com)
> 
> Subject: Re: [edk2-devel] Proposal to switch TianoCore Code Review from
> email to GitHub Pull Requests on 5-24-2024
> 
> On 5/2/2024 6:34 AM, Leif Lindholm wrote:
> > On 2024-05-02 07:33, Marcin Juszkiewicz wrote:
> >> W dniu 1.05.2024 o 19:43, Michael D Kinney via groups.io pisze:
> >>> I would like to propose that TianoCore move all code review from
> email
> >>> based code reviews to GitHub Pull Requests based code reviews.
> >>>
> >>> The proposed date to switch would be immediately after the next
> stable
> >>> tag which is currently scheduled for May 24, 2024.
> >>
> >> O yes! Fully for it!
> >>
> >> Does it mean edk2 only or edk2/edk2-platforms/edk2-non-osi and other
> >> tianocore/ repositories?
> >
> > I don't see why we couldn't switch all of them. Other than we need to
> > get all the Maintainers.txt updated with code forge usernames first.
> >
> > We may want to do one at a time though.
> >
> > /
> >      Leif
> >
> >>> * The Pull Request submitter is required to invite the required
> >>>    maintainers and reviewers to the pull request. This is the same
> >>>    set of maintainers and reviewers that are required to be listed
> in
> >>>    Cc: tags in today's process.
> >>
> >> That can be done by github action started automatically after opening
> >> PR. May require changes to GetMaintainer.py script. Would be good to
> >> have in case someone forget to add one of maintainers.
> >>
> >> Also would be nice to have a bot running PatchCheck and uncrustify on
> PR.

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Dionna Glaze via groups.io]

On Thu, May 2, 2024 at 8:59 AM Brian J. Johnson  wrote:
>
> On 5/1/24 18:19, Dionna Glaze via groups.io wrote:
> > On Wed, May 1, 2024 at 11:12 AM Leif Lindholm via groups.io
> >  wrote:
> >>
> >> On 2024-05-01 18:43, Michael D Kinney wrote:
> >>> Hello,
> >>>
> >>> I would like to propose that TianoCore move all code review from email
> >>> based code reviews to GitHub Pull Requests based code reviews.
> >>>
> >>> The proposed date to switch would be immediately after the next stable
> >>> tag which is currently scheduled for May 24, 2024.
> >>
> >> Thanks Mike.
> >>
> >> I'm in favour of this change, and the date.
> >>
> >> I still want us to try to figure out how to retain review history beyond
> >> what github decides we need, but I don't think it justifies indefinitely
> >> delaying the switchover. And frankly, it will be easier to experiment
> >> with what works and not after the switch.
> >
> > +1. UI-based interactions don't export well for archival-permalinking
> > reasons, and Github archive behavior is for repositories only, not the
> > reviews.
> > But yes, wouldn't want to delay for a bot to echo conversations to
> > devel@edk2.groups.io or some other solution.
> >
>
> +1 from me as well.  We need to maintain review history in some fairly
> permanent manner, both the reviewed code and review comments.
>
> >>
> >> /
> >>   Leif
> >>
> >>> Updates to the following Wiki page would be required to describe the
> >>> required process when using GitHub Pull Requests for all code review
> >>> related activity.
> >>>
> >>>   
> >>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
> >>>
> >>> A couple examples of the changes that would need to be documented are:
> >>>
> >>> * All contributors, maintainers, and reviewers must have GitHub IDs.
> >
> > It looks like this is already resolved for the existing
> > Maintainers.txt with the `[username]` syntax, but I don't see any
> > explanation of that expectation. Seems fine to me.
> >
> >>> * The commit message would no longer require Cc:, Reviewed-by:, Acked-by:
> >>> or Tested-by: tags.  The only required tag would be Signed-off-by.
>
> Would those tags be optional?  Test and ack info can be helpful when
> researching a change, to find people who may be knowledgeable about it.
>
> Similarly, the Reviewed-by info is nice to have in the history, without
> having to dig it out of archives.  But it's a bit awkward to add on
> github:  you have to push new commits with the Reviewed-by tags, but
> that changes the SHAs, so it's not obvious that the commits you're
> merging have the same code as the ones which were reviewed.  For the
> email flow, we trust maintainers to get this right.  For the github
> flow, are we deciding to rely exclusively on the PR archives?
>
> What if a maintainer decides to tweak a commit before merging it, eg. to
> fix a trivial typo?  With the email flow they just go ahead and do it.
> With the github flow, would they need to post another PR, so it could
> make it through the process and be merged?
>
> >>> * The Pull Request submitter is required to invite the required
> >>> maintainers and reviewers to the pull request. This is the same
> >>> set of maintainers and reviewers that are required to be listed in
> >>> Cc: tags in today's process.
> >
> > This is not configured on tianocore/edk2 at the moment. I have no way
> > to invite a reviewer. Is this a planned fix?
> >
> >>> * Maintainers are responsible for verifying that all conversations in
> >>> the code review are resolved and that all review approvals from the
> >>> required set of maintainers are present before setting the 'push' 
> >>> label.
>
> Will there be documentation on how to use the conversation resolution
> feature?  It's unclear to me whether the PR owner or the reviewer is
> responsible for marking a conversation "resolved."
>

Github has branch security features that let you _require_ that all
messages are resolved before merging, so that could be turned on.

> >>>
> >>>
> >>> Please provide feedback
> >>> 1) If you are not in favor of this change.
> >>> 2) If you are not in favor of the proposed date of this change.
> >>> 3) On the process changes you would like to see documented in the Wiki
> >>>  pages related to using GitHub Pull Request based code reviews.
> >>>
> >>> There is some prototype work to automate/simplify some of the PR based
> >>> code review process steps. Those could be added over time as resources
> >>> are available to finish and support them.
> >>>
> >>> Best regards,
> >>>
> >>> Mike
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
> --
>
>  Brian
>
> 
>
>"The answers we have found only serve to raise a whole set of new
> questions.  In some ways we feel we are as confused as ever, but we
> are confused on a higher level an

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Brian J. Johnson]

On 5/1/24 18:19, Dionna Glaze via groups.io wrote:

On Wed, May 1, 2024 at 11:12 AM Leif Lindholm via groups.io
 wrote:


On 2024-05-01 18:43, Michael D Kinney wrote:

Hello,

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


Thanks Mike.

I'm in favour of this change, and the date.

I still want us to try to figure out how to retain review history beyond
what github decides we need, but I don't think it justifies indefinitely
delaying the switchover. And frankly, it will be easier to experiment
with what works and not after the switch.


+1. UI-based interactions don't export well for archival-permalinking
reasons, and Github archive behavior is for repositories only, not the
reviews.
But yes, wouldn't want to delay for a bot to echo conversations to
devel@edk2.groups.io or some other solution.



+1 from me as well.  We need to maintain review history in some fairly 
permanent manner, both the reviewed code and review comments.




/
  Leif


Updates to the following Wiki page would be required to describe the
required process when using GitHub Pull Requests for all code review
related activity.

  
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

A couple examples of the changes that would need to be documented are:

* All contributors, maintainers, and reviewers must have GitHub IDs.


It looks like this is already resolved for the existing
Maintainers.txt with the `[username]` syntax, but I don't see any
explanation of that expectation. Seems fine to me.


* The commit message would no longer require Cc:, Reviewed-by:, Acked-by:
or Tested-by: tags.  The only required tag would be Signed-off-by.


Would those tags be optional?  Test and ack info can be helpful when 
researching a change, to find people who may be knowledgeable about it.


Similarly, the Reviewed-by info is nice to have in the history, without 
having to dig it out of archives.  But it's a bit awkward to add on 
github:  you have to push new commits with the Reviewed-by tags, but 
that changes the SHAs, so it's not obvious that the commits you're 
merging have the same code as the ones which were reviewed.  For the 
email flow, we trust maintainers to get this right.  For the github 
flow, are we deciding to rely exclusively on the PR archives?


What if a maintainer decides to tweak a commit before merging it, eg. to 
fix a trivial typo?  With the email flow they just go ahead and do it. 
With the github flow, would they need to post another PR, so it could 
make it through the process and be merged?



* The Pull Request submitter is required to invite the required
maintainers and reviewers to the pull request. This is the same
set of maintainers and reviewers that are required to be listed in
Cc: tags in today's process.


This is not configured on tianocore/edk2 at the moment. I have no way
to invite a reviewer. Is this a planned fix?


* Maintainers are responsible for verifying that all conversations in
the code review are resolved and that all review approvals from the
required set of maintainers are present before setting the 'push' label.


Will there be documentation on how to use the conversation resolution 
feature?  It's unclear to me whether the PR owner or the reviewer is 
responsible for marking a conversation "resolved."





Please provide feedback
1) If you are not in favor of this change.
2) If you are not in favor of the proposed date of this change.
3) On the process changes you would like to see documented in the Wiki
 pages related to using GitHub Pull Request based code reviews.

There is some prototype work to automate/simplify some of the PR based
code review process steps. Those could be added over time as resources
are available to finish and support them.

Best regards,

Mike

















--

Brian



  "The answers we have found only serve to raise a whole set of new
   questions.  In some ways we feel we are as confused as ever, but we
   are confused on a higher level and about more important things."
   -- Anonymous



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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael Kubacki]

On 5/2/2024 6:34 AM, Leif Lindholm wrote:

On 2024-05-02 07:33, Marcin Juszkiewicz wrote:

W dniu 1.05.2024 o 19:43, Michael D Kinney via groups.io pisze:

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


O yes! Fully for it!

Does it mean edk2 only or edk2/edk2-platforms/edk2-non-osi and other 
tianocore/ repositories?


I don't see why we couldn't switch all of them. Other than we need to 
get all the Maintainers.txt updated with code forge usernames first.


We may want to do one at a time though.

/
     Leif


* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


That can be done by github action started automatically after opening 
PR. May require changes to GetMaintainer.py script. Would be good to 
have in case someone forget to add one of maintainers.


Also would be nice to have a bot running PatchCheck and uncrustify on PR.

Yes, this would need to be in a GitHub workflow so it could parse the 
file and ultimately use the GitHub API to add the maintainers. As I 
mentioned in another email, my team has experience doing this and we're 
happy to help where we can.
















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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Michael Kubacki]

On 5/2/2024 5:37 AM, Ard Biesheuvel wrote:

On Wed, 1 May 2024 at 19:44, Michael D Kinney
 wrote:


Hello,

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.



+1

Some kind of off-github reflector similar to rebecca's public inbox
[0] would be appreciated to at least be able to keep track of
different versions of a series exactly as they were submitted. One of
the things that annoys me about doing GitHub reviews is dealing with
PRs where the underlying branches gets updated through a force-push
and there is no way to find out what changed, and whether the existing
review comments are still in sync.

Would it be possible to require a separate PR for each revision of a
series, lock the underlying branch, and archive it for future
reference (if desired?)



In order for this to be as intuitive and effective as possible, I 
suggest we stick with conventional usage. A single PR allows:


1. A single place to track all of the changes to the contribution 
including force pushes.


2. Clean (less cluttered) PR history where each unique contribution is 
represented by a single PR.


3. References to the PR such as comments, other PRs, and GitHub issues 
to automatically be reflected on the PR. This allows work related to the 
PR such as tracking issue items, future bug fix PRs, etc. to be easily 
found from the original PR.


The consistent PR number is important as it allows data queries that 
many other tools and GitHub workflows use to operate as expected. For 
example, many scripts and applications use the GitHub REST API [0] 
and/or GitHub GraphQL API [1] to query and present PR information. Logic 
would be complicated everywhere sorting through PRs that are dead ends 
to find if a PR is finally the last in a series, etc. Many off-the-shelf 
tools would produce incorrect results.


In addition, many tools and existing processes depend on a single PR 
link to track the status of a code change. Whether in public bug 
tracking tools or internal tools. That would produce stale links constantly.


It is possible to see force pushed diffs in a PR. For example, in this 
PR [2], I force pushed several times. You can simply click 
"force-pushed" or "Compare" on each force push to get a diff of the 
force pushed changes. On a simple rebase, as is the case in the last 
force push, the diff is empty and it reports the contents as identical.


With this it is possible to easily see branch (and its commit details) 
and checkout a specific push state using its respective commit hash.


[0] https://docs.github.com/en/rest?apiVersion=2022-11-28
[1] https://docs.github.com/en/graphql/overview
[2] https://github.com/tianocore/edk2/pull/4835


[0] https://openfw.io/edk2-devel/







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

[edk2-devel] Now: TianoCore Community Meeting EMEA/NAMO - Thursday, May 2, 2024 #cal-notice

[Group Notification]

*TianoCore Community Meeting EMEA/NAMO*

*When:*
Thursday, May 2, 2024
8:00am to 9:00am
(UTC-07:00) America/Los Angeles

*Where:*
Microsoft Teams meeting Join on your computer or mobile app Click here to join 
the meeting Meeting ID: 226 323 011 029 Passcode: hMRCj6 Download Teams | Join 
on the web Join with a video conferencing device te...@conf.intel.com Video 
Conference ID: 112 716 814 3 Alternate VTC instructions Learn More | Meeting 
options

*Organizer:*
Miki Demeter

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

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

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

Meeting ID: 226 323 011 029
Passcode: hMRCj6

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 112 716 814 3

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1127168143&ivr=teams&d=conf.intel.com&test=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_MTAyZGJhNjMtYzQ4Mi00MTUxLWFlMWMtOGU0MWNlZDk4NjY5@thread.v2&messageId=0&language=en-US
 )




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

[edk2-devel] Event: TianoCore Community Meeting EMEA/NAMO - Thursday, May 2, 2024 #cal-reminder

[Group Notification]

*Reminder: TianoCore Community Meeting EMEA/NAMO*

*When:*
Thursday, May 2, 2024
8:00am to 9:00am
(UTC-07:00) America/Los Angeles

*Where:*
Microsoft Teams meeting Join on your computer or mobile app Click here to join 
the meeting Meeting ID: 226 323 011 029 Passcode: hMRCj6 Download Teams | Join 
on the web Join with a video conferencing device te...@conf.intel.com Video 
Conference ID: 112 716 814 3 Alternate VTC instructions Learn More | Meeting 
options

*Organizer:*
Miki Demeter

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

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

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

Meeting ID: 226 323 011 029
Passcode: hMRCj6

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 112 716 814 3

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1127168143&ivr=teams&d=conf.intel.com&test=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_MTAyZGJhNjMtYzQ4Mi00MTUxLWFlMWMtOGU0MWNlZDk4NjY5@thread.v2&messageId=0&language=en-US
 )




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

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

[Sami Mujawar]

Hi Oliver,

We are working on a solution to remove the HOB creation logic from StandaloneMm 
for Arm, and this involves implementing the Firmware handoff specification 
(https://github.com/FirmwareHandoff/firmware_handoff/releases/download/v0.9/firmware_handoff.pdf).

As you rightly mentioned this also requires changes in TF-A, and this work is 
in progress.

Levi (Yeo) is currently working on this feature and will post the patches to 
the mailing list once we have the necessary components ready.

Regards,

Sami Mujawar

On 01/05/2024, 22:32, "Oliver Smith-Denny" mailto:o...@linux.microsoft.com>> wrote:


Hi folks, returning to this thread because I noticed that HOB
creation still exists in StandaloneMmCore for ARM:


https://github.com/tianocore/edk2/blob/5d4c5253e8bbc0baa8837fcd868925212df85201/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
 



As far as I can tell, there is only this one file that creates 6
HOBs from StandaloneMmCore. Per our earlier discussion that led to
disabling HOB creation in StandaloneMm, I think that this falls into
the case where StandaloneMm is a HOB consumer phase, not a producer
phase and so it should not be creating these HOBs. On the x64 side,
all of the StandaloneMm HOB creation functions ASSERT with the
comment that StandaloneMm is a HOB consumer phase and should not
be creating HOBs.


On ARM this is more complicated, as all of this information would
seem to originate from TF-A and so we would need TF-A to produce
these HOBs to tell StandaloneMm the information it needs to
operate. Today TF-A already has to communicate this information, the
HOBs are just created in StandaloneMmCore instead of in TF-A.


Curious to get other folks thoughts here on this paradigm.


Thanks,
Oliver


On 12/5/2023 5:47 AM, Nhi Pham wrote:
> 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 mailto:ray...@intel.com>>
> Cc: Sami Mujawar mailto:sami.muja...@arm.com>>
> Cc: Oliver Smith-Denny  >
> Signed-off-by: Nhi Pham mailto:nhipham...@gmail.com>>
> ---
> 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_ADDRESS FreeMemory;
>
> - 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 A

[edk2-devel] [PATCH ovmf v3 5/5] OvmfPkf: Enable AMD SEV-ES DebugSwap for DXE

[Alexey Kardashevskiy via groups.io]

This writes the feature bit into PcdConfidentialComputingGuestAttr
and enables DebugSwap for the DXE stage too.

Cc: Ard Biesheuvel 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Michael Roth 
Cc: Min Xu 
Cc: Tom Lendacky 
Signed-off-by: Alexey Kardashevskiy 
---
 OvmfPkg/PlatformPei/AmdSev.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index e6724cf493a7..785872537728 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -434,6 +434,7 @@ AmdSevInitialize (
   )
 {
   UINT64 EncryptionMask;
+  UINT64 CCGuestAttr;
   RETURN_STATUS  PcdStatus;
 
   //
@@ -517,13 +518,19 @@ AmdSevInitialize (
   // technology is active.
   //
   if (MemEncryptSevSnpIsEnabled ()) {
-PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSevSnp);
+CCGuestAttr = CCAttrAmdSevSnp;
   } else if (MemEncryptSevEsIsEnabled ()) {
-PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSevEs);
+CCGuestAttr = CCAttrAmdSevEs;
   } else {
-PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSev);
+CCGuestAttr = CCAttrAmdSev;
   }
 
+  if (MemEncryptSevEsDebugSwapIsEnabled ()) {
+CCGuestAttr |= CCAttrFeatureAmdSevDebugSwap;
+  }
+
+  PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCGuestAttr);
+
   ASSERT_RETURN_ERROR (PcdStatus);
 }
 
-- 
2.44.0



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

[edk2-devel] [PATCH ovmf v3 4/5] UefiCpuPkg: Add AMD SEV-ES features support

[Alexey Kardashevskiy via groups.io]

CONFIDENTIAL_COMPUTING_GUEST_ATTR is not a simple SEV level anymore
and includes a feature mask since a previous commit.

This fixes AmdMemEncryptionAttrCheck to check the level and feature
correctly and adds DebugSwap support.

Since the actual feature flag is not set yet, this should cause
no behavioural change.

Cc: Gerd Hoffmann 
Cc: Jiaxin Wu 
Cc: Rahul Kumar 
Cc: Ray Ni 
Cc: Tom Lendacky 
Signed-off-by: Alexey Kardashevskiy 
---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index d7244565029d..52fddfb7e571 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -3178,19 +3178,25 @@ AmdMemEncryptionAttrCheck (
   IN  CONFIDENTIAL_COMPUTING_GUEST_ATTR  Attr
   )
 {
+  UINT64  CurrentLevel;
+
+  CurrentLevel = CurrentAttr & CCAttrTypeMask;
+
   switch (Attr) {
 case CCAttrAmdSev:
   //
   // SEV is automatically enabled if SEV-ES or SEV-SNP is active.
   //
-  return CurrentAttr >= CCAttrAmdSev;
+  return CurrentLevel >= CCAttrAmdSev;
 case CCAttrAmdSevEs:
   //
   // SEV-ES is automatically enabled if SEV-SNP is active.
   //
-  return CurrentAttr >= CCAttrAmdSevEs;
+  return CurrentLevel >= CCAttrAmdSevEs;
 case CCAttrAmdSevSnp:
-  return CurrentAttr == CCAttrAmdSevSnp;
+  return CurrentLevel == CCAttrAmdSevSnp;
+case CCAttrFeatureAmdSevDebugSwap:
+  return !!(CurrentAttr & CCAttrFeatureAmdSevDebugSwap);
 default:
   return FALSE;
   }
-- 
2.44.0



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

[edk2-devel] [PATCH ovmf v3 3/5] OvmfPkg: Add AMD SEV-ES DebugSwap feature support

[Alexey Kardashevskiy via groups.io]

The SEV-ES DebugSwap feature enables type B swaping of debug registers
on #VMEXIT and makes #DB and DR7 intercepts unnecessary and unwanted.

When DebugSwap is enabled, this stops booting if #VC for #DB or
DB7 read/write occurs as this signals unwanted interaction from the HV.

This adds new API which uses SEV-ES working area in PEI and SEC.

This does not change the existing behavour for DXE just yet but soon.

Cc: Ard Biesheuvel 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Michael Roth 
Cc: Min Xu 
Cc: Tom Lendacky 
Signed-off-by: Alexey Kardashevskiy 
---
 OvmfPkg/Include/Library/MemEncryptSevLib.h | 12 
+
 OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c | 27 
+---
 OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c | 19 
++
 OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c | 19 
++
 OvmfPkg/Library/CcExitLib/CcExitVcHandler.c|  8 ++
 5 files changed, 82 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
b/OvmfPkg/Include/Library/MemEncryptSevLib.h
index 4fa9c0d70083..0fa86aecc38c 100644
--- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
+++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
@@ -166,6 +166,18 @@ MemEncryptSevGetEncryptionMask (
   VOID
   );
 
+/**
+  Returns a boolean to indicate whether DebugSwap is enabled.
+
+  @retval TRUE   DebugSwap is enabled
+  @retval FALSE  DebugSwap is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugSwapIsEnabled (
+  VOID
+  );
+
 /**
   Returns the encryption state of the specified virtual address range.
 
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
index 4aba0075b9e2..ebc4c9bb5d06 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
@@ -40,19 +40,25 @@ AmdMemEncryptionAttrCheck (
   IN  CONFIDENTIAL_COMPUTING_GUEST_ATTR  Attr
   )
 {
+  UINT64  CurrentLevel;
+
+  CurrentLevel = CurrentAttr & CCAttrTypeMask;
+
   switch (Attr) {
 case CCAttrAmdSev:
   //
   // SEV is automatically enabled if SEV-ES or SEV-SNP is active.
   //
-  return CurrentAttr >= CCAttrAmdSev;
+  return CurrentLevel >= CCAttrAmdSev;
 case CCAttrAmdSevEs:
   //
   // SEV-ES is automatically enabled if SEV-SNP is active.
   //
-  return CurrentAttr >= CCAttrAmdSevEs;
+  return CurrentLevel >= CCAttrAmdSevEs;
 case CCAttrAmdSevSnp:
-  return CurrentAttr == CCAttrAmdSevSnp;
+  return CurrentLevel == CCAttrAmdSevSnp;
+case CCAttrFeatureAmdSevDebugSwap:
+  return !!(CurrentAttr & CCAttrFeatureAmdSevDebugSwap);
 default:
   return FALSE;
   }
@@ -159,3 +165,18 @@ MemEncryptSevGetEncryptionMask (
 
   return mSevEncryptionMask;
 }
+
+/**
+  Returns a boolean to indicate whether DebugSwap is enabled.
+
+  @retval TRUE   DebugSwap is enabled
+  @retval FALSE  DebugSwap is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugSwapIsEnabled (
+  VOID
+  )
+{
+  return ConfidentialComputingGuestHas (CCAttrFeatureAmdSevDebugSwap);
+}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
index 41d1246a5b31..e2ebc8afcaee 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
@@ -141,3 +141,22 @@ MemEncryptSevGetEncryptionMask (
 
   return SevEsWorkArea->EncryptionMask;
 }
+
+/**
+  Returns a boolean to indicate whether DebugSwap is enabled.
+
+  @retval TRUE   DebugSwap is enabled
+  @retval FALSE  DebugSwap is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugSwapIsEnabled (
+  VOID
+  )
+{
+  MSR_SEV_STATUS_REGISTER  Msr;
+
+  Msr.Uint32 = InternalMemEncryptSevStatus ();
+
+  return Msr.Bits.DebugSwap ? TRUE : FALSE;
+}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
index 27148c7e337a..0e82dc85b299 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c
@@ -142,6 +142,25 @@ MemEncryptSevGetEncryptionMask (
   return SevEsWorkArea->EncryptionMask;
 }
 
+/**
+  Returns a boolean to indicate whether DebugSwap is enabled.
+
+  @retval TRUE   DebugSwap is enabled
+  @retval FALSE  DebugSwap is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsDebugSwapIsEnabled (
+  VOID
+  )
+{
+  MSR_SEV_STATUS_REGISTER  Msr;
+
+  Msr.Uint32 = InternalMemEncryptSevStatus ();
+
+  return Msr.Bits.DebugSwap ? TRUE : FALSE;
+}
+
 /**
   Locate the page range that covers the initial (pre-SMBAS

[edk2-devel] [PATCH ovmf v3 2/5] MdePkg: Add AMD SEV features to PcdConfidentialComputingGuestAttr

[Alexey Kardashevskiy via groups.io]

PcdConfidentialComputingGuestAttr so far only contained an SEV mode bit
but there are more other features which do not translate to levels
such as DebugSwap or SecureTsc.

This adds the features mask and the DebugSwap feature bit to a PCD.

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Cc: Tom Lendacky 
Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2:
* expanded features mask
* added type mask
---
 MdePkg/Include/ConfidentialComputingGuestAttr.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/ConfidentialComputingGuestAttr.h 
b/MdePkg/Include/ConfidentialComputingGuestAttr.h
index 44e6df800207..c3a3dfb393f0 100644
--- a/MdePkg/Include/ConfidentialComputingGuestAttr.h
+++ b/MdePkg/Include/ConfidentialComputingGuestAttr.h
@@ -29,9 +29,20 @@ typedef enum {
 
   /* The guest is running with Intel TDX memory encryption enabled. */
   CCAttrIntelTdx = 0x200,
+
+  CCAttrTypeMask = 0x,
+
+  /* Features */
+
+  /* The AMD SEV-ES DebugSwap feature is enabled in SEV_STATUS */
+  CCAttrFeatureAmdSevDebugSwap = 0x0001,
+
+  CCAttrFeatureMask = 0x,
 } CONFIDENTIAL_COMPUTING_GUEST_ATTR;
 
-#define CC_GUEST_IS_TDX(x)  ((x) == CCAttrIntelTdx)
-#define CC_GUEST_IS_SEV(x)  ((x) == CCAttrAmdSev || (x) == CCAttrAmdSevEs || 
(x) == CCAttrAmdSevSnp)
+#define _CC_GUEST_IS_TDX(x)  ((x) == CCAttrIntelTdx)
+#define CC_GUEST_IS_TDX(x)   _CC_GUEST_IS_TDX((x) & CCAttrTypeMask)
+#define _CC_GUEST_IS_SEV(x)  ((x) == CCAttrAmdSev || (x) == CCAttrAmdSevEs || 
(x) == CCAttrAmdSevSnp)
+#define CC_GUEST_IS_SEV(x)   _CC_GUEST_IS_SEV((x) & CCAttrTypeMask)
 
 #endif
-- 
2.44.0



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

[edk2-devel] [PATCH ovmf v3 1/5] MdePkg/Register/Amd: Define all bits from MSR_SEV_STATUS_REGISTER

[Alexey Kardashevskiy via groups.io]

For now we need DebugSwap but others are likely to be needed too.

Cc: Tom Lendacky 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Signed-off-by: Alexey Kardashevskiy 
---
 MdePkg/Include/Register/Amd/Fam17Msr.h | 63 ++--
 1 file changed, 59 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h 
b/MdePkg/Include/Register/Amd/Fam17Msr.h
index f2d5ccb39dc7..bce51a66517f 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -126,19 +126,74 @@ typedef union {
 ///
 /// [Bit 0] Secure Encrypted Virtualization (Sev) is enabled
 ///
-UINT32SevBit: 1;
+UINT32SevBit  : 1;
 
 ///
 /// [Bit 1] Secure Encrypted Virtualization Encrypted State (SevEs) is 
enabled
 ///
-UINT32SevEsBit  : 1;
+UINT32SevEsBit: 1;
 
 ///
 /// [Bit 2] Secure Nested Paging (SevSnp) is enabled
 ///
-UINT32SevSnpBit : 1;
+UINT32SevSnpBit   : 1;
 
-UINT32Reserved2 : 29;
+///
+/// [Bit 3] The guest was run with the Virtual TOM feature enabled in 
SEV_FEATURES[1]
+///
+UINT32vTOM_Enabled: 1;
+
+///
+/// [Bit 4] The guest was run with the ReflectVC feature enabled in 
SEV_FEATURES[2]
+///
+UINT32ReflectVC   : 1;
+
+///
+/// [Bit 5] The guest was run with the Restricted Injection feature 
enabled in SEV_FEATURES[3]
+///
+UINT32RestrictedInjection : 1;
+
+///
+/// [Bit 6] The guest was run with the Alternate Injection feature enabled 
in SEV_FEATURES[4]
+///
+UINT32AlternateInjection  : 1;
+
+///
+/// [Bit 7] This guest was run with debug register swapping enabled in 
SEV_FEATURES[5]
+///
+UINT32DebugSwap   : 1;
+
+///
+/// [Bit 8]  This guest was run with the PreventHostIBS feature enabled in 
SEV_FEATURES[6]
+///
+UINT32PreventHostIBS  : 1;
+
+///
+/// [Bit 9] The guest was run with the BTB isolation feature enabled in 
SEV_FEATURES[7]
+///
+UINT32SNPBTBIsolation : 1;
+
+///
+/// [Bit 10]
+///
+UINT32Reserved0   : 1;
+
+///
+/// [Bit 11] The guest was run with the Secure TSC feature enabled in 
SEV_FEATURES[9]
+///
+UINT32SecureTsc   : 1;
+
+///
+/// [Bits 12 13 14 15]
+///
+UINT32Reserved1   : 4;
+
+///
+/// [Bit 16] The guest was run with the VMSA Register Protection feature 
enabled in SEV_FEATURES[14]
+///
+UINT32VmsaRegProt_Enabled : 1;
+
+UINT32Reserved2   : 15;
   } Bits;
   ///
   /// All bit fields as a 32-bit value
-- 
2.44.0



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

[edk2-devel] [PATCH ovmf v3 0/5] Enable AMD SEV-ES DebugSwap

[Alexey Kardashevskiy via groups.io]

This is to prevent #DB interception on SEV-ES VM with
enabled DebugSwap feature, more details in 3/5.

The corresponding Linux change (HV and VM) went upstream
long time ago:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e221804dad4e
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1f85fbe836e

The previous conversation (more than a year ago) is here:
https://edk2.groups.io/g/devel/message/96808

v2 failed CI so here is v3 but with cosmetic changes only.

This is based on sha1
fecf55a66a1c Michael Roth "OvmfPkg/CcExitLib: Drop special handling for 
Encrypted MMIO to APIC".

Please comment. Thanks.



Alexey Kardashevskiy (5):
  MdePkg/Register/Amd: Define all bits from MSR_SEV_STATUS_REGISTER
  MdePkg: Add AMD SEV features to PcdConfidentialComputingGuestAttr
  OvmfPkg: Add AMD SEV-ES DebugSwap feature support
  UefiCpuPkg: Add AMD SEV-ES features support
  OvmfPkf: Enable AMD SEV-ES DebugSwap for DXE

 MdePkg/Include/ConfidentialComputingGuestAttr.h| 15 -
 MdePkg/Include/Register/Amd/Fam17Msr.h | 63 
++--
 OvmfPkg/Include/Library/MemEncryptSevLib.h | 12 
 OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c | 27 
-
 OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c | 19 ++
 OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c | 19 ++
 OvmfPkg/Library/CcExitLib/CcExitVcHandler.c|  8 +++
 OvmfPkg/PlatformPei/AmdSev.c   | 13 +++-
 UefiCpuPkg/Library/MpInitLib/MpLib.c   | 12 +++-
 9 files changed, 173 insertions(+), 15 deletions(-)

-- 
2.44.0



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

Re: [edk2-devel] Call or topics for May TianoCore Community Meeting

[Rebecca Cran]

On 5/1/2024 10:45 AM, Michael D Kinney wrote:

Please let me know if you have any topics for the TianoCore Community
Meeting this month.


People might not see this since you replied to the thread about the 
March meeting instead of starting a new discussion.



--

Rebecca Cran



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

[edk2-devel] Now: TianoCore edk2-test Bug Triage Meeting - Thursday, May 2, 2024 #cal-notice

[Group Notification]

*TianoCore edk2-test Bug Triage Meeting*

*When:*
Thursday, May 2, 2024
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai

*Where:*
https://armltd.zoom.us/j/94348061758?pwd=Q3RDeFA5K2JFaU5jdWUxc1FnaGdyUT09&from=addon

*Organizer:*
Edhaya Chandran
edhaya.chand...@arm.com ( 
edhaya.chand...@arm.com?subject=Re:%20Event:%20TianoCore%20edk2-test%20Bug%20Triage%20Meeting
 )

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

*Description:*


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

[edk2-devel] Event: TianoCore edk2-test Bug Triage Meeting - Thursday, May 2, 2024 #cal-reminder

[Group Notification]

*Reminder: TianoCore edk2-test Bug Triage Meeting*

*When:*
Thursday, May 2, 2024
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai

*Where:*
https://armltd.zoom.us/j/94348061758?pwd=Q3RDeFA5K2JFaU5jdWUxc1FnaGdyUT09&from=addon

*Organizer:*
Edhaya Chandran
edhaya.chand...@arm.com ( 
edhaya.chand...@arm.com?subject=Re:%20Event:%20TianoCore%20edk2-test%20Bug%20Triage%20Meeting
 )

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

*Description:*


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

Re: [edk2-devel] [PATCH RESEND edk2-platforms][PATCH V2 00/14] Split NorFlashDxe driver and add CadenceQspiNorFlashDeviceLib library

[PierreGondois]

Hello Sahil,

I had some comments for:
- [PATCH V2 12/14] Platform/ARM: Add CadenceQspiNorFlashDeviceLib for 
NorFlashDxe
for all the other patches:
  Reviewed-by: Pierre Gondois 

Also, unless I missed something, shouldn't your mail address/signed-off tag be:
  'Sahil ' -> 'Sahil Kaushal '
?

Regards,
Pierre

On 4/23/24 07:56, Sahil Kaushal via groups.io wrote:

From: sahil 

This patch series adds the following changes:

1. Splits the NorFlashDxe driver to introduce a NorFlashDeviceLib that
implements the specifics for the respective flash. This will allow us
to plug different libraries implementing functionality of various NOR
Flash. The flash specific code in NorFlashDxe has been moved to
P30NorFlashDeviceLib library.

2. Adds support for CadenceQspiNorFlashDeviceLib which is used by N1Sdp
platform along with NorFlashDxe driver. N1Sdp uses an emulated variable
storage on DDR memory for the variable storage. But this emulated
variable storage is a volatile memory and so the values of variables
can't persist on next reboot or in power cycle. In N1Sdp platform, the
SoC is connected to IOFPGA which has a Cadence Quad SPI (QSPI)
controller. This QSPI controller manages the flash chip device via QSPI
bus. With these changes we use this NOR flash device for persistent
variable storage.

v2:
   - Fixed code review comments
   - Split the NorFlashDxe driver and moved flash specific code to
 P30NorFlashDeviceLib
   - Added NOR flash Dxe Driver for N1Sdp as a library instead of a
 driver

Links to v1:
https://edk2.groups.io/g/devel/topic/102625035
https://edk2.groups.io/g/devel/topic/102625033
https://edk2.groups.io/g/devel/topic/102625034
https://edk2.groups.io/g/devel/topic/102625036
https://edk2.groups.io/g/devel/topic/102625037
https://edk2.groups.io/g/devel/topic/102625038

Link to branch with the patches in this series -
https://github.com/sah01Kaushal/edk2-platforms/tree/n1sdp_persistent_storage_v2

sahil (14):
   Platform/ARM/NorFlashDxe: Move DiskIo related functions out of
 NorFlash.c
   Platform/ARM/NorFlashDxe: Move NorFlashVirtualNotifyEvent
   Platform/ARM/NorFlashDxe: Add NorFlashCommon.h header file
   Platform/ARM/NorFlashDxe: Move flash specific functions to NorFlash.c
   Platform/ARM: Create NorFlashDeviceLib library interface for flash
 specific functions
   Platform/ARM: Add P30NorFlashDeviceLib Library
   Platform/ARM/NorFlashDxe: Switch from NorFlash.c to NorFlashDeviceLib
   Platform/ARM: Add HostRegisterBaseAddress variable
   Platform/ARM: Add optional provision to fetch and print NOR Flash info
   Silicon/ARM/NeoverseN1Soc: Enable SCP QSPI flash region
   Silicon/ARM/NeoverseN1Soc: NOR flash library for N1Sdp
   Platform/ARM: Add CadenceQspiNorFlashDeviceLib for NorFlashDxe
   Platform/ARM/N1Sdp: Persistent storage for N1Sdp
   Platform/ARM/N1Sdp: Enable FaultTolerantWrite Dxe driver for N1Sdp

  Platform/ARM/ARM.dec  
   |4 +
  Platform/ARM/SgiPkg/SgiPlatform.dsc.inc   
   |3 +
  Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc 
   |3 +
  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc  
   |3 +
  Platform/ARM/JunoPkg/ArmJuno.dsc  
   |3 +
  Platform/ARM/N1Sdp/N1SdpPlatform.dsc  
   |   24 +-
  Platform/ARM/VExpressPkg/PlatformStandaloneMm.dsc 
   |3 +
  Platform/ARM/N1Sdp/N1SdpPlatform.fdf  
   |3 +
  Platform/ARM/Drivers/NorFlashDxe/NorFlashDxe.inf  
   |8 +-
  Platform/ARM/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf 
   |8 +-
  
Platform/ARM/Library/CadenceQspiNorFlashDeviceLib/CadenceQspiNorFlashDeviceLib.inf
   |   32 +
  Platform/ARM/Library/P30NorFlashDeviceLib/P30NorFlashDeviceLib.inf
   |   35 +
  Silicon/ARM/NeoverseN1Soc/Library/NorFlashLib/NorFlashLib.inf 
   |   34 +
  Platform/ARM/Drivers/NorFlashDxe/NorFlash.h   
   |  422 
  Platform/ARM/Drivers/NorFlashDxe/NorFlashCommon.h 
   |  209 
  Platform/ARM/Include/Library/NorFlashDeviceLib.h  
   |  163 
  
Platform/ARM/Library/CadenceQspiNorFlashDeviceLib/CadenceQspiNorFlashDeviceLib.h
 |   44 +
  Platform/ARM/Library/P30NorFlashDeviceLib/P30NorFlashDeviceLib.h  
   |   98 ++
  Silicon/ARM/NeoverseN1Soc/Include/NeoverseN1Soc.h

Re: [edk2-devel] [PATCH RESEND edk2-platforms][PATCH V2 12/14] Platform/ARM: Add CadenceQspiNorFlashDeviceLib for NorFlashDxe

[PierreGondois]

Hello Sahil,

On 4/23/24 07:56, Sahil Kaushal via groups.io wrote:

From: sahil 

In N1Sdp platform, the SoC is connected to IOFPGA which has a
Cadence Quad SPI (QSPI) controller. This QSPI controller manages
the flash chip device via QSPI bus.

This patch adds CadenceQspiNorFlashDeviceLib which is used to
manage and access the above configuration.

Signed-off-by: sahil 
---
  
Platform/ARM/Library/CadenceQspiNorFlashDeviceLib/CadenceQspiNorFlashDeviceLib.inf
 |   32 +
  
Platform/ARM/Library/CadenceQspiNorFlashDeviceLib/CadenceQspiNorFlashDeviceLib.h
   |   44 +
  
Platform/ARM/Library/CadenceQspiNorFlashDeviceLib/CadenceQspiNorFlashDeviceLib.c
   | 1011 
  3 files changed, 1087 insertions(+)



[snip]


+
+/**
+  Converts milliseconds into number of ticks of the performance counter.
+
+  @param[in] Milliseconds  Milliseconds to convert into ticks.
+
+  @retval Milliseconds expressed as number of ticks.
+
+**/
+STATIC
+UINT64
+MilliSecondsToTicks (
+  IN UINTN  Milliseconds
+  )
+{
+  CONST UINT64  NanoSecondsPerTick = GetTimeInNanoSecond (1);
+
+  return (Milliseconds * 100) / NanoSecondsPerTick;


Should use DivU64x64Remainder() here:
{
  UINT64  NanoSecondsPerTick;
  UINT64  NanoSeconds;

  NanoSecondsPerTick = GetTimeInNanoSecond (1);
  NanoSeconds = MultU64x32 (Milliseconds, 100);

  return DivU64x64Remainder (NanoSeconds, NanoSecondsPerTick, NULL);
}


+}
+
+/**
+  Poll Status register for NOR flash erase/write completion.
+
+  @param[in]  Instance   NOR flash Instance.
+
+  @retval EFI_SUCCESSRequest is executed successfully.
+  @retval EFI_TIMEOUTOperation timed out.
+  @retval EFI_DEVICE_ERROR   Controller operartion failed.


operartion -> typo
(same at another place I think)

[snip]


+
+/**
+  Read from nor flash.
+
+  @param[in] Instance   NOR flash Instance of variable store 
region.
+  @param[in] LbaThe starting logical block index to 
read from.
+  @param[in] Offset Offset into the block at which to 
begin reading.
+  @param[in] BufferSizeInBytes  The number of bytes to read.
+  @param[out]Buffer The pointer to a caller-allocated 
buffer that
+should copied with read data.
+
+  @retvalEFI_SUCCESSThe read is completed.
+  @retvalEFI_INVALID_PARAMETER  Invalid parameters passed.
+**/
+EFI_STATUS
+NorFlashRead (
+  IN NOR_FLASH_INSTANCE  *Instance,
+  IN EFI_LBA Lba,
+  IN UINTN   Offset,
+  IN UINTN   BufferSizeInBytes,
+  OUT VOID   *Buffer
+  )
+{
+  UINTN  StartAddress;
+
+  // The buffer must be valid
+  if (Buffer == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  // Return if we do not have any byte to read
+  if (BufferSizeInBytes == 0) {
+return EFI_SUCCESS;
+  }
+
+  if (((Lba * Instance->Media.BlockSize) + Offset + BufferSizeInBytes) >
+  Instance->Size)
+  {
+DEBUG ((
+  DEBUG_ERROR,
+  "NorFlashRead: ERROR - Read will exceed device size.\n"
+  ));
+return EFI_INVALID_PARAMETER;
+  }
+
+  // Get the address to start reading from
+  StartAddress = GET_NOR_BLOCK_ADDRESS (
+   Instance->RegionBaseAddress,
+   Lba,
+   Instance->Media.BlockSize
+   );
+
+  // Readout the data
+  CopyMem (Buffer, (UINTN *)(StartAddress + Offset), BufferSizeInBytes);


The original code at:
  Platform/ARM/Library/P30NorFlashDeviceLib/P30NorFlashDeviceLib.c

implements and uses AlignedCopyMem()/NorFlashWriteBuffer() which seems
to be more efficient.
Just to be sure I understand correctly, is the maximal read/write size
of 4 bytes ? Meaning that these functions are not needed ?

---

NorFlashWriteBuffer() is not implemented here IIUC won't be implemtned as not
needed. Maybe in an additional patch, the function could be removed from the
library interface at:
  Platform/ARM/Include/Library/NorFlashDeviceLib.h
and made static in:
  Platform/ARM/Library/P30NorFlashDeviceLib/P30NorFlashDeviceLib.c


+
+  return EFI_SUCCESS;
+}
+
+/**
+  Write a full or portion of a block.
+
+  @param[in]   Instance  NOR flash Instance of variable store 
region.
+  @param[in]   Lba   The starting logical block index to 
write to.
+  @param[in]   OffsetOffset into the block at which to 
begin writing.
+  @param[in, out]  NumBytes  The total size of the buffer.
+  @param[in]   BufferThe pointer to a caller-allocated 
buffer that
+ contains the source for the write.
+
+  @retval  EFI_SUCCESS   The write is completed.
+  @retval  EFI_OUT_OF_RESOURCES  Invalid Buffer passed.
+  @retval  EFI_BAD_BUFFER_SIZE   Buffer size not enough.
+  @retval  EFI_DEVICE_ERROR  The device reported an error

Re: [edk2-devel] [PATCH v4 0/3] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set

[Ard Biesheuvel]

On Thu, 2 May 2024 at 11:06, Gerd Hoffmann  wrote:
>
> On Wed, May 01, 2024 at 02:03:37PM GMT, Michael Roth wrote:
> > For the most part, OVMF will clear the encryption bit for MMIO regions,
> > but there is currently one known exception during SEC when the APIC
> > base address is accessed via MMIO with the encryption bit set for
> > SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
> > handling on the hypervisor side which may not be available in the
> > future[1], so make the necessary changes in the SEC-configured page
> > table to clear the encryption bit for 4K region containing the APIC
> > base address.
> >
> > Since CpuPageTableLib is used to handle the splitting, some additional
> > care must be taken to clear the C-bit in all non-leaf PTEs since the
> > library expects that to be the case. Add handling for that when setting
> > up the SEC page table.
> >
> > While here, drop special handling for the APIC base address in the
> > SEV-ES/SNP #VC handler.
>
> Series:
> Reviewed-by: Gerd Hoffmann 
>

Thanks, I've picked these up now.


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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-02 04:08, Michael Kubacki wrote:
Thank you for this proposal. We've been anticipating this change for 
years and are excited to help support it.


Here's some items we'd like to raise for feedback that we could help 
implement. Many could likely be done in time for the transition.


1. Automate reviewers - We've discussed CODEOWNERS in the past. However, 
a simpler approach (in maintaining/syncing less files) would be to use 
Maintainers.txt directly with a GitHub workflow since the file already 
contains GitHub IDs.


That would be ideal. I know Mike worked on autogenerating CODEOWNERS 
from Maintainers.txt, but ultimately the latter supports more flexible 
use of wildcards (things like */AArch64/ currently requires reconciling 
against the repo contents).


2. Make PR completion contingent on a GitHub review from at least one 
package maintainer/reviewer for each package in the PR.


Yes.

3. Dependabot is already used today to automatically create PRs when 
dependencies like pip modules have updates. To allow this to more 
effectively keep dependencies up-to-date, allow dependabot PRs to be 
completed (after normal acceptance criteria like CI and review 
requirements) without a separate human creating a duplicate PR.


I am not sure what this means in practice :)
This doesn't sound like one we need to worry about before switchover though.

4. Potentially warn users (with an automated comment on the PR) if they 
add a push label to a PR that is less than 24 hours old.


That sounds good.
Is there any way to prevent force-pushes within 24h of previous push?
That would make setting up a transitional review-scraper less lossy.

5. Leave reminder comments on PRs with absolutely no activity after some 
agreed upon time so reviewers are notified to review the PR without the 
submitter having to watch it and send notifications.


Yes. But should take priority below 1, 2, and 4. Unless you have a 
pre-cooked thing to drop in of course.


6. Leave reminder comments on PRs that meet all requirements to be 
completed (all reviews accounted for and status checks pass) but are 
still open so those on the PR are notified to complete it without the 
submitter having to manually watch and send reminders.


Not a response to this, but triggered by reading this:
Is there any way to approve changes within a PR on a commit by commit basis?


7. We are happy to help with process documentation.


Always appreciated,thanks.

Regards,

Leif



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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-02 07:33, Marcin Juszkiewicz wrote:

W dniu 1.05.2024 o 19:43, Michael D Kinney via groups.io pisze:

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


O yes! Fully for it!

Does it mean edk2 only or edk2/edk2-platforms/edk2-non-osi and other 
tianocore/ repositories?


I don't see why we couldn't switch all of them. Other than we need to 
get all the Maintainers.txt updated with code forge usernames first.


We may want to do one at a time though.

/
Leif


* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


That can be done by github action started automatically after opening 
PR. May require changes to GetMaintainer.py script. Would be good to 
have in case someone forget to add one of maintainers.


Also would be nice to have a bot running PatchCheck and uncrustify on PR.









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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-02 02:28, Rebecca Cran wrote:

On Wed, May 1, 2024, at 11:43 AM, Michael D Kinney wrote:

* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


This seems like something that could rather easily be automated by parsing the 
maintainers file.


Yes, I pushed an example update to GetMaintainer.py here:
https://github.com/leiflindholm/edk2/tree/getmaintainer-forgeusername

But I think the actual option name, and output behaviour, needs to be 
discussed.


/
Leif



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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Ard Biesheuvel]

On Wed, 1 May 2024 at 19:44, Michael D Kinney
 wrote:
>
> Hello,
>
> I would like to propose that TianoCore move all code review from email
> based code reviews to GitHub Pull Requests based code reviews.
>
> The proposed date to switch would be immediately after the next stable
> tag which is currently scheduled for May 24, 2024.
>

+1

Some kind of off-github reflector similar to rebecca's public inbox
[0] would be appreciated to at least be able to keep track of
different versions of a series exactly as they were submitted. One of
the things that annoys me about doing GitHub reviews is dealing with
PRs where the underlying branches gets updated through a force-push
and there is no way to find out what changed, and whether the existing
review comments are still in sync.

Would it be possible to require a separate PR for each revision of a
series, lock the underlying branch, and archive it for future
reference (if desired?)


[0] https://openfw.io/edk2-devel/


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

Re: [edk2-devel] [PATCH v4 0/3] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set

[Gerd Hoffmann]

On Wed, May 01, 2024 at 02:03:37PM GMT, Michael Roth wrote:
> For the most part, OVMF will clear the encryption bit for MMIO regions,
> but there is currently one known exception during SEC when the APIC
> base address is accessed via MMIO with the encryption bit set for
> SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
> handling on the hypervisor side which may not be available in the
> future[1], so make the necessary changes in the SEC-configured page
> table to clear the encryption bit for 4K region containing the APIC
> base address.
> 
> Since CpuPageTableLib is used to handle the splitting, some additional
> care must be taken to clear the C-bit in all non-leaf PTEs since the
> library expects that to be the case. Add handling for that when setting
> up the SEC page table.
> 
> While here, drop special handling for the APIC base address in the
> SEV-ES/SNP #VC handler.

Series:
Reviewed-by: Gerd Hoffmann 

take care,
  Gerd



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

Re: [edk2-devel] [PATCH ovmf v2 0/5] Enable AMD SEV-ES DebugSwap

[Gerd Hoffmann]

  Hi,

> How do I proceed from here? Repost patches here or that pull request will
> do? I did not change anything besides spaces and CCs. Thanks,

Patch review happens on the mailing list, so please post v3 series.

thanks,
  Gerd



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

Re: [edk2-devel] [RESEND PATCH v4 0/5] DynamicTablesPkg: Adds FADT, HPET, WSMT and MADT Table generators

[Abdul Lateef Attar via groups.io]

Hi Pierre Gondois and Sami Mujawar,

    Could you please review below patch set and consider for upcoming 
stable release ?


There are non-disruptive patches and won't impact existing ARM platform.

Thanks

AbduL

On 29-04-2024 11:33, Abdul Lateef Attar wrote:

PR: https://github.com/tianocore/edk2/pull/5500/
V4: delta changes
   Added X64 arch specific MADT table generator.
V3: delta changes
   Restructure the code as the review comments.
   Added sanity check for WSMT flags.
   Added CM object for HPET base address.
V2: delta changes
   Addressed review comments
   Adds ACPI HPET table to add HPET to ACPI namespace
V1:
Adds new space for ArchNameSpaceObjects.
Adds generic FADT table generator.
Adds generic HPET table generator.
Adds generic WSMT table generator.

Cc: Sami Mujawar 
Cc: Pierre Gondois 
Cc: Abdul Lateef Attar 

Abdul Lateef Attar (5):
   DynamicTablesPkg: Adds ACPI FADT Table generator
   DynamicTablesPkg: Adds ACPI HPET Table generator
   DynamicTablesPkg: Adds ACPI WSMT Table generator
   DynamicTablesPkg: Adds ACPI SSDT HPET Table generator
   DynamicTablesPkg: Adds X64 arch MADT Table generator

  DynamicTablesPkg/DynamicTables.dsc.inc|  22 +-
  DynamicTablesPkg/DynamicTablesPkg.ci.yaml |   4 +-
  DynamicTablesPkg/Include/AcpiTableGenerator.h |   4 +
  .../Include/ArchNameSpaceObjects.h| 237 ++
  .../Include/ConfigurationManagerObject.h  |   7 +
  .../Include/X64NameSpaceObjects.h |  48 ++
  .../Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf  |  36 +
  .../Library/Acpi/AcpiFadtLib/Arm/FadtUpdate.c |  39 +
  .../Library/Acpi/AcpiFadtLib/FadtGenerator.c  | 745 ++
  .../Library/Acpi/AcpiFadtLib/FadtUpdate.h |  26 +
  .../Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c |  32 +
  .../Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf  |  31 +
  .../Library/Acpi/AcpiHpetLib/HpetGenerator.c  | 246 ++
  .../Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf  |  32 +
  .../Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c  | 295 +++
  .../Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf  |  30 +
  .../Library/Acpi/AcpiWsmtLib/WsmtGenerator.c  | 243 ++
  .../X64/AcpiMadtLibX64/AcpiMadtLibX64.inf |  27 +
  .../Acpi/X64/AcpiMadtLibX64/MadtGenerator.c   | 375 +
  19 files changed, 2477 insertions(+), 2 deletions(-)
  create mode 100644 DynamicTablesPkg/Include/ArchNameSpaceObjects.h
  create mode 100644 DynamicTablesPkg/Include/X64NameSpaceObjects.h
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/AcpiFadtLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/Arm/FadtUpdate.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtGenerator.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/FadtUpdate.h
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiFadtLib/X64/FadtUpdate.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/AcpiHpetLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiHpetLib/HpetGenerator.c
  create mode 100644 
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/AcpiSsdtHpetLib.inf
  create mode 100644 
DynamicTablesPkg/Library/Acpi/AcpiSsdtHpetLib/SsdtHpetGenerator.c
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/AcpiWsmtLib.inf
  create mode 100644 DynamicTablesPkg/Library/Acpi/AcpiWsmtLib/WsmtGenerator.c
  create mode 100644 
DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/AcpiMadtLibX64.inf
  create mode 100644 
DynamicTablesPkg/Library/Acpi/X64/AcpiMadtLibX64/MadtGenerator.c




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