Re: [edk2-devel] [PATCH v4 1/1] MdePkg:Add NVME Sanitize command support to Nvme.h

[Michael D Kinney]

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


> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, November 15, 2023 6:50 PM
> To: Chen, Tina ; devel@edk2.groups.io
> Cc: Ni, Ray ; Chen, Xiao X ; Chen,
> Arthur G ; Gao, Liming ;
> Liu, Zhiguang ; Sean Brogan
> ; Kinney, Michael D 
> Subject: RE: [PATCH v4 1/1] MdePkg:Add NVME Sanitize command support to
> Nvme.h
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Chen, Tina 
> > Sent: Wednesday, November 8, 2023 11:51 PM
> > To: devel@edk2.groups.io
> > Cc: Chen, Tina ; Ni, Ray ;
> > Chen, Xiao X ; Chen, Arthur G
> > ; Gao, Liming ;
> > Liu, Zhiguang ; Sean Brogan
> > ; Kinney, Michael D
> > 
> > Subject: [PATCH v4 1/1] MdePkg:Add NVME Sanitize command support to
> > Nvme.h
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4591
> >
> > 1. Refer NVME spec 2.0c chapter 5.24, add Sanitize Command related
> > definition.
> > 2. Refer NVME spec 2.0c chapter 5.16, add Get Log Page Command related
> > definition for Sanitize status support.
> >
> > Cc: Ray Ni 
> > Cc: Xiao X Chen 
> > Cc: Arthur Chen 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Sean Brogan 
> > Cc: Michael D Kinney 
> > Signed-off-by: Tina Chen 
> > ---
> >  MdePkg/Include/IndustryStandard/Nvme.h | 121 ++--
> >  1 file changed, 110 insertions(+), 11 deletions(-)
> >
> > diff --git a/MdePkg/Include/IndustryStandard/Nvme.h
> > b/MdePkg/Include/IndustryStandard/Nvme.h
> > index 8b8a1bb7f3..67f2196bc7 100644
> > --- a/MdePkg/Include/IndustryStandard/Nvme.h
> > +++ b/MdePkg/Include/IndustryStandard/Nvme.h
> > @@ -1,5 +1,5 @@
> >  /** @file
> >
> > -  Definitions based on NVMe spec. version 1.1.
> >
> > +  Definitions based on NVMe spec. version 2.0c.
> >
> >
> >
> >(C) Copyright 2016 Hewlett Packard Enterprise Development LP
> >
> >Copyright (c) 2017 - 2023, Intel Corporation. All rights
> > reserved.
> >
> > @@ -9,6 +9,7 @@
> >NVMe Specification 1.1
> >
> >NVMe Specification 1.4
> >
> >NVMe Specification 2.0
> >
> > +  NVMe Specification 2.0c
> >
> >
> >
> >  **/
> >
> >
> >
> > @@ -354,6 +355,15 @@ typedef struct {
> >UINT8 Rsvd7[16];  /* Reserved as of Nvm Express 1.1 Spec */
> >
> >  } NVME_PSDESCRIPTOR;
> >
> >
> >
> > +typedef struct {
> >
> > +  UINT32Ces : 1;/* Crypto Erase Supported */
> >
> > +  UINT32Bes : 1;/* Block Erase Supported */
> >
> > +  UINT32Ows : 1;/* Overwrite Supported */
> >
> > +  UINT32Rsvd1   : 26;   /* Reserved as of NVM Express 2.0c Spec
> > */
> >
> > +  UINT32Ndi : 1;/* No-Deallocate Inhibited */
> >
> > +  UINT32Nodmmas : 2;/* No-Deallocate Modifies Media After
> > Sanitize */
> >
> > +} NVME_SANICAP;
> >
> > +
> >
> >  //
> >
> >  //  Identify Controller Data
> >
> >  //
> >
> > @@ -403,7 +413,12 @@ typedef struct {
> >UINT16   Edstt;   /* Extended Device Self-test Time
> > */
> >
> >UINT8Dsto;/* Device Self-test Options  */
> >
> >UINT8Fwug;/* Firmware Update Granularity */
> >
> > -  UINT8Rsvd2[192];  /* Reserved as of Nvm Express 1.4
> > Spec */
> >
> > +  UINT16   Kas; /* Keep Alive Support */
> >
> > +  UINT16   Hctma;   /* Host Controlled Thermal
> > Management Attributes */
> >
> > +  UINT16   Mntmt;   /* Minimum Thermal Management
> > Temperature */
> >
> > +  UINT16   Mxtmt;   /* Maximum Thermal Management
> > Temperature */
> >
> > +  NVME_SANICAP Sanicap; /* Sanitize Capabilities */
> >
> > +  UINT8Rsvd2[180];  /* Reserved as of Nvm Express 1.4
> > Spec */
> >
> >//
> >
> >// NVM Command Set Attributes
> >
> >//
> >
> > @@ -687,10 +702,11 @@ typedef struct {
> >// CDW 10
> >
> >//
> >
> >UINT32Lid   : 8;/* Log Page Identifier */
> >
> > -  #define LID_ERROR_INFO0x1
> >
> > -  #define LID_SMART_INFO0x2
> >
> > -  #define LID_FW_SLOT_INFO  0x3
> >
&g

[edk2-devel] TianoCore Community Meeting call for topics

[Michael D Kinney]

Are there any topics for the TianoCore Community Meeting this week?

Thanks,

Mike


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

Re: [edk2-devel] [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

[Michael D Kinney]

Hi Jake,

PR opened with Rb tag added: https://github.com/tianocore/edk2/pull/5113

Mike

From: Jake Garver 
Sent: Wednesday, December 6, 2023 8:37 AM
To: Gao, Liming ; devel@edk2.groups.io
Cc: Kinney, Michael D ; Liu, Zhiguang 

Subject: Re: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

Any further comments on this change?

I'd like to get it merged.

Thanks,
Jake

From: Jake Garver mailto:j...@nvidia.com>>
Sent: Wednesday, October 18, 2023 10:45 AM
To: gaoliming mailto:gaolim...@byosoft.com.cn>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: michael.d.kin...@intel.com 
mailto:michael.d.kin...@intel.com>>; 
zhiguang@intel.com 
mailto:zhiguang@intel.com>>
Subject: Re: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

Thanks for the review, Liming Gao.

Any further comments on this change?

Thanks,
Jake

From: gaoliming mailto:gaolim...@byosoft.com.cn>>
Sent: Saturday, October 7, 2023 1:05 AM
To: Jake Garver mailto:j...@nvidia.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: michael.d.kin...@intel.com 
mailto:michael.d.kin...@intel.com>>; 
zhiguang@intel.com 
mailto:zhiguang@intel.com>>
Subject: 回复: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

External email: Use caution opening links or attachments


Reviewed-by: Liming Gao 
mailto:gaolim...@byosoft.com.cn>>

> -邮件原件-
> 发件人: Jake Garver mailto:j...@nvidia.com>>
> 发送时间: 2023年10月6日 0:19
> 收件人: devel@edk2.groups.io
> 抄送: michael.d.kin...@intel.com; 
> gaolim...@byosoft.com.cn;
> zhiguang@intel.com; Jake Garver 
> mailto:j...@nvidia.com>>
> 主题: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message
>
> __builtin_return_address returns a pointer, not a string.  Fix the STACK
> FAULT message in BaseStackCheckLib appropriately.
>
> Signed-off-by: Jake Garver mailto:j...@nvidia.com>>
> ---
>  MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> index 0d2918668e..ea168841b6 100644
> --- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> @@ -6,6 +6,7 @@
>   to exiting the function. If the "canary" is overwritten
__stack_chk_fail()
>   is called. This is GCC specific code.
>
> + Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights
reserved.
>   Copyright (c) 2012, Apple Inc. All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -34,7 +35,7 @@ __stack_chk_fail (
>  {
>UINT8  DebugPropertyMask;
>
> -  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow in
> function %a.\n", __builtin_return_address (0)));
> +  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow at 0x%p.\n",
> RETURN_ADDRESS (0)));
>
>//
>// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings even
> if
> --
> 2.34.1




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

Re: [edk2-devel] [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

[Michael D Kinney]

Merged

Mike

From: Kinney, Michael D 
Sent: Wednesday, December 6, 2023 8:47 AM
To: Jake Garver ; Gao, Liming ; 
devel@edk2.groups.io
Cc: Liu, Zhiguang ; Kinney, Michael D 

Subject: RE: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

Hi Jake,

PR opened with Rb tag added: https://github.com/tianocore/edk2/pull/5113

Mike

From: Jake Garver mailto:j...@nvidia.com>>
Sent: Wednesday, December 6, 2023 8:37 AM
To: Gao, Liming mailto:gaolim...@byosoft.com.cn>>; 
devel@edk2.groups.io
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Liu, Zhiguang 
mailto:zhiguang@intel.com>>
Subject: Re: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

Any further comments on this change?

I'd like to get it merged.

Thanks,
Jake

From: Jake Garver mailto:j...@nvidia.com>>
Sent: Wednesday, October 18, 2023 10:45 AM
To: gaoliming mailto:gaolim...@byosoft.com.cn>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: michael.d.kin...@intel.com 
mailto:michael.d.kin...@intel.com>>; 
zhiguang@intel.com 
mailto:zhiguang@intel.com>>
Subject: Re: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

Thanks for the review, Liming Gao.

Any further comments on this change?

Thanks,
Jake

From: gaoliming mailto:gaolim...@byosoft.com.cn>>
Sent: Saturday, October 7, 2023 1:05 AM
To: Jake Garver mailto:j...@nvidia.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: michael.d.kin...@intel.com 
mailto:michael.d.kin...@intel.com>>; 
zhiguang@intel.com 
mailto:zhiguang@intel.com>>
Subject: 回复: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

External email: Use caution opening links or attachments


Reviewed-by: Liming Gao 
mailto:gaolim...@byosoft.com.cn>>

> -邮件原件-
> 发件人: Jake Garver mailto:j...@nvidia.com>>
> 发送时间: 2023年10月6日 0:19
> 收件人: devel@edk2.groups.io
> 抄送: michael.d.kin...@intel.com; 
> gaolim...@byosoft.com.cn;
> zhiguang@intel.com; Jake Garver 
> mailto:j...@nvidia.com>>
> 主题: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message
>
> __builtin_return_address returns a pointer, not a string.  Fix the STACK
> FAULT message in BaseStackCheckLib appropriately.
>
> Signed-off-by: Jake Garver mailto:j...@nvidia.com>>
> ---
>  MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> index 0d2918668e..ea168841b6 100644
> --- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> @@ -6,6 +6,7 @@
>   to exiting the function. If the "canary" is overwritten
__stack_chk_fail()
>   is called. This is GCC specific code.
>
> + Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights
reserved.
>   Copyright (c) 2012, Apple Inc. All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -34,7 +35,7 @@ __stack_chk_fail (
>  {
>UINT8  DebugPropertyMask;
>
> -  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow in
> function %a.\n", __builtin_return_address (0)));
> +  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow at 0x%p.\n",
> RETURN_ADDRESS (0)));
>
>//
>// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings even
> if
> --
> 2.34.1



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

Re: [edk2-devel] TianoCore Community Meeting call for topics

[Michael D Kinney]

No topics.  Meeting canceled.

Mike

From: Kinney, Michael D 
Sent: Tuesday, December 5, 2023 3:11 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: TianoCore Community Meeting call for topics

Are there any topics for the TianoCore Community Meeting this week?

Thanks,

Mike


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

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

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

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



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

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

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

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



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

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

[Michael D Kinney]

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


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



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

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

[Michael D Kinney]

Series Reviewed-by: Michael D Kinney 


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



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

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

[Michael D Kinney]

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


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



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

Re: [edk2-devel] [edk2-libc Patch 1/1] ek2-libc: writeio function in edk2module.c not working as expected

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Jayaprakash, N 
> Sent: Saturday, December 9, 2023 9:43 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran
> ; Kinney, Michael D 
> Subject: [edk2-libc Patch 1/1] ek2-libc: writeio function in
> edk2module.c not working as expected
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4619
> 
> This commit fixes the issue reported in the BZ4619.
> The order of passing the parameters to IoWrite* functions
> called within writeio function in edk2module.c has been corrected
> Also verified the changes by writing reset command to 0xCF9 port
> using writeio function in edk2module.c
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Jayaprakash N 
> ---
>  .../Python/Python-3.6.8/PyMod-3.6.8/Modules/edk2module.c| 6 +++---
>  1 file changed, 3 insertions(+), 3 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 8786df8..d6af8da 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/edk2module.c
> @@ -3985,9 +3985,9 @@ edk2_writeio(PyObject *self, PyObject *args)
> 
>Py_BEGIN_ALLOW_THREADS
>addrs = (short)(addr & 0x);
> -  if (1 == sz) IoWrite8((unsigned char)(value & 0xFF), addrs);
> -  else if (2 == sz) IoWrite16((unsigned short)(value & 0x), addrs);
> -  else if (4 == sz) IoWrite32(value, addrs);
> +  if (1 == sz) IoWrite8(addrs, (unsigned char)(value & 0xFF));
> +  else if (2 == sz) IoWrite16(addrs, (unsigned short)(value & 0x));
> +  else if (4 == sz) IoWrite32(addrs, value);
>Py_END_ALLOW_THREADS
> 
>Py_INCREF(Py_None);
> --
> 2.40.0.windows.1



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

Re: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in BaseIoLibIntrinsic

[Michael D Kinney]

Acked-by: Michael D Kinney 

Mike

> -Original Message-
> From: Tan, Dun 
> Sent: Wednesday, December 6, 2023 1:26 AM
> To: devel@edk2.groups.io; Tan, Dun 
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ni,
> Ray 
> Subject: RE: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> BaseIoLibIntrinsic
> 
> Hi Mike and Liming,
> 
> Could you please help to review this patch?
> 
> Thanks,
> Dun
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Thursday, November 9, 2023 10:50 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ni,
> Ray 
> Subject: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> BaseIoLibIntrinsic
> 
> Simplify IoRead/WriteFifo implement by repeatedly calling IoRead/Write
> in the C code.
> This can avoid calling assembly code to use string I/O instructions.
> With this change Ia32/IoFifo.nasm and X64/IoFifo.nasm can be removed.
> Then the source files for IA32 and X64 are the same.
> 
> Signed-off-by: Dun Tan 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Ray Ni 
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |  10 ++--
> --
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm   | 131 
> 
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c| 220
> 
> 
> 
> 
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm| 120 
> 
> 
>  4 files changed, 222 insertions(+), 259 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> index aeb072ee95..b587e2cded 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> @@ -38,17 +38,11 @@
>IoLibInternalTdxNull.c
>IoLibTdx.h
> 
> -[Sources.IA32]
> +[Sources.IA32, Sources.X64]
>IoLibGcc.c| GCC
>IoLibMsc.c| MSFT
>IoLib.c
> -  Ia32/IoFifo.nasm
> -
> -[Sources.X64]
> -  IoLibGcc.c| GCC
> -  IoLibMsc.c| MSFT
> -  IoLib.c
> -  X64/IoFifo.nasm
> +  IoLibFifo.c
> 
>  [Sources.EBC]
>IoLibEbc.c
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> deleted file mode 100644
> index a4ae1a0053..00
> --- a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> +++ /dev/null
> @@ -1,131 +0,0 @@
> -;--
> 
> -;
> -; Copyright (c) 2006 - 2012, Intel Corporation. All rights
> reserved. -; Copyright (c) 2017, AMD Incorporated. All rights
> reserved. -; -; SPDX-License-Identifier: BSD-2-Clause-Patent -;
> -;--
> 
> -
> -SECTION .text
> -
> -;--
> 
> -;  VOID
> -;  EFIAPI
> -;  IoReadFifo8 (
> -;IN  UINTN Port,
> -;IN  UINTN Size,
> -;OUT VOID  *Buffer
> -;);
> -;--
> 
> -global ASM_PFX(IoReadFifo8)
> -ASM_PFX(IoReadFifo8):
> -pushedi
> -cld
> -mov dx, [esp + 8]
> -mov ecx, [esp + 12]
> -mov edi, [esp + 16]
> -rep insb
> -pop edi
> -ret
> -
> -;--
> 
> -;  VOID
> -;  EFIAPI
> -;  IoReadFifo16 (
> -;IN  UINTN Port,
> -;IN  UINTN Size,
> -;OUT VOID  *Buffer
> -;);
> -;--
> 
> -global ASM_PFX(IoReadFifo16)
> -ASM_PFX(IoReadFifo16):
> -pushedi
> -cld
> -mov dx, [esp + 8]
> -mov ecx, [esp + 12]
> -mov edi, [esp + 16]
> -rep insw
> -pop edi
> -ret
> -
> -;--
> 
> -;  VOID
> -;  EFIAPI
> -

Re: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in BaseIoLibIntrinsic

[Michael D Kinney]

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

> -Original Message-
> From: Kinney, Michael D 
> Sent: Monday, December 11, 2023 9:34 AM
> To: Tan, Dun ; devel@edk2.groups.io
> Cc: Gao, Liming ; Liu, Zhiguang
> ; Ni, Ray ; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> BaseIoLibIntrinsic
> 
> Acked-by: Michael D Kinney 
> 
> Mike
> 
> > -Original Message-
> > From: Tan, Dun 
> > Sent: Wednesday, December 6, 2023 1:26 AM
> > To: devel@edk2.groups.io; Tan, Dun 
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> Ni,
> > Ray 
> > Subject: RE: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> > BaseIoLibIntrinsic
> >
> > Hi Mike and Liming,
> >
> > Could you please help to review this patch?
> >
> > Thanks,
> > Dun
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of duntan
> > Sent: Thursday, November 9, 2023 10:50 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> Ni,
> > Ray 
> > Subject: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> > BaseIoLibIntrinsic
> >
> > Simplify IoRead/WriteFifo implement by repeatedly calling IoRead/Write
> > in the C code.
> > This can avoid calling assembly code to use string I/O instructions.
> > With this change Ia32/IoFifo.nasm and X64/IoFifo.nasm can be removed.
> > Then the source files for IA32 and X64 are the same.
> >
> > Signed-off-by: Dun Tan 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Ray Ni 
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |  10 ++
> --
> > --
> >  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm   | 131 --
> --
> > --
> --
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c| 220
> >
> 
> >
> 
> >
> 
> > 
> >  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm| 120 --
> --
> > --
> --
> > 
> >  4 files changed, 222 insertions(+), 259 deletions(-)
> >
> > diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > index aeb072ee95..b587e2cded 100644
> > --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > @@ -38,17 +38,11 @@
> >IoLibInternalTdxNull.c
> >IoLibTdx.h
> >
> > -[Sources.IA32]
> > +[Sources.IA32, Sources.X64]
> >IoLibGcc.c| GCC
> >IoLibMsc.c| MSFT
> >IoLib.c
> > -  Ia32/IoFifo.nasm
> > -
> > -[Sources.X64]
> > -  IoLibGcc.c| GCC
> > -  IoLibMsc.c| MSFT
> > -  IoLib.c
> > -  X64/IoFifo.nasm
> > +  IoLibFifo.c
> >
> >  [Sources.EBC]
> >IoLibEbc.c
> > diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> > b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> > deleted file mode 100644
> > index a4ae1a0053..00
> > --- a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> > +++ /dev/null
> > @@ -1,131 +0,0 @@
> > -;
> --
> > 
> > -;
> > -; Copyright (c) 2006 - 2012, Intel Corporation. All rights
> > reserved. -; Copyright (c) 2017, AMD Incorporated. All rights
> > reserved. -; -; SPDX-License-Identifier: BSD-2-Clause-Patent -;
> > -;
> --
> > 
> > -
> > -SECTION .text
> > -
> > -;
> --
> > 
> > -;  VOID
> > -;  EFIAPI
> > -;  IoReadFifo8 (
> > -;IN  UINTN Port,
> > -;IN  UINTN Size,
> > -;OUT VOID  *Buffer
> > -;);
> > -;
> --
> > 
> > -globa

Re: [edk2-devel] [PATCH v1 1/1] FatPkg/FatPei: Check array offset before use

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Tuesday, December 12, 2023 11:24 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray 
> Subject: [edk2-devel] [PATCH v1 1/1] FatPkg/FatPei: Check array offset
> before use
> 
> From: Michael Kubacki 
> 
> Move the range check before array access to enforce the bounds
> as expected.
> 
> Cc: Ray Ni 
> Signed-off-by: Michael Kubacki 
> ---
>  FatPkg/FatPei/FatLiteApi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/FatPkg/FatPei/FatLiteApi.c b/FatPkg/FatPei/FatLiteApi.c
> index cc48c4c66b7b..b89ab7009da0 100644
> --- a/FatPkg/FatPei/FatLiteApi.c
> +++ b/FatPkg/FatPei/FatLiteApi.c
> @@ -459,7 +459,7 @@ GetRecoveryCapsuleInfo (
>// Find corresponding physical block device
>//
>BlockDeviceNo = PrivateData->Volume[Index].BlockDeviceNo;
> -  while (PrivateData->BlockDevice[BlockDeviceNo].Logical &&
> BlockDeviceNo < PrivateData->BlockDeviceCount) {
> +  while (BlockDeviceNo < PrivateData->BlockDeviceCount &&
> PrivateData->BlockDevice[BlockDeviceNo].Logical) {
>  BlockDeviceNo = PrivateData-
> >BlockDevice[BlockDeviceNo].ParentDevNo;
>}
> 
> --
> 2.43.0.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#112453):
> https://edk2.groups.io/g/devel/message/112453
> Mute This Topic: https://groups.io/mt/103136267/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [PATCH v4 3/8] MdePkg/MdeLibs.dsc.inc: Add SafeIntLib instance

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Wu, Jiaxin 
> Sent: Friday, December 15, 2023 1:55 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ;
> Laszlo Ersek ; Ni, Ray ; Zeng, Star
> 
> Subject: [PATCH v4 3/8] MdePkg/MdeLibs.dsc.inc: Add SafeIntLib instance
> 
> This patch is to add SafeIntLib in MdeLibs.dsc.inc
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Laszlo Ersek 
> Cc: Ray Ni 
> Cc: Zeng Star 
> Signed-off-by: Jiaxin Wu 
> ---
>  MdePkg/MdeLibs.dsc.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdePkg/MdeLibs.dsc.inc b/MdePkg/MdeLibs.dsc.inc
> index 4580481cb5..deb35c1a18 100644
> --- a/MdePkg/MdeLibs.dsc.inc
> +++ b/MdePkg/MdeLibs.dsc.inc
> @@ -14,5 +14,6 @@
>  [LibraryClasses]
>ArmTrngLib|MdePkg/Library/BaseArmTrngLibNull/BaseArmTrngLibNull.inf
> 
> RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLib
> Null.inf
>CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> 
> SmmCpuRendezvousLib|MdePkg/Library/SmmCpuRendezvousLibNull/SmmCpuRendezv
> ousLibNull.inf
> +  SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
> --
> 2.16.2.windows.1



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

Re: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python VfrCompiler implementation

[Michael D Kinney]

There are several advantages for this direction:


* Current VFR compiler in C has dependencies on very old libs that
  have not been updated.

* The movement to python will remove the pre-build step that requires
  some of the build tools to be built using host C compiler before
  running edk2 build command.

* The other element is moving all the python code into edk2-basetools
  repo with a published pip package.  This enables the use of 
  pip-requirements.txt to provide developers all the content needed
  to build.

I agree that we should not have both VFR compilers.  We need to make
sure the new one in Python is 100% compatible with the C version and
make the decision to simultaneously add Python one and delete the C
one and commit to the Python one.  I provided this feedback to the
VFR developers in the TianoCore Tools/CI meeting earlier this year.

The perf question is very good. It would be good for the VFR developers
to provide some perf comparisons.  I do not expect any significant
different that would impact overall platform build times.

Mike

> -Original Message-
> From: Pedro Falcato 
> Sent: Friday, December 15, 2023 9:04 AM
> To: devel@edk2.groups.io; Chen, Christine 
> Cc: Gao, Liming ; Rebecca Cran
> ; Zimmer, Vincent ; Kinney,
> Michael D ; Leif Lindholm
> ; Andrew Fish ; Feng, Bob C
> ; Yang, Yuting2 ; Hartung,
> Stephen 
> Subject: Re: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python
> VfrCompiler implementation
> 
> On Thu, Dec 7, 2023 at 9:08 AM Yuwei Chen  wrote:
> >
> > Hi Liming,
> >
> >
> >
> > Is this feature been tested and reviewed these two weeks? 😊
> 
> Two questions:
> 
> 1) What testing strategy do you have to test for regressions in such a
> huge rewrite?
> 2) What's the point in shipping this to upstream if you're not aiming
> for the replacement of the original VfrCompiler?
> 3) What's the value of rewriting this in Python? If the existing
> VfrCompiler is already working fine (AFAIK?), a python version will
> likely just be slower (unless the original C version is super badly
> written).
> I *seriously* struggle to understand what this Python movement is
> supposed to do, except gratuitously rewrite large bits of BaseTools
> for a net loss (performance)
> 
> --
> Pedro


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

[edk2-devel] TianoCore Community Meeting - call for topics

[Michael D Kinney]

Any topics for the TianoCore Community meeting this week?

Mike


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

Re: [edk2-devel] TianoCore Community Meeting - call for topics

[Michael D Kinney]

Meeting canceled.

Mike


> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, January 10, 2024 10:37 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D 
> Subject: TianoCore Community Meeting - call for topics
> 
> Any topics for the TianoCore Community meeting this week?
> 
> Mike


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

Re: [edk2-devel] [PATCH v1 1/1] pip-requirements.txt: Update to latest

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Joey Vagedes 
> Sent: Thursday, January 11, 2024 1:35 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm ;
> Kinney, Michael D 
> Subject: [PATCH v1 1/1] pip-requirements.txt: Update to latest
> 
> From: "Joey Vagedes (from Dev Box)" 
> 
> Updates edk2-pytool-extensions, edk2-pytool-library, and regex to their
> latest respective releases.
> 
> Signed-off-by: Joey Vagedes 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> ---
>  pip-requirements.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/pip-requirements.txt b/pip-requirements.txt
> index 8177c60d1808..6420078822b5 100644
> --- a/pip-requirements.txt
> +++ b/pip-requirements.txt
> @@ -12,9 +12,9 @@
>  # https://www.python.org/dev/peps/pep-0440/#version-specifiers
> 
>  ##
> 
> 
> 
> -edk2-pytool-library==0.19.3
> 
> -edk2-pytool-extensions~=0.25.1
> 
> +edk2-pytool-library==0.19.9
> 
> +edk2-pytool-extensions==0.26.4
> 
>  edk2-basetools==0.1.48
> 
>  antlr4-python3-runtime==4.7.1
> 
>  lcov-cobertura==2.0.2
> 
> -regex==2023.8.8
> 
> +regex==2023.12.25
> 
> --
> 2.43.0



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

Re: [edk2-devel] [PATCH v1 1/1] pip-requirements.txt: Update to latest

[Michael D Kinney]

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


From: Joey Vagedes via groups.io 
Sent: Thursday, January 11, 2024 3:16 PM
To: Kinney, Michael D ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v1 1/1] pip-requirements.txt: Update to latest

Thanks Mike,

I've updated the PR / branch with the reviewed-by tag. It is ready to be merged 
at your convenience.

pip-requirements.txt: Update to latest by Javagedes · Pull Request #5256 · 
tianocore/edk2 (github.com)

Thanks,
Joey


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

Re: [edk2-devel] Memory Attribute for depex section

[Michael D Kinney]

Hi Pedro,

Thank you for evaluating this idea change from linked list to improve
performance of the handle database.

The concept of using integers for an EFI_HANDLE has been considered before.
One advantage over pointers is that a guarantee can be made that an EFI_HANDLE
value can be guaranteed to be unique.  In the current implementation with
EFI_HANDLE being a pointer to an allocated buffer, an EFI_HANDLE value could
potentially be reused if an EFI_HANDLE is freed and later allocated for a 
different EFI_HANDLE.

If you continue to explore this path I agree that EFI_HANDLE value of 0 should
be reserved and never used.  I also recommend that new EFI_HANDLE values are
always assigned a new unique value that freed EFI_HANDLE values are never 
reused.

The overall linked list performance of the handle database has also been noted
before, but has rarely raised to the level where it impacts the overall boot
performance relative to other optimization opportunities.  I look forward to
the performance data.  The PERF_X() macros are the right service to use.  On
x86 it is based on the time stamp counter (TSC) which has very small 
granularity.

Mike


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Pedro Falcato
> Sent: Friday, January 12, 2024 6:47 AM
> To: Laszlo Ersek 
> Cc: devel@edk2.groups.io; n...@os.amperecomputing.com;
> ardb+tianoc...@kernel.org; Andrew Fish 
> Subject: Re: [edk2-devel] Memory Attribute for depex section
> 
> On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek  wrote:
> >
> > On 1/12/24 03:10, Pedro Falcato wrote:
> > > My idea was to make each handle an index - like a file descriptor -
> > > AFAIK there's no reason why it *needs* to be an actual pointer.
> > > We'd allocate indices when creating a handle, and return that (casted to
> VOID*).
> >
> > Huh, sneaky.
> >
> > I see two potential problems with this.
> >
> > First, per C std, these "pointers" would be invalid (they wouldn't
> > actually point to valid memory), so even just evaluating them (not
> > dereferencing them!) would invoke undefined behavior. May or may not
> > matter in practice. With compilers getting smarter about optimization
> > (and stricter about std conformance), there could be issues, perhaps.
> 
> This is true. Stashing random integers in pointers is
> implementation-defined. But it's also super common. Win32 HANDLEs are
> exactly this, just integers (stashed in VOID*). The Linux kernel world
> also has a bunch of fun tricks with stashing flags in a pointer's
> bottom bits, magic pointer values, etc. I severely doubt we can run
> into issues with this. EDK2 will not exactly run on the C standard's
> abstract machine anyway ;)
> 
> >
> > The other concern is a bit contrived, but I *guess* there could be code
> > out there that actually dereferences EFI_HANDLEs. That code would crash.
> > May or may not matter, because such code is arguably already
> > semantically invalid. (It would not necessarily be invalid at the
> > language level -- cf. my previous paragraph --, because passing an
> > otherwise valid EFI_HANDLE to CopyMem, for copying just 1 byte out of
> > the underlying opaque data structure, would not violate the language.)
> 
> This is a feature, not a bug! :P
> 
> Seriously though, IHANDLE is not even exposed in semi-public headers,
> so any code that's derefing an EFI_HANDLE will need to do something
> like
> 
> typedef struct {
>   /* ... */
> } IHANDLE;
> 
> EFI_HANDLE Handle = /* ... */;
> 
> IHANDLE *HandleImpl = (IHANDLE *) Handle;
> 
> and I'm a strong believer in "play stupid games, win stupid prizes".
> You can definitely make an argument for "this should definitely crash"
> instead of just "maybe crashing" (for instance, platforms that still
> map the NULL page (like OVMF!), or handles > 4096), so I'm inclined to
> think that if we indeed go this route, we should set one or two upper
> bits (on 64-bit platforms!) to make handles non-canonical addresses
> and therefore necessarily crash on dereference.
> 
> >
> > > I should note that I find it super hard to get a concrete idea on
> > > performance for EFI firmware without adequate tooling - I meant to
> > > write a standalone flamegraph tool a few weeks back (even posted in
> > > edk2-devel), but, as far as I could tell, the architectural timer
> > > protocol couldn't get me the interrupt frame[1]. Until then, whether
> > > any of this radix tree vs RB tree vs flat array stuff really
> > > matters... I find it hard to say.
> > >
> > > [1] x86 has 3 timers (PIT, LAPIC timer, HPET) and performance
> > > monitoring interrupts, and I couldn't freely use any of them :^)
> >
> > Edk2 has some form of profiling already (see
> > "MdePkg/Include/Library/PerformanceLib.h"). Usually one sees core code
> > peppered with PERF_CODE_BEGIN and PERF_CODE_END macros. I *think* there
> > is something like a "display performance" (dp) shell application too,
> > that can show the collected stats. But I've never used these facilities.
> >
> > The

Re: [edk2-devel] Memory Attribute for depex section

[Michael D Kinney]

Agreed.  Basically every API that takes an EF_HANDLE as input calls that API to 
make sure it is a valid handle.

The first question is if we get value from making sure the EFI_HANDLE is a 
member of the active set of handles.

A simple signature check in the EFI_HANDLE may be enough as long as all freed 
handles clear the signature.

Then, the only way that the linked list walk adds value is if there it a call 
with an invalid handle that happens to
have the matching signature.

The

From: Andrew (EFI) Fish 
Sent: Friday, January 12, 2024 10:57 AM
To: edk2-devel-groups-io ; Kinney, Michael D 

Cc: pedro.falc...@gmail.com; Laszlo Ersek ; 
n...@os.amperecomputing.com; ardb+tianoc...@kernel.org
Subject: Re: [edk2-devel] Memory Attribute for depex section




On Jan 12, 2024, at 8:37 AM, Michael D Kinney 
mailto:michael.d.kin...@intel.com>> wrote:

Hi Pedro,

Thank you for evaluating this idea change from linked list to improve
performance of the handle database.

The concept of using integers for an EFI_HANDLE has been considered before.
One advantage over pointers is that a guarantee can be made that an EFI_HANDLE
value can be guaranteed to be unique.  In the current implementation with
EFI_HANDLE being a pointer to an allocated buffer, an EFI_HANDLE value could
potentially be reused if an EFI_HANDLE is freed and later allocated for a
different EFI_HANDLE.

If you continue to explore this path I agree that EFI_HANDLE value of 0 should
be reserved and never used.  I also recommend that new EFI_HANDLE values are
always assigned a new unique value that freed EFI_HANDLE values are never 
reused.

The overall linked list performance of the handle database has also been noted
before, but has rarely raised to the level where it impacts the overall boot
performance relative to other optimization opportunities.  I look forward to
the performance data.  The PERF_X() macros are the right service to use.  On
x86 it is based on the time stamp counter (TSC) which has very small 
granularity.


Mike,

We tracked this a while back with the PERF macros when we had some performance 
issues running diagnostics on a system with 3,000+ handles. The hot path was 
CoreValidateHandle(). I think the number of calls to CoreValidateHandle() 
explodes if you have more handles so it is not just the raw performance of 
CoreValidateHandle(), but also how many times it gets called.

Thanks,

Andrew Fish


Mike



-Original Message-
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>> On Behalf Of Pedro Falcato
Sent: Friday, January 12, 2024 6:47 AM
To: Laszlo Ersek mailto:ler...@redhat.com>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 
n...@os.amperecomputing.com<mailto:n...@os.amperecomputing.com>;
ardb+tianoc...@kernel.org<mailto:ardb+tianoc...@kernel.org>; Andrew Fish 
mailto:af...@apple.com>>
Subject: Re: [edk2-devel] Memory Attribute for depex section

On Fri, Jan 12, 2024 at 9:35 AM Laszlo Ersek 
mailto:ler...@redhat.com>> wrote:


On 1/12/24 03:10, Pedro Falcato wrote:

My idea was to make each handle an index - like a file descriptor -
AFAIK there's no reason why it *needs* to be an actual pointer.
We'd allocate indices when creating a handle, and return that (casted to
VOID*).


Huh, sneaky.

I see two potential problems with this.

First, per C std, these "pointers" would be invalid (they wouldn't
actually point to valid memory), so even just evaluating them (not
dereferencing them!) would invoke undefined behavior. May or may not
matter in practice. With compilers getting smarter about optimization
(and stricter about std conformance), there could be issues, perhaps.

This is true. Stashing random integers in pointers is
implementation-defined. But it's also super common. Win32 HANDLEs are
exactly this, just integers (stashed in VOID*). The Linux kernel world
also has a bunch of fun tricks with stashing flags in a pointer's
bottom bits, magic pointer values, etc. I severely doubt we can run
into issues with this. EDK2 will not exactly run on the C standard's
abstract machine anyway ;)



The other concern is a bit contrived, but I *guess* there could be code
out there that actually dereferences EFI_HANDLEs. That code would crash.
May or may not matter, because such code is arguably already
semantically invalid. (It would not necessarily be invalid at the
language level -- cf. my previous paragraph --, because passing an
otherwise valid EFI_HANDLE to CopyMem, for copying just 1 byte out of
the underlying opaque data structure, would not violate the language.)

This is a feature, not a bug! :P

Seriously though, IHANDLE is not even exposed in semi-public headers,
so any code that's derefing an EFI_HANDLE will need to do something
like

typedef struct {
 /* ... */
} IHANDLE;

EFI_HANDLE Handle = /* ... */;

IHANDLE *HandleImpl = (IHANDLE *) Handle;

and I'm a strong 

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

[Michael D Kinney]

Hi Ray,

I think nesting may be possible in physical platforms, but very hard to induce.

One option is to consolidate to a single LocalApicTimerDxe implementation
in the UefiCpuPkg, but allow the platform DSC to either specify a Null
NestedInterruptTplLib for physical platforms or the full one from the
OvmfPkg for VM use cases.

The other changes could be included for OvmfPkg use cases.  If the VM
does not support the CPUID leafs, then the PCD value should be used.

Mike

> -Original Message-
> From: Pedro Falcato 
> Sent: Monday, January 15, 2024 1:00 AM
> To: devel@edk2.groups.io; Ni, Ray 
> Cc: Kinney, Michael D ; Desimone, Nathaniel
> L ; Laszlo Ersek ;
> Kumar, Rahul R ; Gerd Hoffmann
> 
> Subject: Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe:
> Duplicate OvmfPkg/LocalApicTimerDxe driver
> 
> On Mon, Jan 15, 2024 at 8:04 AM Ni, Ray  wrote:
> >
> > This commit only duplicates the OvmfPkg/LocalApicTimerDxe.
> > Following commits will enhance the driver.
> 
> Hi,
> 
> Please describe why you're doing this change. i.e what's your use case
> for LocalApicTimerDxe, and why are you duplicating this instead of
> moving OvmfPkg's (why do we need to maintain 2 separate versions of
> what is essentially the same driver)?
> 
> Thanks,
> Pedro


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

Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver

[Michael D Kinney]

Unit tests for the math calculations would help with reviews too.

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, January 16, 2024 2:03 AM
> To: Kinney, Michael D ; Pedro Falcato
> ; devel@edk2.groups.io; Ni, Ray
> 
> Cc: Desimone, Nathaniel L ; Kumar, Rahul
> R ; Gerd Hoffmann 
> Subject: Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe:
> Duplicate OvmfPkg/LocalApicTimerDxe driver
> 
> On 1/15/24 19:10, Kinney, Michael D wrote:
> > Hi Ray,
> >
> > I think nesting may be possible in physical platforms, but very hard
> > to induce.
> >
> > One option is to consolidate to a single LocalApicTimerDxe
> > implementation in the UefiCpuPkg, but allow the platform DSC to either
> > specify a Null NestedInterruptTplLib for physical platforms or the
> > full one from the OvmfPkg for VM use cases.
> >
> > The other changes could be included for OvmfPkg use cases.  If the VM
> > does not support the CPUID leafs, then the PCD value should be used.
> 
> All of this sounds great!
> 
> (And I do think that *some* nesting should not be a problem, on either
> physical or virtual platforms, as (IIRC) the interrupt handler stack can
> accommodate a certain level of reentrancy. It's the "storm" that is a
> problem, but that should never occur on physical machines, I reckon.)
> 
> Assuming a v2 is coming up, my advance request would be for Ray to
> re-review the math in patch #4, before posting v2, focusing on integer
> overflows, and SafeIntLib (if needed). I've not looked at the patch in
> detail yet, but I reviewed something similar not so long ago [1]. The
> latter frequency calculation code had been quite commonly used in edk2,
> and I needed hours to review just that one patch. Plus, the review
> turned up a number of issues to fix. So, preferably such a patch should
> not only prevent any integer overflows, but also clarify, in comments,
> why overflows are impossible, and/or how they are prevented.
> 
> [1] https://edk2.groups.io/g/devel/message/111613
> http://mid.mail-archive.com/2e42db7c-a927-f47b-7d80-
> 632895b11...@redhat.com
> 
> Thanks!
> Laszlo



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

Re: [edk2-devel] [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition

[Michael D Kinney]

Reviewed-by: Michael D Kinney 



> -Original Message-
> From: Pethaiyan, Madhan 
> Sent: Thursday, January 18, 2024 12:57 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Kinney, Michael D
> ; Xu, Wei6 ; Tan, Ming
> ; S, Ashraf Ali 
> Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition
> 
> Hi All,
> 
> I had corrected the description, added the UEFI spec version and section
> details . Please check and approve it
> 
> Thanks,
> P. Madhan
> 
> -Original Message-
> From: Pethaiyan, Madhan 
> Sent: Monday, January 8, 2024 12:13 PM
> To: devel@edk2.groups.io
> Cc: Pethaiyan, Madhan ; Gao, Liming
> ; Kinney, Michael D
> ; Xu, Wei6 
> Subject: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition
> 
> From: "Pethaiyan, Madhan" 
> 
> UEFI Spec 2.10 , 23.1 Firmware Management Protocol , Added missing
> condition check under GetImageInfo function, if the PackageVersionName
> is NULL return EFI_INVALID_PARAMETER
> 
> Signed-off-by: Pethaiyan Madhan 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Wei6 Xu 
> ---
>  FmpDevicePkg/FmpDxe/FmpDxe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/FmpDevicePkg/FmpDxe/FmpDxe.c b/FmpDevicePkg/FmpDxe/FmpDxe.c
> index 1e7ec4a09e..e87094f84c 100644
> --- a/FmpDevicePkg/FmpDxe/FmpDxe.c
> +++ b/FmpDevicePkg/FmpDxe/FmpDxe.c
> @@ -495,7 +495,7 @@ GetTheImageInfo (
>// Confirm that buffer isn't null
>//
>if (  (ImageInfo == NULL) || (DescriptorVersion == NULL) ||
> (DescriptorCount == NULL) || (DescriptorSize == NULL)
> - || (PackageVersion == NULL))
> + || (PackageVersion == NULL) || (PackageVersionName == NULL))
>{
>  DEBUG ((DEBUG_ERROR, "FmpDxe(%s): GetImageInfo() - Pointer
> Parameter is NULL.\n", mImageIdName));
>  Status = EFI_INVALID_PARAMETER;
> --
> 2.38.1.windows.1



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

Re: [edk2-devel] [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition

[Michael D Kinney]

Hi Madhan,

The patch you provided does fix the logic in the .c file, but the update is
incomplete.

* FmpDevicePkg/FmpDxe/FmpDxe.c - Update GetTheImageInfo() function header 
  to match the UEFI 2.10 specification that includes all the conditions to
  return EFI_INVALID_PARAMETER.

* FmpDevicePkg/FmpDxe/FmpDxe.h - Update GetTheImageInfo() function header 
  to match the UEFI 2.10 specification that includes all the conditions to
  return EFI_INVALID_PARAMETER.

* MdePkg/Include/Protocol/FirmwareManagement.h - Update function header
  For EFI_FIRMWARE_MANAGEMENT_PROTOCOL_GET_IMAGE_INFO to match the UEFI 2.10
  specification that includes all the conditions to return 
EFI_INVALID_PARAMETER.

Also, when trying to search for these, I found that the FmpDxe implementation
uses the function name "GetTheImageInfo()" for the protocol service called
"GetImageInfo()".  I recommend the FmpDxe implementation be updated so the
function name matches the name of the protocol service.

I will wait for a V3 patch set to review as a whole before merging.

Also, the UEFI SCTs would need to be updated for this additional return status.
please enter a Bugzilla and work with the UEFI SCT team to get them updated.

Thanks,

Mike


> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, January 18, 2024 12:03 PM
> To: Pethaiyan, Madhan ; devel@edk2.groups.io
> Cc: Gao, Liming ; Xu, Wei6
> ; Tan, Ming ; S, Ashraf Ali
> ; Kinney, Michael D 
> Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition
> 
> Reviewed-by: Michael D Kinney 
> 
> 
> 
> > -Original Message-
> > From: Pethaiyan, Madhan 
> > Sent: Thursday, January 18, 2024 12:57 AM
> > To: devel@edk2.groups.io
> > Cc: Gao, Liming ; Kinney, Michael D
> > ; Xu, Wei6 ; Tan, Ming
> > ; S, Ashraf Ali 
> > Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing
> condition
> >
> > Hi All,
> >
> > I had corrected the description, added the UEFI spec version and
> section
> > details . Please check and approve it
> >
> > Thanks,
> > P. Madhan
> >
> > -Original Message-
> > From: Pethaiyan, Madhan 
> > Sent: Monday, January 8, 2024 12:13 PM
> > To: devel@edk2.groups.io
> > Cc: Pethaiyan, Madhan ; Gao, Liming
> > ; Kinney, Michael D
> > ; Xu, Wei6 
> > Subject: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition
> >
> > From: "Pethaiyan, Madhan" 
> >
> > UEFI Spec 2.10 , 23.1 Firmware Management Protocol , Added missing
> > condition check under GetImageInfo function, if the PackageVersionName
> > is NULL return EFI_INVALID_PARAMETER
> >
> > Signed-off-by: Pethaiyan Madhan 
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > Cc: Wei6 Xu 
> > ---
> >  FmpDevicePkg/FmpDxe/FmpDxe.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/FmpDevicePkg/FmpDxe/FmpDxe.c
> b/FmpDevicePkg/FmpDxe/FmpDxe.c
> > index 1e7ec4a09e..e87094f84c 100644
> > --- a/FmpDevicePkg/FmpDxe/FmpDxe.c
> > +++ b/FmpDevicePkg/FmpDxe/FmpDxe.c
> > @@ -495,7 +495,7 @@ GetTheImageInfo (
> >// Confirm that buffer isn't null
> >//
> >if (  (ImageInfo == NULL) || (DescriptorVersion == NULL) ||
> > (DescriptorCount == NULL) || (DescriptorSize == NULL)
> > - || (PackageVersion == NULL))
> > + || (PackageVersion == NULL) || (PackageVersionName == NULL))
> >{
> >  DEBUG ((DEBUG_ERROR, "FmpDxe(%s): GetImageInfo() - Pointer
> > Parameter is NULL.\n", mImageIdName));
> >  Status = EFI_INVALID_PARAMETER;
> > --
> > 2.38.1.windows.1



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

Re: [edk2-devel] [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition

[Michael D Kinney]

Hi Madhan,

There are 2 additional files that need function header updates:

* SignedCapsulePkg\Universal\SystemFirmwareUpdate\SystemFirmwareCommonDxe.c
* SignedCapsulePkg\Universal\SystemFirmwareUpdate\SystemFirmwareDxe.h

In addition, there are function headers in the edk2-platforms repo that 
also need to be updated in separate patch series.

* 
edk2-platforms\Silicon\Intel\IntelSiliconPkg\Feature\Capsule\MicrocodeUpdateDxe\MicrocodeFmp.c
* 
edk2-platforms\Silicon\Intel\IntelSiliconPkg\Feature\Capsule\MicrocodeUpdateDxe\MicrocodeUpdate.h

Mike

> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, January 18, 2024 2:30 PM
> To: Pethaiyan, Madhan ; devel@edk2.groups.io
> Cc: Gao, Liming ; Xu, Wei6
> ; Tan, Ming ; S, Ashraf Ali
> ; Kinney, Michael D 
> Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition
> 
> Hi Madhan,
> 
> The patch you provided does fix the logic in the .c file, but the update
> is
> incomplete.
> 
> * FmpDevicePkg/FmpDxe/FmpDxe.c - Update GetTheImageInfo() function
> header
>   to match the UEFI 2.10 specification that includes all the conditions
> to
>   return EFI_INVALID_PARAMETER.
> 
> * FmpDevicePkg/FmpDxe/FmpDxe.h - Update GetTheImageInfo() function
> header
>   to match the UEFI 2.10 specification that includes all the conditions
> to
>   return EFI_INVALID_PARAMETER.
> 
> * MdePkg/Include/Protocol/FirmwareManagement.h - Update function header
>   For EFI_FIRMWARE_MANAGEMENT_PROTOCOL_GET_IMAGE_INFO to match the UEFI
> 2.10
>   specification that includes all the conditions to return
> EFI_INVALID_PARAMETER.
> 
> Also, when trying to search for these, I found that the FmpDxe
> implementation
> uses the function name "GetTheImageInfo()" for the protocol service
> called
> "GetImageInfo()".  I recommend the FmpDxe implementation be updated so
> the
> function name matches the name of the protocol service.
> 
> I will wait for a V3 patch set to review as a whole before merging.
> 
> Also, the UEFI SCTs would need to be updated for this additional return
> status.
> please enter a Bugzilla and work with the UEFI SCT team to get them
> updated.
> 
> Thanks,
> 
> Mike
> 
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Thursday, January 18, 2024 12:03 PM
> > To: Pethaiyan, Madhan ;
> devel@edk2.groups.io
> > Cc: Gao, Liming ; Xu, Wei6
> > ; Tan, Ming ; S, Ashraf Ali
> > ; Kinney, Michael D
> 
> > Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing
> condition
> >
> > Reviewed-by: Michael D Kinney 
> >
> >
> >
> > > -Original Message-
> > > From: Pethaiyan, Madhan 
> > > Sent: Thursday, January 18, 2024 12:57 AM
> > > To: devel@edk2.groups.io
> > > Cc: Gao, Liming ; Kinney, Michael D
> > > ; Xu, Wei6 ; Tan,
> Ming
> > > ; S, Ashraf Ali 
> > > Subject: RE: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing
> > condition
> > >
> > > Hi All,
> > >
> > > I had corrected the description, added the UEFI spec version and
> > section
> > > details . Please check and approve it
> > >
> > > Thanks,
> > > P. Madhan
> > >
> > > -Original Message-
> > > From: Pethaiyan, Madhan 
> > > Sent: Monday, January 8, 2024 12:13 PM
> > > To: devel@edk2.groups.io
> > > Cc: Pethaiyan, Madhan ; Gao, Liming
> > > ; Kinney, Michael D
> > > ; Xu, Wei6 
> > > Subject: [PATCH V2] FmpDevicePkg: GetImageInfo Add missing condition
> > >
> > > From: "Pethaiyan, Madhan" 
> > >
> > > UEFI Spec 2.10 , 23.1 Firmware Management Protocol , Added missing
> > > condition check under GetImageInfo function, if the
> PackageVersionName
> > > is NULL return EFI_INVALID_PARAMETER
> > >
> > > Signed-off-by: Pethaiyan Madhan 
> > > Cc: Liming Gao 
> > > Cc: Michael D Kinney 
> > > Cc: Wei6 Xu 
> > > ---
> > >  FmpDevicePkg/FmpDxe/FmpDxe.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/FmpDevicePkg/FmpDxe/FmpDxe.c
> > b/FmpDevicePkg/FmpDxe/FmpDxe.c
> > > index 1e7ec4a09e..e87094f84c 100644
> > > --- a/FmpDevicePkg/FmpDxe/FmpDxe.c
> > > +++ b/FmpDevicePkg/FmpDxe/FmpDxe.c
> > > @@ -495,7 +495,7 @@ GetTheImageInfo (
> > >// Confirm that buffer isn't null
> > >//
> > >if (  (ImageInfo == NULL) || (DescriptorVersion == NULL) ||
> > > (DescriptorCount == NULL) || (DescriptorSize == NULL)
> > > - || (PackageVersion == NULL))
> > > + || (PackageVersion == NULL) || (PackageVersionName == NULL))
> > >{
> > >  DEBUG ((DEBUG_ERROR, "FmpDxe(%s): GetImageInfo() - Pointer
> > > Parameter is NULL.\n", mImageIdName));
> > >  Status = EFI_INVALID_PARAMETER;
> > > --
> > > 2.38.1.windows.1



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

Re: [edk2-devel] [PATCH RESEND v2 1/2] MdePkg: Adds AMD Extended CPU topology CPUID

[Michael D Kinney]

Acked-by: Michael D Kinney 

> -Original Message-
> From: Abdul Lateef Attar 
> Sent: Wednesday, January 17, 2024 7:54 PM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar ; Kinney, Michael D
> ; Liming Gao ;
> Liu, Zhiguang ; Ni, Ray ;
> Kumar, Rahul R ; Gerd Hoffmann
> 
> Subject: [PATCH RESEND v2 1/2] MdePkg: Adds AMD Extended CPU topology
> CPUID
> 
> From: Abdul Lateef Attar 
> 
> Adds cpuid macro for AMD extended CPU topology.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Abdul Lateef Attar 
> ---
>  MdePkg/Include/Register/Amd/Cpuid.h | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Register/Amd/Cpuid.h
> b/MdePkg/Include/Register/Amd/Cpuid.h
> index 44394fc7a4..add43c40aa 100644
> --- a/MdePkg/Include/Register/Amd/Cpuid.h
> +++ b/MdePkg/Include/Register/Amd/Cpuid.h
> @@ -6,7 +6,7 @@
>If a register returned is a single 32-bit value, then a data
> structure is
>not provided for that register.
> 
> -  Copyright (c) 2017, Advanced Micro Devices. All rights reserved.
> +  Copyright (c) 2017 - 2024, Advanced Micro Devices. All rights
> reserved.
> 
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> @@ -42,6 +42,27 @@ CPUID Signature Information
>  /// @}
>  ///
> 
> +/**
> +  CPUID Extended Topology Enumeration
> +
> +  @note
> +  Reference: AMD64 Architecture Programmer’s Manual Volume 3: General-
> Purpose and System Instructions,
> + Revision 3.35 Appendix E,
> +  E.4.24 Function 8000_0026—Extended CPU Topology:
> +CPUID Fn8000_0026 reports extended topology information for logical
> processors, including
> +asymmetric and heterogenous topology descriptions. Individual
> logical processors may report
> +different values in systems with asynchronous and heterogeneous
> topologies.
> +The topology level is selected by the value passed to the
> instruction in ECX. To discover the topology
> +of a system, software should execute CPUID Fn8000_0026 with
> increasing ECX values, starting with
> +a value of zero, until the returned hierarchy level type (CPUID
> Fn8000_0026_ECX[LevelType]) is
> +equal to zero. It is not guaranteed that all topology level types
> are present in the system
> +
> +  @param   EAX  AMD_CPUID_EXTENDED_TOPOLOGY   (0x8026)
> +  @param   ECX  Level number
> +
> +**/
> +#define AMD_CPUID_EXTENDED_TOPOLOGY  0x8026
> +
>  /**
>CPUID Extended Processor Signature and Features
> 
> --
> 2.34.1



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

Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf

[Michael D Kinney]

Hi Tom,

I do not see any harm in zeroing ECX in AsmCpuid().

If it is not zeroed, then it would have an undefined value.

However, calling AsmCpuid() for any Index that evaluates ECX
(including a check for 0) should never be done.  If ECX is
evaluated for a given Index, then AsmCpuIdEx() must be used.

Mike

> -Original Message-
> From: Tom Lendacky 
> Sent: Wednesday, January 17, 2024 1:26 PM
> To: devel@edk2.groups.io; Kinney, Michael D
> ; Gao, Liming ; Liu,
> Zhiguang ; Dong, Eric ; Ni,
> Ray ; Kumar, Rahul R ; Gerd
> Hoffmann ; Ard Biesheuvel 
> Cc: Michael Roth 
> Subject: Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use
> AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf
> 
> On 11/28/23 08:35, Lendacky, Thomas via groups.io wrote:
> > On 11/6/23 17:15, Tom Lendacky wrote:
> >> On 11/6/23 16:45, Lendacky, Thomas via groups.io wrote:
> >>> The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
> >>> returning CPUID information. However, the AsmCpuid() function does
> not
> >>> zero out ECX before the CPUID instruction, so the input leaf is used
> as
> >>> the sub-leaf for the CPUID request and returns erroneous/invalid
> CPUID
> >>> data, since the intent of the request was to get data related to
> sub-leaf
> >>> 0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf.
> >>
> >> Alternatively, the AsmCpuid() function could be changed to XOR ECX
> >> before invoking the CPUID instruction. This would ensure that the 0
> >> sub-leaf is returned for any CPUID leaves that support sub-leaves.
> >> Thoughts?
> >>
> >> Adding some additional maintainers for their thoughts, too.
> >
> > Any thoughts on this approach (as a separate, unrelated patch) to
> > eliminate future issues that could pop up?
> >
> > Seems like zeroing out ECX before calling CPUID would be an
> appropriate
> > thing to do, but I'm not sure if that will have any impact on the
> existing
> > code base... it shouldn't, but you never know.
> 
> Just a re-ping for thoughts on this.
> 
> Thanks,
> Tom
> 
> >
> > Thanks,
> > Tom
> >
> >>
> >> Thanks,
> >> Tom


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

Re: [edk2-devel] [PATCH edk2-platforms 1/1] IpmiFeaturePkg/ServerManagementLib: Fix a GCC compile error

[Michael D Kinney]

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Xu, Wei6
> Sent: Wednesday, January 17, 2024 10:12 AM
> To: devel@edk2.groups.io
> Cc: Xu, Wei6 ; Abner Chang ;
> Desimone, Nathaniel L 
> Subject: [edk2-devel] [PATCH edk2-platforms 1/1]
> IpmiFeaturePkg/ServerManagementLib: Fix a GCC compile error
> 
> The source file definition in INF file is ServerManagementELog.c,
> while the actual file name is ServerManagementElog.c. The case is
> mismatched. Correct the definition in INF file to fix this issue.
> 
> Cc: Abner Chang 
> Cc: Nate DeSimone 
> Signed-off-by: Wei6 Xu 
> ---
>  .../Library/ServerManagementLib/ServerManagementLib.inf   | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/ServerManage
> mentLib/ServerManagementLib.inf
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/ServerManage
> mentLib/ServerManagementLib.inf
> index 6e7702e0db33..5c5e8f6d48af 100644
> ---
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/ServerManage
> mentLib/ServerManagementLib.inf
> +++
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/ServerManage
> mentLib/ServerManagementLib.inf
> @@ -1,6 +1,6 @@
>  ### @file
>  #
> -# Copyright (c) 2023, Intel Corporation. All rights reserved.
> +# Copyright (c) 2023 - 2024, Intel Corporation. All rights
> reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -17,7 +17,7 @@
>LIBRARY_CLASS  = ServerManagementLib
> 
>  [Sources]
> -  ServerManagementELog.c
> +  ServerManagementElog.c
>ServerManagementTime.c
> 
>  [Packages]
> --
> 2.29.2.windows.2
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

[Michael D Kinney]

Acked-by: Michael D Kinney 

I will prepare PR for merge




From: Kasbekar, Saloni  
Sent: Wednesday, January 17, 2024 9:27 AM
To: Ashish Singhal ; devel@edk2.groups.io; 
Clark-williams, Zachary ; Jeff Brasen 
; Kinney, Michael D ; Gao, 
Liming 
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Liming, Mike,

Could you please help merge this PR?

Thanks,
Saloni

From: Ashish Singhal <mailto:ashishsin...@nvidia.com> 
Sent: Wednesday, January 17, 2024 6:08 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io; Clark-williams, Zachary 
<mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Hello,

Checking back for an update on when this PR can be merged or if there are any 
other changes you recommend.

Thanks
Ashish


From: Ashish Singhal <mailto:ashishsin...@nvidia.com>
Sent: Saturday, January 6, 2024 5:53 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Clark-williams, 
Zachary <mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default 
 
Thanks Saloni. PR for getting this merged is available at 
https://github.com/tianocore/edk2/pull/5150

Thanks
Ashish


From: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>
Sent: Saturday, January 6, 2024 1:31 AM
To: Ashish Singhal <mailto:ashishsin...@nvidia.com>; 
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Clark-williams, 
Zachary <mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default 
 
External email: Use caution opening links or attachments

Yes, SetData does reset the previous configuration.
 
Reviewed-by: Saloni Kasbekar <mailto:saloni.kasbe...@intel.com>
 
Thanks,
Saloni
 
From: Ashish Singhal <mailto:ashishsin...@nvidia.com>
Sent: Friday, January 5, 2024 2:34 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io; Clark-williams, Zachary 
<mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default
 
I do not recommend doing that. Setting policy via SetData does enough to wipe 
out any previous manual configuration and that is the goal for reset to default.

From: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>
Sent: Friday, January 5, 2024 2:30 AM
To: Ashish Singhal <mailto:ashishsin...@nvidia.com>; 
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Clark-williams, 
Zachary <mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default
 
External email: Use caution opening links or attachments
 
Makes sense. Should we also set IfrNvData->DhcpEnable = TRUE when updating the 
Policy then?
 
From: Ashish Singhal <mailto:ashishsin...@nvidia.com>
Sent: Wednesday, January 3, 2024 8:52 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io; Clark-williams, Zachary 
<mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default
 
Hello Saloni,
 
Thanks for the feedback. After the reset, or when we disable configure from 
menu, GetData returns policy to static as the enum value is 0. However, setting 
value as static does not have any benefit as it forces to reuse the old network 
settings. Using DHCP really mimics the reset behavior that we see without any 
configuration done manually.
 
Thanks
Ashish
 

From: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>
Sent: Tuesday, January 2, 2024 1:47 PM
To: Ashish Singhal <mailto:ashishsin...@nvidia.com>; 
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Clark-williams, 
Zachary <mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default
 
External email: Use caution opening links or attachments
 
Hi Ashish,
 
+    Ip4NvData->Policy = Ip4Config2PolicyDhcp;
+    Status    = Ip4Cfg2->SetData (
+   Ip4Cfg2,
+   Ip4Config2DataTypePolicy,
+   sizeof (EFI_IP4_CONFIG2_POLICY),
+   &Ip4NvData->Policy
+   );
 
Here we're assuming IfrFormNvData->DhcpEnable is TRUE. Should we

Re: [edk2-devel] [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

[Michael D Kinney]

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

Mike

From: Ashish Singhal 
Sent: Thursday, January 18, 2024 5:55 PM
To: Kinney, Michael D ; Kasbekar, Saloni 
; devel@edk2.groups.io; Clark-williams, Zachary 
; Jeff Brasen ; Gao, 
Liming 
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Replied too soon. I saw you had already closed mine.

Thanks
Ashish


From: Ashish Singhal mailto:ashishsin...@nvidia.com>>
Sent: Friday, January 19, 2024 7:23 AM
To: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Kasbekar, 
Saloni mailto:saloni.kasbe...@intel.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>; Clark-williams, Zachary 
mailto:zachary.clark-willi...@intel.com>>; 
Jeff Brasen mailto:jbra...@nvidia.com>>; Gao, Liming 
mailto:gaolim...@byosoft.com.cn>>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Hi Michael,

If you are going to create a new PR yourself instead of using the one I already 
created (https://github.com/tianocore/edk2/pull/5150), should I close this one?

Thanks
Ashish

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Friday, January 19, 2024 4:57 AM
To: Kasbekar, Saloni 
mailto:saloni.kasbe...@intel.com>>; Ashish Singhal 
mailto:ashishsin...@nvidia.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>; Clark-williams, Zachary 
mailto:zachary.clark-willi...@intel.com>>; 
Jeff Brasen mailto:jbra...@nvidia.com>>; Gao, Liming 
mailto:gaolim...@byosoft.com.cn>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

External email: Use caution opening links or attachments


Acked-by: Michael D Kinney 
mailto:michael.d.kin...@intel.com>>

I will prepare PR for merge




From: Kasbekar, Saloni 
mailto:saloni.kasbe...@intel.com>>
Sent: Wednesday, January 17, 2024 9:27 AM
To: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Clark-williams, Zachary 
mailto:zachary.clark-willi...@intel.com>>; 
Jeff Brasen mailto:jbra...@nvidia.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:gaolim...@byosoft.com.cn>>
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Liming, Mike,

Could you please help merge this PR?

Thanks,
Saloni

From: Ashish Singhal <mailto:ashishsin...@nvidia.com>
Sent: Wednesday, January 17, 2024 6:08 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io; Clark-williams, Zachary 
<mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Hello,

Checking back for an update on when this PR can be merged or if there are any 
other changes you recommend.

Thanks
Ashish


From: Ashish Singhal <mailto:ashishsin...@nvidia.com>
Sent: Saturday, January 6, 2024 5:53 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Clark-williams, 
Zachary <mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

Thanks Saloni. PR for getting this merged is available at 
https://github.com/tianocore/edk2/pull/5150

Thanks
Ashish


From: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>
Sent: Saturday, January 6, 2024 1:31 AM
To: Ashish Singhal <mailto:ashishsin...@nvidia.com>; 
mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Clark-williams, 
Zachary <mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: RE: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

External email: Use caution opening links or attachments

Yes, SetData does reset the previous configuration.

Reviewed-by: Saloni Kasbekar <mailto:saloni.kasbe...@intel.com>

Thanks,
Saloni

From: Ashish Singhal <mailto:ashishsin...@nvidia.com>
Sent: Friday, January 5, 2024 2:34 AM
To: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>; 
mailto:devel@edk2.groups.io; Clark-williams, Zachary 
<mailto:zachary.clark-willi...@intel.com>; Jeff Brasen 
<mailto:jbra...@nvidia.com>
Subject: Re: [PATCH] NetworkPkg/Ip4Dxe: Fix Reset To Default

I do not recommend doing that. Setting policy via SetData does enough to wipe 
out any previous manual configuration and that is the goal for reset to default.

From: Kasbekar, Saloni <mailto:saloni.kasbe...@intel.com>
Sent: Friday, January 5, 2024 2:30 AM
To: Ashish Singhal <

Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf

[Michael D Kinney]

Hi Ray,

It is about having deterministic behavior if a call if made for
a CPUID EAX value that does depend on ECX.  If ECX is not zeroed,
then it will have a random value that may return different
information.

The problem statement from Tom is not about zeroing ECX.  It is
about avoiding code bugs where AsmCpuid() is called for an Index
value that is documented to depend on ECX.  In this case, we would
want an error condition so the developer knows they should use 
AsmCpuidEx() instead.

From looking at the Intel SDM, there is a small set of Index
values that do not look at ECX at all.  We could consider
adding an ASSERT() condition in AsmCpuid() if Index is 
a value that depends on ECX.  Perhaps in DEBUG_CODE() so
it is not always present. 

Mike

> -Original Message-
> From: Ni, Ray 
> Sent: Friday, January 19, 2024 2:01 AM
> To: Kinney, Michael D ; Tom Lendacky
> ; devel@edk2.groups.io; Gao, Liming
> ; Liu, Zhiguang ; Dong,
> Eric ; Kumar, Rahul R ;
> Gerd Hoffmann ; Ard Biesheuvel
> 
> Cc: Michael Roth 
> Subject: RE: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use
> AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf
> 
> Mike,
> I agree with your words after "However".
> Zeroing ECX in AsmCpuid() is confusing to future code maintainer: If
> CPUID instruction does
> not consume "ECX", why is it needed to zero "ECX"?
> 
> Thanks,
> Ray
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Friday, January 19, 2024 7:11 AM
> > To: Tom Lendacky ; devel@edk2.groups.io;
> > Gao, Liming ; Liu, Zhiguang
> ;
> > Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R
> > ; Gerd Hoffmann ; Ard
> > Biesheuvel 
> > Cc: Michael Roth ; Kinney, Michael D
> > 
> > Subject: RE: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use
> > AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf
> >
> > Hi Tom,
> >
> > I do not see any harm in zeroing ECX in AsmCpuid().
> >
> > If it is not zeroed, then it would have an undefined value.
> >
> > However, calling AsmCpuid() for any Index that evaluates ECX
> > (including a check for 0) should never be done.  If ECX is
> > evaluated for a given Index, then AsmCpuIdEx() must be used.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Tom Lendacky 
> > > Sent: Wednesday, January 17, 2024 1:26 PM
> > > To: devel@edk2.groups.io; Kinney, Michael D
> > > ; Gao, Liming ;
> Liu,
> > > Zhiguang ; Dong, Eric ;
> Ni,
> > > Ray ; Kumar, Rahul R ;
> Gerd
> > > Hoffmann ; Ard Biesheuvel
> > 
> > > Cc: Michael Roth 
> > > Subject: Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use
> > > AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf
> > >
> > > On 11/28/23 08:35, Lendacky, Thomas via groups.io wrote:
> > > > On 11/6/23 17:15, Tom Lendacky wrote:
> > > >> On 11/6/23 16:45, Lendacky, Thomas via groups.io wrote:
> > > >>> The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input
> > when
> > > >>> returning CPUID information. However, the AsmCpuid() function
> does
> > > not
> > > >>> zero out ECX before the CPUID instruction, so the input leaf is
> used
> > > as
> > > >>> the sub-leaf for the CPUID request and returns erroneous/invalid
> > > CPUID
> > > >>> data, since the intent of the request was to get data related to
> > > sub-leaf
> > > >>> 0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY
> leaf.
> > > >>
> > > >> Alternatively, the AsmCpuid() function could be changed to XOR
> ECX
> > > >> before invoking the CPUID instruction. This would ensure that the
> 0
> > > >> sub-leaf is returned for any CPUID leaves that support sub-
> leaves.
> > > >> Thoughts?
> > > >>
> > > >> Adding some additional maintainers for their thoughts, too.
> > > >
> > > > Any thoughts on this approach (as a separate, unrelated patch) to
> > > > eliminate future issues that could pop up?
> > > >
> > > > Seems like zeroing out ECX before calling CPUID would be an
> > > appropriate
> > > > thing to do, but I'm not sure if that will have any impact on the
> > > existing
> > > > code base... it shouldn't, but you never know.
> > >
> > > Just a re-ping for thoughts on this.
> > >
> > > Thanks,
> > > Tom
> > >
> > > >
> > > > Thanks,
> > > > Tom
> > > >
> > > >>
> > > >> Thanks,
> > > >> Tom


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

Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf

[Michael D Kinney]

The issue is if AsmCpuid() is called for an Index value that does depend on 
ECX.  That would be a bug on the caller's part and would not have deterministic 
behavior because ECX on input is not deterministic.  That is the condition that 
would be good to catch.

Mike

From: Ni, Ray 
Sent: Friday, January 19, 2024 3:49 PM
To: Kinney, Michael D ; Tom Lendacky 
; devel@edk2.groups.io; Gao, Liming 
; Liu, Zhiguang ; Dong, Eric 
; Kumar, Rahul R ; Gerd Hoffmann 
; Ard Biesheuvel 
Cc: Michael Roth ; Kinney, Michael D 

Subject: Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() 
for CPUID_EXTENDED_TOPOLOGY leaf

Mike,
For a certain Cupid leaf that does not have sub leaf, Cupid instruction does 
not consume ecx and it always fills ecx with a determined value, defined by sdm.
So, I don't see any hurt to deterministic behavior if not zeroing ecx in 
AsmCpuid.

thanks,
ray

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Saturday, January 20, 2024 7:16:14 AM
To: Ni, Ray mailto:ray...@intel.com>>; Tom Lendacky 
mailto:thomas.lenda...@amd.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; Gao, Liming 
mailto:liming@intel.com>>; Liu, Zhiguang 
mailto:zhiguang@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>; Kumar, Rahul R 
mailto:rahul.r.ku...@intel.com>>; Gerd Hoffmann 
mailto:kra...@redhat.com>>; Ard Biesheuvel 
mailto:ardb+tianoc...@kernel.org>>
Cc: Michael Roth mailto:michael.r...@amd.com>>; Kinney, 
Michael D mailto:michael.d.kin...@intel.com>>
Subject: RE: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() 
for CPUID_EXTENDED_TOPOLOGY leaf

Hi Ray,

It is about having deterministic behavior if a call if made for
a CPUID EAX value that does depend on ECX.  If ECX is not zeroed,
then it will have a random value that may return different
information.

The problem statement from Tom is not about zeroing ECX.  It is
about avoiding code bugs where AsmCpuid() is called for an Index
value that is documented to depend on ECX.  In this case, we would
want an error condition so the developer knows they should use
AsmCpuidEx() instead.

>From looking at the Intel SDM, there is a small set of Index
values that do not look at ECX at all.  We could consider
adding an ASSERT() condition in AsmCpuid() if Index is
a value that depends on ECX.  Perhaps in DEBUG_CODE() so
it is not always present.

Mike

> -Original Message-
> From: Ni, Ray mailto:ray...@intel.com>>
> Sent: Friday, January 19, 2024 2:01 AM
> To: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Tom Lendacky
> mailto:thomas.lenda...@amd.com>>; 
> devel@edk2.groups.io; Gao, Liming
> mailto:liming@intel.com>>; Liu, Zhiguang 
> mailto:zhiguang@intel.com>>; Dong,
> Eric mailto:eric.d...@intel.com>>; Kumar, Rahul R 
> mailto:rahul.r.ku...@intel.com>>;
> Gerd Hoffmann mailto:kra...@redhat.com>>; Ard Biesheuvel
> mailto:ardb+tianoc...@kernel.org>>
> Cc: Michael Roth mailto:michael.r...@amd.com>>
> Subject: RE: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use
> AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf
>
> Mike,
> I agree with your words after "However".
> Zeroing ECX in AsmCpuid() is confusing to future code maintainer: If
> CPUID instruction does
> not consume "ECX", why is it needed to zero "ECX"?
>
> Thanks,
> Ray
> > -Original Message-
> > From: Kinney, Michael D 
> > mailto:michael.d.kin...@intel.com>>
> > Sent: Friday, January 19, 2024 7:11 AM
> > To: Tom Lendacky mailto:thomas.lenda...@amd.com>>; 
> > devel@edk2.groups.io;
> > Gao, Liming mailto:liming@intel.com>>; Liu, 
> > Zhiguang
> mailto:zhiguang@intel.com>>;
> > Dong, Eric mailto:eric.d...@intel.com>>; Ni, Ray 
> > mailto:ray...@intel.com>>; Kumar,
> Rahul R
> > mailto:rahul.r.ku...@intel.com>>; Gerd Hoffmann 
> > mailto:kra...@redhat.com>>; Ard
> > Biesheuvel mailto:ardb+tianoc...@kernel.org>>
> > Cc: Michael Roth mailto:michael.r...@amd.com>>; 
> > Kinney, Michael D
> > mailto:michael.d.kin...@intel.com>>
> > Subject: RE: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use
> > AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf
> >
> > Hi Tom,
> >
> > I do not see any harm in zeroing ECX in AsmCpuid().
> >
> > If it is not zeroed, then it would have an undefined value.
> >
> > However, calling AsmCpuid() for any Index that evaluates ECX
> > (including a check for 0) should never be done.  If ECX is
> > evaluated for a given Index, then AsmCpuIdEx() must be used.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Tom Lendacky 
> > > mailto:thomas.lenda...@amd.com>>
> > > Sent: Wednesday, January 17, 2024 1:26 PM
> > > To: devel@edk2.groups.io; Kinney, Michael D
> > > mailto:michael.d.kin...@intel.com>>; Gao, 
> > > Liming mailto:liming@intel.com>>;
> Liu,
> > > Zhiguang mailto:zhiguang@intel.com>>; Dong, 
> > > Eric mailto:eric.d...@in

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg: Optimize CoreConnectSingleController

[Michael D Kinney]

I agree that this implements the similar check as other 
optional protocols to adjust driver binding order to skip
checks for which where are no instances of the optional
protocol.

Reviewed-by: Michael D Kinney 




> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zhi Jin
> Sent: Tuesday, January 16, 2024 10:45 PM
> To: devel@edk2.groups.io
> Cc: Jin, Zhi ; Liming Gao ;
> Ni, Ray 
> Subject: [edk2-devel] [PATCH 2/2] MdeModulePkg: Optimize
> CoreConnectSingleController
> 
> CoreConnectSingleController() searches for the Driver Family Override
> Protocol drivers by looping and checking each Driver Binding Handles.
> This loop can be skipped by checking if any Driver Family Override
> Protocol installed in the platform first, to improve the performance.
> 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Signed-off-by: Zhi Jin 
> ---
>  MdeModulePkg/Core/Dxe/Hand/DriverSupport.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
> b/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
> index 0b824c62b7..64d7474f15 100644
> --- a/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
> +++ b/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c
> @@ -497,7 +497,12 @@ CoreConnectSingleController (
>//
>// Add the Driver Family Override Protocol drivers for
> ControllerHandle
>//
> -  while (TRUE) {
> +  Status = CoreLocateProtocol (
> + &gEfiDriverFamilyOverrideProtocolGuid,
> + NULL,
> + (VOID **)&DriverFamilyOverride
> + );
> +  while (!EFI_ERROR (Status) && (DriverFamilyOverride != NULL)) {
>  HighestIndex   = DriverBindingHandleCount;
>  HighestVersion = 0;
>  for (Index = 0; Index < DriverBindingHandleCount; Index++) {
> --
> 2.39.2
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 1/2] MdeModulePkg: Remove the handle validation check in CoreGetProtocolInterface

[Michael D Kinney]

Hi Zhi,

Some comments below.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zhi Jin
> Sent: Tuesday, January 16, 2024 10:45 PM
> To: devel@edk2.groups.io
> Cc: Jin, Zhi ; Liming Gao ;
> Ni, Ray 
> Subject: [edk2-devel] [PATCH 1/2] MdeModulePkg: Remove the handle
> validation check in CoreGetProtocolInterface
> 
> CoreGetProtocolInterface() is called by CoreOpenProtocol(),
> CoreCloseProtocol() and CoreOpenProtocolInformation().
> Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input
> parameter UserHandle has been already checked for validation. So does
> CoreCloseProtocol().
> Removing the handle validation check in CoreGetProtocolInterface()
> could improve the performance, as CoreOpenProtocol() is called very
> frequently.
> Meanwhile, need to make it the caller's responsibility to check the
> parameters, and add the check in CoreOpenProtocolInformation().
> 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Signed-off-by: Zhi Jin 
> ---
>  MdeModulePkg/Core/Dxe/Hand/Handle.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.c
> b/MdeModulePkg/Core/Dxe/Hand/Handle.c
> index 51e5b5d3b3..a0d2d03267 100644
> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.c
> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.c
> @@ -916,6 +916,8 @@ CoreUninstallMultipleProtocolInterfaces (
> 
>  /**
>Locate a certain GUID protocol interface in a Handle's protocols.
> +  Note: This function doesn't do parameters checking, it's caller's
> responsibility
> +  to pass in valid parameters.
> 
>@param  UserHandle The handle to obtain the protocol
> interface on

Instead of a Note:, I recommend the description of this parameter
be updated to state that the caller must pass in a valid UserHandle
that is checked with CoreValidateHandle().

Also, this API CoreGetProtocolInterface() is an internal helper 
function.  I also recommend that this function be declared 'static'
so the scope of the assumption that UserHandle is valid is only 
by calls from other functions in this same file.

>@param  Protocol   The GUID of the protocol
> @@ -929,17 +931,11 @@ CoreGetProtocolInterface (
>IN  EFI_GUID*Protocol
>)
>  {
> -  EFI_STATUS  Status;
>PROTOCOL_ENTRY  *ProtEntry;
>PROTOCOL_INTERFACE  *Prot;
>IHANDLE *Handle;
>LIST_ENTRY  *Link;
> 
> -  Status = CoreValidateHandle (UserHandle);
> -  if (EFI_ERROR (Status)) {
> -return NULL;
> -  }
> -
>Handle = (IHANDLE *)UserHandle;
> 
>//
> @@ -1392,6 +1388,15 @@ CoreOpenProtocolInformation (
>//
>CoreAcquireProtocolLock ();
> 
> +  //
> +  // Check for invalid UserHandle
> +  //
> +  Status = CoreValidateHandle (UserHandle);
> +  if (EFI_ERROR (Status)) {
> +Status = EFI_NOT_FOUND;
> +goto Done;
> +  }
> +
>//
>// Look at each protocol interface for a match
>//
> --
> 2.39.2
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] BaseTools: Optimize GenerateByteArrayValue and CollectPlatformGuids APIs

[Michael D Kinney]

Hi Ashraf,

What is captured in the file?

What PCD/VPD changes will invalidate the cache?  Just the number and 
type of PCD/VPD elements or their default values/sizes?

How was this tested?  Were all conditions that invalidate the cache
tested?  I ask because incremental build is a very important feature
and if there is any logic error in the cache management of a file like
this, it will cause unexpected behavior and developers will not trust
incremental builds.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ashraf
> Ali S
> Sent: Tuesday, January 16, 2024 11:55 PM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Chen, Christine
> ; Rebecca Cran ; Liming Gao
> ; Feng, Bob C ; Chan,
> Amy ; Chaganty, Rangasai V
> ; Solanki, Digant H
> 
> Subject: [edk2-devel] [PATCH] BaseTools: Optimize GenerateByteArrayValue
> and CollectPlatformGuids APIs
> 
> During the Incremental build GenerateByteArrayValue used to generate the
> ByteArrayValue even when there is no change in the PCD/VPDs. which is
> time consuming API based on the number of PCD/VPDs and SKU IDs.
> 
> The optimization is that GenerateByteArrayValue is used to store the
> PcdRecordList in a JSON file for each of the arch. and during the
> Incremental build this API will check if there is any change in the PCD
> /VPDs then rest of the flow remains the same. if there is no change then
> it will return the provious build data.
> 
> Flow:
> during the 1st build PcdRecordList.json is not exists, PcdRecordList
> will be dumped to json file. and it will copy the output.txt as well.
> Note: as the output.txt are different for different Arch, so it will be
> stored in the Arch folder.
> During the Incremental build check if there is any change in PCD/VPD.
> if there is a change in VPD/PCD then recreate the PcdRecordList.json.
> and rest of the flow remains same.
> if there is no change in VPD/PCD read the output.txt and return the data
> 
> Cc: Yuwei Chen 
> Cc: Rebecca Cran 
> Cc: Liming Gao 
> Cc: Bob Feng 
> Cc: Amy Chan 
> Cc: Sai Chaganty 
> Cc: Digant H Solanki 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../Source/Python/AutoGen/WorkspaceAutoGen.py | 16 ++---
>  .../Source/Python/Workspace/DscBuildData.py   | 72 +++
>  2 files changed, 64 insertions(+), 24 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> index 160e3a3cd3..eec9280c8e 100644
> --- a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> @@ -160,22 +160,18 @@ class WorkspaceAutoGen(AutoGen):
> 
>  def CollectPlatformGuids(self):
>  oriInfList = []
> -oriPkgSet = set()
> -PlatformPkg = set()
> +pkgSet = set()
>  for Arch in self.ArchList:
>  Platform = self.BuildDatabase[self.MetaFile, Arch,
> self.BuildTarget, self.ToolChain]
>  oriInfList = Platform.Modules
>  for ModuleFile in oriInfList:
>  ModuleData = self.BuildDatabase[ModuleFile,
> Platform._Arch, Platform._Target, Platform._Toolchain]
> -oriPkgSet.update(ModuleData.Packages)
> -for Pkg in oriPkgSet:
> -Guids = Pkg.Guids
> -GlobalData.gGuidDict.update(Guids)
> +pkgSet.update(ModuleData.Packages)
>  if Platform.Packages:
> -PlatformPkg.update(Platform.Packages)
> -for Pkg in PlatformPkg:
> -Guids = Pkg.Guids
> -GlobalData.gGuidDict.update(Guids)
> +pkgSet.update(Platform.Packages)
> +for Pkg in pkgSet:
> +Guids = Pkg.Guids
> +GlobalData.gGuidDict.update(Guids)
> 
>  @cached_property
>  def FdfProfile(self):
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 4768099343..740b8e22be 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -37,6 +37,8 @@ from functools import reduce
>  from Common.Misc import SaveFileOnChange
>  from Workspace.BuildClassObject import PlatformBuildClassObject,
> StructurePcd, PcdClassObject, ModuleBuildClassObject
>  from collections import OrderedDict, defaultdict
> +import json
> +import shutil
> 
>  def _IsFieldValueAnArray (Value):
>  Value = Value.strip()
> @@ -56,6 +58,7 @@ def _IsFieldValueAnArray (Value):
> 
>  PcdValueInitName = 'PcdValueInit'
>  PcdValueCommonName = 'PcdValueCommon'
> +PcdRecordListName = 'PcdRecordList.json'
> 
>  PcdMainCHeader = '''
>  /**
> @@ -1599,7 +1602,7 @@ class DscBuildData(PlatformBuildClassObject):
>  S_pcd_set = DscBuildData.OverrideByComm(S_pcd_set)
> 
>  # Create a tool to caculate structure pcd value
> -Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
> +Str_Pcd_Val

Re: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of HiiConfigAccess ExtractConfig

[Michael D Kinney]

Hi Suqiang,

For the Browser/HII related changes to the MdePkg can you also 
prepare a patch to update the function headers in the implementation
of these APIs and make sure the implementation conforms to the 
update header file changes?

Thanks,

Mike

> -Original Message-
> From: Ren, SuqiangX 
> Sent: Sunday, January 14, 2024 6:09 PM
> To: gaoliming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liu, Zhiguang
> ; Li, Yi1 
> Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> HiiConfigAccess ExtractConfig
> 
> Hi Liming,
> 
>   Could you help to merge below patches which all your reviewed-by?
> Thanks!
>   https://github.com/tianocore/edk2/pull/5170
>   https://github.com/tianocore/edk2/pull/5186
>   https://github.com/tianocore/edk2/pull/5190
> 
> 
> Thanks
> Ren, Suqiang
> 
> -Original Message-
> From: Ren, SuqiangX
> Sent: Monday, January 8, 2024 9:31 PM
> To: gaoliming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liu, Zhiguang
> ; Li, Yi1 
> Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> HiiConfigAccess ExtractConfig
> 
> Hi Liming,
> 
>   Could you please help to check and merge this patch?
>   https://github.com/tianocore/edk2/pull/5170
> 
> 
> Thanks
> Ren, Suqiang
> 
> -Original Message-
> From: gaoliming 
> Sent: Saturday, December 23, 2023 10:10 AM
> To: devel@edk2.groups.io; Ren, SuqiangX 
> Cc: Kinney, Michael D ; Liu, Zhiguang
> ; Li, Yi1 
> Subject: 回复: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> HiiConfigAccess ExtractConfig
> 
> Reviewed-by: Liming Gao 
> 
> > -----邮件原件-
> > 发件人: devel@edk2.groups.io  代表 SuqiangX Ren
> > 发送时间: 2023年12月21日 10:41
> > 收件人: devel@edk2.groups.io
> > 抄送: Ren,Suqiang ; Michael D Kinney
> > ; Liming Gao ;
> > Zhiguang Liu ; Yi Li 
> > 主题: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> > HiiConfigAccess ExtractConfig
> >
> > From: "Ren,Suqiang" 
> >
> > Add status code returned for HiiConfigAccess ExtractConfig to align
> > with UEFI spec 2.10.
> >
> > REF: UEFI spec 2.10 Table 35.5.2
> >
> > Signed-off-by: SuqiangX Ren 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Yi Li 
> > ---
> >  MdePkg/Include/Protocol/HiiConfigAccess.h | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Include/Protocol/HiiConfigAccess.h
> > b/MdePkg/Include/Protocol/HiiConfigAccess.h
> > index 3baf91e07b2e..fbee7c52b021 100644
> > --- a/MdePkg/Include/Protocol/HiiConfigAccess.h
> > +++ b/MdePkg/Include/Protocol/HiiConfigAccess.h
> > @@ -102,9 +102,16 @@ typedef UINTN EFI_BROWSER_ACTION;
> >string.
> >
> >@retval EFI_INVALID_PARAMETER   Unknown name. Progress points
> > -  to the & before the name in
> > +  to the "&" before the name in
> >question.
> >
> > +  @retval EFI_INVALID_PARAMETER   If Results or Progress is NULL.
> > +
> > +  @retval EFI_ACCESS_DENIED   The action violated a system
> policy.
> > +
> > +  @retval EFI_DEVICE_ERRORFailed to extract the current
> > configuration
> > +  for one or more named elements.
> > +
> >  **/
> >  typedef
> >  EFI_STATUS
> > --
> > 2.26.2.windows.1
> >
> >
> >
> > 
> >
> 
> 



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

Re: [edk2-devel] [PATCH] MdePkg: fix the types of casting for TD MMIO read

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

Please include Cc tags in commit message with the maintainers of
the patch for review.  Otherwise, the maintainers may miss the 
email patches.

Thanks,

Mike



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zhiquan
> Li
> Sent: Thursday, January 11, 2024 10:02 PM
> To: devel@edk2.groups.io
> Cc: Li, Zhiquan1 
> Subject: [edk2-devel] [PATCH] MdePkg: fix the types of casting for TD
> MMIO read
> 
> Currently the types of casting mismatch with TD MMIO read 1, 2 and 4
> bytes, that might introduce potential issues.  So fix the types as
> conventional MmioRead[8|16|32] does.
> 
> Signed-off-by: Zhiquan Li 
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> b/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> index ec837f5eb03e..1acc3b3d9638 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> @@ -237,7 +237,7 @@ TdMmioRead8 (
> 
> 
>Status = TdVmCall (TDVMCALL_MMIO, TDVMCALL_ACCESS_SIZE_1,
> TDVMCALL_ACCESS_READ, Address | TdSharedPageMask (), 0, &Value);
> 
>if (Status != 0) {
> 
> -Value = *(volatile UINT64 *)Address;
> 
> +Value = *(volatile UINT8 *)Address;
> 
>}
> 
> 
> 
>return (UINT8)Value;
> 
> @@ -294,7 +294,7 @@ TdMmioRead16 (
> 
> 
>Status = TdVmCall (TDVMCALL_MMIO, TDVMCALL_ACCESS_SIZE_2,
> TDVMCALL_ACCESS_READ, Address | TdSharedPageMask (), 0, &Value);
> 
>if (Status != 0) {
> 
> -Value = *(volatile UINT64 *)Address;
> 
> +Value = *(volatile UINT16 *)Address;
> 
>}
> 
> 
> 
>return (UINT16)Value;
> 
> @@ -353,7 +353,7 @@ TdMmioRead32 (
> 
> 
>Status = TdVmCall (TDVMCALL_MMIO, TDVMCALL_ACCESS_SIZE_4,
> TDVMCALL_ACCESS_READ, Address | TdSharedPageMask (), 0, &Value);
> 
>if (Status != 0) {
> 
> -Value = *(volatile UINT64 *)Address;
> 
> +Value = *(volatile UINT32 *)Address;
> 
>}
> 
> 
> 
>return (UINT32)Value;
> 
> --
> 2.25.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#113765):
> https://edk2.groups.io/g/devel/message/113765
> Mute This Topic: https://groups.io/mt/103689726/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [PATCH v2 1/1] MdePkg/IndustryStandard: Add _PSD/_CPC/Coord types definitions

[Michael D Kinney]

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


From: devel@edk2.groups.io  On Behalf Of gaoliming via 
groups.io
Sent: Tuesday, January 16, 2024 6:18 AM
To: devel@edk2.groups.io; sami.muja...@arm.com; 'PierreGondois' 

Subject: 回复: [edk2-devel] [PATCH v2 1/1] MdePkg/IndustryStandard: Add 
_PSD/_CPC/Coord types definitions

I am OK to merge it. Reviewed-by: Liming Gao 
mailto:gaolim...@byosoft.com.cn>>

发件人: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> 代表 Sami Mujawar
发送时间: 2024年1月12日 22:37
收件人: PierreGondois mailto:pierre.gond...@arm.com>>; 
devel@edk2.groups.io
主题: Re: [edk2-devel] [PATCH v2 1/1] MdePkg/IndustryStandard: Add 
_PSD/_CPC/Coord types definitions

Hi Liming,

If there are no further comments on this patch, can you let me know if I can 
merge this, please?

Regards,

Sami Mujawar



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

Re: [edk2-devel] [PATCH] MdePkg: fix the types of casting for TD MMIO read

[Michael D Kinney]

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



> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, January 19, 2024 6:49 PM
> To: devel@edk2.groups.io; Li, Zhiquan1 
> Cc: Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH] MdePkg: fix the types of casting for
> TD MMIO read
> 
> Reviewed-by: Michael D Kinney 
> 
> Please include Cc tags in commit message with the maintainers of
> the patch for review.  Otherwise, the maintainers may miss the
> email patches.
> 
> Thanks,
> 
> Mike
> 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Zhiquan
> > Li
> > Sent: Thursday, January 11, 2024 10:02 PM
> > To: devel@edk2.groups.io
> > Cc: Li, Zhiquan1 
> > Subject: [edk2-devel] [PATCH] MdePkg: fix the types of casting for TD
> > MMIO read
> >
> > Currently the types of casting mismatch with TD MMIO read 1, 2 and 4
> > bytes, that might introduce potential issues.  So fix the types as
> > conventional MmioRead[8|16|32] does.
> >
> > Signed-off-by: Zhiquan Li 
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> > b/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> > index ec837f5eb03e..1acc3b3d9638 100644
> > --- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> > +++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibInternalTdx.c
> > @@ -237,7 +237,7 @@ TdMmioRead8 (
> >
> >
> >Status = TdVmCall (TDVMCALL_MMIO, TDVMCALL_ACCESS_SIZE_1,
> > TDVMCALL_ACCESS_READ, Address | TdSharedPageMask (), 0, &Value);
> >
> >if (Status != 0) {
> >
> > -Value = *(volatile UINT64 *)Address;
> >
> > +Value = *(volatile UINT8 *)Address;
> >
> >}
> >
> >
> >
> >return (UINT8)Value;
> >
> > @@ -294,7 +294,7 @@ TdMmioRead16 (
> >
> >
> >Status = TdVmCall (TDVMCALL_MMIO, TDVMCALL_ACCESS_SIZE_2,
> > TDVMCALL_ACCESS_READ, Address | TdSharedPageMask (), 0, &Value);
> >
> >if (Status != 0) {
> >
> > -Value = *(volatile UINT64 *)Address;
> >
> > +Value = *(volatile UINT16 *)Address;
> >
> >}
> >
> >
> >
> >return (UINT16)Value;
> >
> > @@ -353,7 +353,7 @@ TdMmioRead32 (
> >
> >
> >Status = TdVmCall (TDVMCALL_MMIO, TDVMCALL_ACCESS_SIZE_4,
> > TDVMCALL_ACCESS_READ, Address | TdSharedPageMask (), 0, &Value);
> >
> >if (Status != 0) {
> >
> > -Value = *(volatile UINT64 *)Address;
> >
> > +Value = *(volatile UINT32 *)Address;
> >
> >}
> >
> >
> >
> >return (UINT32)Value;
> >
> > --
> > 2.25.1
> >
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> > View/Reply Online (#113765):
> > https://edk2.groups.io/g/devel/message/113765
> > Mute This Topic: https://groups.io/mt/103689726/1643496
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe: https://edk2.groups.io/g/devel/unsub
> > [michael.d.kin...@intel.com]
> > -=-=-=-=-=-=
> >



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

Re: [edk2-devel] EFI_SYSTEM_TABLE allocated by AllocateRuntimeCopyPool isn't aligned to 4KB

[Michael D Kinney]

Hi Rebecca,

I do not recall any statements in the EFI Spec that require 4KB
alignment of the UEFI System Table, Boot Services Table, 
or Runtime Services Table.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Rebecca
> Cran
> Sent: Monday, January 22, 2024 11:53 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] EFI_SYSTEM_TABLE allocated by
> AllocateRuntimeCopyPool isn't aligned to 4KB
> 
> I've been working on updating the T32 script EfiLoadDxe.cmm in
> EmbeddedPkg/Scripts/LauterbachT32 and one of the issues I've run into is
> that the EFI_SYSTEM_TABLE - pointed to by `gST` and `gDxeCoreST` - isn't
> aligned to 4KB like the script expects.
> 
> Instead, I'm seeing AllocateRuntimeCopyPool return 0xFB7D0018 in
> MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:
> 
> //
> // Allocate the EFI System Table and EFI Runtime Service Table from
> EfiRuntimeServicesData
> // Use the templates to initialize the contents of the EFI System Table
> and EFI Runtime Services Table
> //
> gDxeCoreST = AllocateRuntimeCopyPool (sizeof (EFI_SYSTEM_TABLE),
> &mEfiSystemTableTemplate);
> ASSERT (gDxeCoreST != NULL);
> 
> I'm wondering which is wrong: should AllocateRuntimeCopyPool be
> returning a 4KB-aligned pointer, or is the script's assumption wrong?
> 
> 
> --
> Rebecca Cran
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 1/1] MdePkg:Updated the comments of EFI_FIRMWARE_MANAGEMENT_PROTOCOL

[Michael D Kinney]

Hi Guo,

Thank you for starting this task to update Firmware Management Protocol.

There are additional tasks to make sure all required code changes are
also implemented for a specification update like this.

* Create a TianoCore Bugzilla that describes the specification update
  needed with links to the public documents with the required
  specification update. 

* Review/update edk2 repo include files.

* Review/update function headers of the implementations of the
  Firmware Management Protocol in the edk2 repo.

* Review/update logic in implementations of the Firmware
  Management Protocol in the edk2 repo to make sure all error 
  return conditions are checked.

* Review/update function headers of the implementations of the
  Firmware Management Protocol in the edk2-platforms repo.

* Review/update logic in implementations of the Firmware
  Management Protocol in the edk2-platforms repo to make sure 
  all error return conditions are checked.

* Review/update test cases edk2-test repo for the UEFI SCTs for
  these error return conditions.


The "REF" in the commit message should be a link to the TianoCore
Bugzilla.  The reference to the specification is also required, but
should be in the text of the commit message.

Thanks,

Mike


> -Original Message-
> From: Xu, GuoX 
> Sent: Sunday, January 21, 2024 9:37 PM
> To: gaoliming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liu, Zhiguang
> 
> Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg:Updated the comments of
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL
> 
> Hi Liming,
>   I created a PR: https://github.com/tianocore/edk2/pull/5182, could you
> help push it ?
> 
> Thanks
> Xu Guo
> 
> -Original Message-
> From: gaoliming 
> Sent: Tuesday, January 16, 2024 10:20 PM
> To: devel@edk2.groups.io; Xu, GuoX 
> Cc: Kinney, Michael D ; Liu, Zhiguang
> 
> Subject: 回复: [edk2-devel] [PATCH 1/1] MdePkg:Updated the comments of
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL
> 
> I am OK for this change. Reviewed-by: Liming Gao
> 
> 
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Xu, GuoX
> > 发送时间: 2024年1月9日 17:24
> > 收件人: devel@edk2.groups.io
> > 抄送: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang 
> > 主题: Re: [edk2-devel] [PATCH 1/1] MdePkg:Updated the comments of
> > EFI_FIRMWARE_MANAGEMENT_PROTOCOL
> >
> > Hi all, any comments about this patch?
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of GuoX Xu
> > Sent: Monday, December 25, 2023 9:21 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> > Li, Yi1 
> > Subject: [edk2-devel] [PATCH 1/1] MdePkg:Updated the comments of
> > EFI_FIRMWARE_MANAGEMENT_PROTOCOL
> >
> > 1.For EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImage():
> > Add the following sentence at the end of the Image parameter
> description.
> > "May be NULL with a zero ImageSize in order to determine the size of
> > the buffer needed".
> >
> > Modify the description of "EFI_INVALID_PARAMETER" return code as "The
> > ImageSize is not too small and Image is NULL."
> >
> > 2.For EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo():
> > Add the following sentence at the end of the ImageInfo parameter
> > description."May be NULL with a zero ImageInfoSize in order to
> > determine the size of the buffer needed".
> >
> > Modify the description of "EFI_INVALID_PARAMETER" return code as "The
> > ImageInfoSize is not too small and Image is NULL." and add new
> > descriptions for "EFI_INVALID_PARAMETER" return code.
> >
> > REF: UEFI Spec 2.7B Chapter 23.1.
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Yi Li 
> > Signed-off-by: GuoX Xu 
> > ---
> >  MdePkg/Include/Protocol/FirmwareManagement.h | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdePkg/Include/Protocol/FirmwareManagement.h
> > b/MdePkg/Include/Protocol/FirmwareManagement.h
> > index f37067df3455..93c8b7658e1a 100644
> > --- a/MdePkg/Include/Protocol/FirmwareManagement.h
> > +++ b/MdePkg/Include/Protocol/FirmwareManagement.h
> > @@ -293,6 +293,8 @@ EFI_STATUS
> >   to contain the image(s)
> > information if the buffer was too small.
> >@param[in, out] ImageInfo  A pointer to the buffer in which
> > firmware places the current image(s)
> >   information. The information is
> > an array of EFI_FIRMWARE_IMAGE_DESCRIPTORs.
> > + 

Re: [edk2-devel] [PATCH v1 1/1] .pytool/Plugin: UncrustifyCheck: use stat instead of os.stat

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Joey Vagedes 
> Sent: Monday, January 22, 2024 3:21 PM
> To: devel@edk2.groups.io
> Cc: Liming Gao ; Kinney, Michael D
> ; Sean Brogan 
> Subject: [PATCH v1 1/1] .pytool/Plugin: UncrustifyCheck: use stat
> instead of os.stat
> 
> The UncrustifyCheck plugin passes os.stat.S_IWRITE to os.chmod, when
> attempting to change file permissions. os.stat.S_IWRITE does not exist
> as os.stat is a function. The correct value is stat.S_IWRITE.
> 
> Signed-off-by: Joey Vagedes 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Sean Brogan 
> ---
>  .pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> b/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> index 9aeef5a5a3..73dc03c0dc 100644
> --- a/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> +++ b/.pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> @@ -12,6 +12,7 @@ import logging
>  import os
> 
>  import pathlib
> 
>  import shutil
> 
> +import stat
> 
>  import timeit
> 
>  from edk2toolext.environment import version_aggregator
> 
>  from edk2toolext.environment.plugin_manager import PluginManager
> 
> @@ -628,7 +629,7 @@ class UncrustifyCheck(ICiBuildPlugin):
>  """
> 
>  Private function to attempt to change permissions on
> file/folder being deleted.
> 
>  """
> 
> -os.chmod(path, os.stat.S_IWRITE)
> 
> +os.chmod(path, stat.S_IWRITE)
> 
>  func(path)
> 
> 
> 
>  for _ in range(3):  # retry up to 3 times
> 
> --
> 2.40.1.vfs.0.0



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

Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for depex evaluation

[Michael D Kinney]

Hi Ray,

+Andrew Fish

That optimization was imported into git history 17 years ago, so
it has effectively always been there.  I do not recall the performance
improvement at the time the optimization was originally implemented.

The difference in behavior is that caching the result may miss
an uninstall later before dispatch. Always evaluating right before 
dispatch is safer because is guarantees that the expression is TRUE
and all conditions met when the image is started.

Your example is possible, but not likely to appear in practice for
the types of protocols used in dependency expressions.

Protocols that are uninstalled are more typically associated with 
the UEFI Driver model for buses/devices that can be added/removed.

If CoreLocateProtocol() was optimized, then perhaps this optimization
would have never been implemented.

I see no harm in removing the optimization, especially for only
Standalone MM.

If there is a need to treat DEPEX section of all images as const,
then there are other places that the cached evaluation could be
stored to enable this specific optimization for all image types.

Best regards,

Mike

> -Original Message-
> From: Ni, Ray 
> Sent: Sunday, January 21, 2024 7:05 PM
> To: Nhi Pham ; devel@edk2.groups.io; Kinney,
> Michael D 
> Cc: ardb+tianoc...@kernel.org; sami.muja...@arm.com; ler...@redhat.com
> Subject: RE: [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for
> depex evaluation
> 
> Reviewed-by: Ray Ni 
> 
> PI spec does not define the REPLACE_TRUE op-code.
> Existing dispatchers (DXE, SMM and Standalone MM) use REPLACE_TRUE to
> optimize the protocol evaluation. PEI dispatcher does not use this
> optimization as the Depex binary might be in flash.
> 
> Now this patch only modifies standalone MM version to not use the
> optimization. I think it's a right way.
> 
> 
> 
> Because the optimization cannot handle a case:
> 1. driver A installs protocol #a.
> 2. driver B depends on protocol #a.
> 3. driver A uninstalls the protocol #a in a callback (protocol callback,
> timer callback, or a service provided by A that driver B invokes)
> 4. driver B gets dispatched after the callback. <--- problem here. The
> protocol #a does not exist!!
> 
> @Kinney, Michael D, do you have history data of which optimization
> result it achieved? Do you think that the optimization can be in
> CoreLocateProtocol() instead of in the callers?
> 
> Thanks,
> Ray
> > -Original Message-
> > From: Nhi Pham 
> > Sent: Friday, January 19, 2024 12:57 PM
> > To: devel@edk2.groups.io
> > Cc: ardb+tianoc...@kernel.org; Ni, Ray ;
> > sami.muja...@arm.com; ler...@redhat.com; Nhi Pham
> > 
> > Subject: [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for
> > depex evaluation
> >
> > From: Laszlo Ersek 
> >
> > The current dependency evaluator violates the memory access permission
> > when patching depex grammar directly in the read-only depex memory
> area.
> >
> > Laszlo pointed out the optimization issue in the thread (1) "Memory
> > Attribute for depex section" and provided suggested patch to remove
> the
> > perf optimization.
> >
> > In my testing, removing the optimization does not make significant
> perf
> > reduction. That makes sense that StandaloneMM dispatcher only searches
> > in MM protocol database and does not depend on UEFI/DXE protocol
> > database. Also, we don't have many protocols in StandaloneMM like
> > UEFI/DXE.
> >
> > From Laszlo,
> >
> > "The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus
> it
> > CONST-ifies the Iterator pointer (which points into the DEPEX
> section),
> > so that the compiler catch any possible accesses at *build time* that
> > would write to the write-protected DEPEX memory area."
> >
> > (1) https://edk2.groups.io/g/devel/message/113531
> >
> > Signed-off-by: Nhi Pham 
> > ---
> >  StandaloneMmPkg/Core/Dependency.c | 37 
> >  1 file changed, 7 insertions(+), 30 deletions(-)
> >
> > diff --git a/StandaloneMmPkg/Core/Dependency.c
> > b/StandaloneMmPkg/Core/Dependency.c
> > index 440fe3e45238..2bcb07d34666 100644
> > --- a/StandaloneMmPkg/Core/Dependency.c
> > +++ b/StandaloneMmPkg/Core/Dependency.c
> > @@ -13,16 +13,6 @@
> >
> >
> >  #include "StandaloneMmCore.h"
> >
> >
> >
> > -///
> >
> > -/// EFI_DEP_REPLACE_TRUE - Used to dynamically patch the dependency
> > expression
> >
> > -///to save time.  A EFI_DEP_PUSH is
> > evaluated one an
> >
> > -///replaced with EFI_DEP_REPLACE_TRUE. If
> > PI spec's Vol 2
> >
> > -///Driver Execution Environment Core
> > Interface use 0xff
> >
> > -///as new DEPEX opcode.
> > EFI_DEP_REPLACE_TRUE should be
> >
> > -///defined to a new value that is not
> > conflicting with PI spec.
> >
> > -///
> >
> > -#define EFI_DEP_REPLACE_TRUE  0xff
> >
> > -
> >
> >  ///
> >
> >  /// Define the initial size of the dependency expression evaluation
> stack
> >

Re: [edk2-devel] [PATCH 1/1] MdePkg: Add EFI_UNSUPPORTED return for some Runtime Service functions

[Michael D Kinney]

Hi Suqiang,

The changes to this one .h file look ok.

However, there are implementations of the Runtime Services in the edk2 repo
that also need their function headers updates.  Can you please add those
changes to this patch series?

Thanks,

Mike





> -Original Message-
> From: Ren, SuqiangX 
> Sent: Thursday, January 11, 2024 1:05 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang 
> Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: Add EFI_UNSUPPORTED return
> for some Runtime Service functions
> 
> Hi All,
> 
>   Any comments about this patch?
> 
> Thanks
> Ren, Suqiang
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ren,
> Suqiang
> Sent: Wednesday, December 27, 2023 4:47 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang 
> Subject: [edk2-devel] [PATCH 1/1] MdePkg: Add EFI_UNSUPPORTED return for
> some Runtime Service functions
> 
> According to UEFI Spec 2.10 page 206, if any EFI_RUNTIME_SERVICES* calls
> are not supported for use by the OS at runtime, an
> EFI_RT_PROPERTIES_TABLE configuration table should be published
> describing which runtime services are supported at runtime. So need to
> add EFI_UNSUPPORTED return for some Runtime Service functions.
> 
> REF: UEFI spec 2.10 section 8 Services — Runtime Services
> 
> Signed-off-by: Suqiang Ren 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 40 --
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h index 5de00e8ea2af..b25485b06763 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -320,6 +320,9 @@ EFI_STATUS
>  map that requires a mapping.
>@retval EFI_NOT_FOUND A virtual address was supplied for an
> address that is not found
>  in the memory map.
> +  @retval EFI_UNSUPPORTED   This call is not supported by this
> platform at the time the call is made.
> +The platform should describe this
> runtime service as unsupported at runtime
> +via an EFI_RT_PROPERTIES_TABLE
> configuration table.
> 
>  **/
>  typedef
> @@ -415,6 +418,9 @@ EFI_STATUS
>  not have the EFI_OPTIONAL_PTR bit set.
>@retval EFI_NOT_FOUND The pointer pointed to by Address was
> not found to be part
>  of the current memory map. This is
> normally fatal.
> +  @retval EFI_UNSUPPORTED   This call is not supported by this
> platform at the time the call is made.
> +The platform should describe this
> runtime service as unsupported at runtime
> +via an EFI_RT_PROPERTIES_TABLE
> configuration table.
> 
>  **/
>  typedef
> @@ -679,6 +685,10 @@ VOID
>@retval EFI_INVALID_PARAMETER  The DataSize is not too small and Data
> is NULL.
>@retval EFI_DEVICE_ERROR   The variable could not be retrieved
> due to a hardware error.
>@retval EFI_SECURITY_VIOLATION The variable could not be retrieved
> due to an authentication failure.
> +  @retval EFI_UNSUPPORTEDAfter ExitBootServices() has been
> called, this return code may be returned
> + if no variable storage is supported.
> The platform should describe this
> + runtime service as unsupported at
> runtime via an EFI_RT_PROPERTIES_TABLE
> + configuration table.
> 
>  **/
>  typedef
> @@ -715,6 +725,10 @@ EFI_STATUS
>@retval EFI_INVALID_PARAMETER Null-terminator is not found in the
> first VariableNameSize bytes of
>  the input VariableName buffer.
>@retval EFI_DEVICE_ERROR  The variable could not be retrieved due
> to a hardware error.
> +  @retval EFI_UNSUPPORTED   After ExitBootServices() has been
> called, this return code may be returned
> +if no variable storage is supported.
> The platform should describe this
> +runtime service as unsupported at
> runtime via an EFI_RT_PROPERTIES_TABLE
> +configuration table.
> 
>  **/
>  typedef
> @@ -757,6 +771,9 @@ EFI_STATUS
>   but the AuthInfo does NOT pass the
> validation check carried out by the firmware.
> 
>@retval EFI_NOT_FOUND  The variable trying to be updat

Re: [edk2-devel] [PATCH V2 1/1] MdePkg: Update the definition of FileName on EFI_FILE_INFO

[Michael D Kinney]

Hi Suqiang,

The comment line added look like is exceeds 80 columns.  Please reformat.

Also, there are implementations of this service in the edk2 repo.
Please update those with this same function header update.

Thanks,

Mike

> -Original Message-
> From: Ren, SuqiangX 
> Sent: Thursday, January 11, 2024 1:04 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang 
> Subject: RE: [edk2-devel] [PATCH V2 1/1] MdePkg: Update the definition
> of FileName on EFI_FILE_INFO
> 
> Hi All,
> 
>   Any comments about this patch?
> 
> Thanks
> Ren, Suqiang
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ren,
> Suqiang
> Sent: Tuesday, December 26, 2023 1:22 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang 
> Subject: [edk2-devel] [PATCH V2 1/1] MdePkg: Update the definition of
> FileName on EFI_FILE_INFO
> 
> Add the description of FileName to align with UEFI spec 2.10.
> 
> REF: UEFI spec 2.10 Table 13.5.16
> 
> Signed-off-by: Suqiang Ren 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/Guid/FileInfo.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Guid/FileInfo.h
> b/MdePkg/Include/Guid/FileInfo.h index 2b7edf36aabc..c152789b40c8 100644
> --- a/MdePkg/Include/Guid/FileInfo.h
> +++ b/MdePkg/Include/Guid/FileInfo.h
> @@ -46,7 +46,7 @@ typedef struct {
>///
>UINT64  Attribute;
>///
> -  /// The Null-terminated name of the file.
> +  /// The Null-terminated name of the file. For a root directory, the
> name is an empty string.
>///
>CHAR16  FileName[1];
>  } EFI_FILE_INFO;
> --
> 2.26.2.windows.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] BaseTools: Optimize GenerateByteArrayValue and CollectPlatformGuids APIs

[Michael D Kinney]

Hi Ashraf,

The PcdValueInit feature is not limited to only PCDs of type VPD.  It is
for any structured PCDs.  Did you test PCDs with all types (e.g. 
PcdsFixedAtBuild
PcdsPactahbleInModule, PcdsDynamicHii, PcdsDynamicDatabase, PcdsDynamicVpd,
PcdsDynamicExHii, PcdsDynamicExDatabase, PcdsDynamicExVpd)

And did you DSC test cases cover both changes in PCD types and changes in PCD 
values?

Thanks,

Mike

> -Original Message-
> From: S, Ashraf Ali 
> Sent: Sunday, January 21, 2024 4:14 AM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Chen, Christine ; Rebecca Cran
> ; Liming Gao ; Feng, Bob C
> ; Chan, Amy ; Chaganty,
> Rangasai V ; Solanki, Digant H
> 
> Subject: RE: [edk2-devel] [PATCH] BaseTools: Optimize
> GenerateByteArrayValue and CollectPlatformGuids APIs
> 
> Hi., @Kinney, Michael D
> 
> The main API which is modified in this Patch is GenerateByteArrayValue.
> 
> This API is used to return the list of SKUID.TokenSpaceGuid.VpdName|VPD
> STRUCT|Binary Data which will be stored in Output.txt
> Example:
> SAMPLESKUID.STANDARD.gEfiMdePkgTokenSpaceGuid.SampleVpd|SAMPLE_STRUCT[]|
> {0x01,0x01,0x05,0x09,0x02}
> 
> This VPD/PCD is coming from either the DEC file or the DSC file.
> 
> GenerateByteArrayValue API is used to create the PcdValueInit.exe and
> it's equivalent C and Make File.
> 
> When there is no change in DEC or DSC VPD/PCD still it used to do the
> same process again in the incremental build which is time consuming.
> In my project this API is used to take 3min of time with High end server
> (64Threads) and 3.5Min in Laptop (16 threads with performance mode
> enabled) only for GenerateByteArrayValue API.
> 
> This  patch will check if there are any change in the DEC/DSC
> VPDs/PCDs2, if there is any change in VPD the current flow is not
> affect. (it will create the PcdRecordList.json and copy Output.txt for
> Arch folder with the project. Ex:
> Build\{Project}Pkg\DEBUG_VS2019\PcdValueInit\{IA32/X64/Any}\PcdRecordLis
> t.json and
> Build\{Project}Pkg\DEBUG_VS2019\PcdValueInit\{IA32/X64/Any}\Output.txt)
> If there is no change the DSC/DEC VPDs it will read the data from
> Output.txt and return the same data. (we will compare the Input
> structure and PcdRecordList.json) if there is any mismatch then it there
> change in VPDs if not then no change in VPDs).
> 
> Unit testing from my side as follows:
> * Build the Firmware.
>   * PcdRecordList.json and Output.txt will be created based on the
> Arch.
> * Build the Firmware again without any change.
>   * It will read the Output.txt and return the data. (it will match
> Input PCD/VPD list and compare with existing PcdRecordList.json)
>   * I verified the return length and content GenerateByteArrayValue
> (it's same with and without my changes)
> * Build the Firmware again my modifying the VPDs in DSC file
>   * Change in VPDs, it will regenerate PcdRecordList.json file
>   *  it will create the Exe file and Output.txt
>   * New Output.txt will be copied to above path.
> * Build the Firmware again by modifying the VPDs in DEC file.
>   * Change in VPDs, it will regenerate PcdRecordList.json file
>   *  it will create the Exe file and Output.txt
>   * New Output.txt will be copied to above path.
> * Build the Firmware again without modifying the code.
>   * It will read the Output.txt and return the data.
>   * I verified the return length and content GenerateByteArrayValue
> (it's same with and without my changes)
> 
> 
> There is no impact on the Boot/cache.
> This patch is used to reduce the incremental build time by checking if
> the VPDs/PCDs are changed or not, if not changed then it will return the
> previous stored data.
> 
> Thanks.,
> S, Ashraf Ali
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Saturday, January 20, 2024 7:36 AM
> To: devel@edk2.groups.io; S, Ashraf Ali 
> Cc: Chen, Christine ; Rebecca Cran
> ; Liming Gao ; Feng, Bob C
> ; Chan, Amy ; Chaganty,
> Rangasai V ; Solanki, Digant H
> ; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [PATCH] BaseTools: Optimize
> GenerateByteArrayValue and CollectPlatformGuids APIs
> 
> Hi Ashraf,
> 
> What is captured in the file?
> 
> What PCD/VPD changes will invalidate the cache?  Just the number and
> type of PCD/VPD elements or their default values/sizes?
> 
> How was this tested?  Were all conditions that invalidate the cache
> tested?  I ask because incremental build is a very important feature and
> if there is any logic error in the cache management of a file like this,
> it will cause unexpected behavior and developers will not trust
> incremental builds.
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Ashraf
> > Ali S
> > Sent: Tuesday, January 16, 2024 11:55 PM
> > To: devel@edk2.groups.io
> > Cc: S, Ashraf Ali ; Chen, Christine
> > ; Rebecca Cran ; Liming Gao
> > ; Feng, Bob C ; Chan,
> > Amy ; Chaganty, Rangasai V
> > ; Solanki, Digant H
> > 
> > Subject: [edk2-dev

Re: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of HiiConfigAccess ExtractConfig

[Michael D Kinney]

Hi Tan Ming,

In this case, the function header in the implementation needs to be
updated to match the MdePkg header file changes.

I agree that the device error would have to propagate from the HII
Config Routing Protocol that may use services such as UEFI Variable
Services or other device specific services to read/write config
data and that is where an EFI_DEVICE_ERROR can occur.

Mike

> -Original Message-
> From: Tan, Ming 
> Sent: Sunday, January 21, 2024 5:54 PM
> To: devel@edk2.groups.io; Kinney, Michael D
> ; Ren, SuqiangX ;
> gaoliming 
> Cc: Liu, Zhiguang ; Li, Yi1 
> Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> HiiConfigAccess ExtractConfig
> 
> Mike:
>   For the change of https://github.com/tianocore/edk2/pull/5170.
>   We checked all the files for function XxxExtractConfig, find there is
> not function will return EFI_DEVICE_ERROR in the function code directly.
>   One possible place is just call xxx ->BlockToConfig(), and the
> XxxExtractConfig will return the Status of call BlockToConfig().
>   For example in
> https://github.com/tianocore/edk2/blob/c251015292cc5f4ca003894e5922a40b0
> 8cd14b0/MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c#L808
> Status = HiiConfigRouting->BlockToConfig (
>  HiiConfigRouting,
>  ConfigRequest,
>  (UINT8 *)&PrivateData->Configuration,
>  BufferSize,
>  Results,
>  Progress
>  );
> ..
> return Status;
> 
>   So need we change the code, if such BlockToConfig return failed, then
> ignore the detail reason, but return EFI_DEVICE_ERROR in function
> XxxExtractConfig?
> 
>   BR/Tan Ming.
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael D
> Kinney
> Sent: Saturday, January 20, 2024 10:32 AM
> To: Ren, SuqiangX ; gaoliming
> ; devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Li, Yi1 ;
> Kinney, Michael D 
> Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> HiiConfigAccess ExtractConfig
> 
> Hi Suqiang,
> 
> For the Browser/HII related changes to the MdePkg can you also prepare a
> patch to update the function headers in the implementation of these APIs
> and make sure the implementation conforms to the update header file
> changes?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Ren, SuqiangX 
> > Sent: Sunday, January 14, 2024 6:09 PM
> > To: gaoliming ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Liu, Zhiguang
> > ; Li, Yi1 
> > Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> > HiiConfigAccess ExtractConfig
> >
> > Hi Liming,
> >
> > Could you help to merge below patches which all your reviewed-by?
> > Thanks!
> > https://github.com/tianocore/edk2/pull/5170
> > https://github.com/tianocore/edk2/pull/5186
> > https://github.com/tianocore/edk2/pull/5190
> >
> >
> > Thanks
> > Ren, Suqiang
> >
> > -Original Message-
> > From: Ren, SuqiangX
> > Sent: Monday, January 8, 2024 9:31 PM
> > To: gaoliming ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Liu, Zhiguang
> > ; Li, Yi1 
> > Subject: RE: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> > HiiConfigAccess ExtractConfig
> >
> > Hi Liming,
> >
> > Could you please help to check and merge this patch?
> > https://github.com/tianocore/edk2/pull/5170
> >
> >
> > Thanks
> > Ren, Suqiang
> >
> > -Original Message-
> > From: gaoliming 
> > Sent: Saturday, December 23, 2023 10:10 AM
> > To: devel@edk2.groups.io; Ren, SuqiangX 
> > Cc: Kinney, Michael D ; Liu, Zhiguang
> > ; Li, Yi1 
> > Subject: 回复: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> > HiiConfigAccess ExtractConfig
> >
> > Reviewed-by: Liming Gao 
> >
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 SuqiangX Ren
> > > 发送时间: 2023年12月21日 10:41
> > > 收件人: devel@edk2.groups.io
> > > 抄送: Ren,Suqiang ; Michael D Kinney
> > > ; Liming Gao ;
> > > Zhiguang Liu ; Yi Li 
> > > 主题: [edk2-devel] [PATCH 1/1] MdePkg: Update the comments of
> > > HiiConfigAccess ExtractConfig
> > >
> > > From: "Ren,Suqiang" 
> > >
> > > Add status code returned for HiiConfigAccess ExtractConfig to align
> > > with UEFI spec 2.10.
> > &

[edk2-devel] [Patch 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

[Michael D Kinney]

Provide an optional method for PEI to declare a specific address
range to use for the Memory Type Information bins. The current
algorithm uses heuristics that tends to place the Memory Type
Information bins in the same location, but memory configuration
changes across boots or algorithm changes across a firmware
updates could potentially change the Memory Type Information bin
location.

If the HOB List contains a Resource Descriptor HOB that
describes tested system memory and has an Owner GUID of
gEfiMemoryTypeInformationGuid, then use the address range
described by the Resource Descriptor HOB as the preferred
location of the Memory Type Information bins. If this HOB is
not detected, then the current behavior is preserved.

The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
is ignored for the following conditions:
* The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
  is smaller than the Memory Type Information bins.
* The HOB list contains more than one Resource Descriptor HOB
  with an owner GUID of gEfiMemoryTypeInformationGuid.
* The Resource Descriptor HOB with an Owner GUID of
  gEfiMemoryTypeInformationGuid is the same Resource Descriptor
  HOB that that describes the PHIT memory range.

Update the DxeMain initialization order to initialize GCD
services before any runtime allocations are performed.  This
is required to prevent runtime data fragmentation when the
UEFI System Table and UEFI Runtime Service Table is allocated.

Cc: Liming Gao 
Cc: Aaron Li 
Cc: Liu Yun 
Cc: Andrew Fish 
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/Core/Dxe/DxeMain.h |  6 ++
 MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 23 +++---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 65 +++-
 MdeModulePkg/Core/Dxe/Mem/Page.c| 99 +
 4 files changed, 182 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
index 86a7be2f5188..53e26703f8c7 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -277,6 +277,12 @@ CoreInitializePool (
   VOID
   );
 
+VOID
+CoreSetMemoryTypeInformationRange (
+  IN EFI_PHYSICAL_ADDRESS  Start,
+  IN UINT64Length
+  );
+
 /**
   Called to initialize the memory map and add descriptors to
   the current descriptor list.
diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c 
b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
index 0e0f9769b99d..17d510a287e5 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
+++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
@@ -276,6 +276,18 @@ DxeMain (
 
   MemoryProfileInit (HobStart);
 
+  //
+  // Start the Image Services.
+  //
+  Status = CoreInitializeImageServices (HobStart);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Initialize the Global Coherency Domain Services
+  //
+  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, 
MemoryLength);
+  ASSERT_EFI_ERROR (Status);
+
   //
   // Allocate the EFI System Table and EFI Runtime Service Table from 
EfiRuntimeServicesData
   // Use the templates to initialize the contents of the EFI System Table and 
EFI Runtime Services Table
@@ -289,16 +301,9 @@ DxeMain (
   gDxeCoreST->RuntimeServices = gDxeCoreRT;
 
   //
-  // Start the Image Services.
+  // Update DXE Core Loaded Image Protocol with allocated UEFI System Table
   //
-  Status = CoreInitializeImageServices (HobStart);
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Initialize the Global Coherency Domain Services
-  //
-  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, 
MemoryLength);
-  ASSERT_EFI_ERROR (Status);
+  gDxeCoreLoadedImage->SystemTable = gDxeCoreST;
 
   //
   // Call constructor for all libraries
diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index 792cd2e0af23..189a87470251 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -2238,6 +2238,8 @@ CoreInitializeMemoryServices (
   EFI_HOB_HANDOFF_INFO_TABLE   *PhitHob;
   EFI_HOB_RESOURCE_DESCRIPTOR  *ResourceHob;
   EFI_HOB_RESOURCE_DESCRIPTOR  *PhitResourceHob;
+  EFI_HOB_RESOURCE_DESCRIPTOR  *MemoryTypeInformationResourceHob;
+  UINTNCount;
   EFI_PHYSICAL_ADDRESS BaseAddress;
   UINT64   Length;
   UINT64   Attributes;
@@ -2289,12 +2291,42 @@ CoreInitializeMemoryServices (
   //
   // See if a Memory Type Information HOB is available
   //
+  MemoryTypeInformationResourceHob = NULL;
   GuidHob = GetFirstGuidHob (&gEfiMemoryTypeInformationGuid);
   if (GuidHob != NULL) {
 EfiMemoryTypeInformation = GET_GUID_HOB_DATA (GuidHob);
 DataSize = GET_GUID_HOB_DATA_SIZE (GuidHob);
 if ((EfiMemoryTypeInformation != NULL) && (DataSize > 0) && (DataSize <= 
(EfiMaxMemoryType + 1) * sizeof (EFI_MEMORY_TYPE_INFORMATION))) {
   CopyMem (&gMemoryTypeInformation, EfiMemoryTypeInformation, DataSize);
+
+  /

Re: [edk2-devel] [PATCH V3 1/1] MdePkg: Update the definition of FileName on EFI_FILE_INFO

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Ren, SuqiangX 
> Sent: Monday, January 22, 2024 11:03 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liming Gao
> ; Liu, Zhiguang 
> Subject: [PATCH V3 1/1] MdePkg: Update the definition of FileName on
> EFI_FILE_INFO
> 
> Add the description of FileName[1] to align with UEFI spec 2.10.
> 
> REF: UEFI spec 2.10 section 13.5.16
> 
> Signed-off-by: Suqiang Ren 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/Guid/FileInfo.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdePkg/Include/Guid/FileInfo.h
> b/MdePkg/Include/Guid/FileInfo.h
> index 2b7edf36aabc..71bb289e1256 100644
> --- a/MdePkg/Include/Guid/FileInfo.h
> +++ b/MdePkg/Include/Guid/FileInfo.h
> @@ -47,6 +47,7 @@ typedef struct {
>UINT64  Attribute;
>///
>/// The Null-terminated name of the file.
> +  /// For a root directory, the name is an empty string.
>///
>CHAR16  FileName[1];
>  } EFI_FILE_INFO;
> --
> 2.26.2.windows.1



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

Re: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance

[Michael D Kinney]

Hi Qing,

Thank you for this update to add the missing API to BaseCpuLibNull.

There are a few very minor comments below.  I will make those updates
in the PR for merge.  With those changes:

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Huang,
> Qing
> Sent: Tuesday, January 23, 2024 3:37 AM
> To: devel@edk2.groups.io
> Cc: Huang, Qing 
> Subject: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub
> function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance

Subject line too long

> 
> CpuLib.h exposes StandardSignatureIsAuthenticAMD() API and we require
> stub function in its BaseCpuLibNull library
> instance to avoid potential link issue.
> 

Missing Cc for MdePkg maintainers.

> Signed-off-by: Qing Huang 
> ---
>  MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> index 3ba7a35096..ba7981551d 100644
> --- a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> +++ b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> @@ -1,7 +1,7 @@
>  /** @file
>Null instance of CPU Library.
> 
> -  Copyright (c) 2020, Intel Corporation. All rights reserved.
> +  Copyright (c) 2020 - 2024, Intel Corporation. All rights
> reserved.

Updating end year not required for Intel copyright statements.

>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -35,3 +35,18 @@ CpuFlushTlb (
>)
>  {
>  }
> +
> +/**
> +  Determine if the standard CPU signature is "AuthenticAMD".
> +
> +  @retval TRUE  The CPU signature matches.
> +  @retval FALSE The CPU signature does not match.
> +**/
> +BOOLEAN
> +EFIAPI
> +StandardSignatureIsAuthenticAMD (
> +  VOID
> +  )
> +{
> +  return FALSE;
> +}
> --
> 2.42.0.windows.2
> 
> 
> 
> 
> 



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

[edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

[Michael D Kinney]

Provide an optional method for PEI to declare a specific address
range to use for the Memory Type Information bins. The current
algorithm uses heuristics that tends to place the Memory Type
Information bins in the same location, but memory configuration
changes across boots or algorithm changes across a firmware
updates could potentially change the Memory Type Information bin
location.

If the HOB List contains a Resource Descriptor HOB that
describes tested system memory and has an Owner GUID of
gEfiMemoryTypeInformationGuid, then use the address range
described by the Resource Descriptor HOB as the preferred
location of the Memory Type Information bins. If this HOB is
not detected, then the current behavior is preserved.

The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
is ignored for the following conditions:
* The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
  is smaller than the Memory Type Information bins.
* The HOB list contains more than one Resource Descriptor HOB
  with an owner GUID of gEfiMemoryTypeInformationGuid.
* The Resource Descriptor HOB with an Owner GUID of
  gEfiMemoryTypeInformationGuid is the same Resource Descriptor
  HOB that that describes the PHIT memory range.

Update the DxeMain initialization order to initialize GCD
services before any runtime allocations are performed.  This
is required to prevent runtime data fragmentation when the
UEFI System Table and UEFI Runtime Service Table is allocated.

Cc: Liming Gao 
Cc: Aaron Li 
Cc: Liu Yun 
Cc: Andrew Fish 
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/Core/Dxe/DxeMain.h |   6 ++
 MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c |  72 -
 MdeModulePkg/Core/Dxe/Mem/Page.c| 101 
 4 files changed, 190 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
index 86a7be2f5188..53e26703f8c7 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -277,6 +277,12 @@ CoreInitializePool (
   VOID
   );
 
+VOID
+CoreSetMemoryTypeInformationRange (
+  IN EFI_PHYSICAL_ADDRESS  Start,
+  IN UINT64Length
+  );
+
 /**
   Called to initialize the memory map and add descriptors to
   the current descriptor list.
diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c 
b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
index 0e0f9769b99d..17d510a287e5 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
+++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
@@ -276,6 +276,18 @@ DxeMain (
 
   MemoryProfileInit (HobStart);
 
+  //
+  // Start the Image Services.
+  //
+  Status = CoreInitializeImageServices (HobStart);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Initialize the Global Coherency Domain Services
+  //
+  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, 
MemoryLength);
+  ASSERT_EFI_ERROR (Status);
+
   //
   // Allocate the EFI System Table and EFI Runtime Service Table from 
EfiRuntimeServicesData
   // Use the templates to initialize the contents of the EFI System Table and 
EFI Runtime Services Table
@@ -289,16 +301,9 @@ DxeMain (
   gDxeCoreST->RuntimeServices = gDxeCoreRT;
 
   //
-  // Start the Image Services.
+  // Update DXE Core Loaded Image Protocol with allocated UEFI System Table
   //
-  Status = CoreInitializeImageServices (HobStart);
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Initialize the Global Coherency Domain Services
-  //
-  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, 
MemoryLength);
-  ASSERT_EFI_ERROR (Status);
+  gDxeCoreLoadedImage->SystemTable = gDxeCoreST;
 
   //
   // Call constructor for all libraries
diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index 792cd2e0af23..c450d1bf2531 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -2238,6 +2238,8 @@ CoreInitializeMemoryServices (
   EFI_HOB_HANDOFF_INFO_TABLE   *PhitHob;
   EFI_HOB_RESOURCE_DESCRIPTOR  *ResourceHob;
   EFI_HOB_RESOURCE_DESCRIPTOR  *PhitResourceHob;
+  EFI_HOB_RESOURCE_DESCRIPTOR  *MemoryTypeInformationResourceHob;
+  UINTNCount;
   EFI_PHYSICAL_ADDRESS BaseAddress;
   UINT64   Length;
   UINT64   Attributes;
@@ -2289,12 +2291,47 @@ CoreInitializeMemoryServices (
   //
   // See if a Memory Type Information HOB is available
   //
-  GuidHob = GetFirstGuidHob (&gEfiMemoryTypeInformationGuid);
+  MemoryTypeInformationResourceHob = NULL;
+  GuidHob  = GetFirstGuidHob 
(&gEfiMemoryTypeInformationGuid);
   if (GuidHob != NULL) {
 EfiMemoryTypeInformation = GET_GUID_HOB_DATA (GuidHob);
 DataSize = GET_GUID_HOB_DATA_SIZE (GuidHob);
 if ((EfiMemoryTypeInformation != NULL) && (DataSize > 0) && (DataSize <= 
(EfiMaxMemoryType + 1) * sizeof (EFI_MEMORY_TYPE_INFORMATION)

Re: [edk2-devel] [PATCH V3 1/1] MdePkg: Update the definition of FileName on EFI_FILE_INFO

[Michael D Kinney]

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

> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, January 23, 2024 9:13 AM
> To: Ren, SuqiangX ; devel@edk2.groups.io
> Cc: Liming Gao ; Liu, Zhiguang
> ; Kinney, Michael D 
> Subject: RE: [PATCH V3 1/1] MdePkg: Update the definition of FileName on
> EFI_FILE_INFO
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Ren, SuqiangX 
> > Sent: Monday, January 22, 2024 11:03 PM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Liming Gao
> > ; Liu, Zhiguang 
> > Subject: [PATCH V3 1/1] MdePkg: Update the definition of FileName on
> > EFI_FILE_INFO
> >
> > Add the description of FileName[1] to align with UEFI spec 2.10.
> >
> > REF: UEFI spec 2.10 section 13.5.16
> >
> > Signed-off-by: Suqiang Ren 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > ---
> >  MdePkg/Include/Guid/FileInfo.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MdePkg/Include/Guid/FileInfo.h
> > b/MdePkg/Include/Guid/FileInfo.h
> > index 2b7edf36aabc..71bb289e1256 100644
> > --- a/MdePkg/Include/Guid/FileInfo.h
> > +++ b/MdePkg/Include/Guid/FileInfo.h
> > @@ -47,6 +47,7 @@ typedef struct {
> >UINT64  Attribute;
> >///
> >/// The Null-terminated name of the file.
> > +  /// For a root directory, the name is an empty string.
> >///
> >CHAR16  FileName[1];
> >  } EFI_FILE_INFO;
> > --
> > 2.26.2.windows.1



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

Re: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance

[Michael D Kinney]

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

> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, January 23, 2024 9:26 AM
> To: devel@edk2.groups.io; Huang, Qing 
> Cc: Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub
> function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance
> 
> Hi Qing,
> 
> Thank you for this update to add the missing API to BaseCpuLibNull.
> 
> There are a few very minor comments below.  I will make those updates
> in the PR for merge.  With those changes:
> 
> Reviewed-by: Michael D Kinney 
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Huang,
> > Qing
> > Sent: Tuesday, January 23, 2024 3:37 AM
> > To: devel@edk2.groups.io
> > Cc: Huang, Qing 
> > Subject: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub
> > function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance
> 
> Subject line too long
> 
> >
> > CpuLib.h exposes StandardSignatureIsAuthenticAMD() API and we require
> > stub function in its BaseCpuLibNull library
> > instance to avoid potential link issue.
> >
> 
> Missing Cc for MdePkg maintainers.
> 
> > Signed-off-by: Qing Huang 
> > ---
> >  MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > index 3ba7a35096..ba7981551d 100644
> > --- a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > +++ b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >Null instance of CPU Library.
> >
> > -  Copyright (c) 2020, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2020 - 2024, Intel Corporation. All rights
> > reserved.
> 
> Updating end year not required for Intel copyright statements.
> 
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -35,3 +35,18 @@ CpuFlushTlb (
> >)
> >  {
> >  }
> > +
> > +/**
> > +  Determine if the standard CPU signature is "AuthenticAMD".
> > +
> > +  @retval TRUE  The CPU signature matches.
> > +  @retval FALSE The CPU signature does not match.
> > +**/
> > +BOOLEAN
> > +EFIAPI
> > +StandardSignatureIsAuthenticAMD (
> > +  VOID
> > +  )
> > +{
> > +  return FALSE;
> > +}
> > --
> > 2.42.0.windows.2
> >
> >
> >
> > 
> >



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

Re: [edk2-devel] [PATCH] MdePkg/BaseFdtLib: Rename standard functions

[Michael D Kinney]

Hi Jeff,

One comment below.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Jeff
> Brasen via groups.io
> Sent: Monday, December 11, 2023 7:40 AM
> To: devel@edk2.groups.io
> Cc: Jeff Brasen 
> Subject: [edk2-devel] [PATCH] MdePkg/BaseFdtLib: Rename standard
> functions
> 
> Rename the standard functions in the LibFdtSupport to remove conflicts
> with other libraries that define them.
> 
> Signed-off-by: Jeff Brasen 
> ---
>  MdePkg/Library/BaseFdtLib/LibFdtSupport.h | 16 +++
>  MdePkg/Library/BaseFdtLib/LibFdtWrapper.c | 25 ++-
>  2 files changed, 18 insertions(+), 23 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> index 393019324b..47beac9fac 100644
> --- a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> +++ b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> @@ -68,6 +68,12 @@ strrchr(
>int
>);
> 
> +char *
> +fdt_strrchr(
> +  const char *,
> +  int
> +  );
> +
>  unsigned long
>  strtoul (
>const char *,
> @@ -75,6 +81,13 @@ strtoul (
>int
>);

Since stroul() is defined to something else, is the function prototype required?
Same comment for strrchr()

> 
> +unsigned long
> +fdt_strtoul (
> +  const char *,
> +  char **,
> +  int
> +  );
> +
>  char *
>  strcpy (
>char*strDest,
> @@ -93,7 +106,10 @@ strcpy (
>  #define strnlen(str, count) (size_t)(AsciiStrnLenS(str,
> count))
>  #define strncpy(strDest, strSource, count)  AsciiStrnCpyS(strDest,
> MAX_STRING_SIZE, strSource, (UINTN)count)
>  #define strcat(strDest, strSource)  AsciiStrCatS(strDest,
> MAX_STRING_SIZE, strSource)
> +#define strchr(str, ch) ScanMem8(str, AsciiStrSize
> (str), (UINT8)ch)
>  #define strcmp(string1, string2, count) (int)(AsciiStrCmp(string1,
> string2))
>  #define strncmp(string1, string2, count)(int)(AsciiStrnCmp(string1,
> string2, (UINTN)(count)))
> +#define strrchr(str, ch)fdt_strrchr(str, ch)
> +#define strtoul(ptr, end_ptr, base) fdt_strtoul(ptr, end_ptr,
> base)
> 
>  #endif /* FDT_LIB_SUPPORT_H_ */
> diff --git a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> index ef6452914f..1a4cd573fd 100644
> --- a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> +++ b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> @@ -18,28 +18,7 @@
>  // so the code gets a bit clunky to handle that case specifically.
> 
>  char *
> -strchr (
> -  const char  *Str,
> -  int Char
> -  )
> -{
> -  char  *S;
> -
> -  S = (char *)Str;
> -
> -  for ( ; ; S++) {
> -if (*S == Char) {
> -  return S;
> -}
> -
> -if (*S == '\0') {
> -  return NULL;
> -}
> -  }
> -}
> -
> -char *
> -strrchr (
> +fdt_strrchr (
>const char  *Str,
>int Char
>)
> @@ -71,7 +50,7 @@ __isspace (
>  }
> 
>  unsigned long
> -strtoul (
> +fdt_strtoul (
>const char  *Nptr,
>char**EndPtr,
>int Base
> --
> 2.34.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] MdePkg: Add FdtLib gmock support

[Michael D Kinney]

Hi Jeff,

Thanks for this mock lib contribution.

I few comments below.

Thanks,

Mike



> -Original Message-
> From: Jeff Brasen 
> Sent: Monday, December 11, 2023 7:43 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Kinney, Michael D
> ; Liu, Zhiguang ;
> Jeff Brasen 
> Subject: [PATCH] MdePkg: Add FdtLib gmock support
> 
> Add Google Mock Library for FdtLib
> 
> Signed-off-by: Jeff Brasen 
> ---
>  .../Include/GoogleTest/Library/MockFdtLib.h   | 165 ++
>  .../GoogleTest/MockFdtLib/MockFdtLib.cpp  |  34 
>  .../GoogleTest/MockFdtLib/MockFdtLib.inf  |  28 +++
>  3 files changed, 227 insertions(+)
>  create mode 100644
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> 
> diff --git a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> new file mode 100644
> index 00..c0aeaa25c0
> --- /dev/null
> +++ b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> @@ -0,0 +1,165 @@
> +/** @file
> +  Google Test mocks for FdtLib
> +
> +  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef MOCK_FDT_LIB_H_
> +#define MOCK_FDT_LIB_H_
> +
> +#include 
> +#include 
> +extern "C" {
> +#include 
> +#include 

I think the 2 includes above can be replaced with 

> +#include 
> +}
> +
> +struct MockFdtLib {
> +  MOCK_INTERFACE_DECLARATION (MockFdtLib);
> +
> +  MOCK_FUNCTION_DECLARATION (
> +UINT16,
> +Fdt16ToCpu,
> +(IN UINT16 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT16,
> +CpuToFdt16,
> +(IN UINT16 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT32,
> +Fdt32ToCpu,
> +(IN UINT32 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT32,
> +CpuToFdt32,
> +(IN UINT32 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT64,
> +Fdt64ToCpu,
> +(IN UINT64 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT64,
> +CpuToFdt64,
> +(IN UINT64 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtCheckHeader,
> +(IN CONST VOID  *Fdt)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtCreateEmptyTree,
> +(IN VOID*Buffer,
> + IN UINT32  BufferSize)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNextNode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset,
> + IN INT32   *Depth)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtFirstSubnode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNextSubnode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtSubnodeOffsetNameLen,
> +(IN CONST VOID   *Fdt,
> + IN INT32ParentOffset,
> + IN CONST CHAR8  *Name,
> + IN INT32NameLength)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNodeOffsetByPropValue,
> +(IN CONST VOID   *Fdt,
> + IN INT32StartOffset,
> + IN CONST CHAR8  *PropertyName,
> + IN CONST VOID   *PropertyValue,
> + IN INT32PropertyLength)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +CONST FDT_PROPERTY *,
> +FdtGetProperty,
> +(IN CONST VOID   *Fdt,
> + IN INT32NodeOffset,
> + IN CONST CHAR8  *Name,
> + IN INT32*Length)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtFirstPropertyOffset,
> +(IN CONST VOID  *Fdt,
> + IN INT32   NodeOffset)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNextPropertyOffset,
> +(IN CONST VOID  *Fdt,
> + IN INT32   NodeOffset)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +CONST FDT_PROPERTY *,
> +FdtGetPropertyByOffset,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset,
> + IN INT32   *Length)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +CONST CHAR8 *,
> +FdtGetString,
> +(IN CONST VOID  *Fdt,
> + IN INT32   StrOffset,
> + IN INT32   *LengthOPTIONAL)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtAddSubnode,
> +(IN VOID *Fdt,
> + IN INT32ParentOffset,
> + IN CONST CHAR8  *Name)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtSetProp,
> +(IN VOID *Fdt,
> + IN INT32NodeOffset,
> + IN CONST CHAR8  *Name,
> + IN CONST VOID   *Value,
> + IN UINT32   Length)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +CONST CHAR8 *,
> +FdtGetName,
> +(IN VOID*Fdt,
> + IN INT32   NodeOffset,
> 

Re: [edk2-devel] [PATCH v2 1/2] MdeModulePkg: Remove the handle validation check in CoreGetProtocolInterface

[Michael D Kinney]

Hi Zhi,

Thanks for the update.  One minor comment on 'STATIC' should be 'static'.

We no longer depend on macros to redefine 'STATIC' and it is better to
just used the standard C 'static' form.

With that change:

Reviewed-by: Michael D Kinney 


Mike

> -Original Message-
> From: Jin, Zhi 
> Sent: Monday, January 22, 2024 1:53 AM
> To: devel@edk2.groups.io
> Cc: Jin, Zhi ; Liming Gao ;
> Ni, Ray ; Kinney, Michael D
> 
> Subject: [PATCH v2 1/2] MdeModulePkg: Remove the handle validation check
> in CoreGetProtocolInterface
> 
> CoreGetProtocolInterface() is called by CoreOpenProtocol(),
> CoreCloseProtocol() and CoreOpenProtocolInformation().
> Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input
> parameter UserHandle has been already checked for validation. So does
> CoreCloseProtocol().
> Removing the handle validation check in CoreGetProtocolInterface()
> could improve the performance, as CoreOpenProtocol() is called very
> frequently.
> To ensure the assumption that the caller of CoreGetProtocolInterface()
> must pass in a valid UserHandle that is checked with
> CoreValidateHandle(),
> add the parameter check in CoreOpenProtocolInformation(), and declare
> CoreGetProtocolInterface() as static.
> 
> v1 -> v2:
>   1. Update the description of UserHandle to state that the caller
>  must pass in a valid UserHandle that is checked with
>      CoreValidateHandle().
>   2. Declare CoreGetProtocolInterface() as static.
> 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Signed-off-by: Zhi Jin 
> ---
>  MdeModulePkg/Core/Dxe/Hand/Handle.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.c
> b/MdeModulePkg/Core/Dxe/Hand/Handle.c
> index 51e5b5d3b3..24e4fbf5f3 100644
> --- a/MdeModulePkg/Core/Dxe/Hand/Handle.c
> +++ b/MdeModulePkg/Core/Dxe/Hand/Handle.c
> @@ -918,28 +918,25 @@ CoreUninstallMultipleProtocolInterfaces (
>Locate a certain GUID protocol interface in a Handle's protocols.
> 
>@param  UserHandle The handle to obtain the protocol
> interface on
> + The caller must pass in a valid
> UserHandle that
> + is checked with CoreValidateHandle().
>@param  Protocol   The GUID of the protocol
> 
>@return The requested protocol interface for the handle
> 
>  **/
> +STATIC
>  PROTOCOL_INTERFACE  *
>  CoreGetProtocolInterface (
>IN  EFI_HANDLE  UserHandle,
>IN  EFI_GUID*Protocol
>)
>  {
> -  EFI_STATUS  Status;
>PROTOCOL_ENTRY  *ProtEntry;
>PROTOCOL_INTERFACE  *Prot;
>IHANDLE *Handle;
>LIST_ENTRY  *Link;
> 
> -  Status = CoreValidateHandle (UserHandle);
> -  if (EFI_ERROR (Status)) {
> -return NULL;
> -  }
> -
>Handle = (IHANDLE *)UserHandle;
> 
>//
> @@ -1392,6 +1389,15 @@ CoreOpenProtocolInformation (
>//
>CoreAcquireProtocolLock ();
> 
> +  //
> +  // Check for invalid UserHandle
> +  //
> +  Status = CoreValidateHandle (UserHandle);
> +  if (EFI_ERROR (Status)) {
> +Status = EFI_NOT_FOUND;
> +goto Done;
> +  }
> +
>//
>// Look at each protocol interface for a match
>//
> --
> 2.39.2



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

Re: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance

[Michael D Kinney]

Hi Laszlo,

Thanks for the feedback.  Sorry I missed this email this morning.

I will prepare a 2nd patch with these additional updates.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, January 23, 2024 5:57 AM
> To: devel@edk2.groups.io; Huang, Qing 
> Subject: Re: [edk2-devel] [PATCH v1] MdePkg/BaseCpuLibNull: Add stub
> function of StandardSignatureIsAuthenticAMD() in CpuLibNull instance
> 
> On 1/23/24 12:36, Huang, Qing wrote:
> > CpuLib.h exposes StandardSignatureIsAuthenticAMD() API and we require
> stub function in its BaseCpuLibNull library
> > instance to avoid potential link issue.
> >
> > Signed-off-by: Qing Huang 
> > ---
> >  MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > index 3ba7a35096..ba7981551d 100644
> > --- a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > +++ b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >Null instance of CPU Library.
> >
> > -  Copyright (c) 2020, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2020 - 2024, Intel Corporation. All rights
> reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -35,3 +35,18 @@ CpuFlushTlb (
> >)
> >  {
> >  }
> > +
> > +/**
> > +  Determine if the standard CPU signature is "AuthenticAMD".
> > +
> > +  @retval TRUE  The CPU signature matches.
> > +  @retval FALSE The CPU signature does not match.
> > +**/
> > +BOOLEAN
> > +EFIAPI
> > +StandardSignatureIsAuthenticAMD (
> > +  VOID
> > +  )
> > +{
> > +  return FALSE;
> > +}
> 
> (1) Could we complete the Null instance with all the missing functions,
> in one go? Such as: InitializeFloatingPointUnits,
> StandardSignatureIsAuthenticAMD, GetCpuFamilyModel, GetCpuSteppingId?
> 
> (2) All four of the mentioned APIs are only declared for IA32 and X64,
> by the lib class header. Therefore their stub implementations, including
> that of StandardSignatureIsAuthenticAMD(), should be restricted to IA32
> and X64 too.
> 
> Thanks
> Laszlo
> 
> 
> 
> 
> 



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

[edk2-devel] [Patch 1/1] MdePkg/Library/BaseCpuLibNull: Add missing X86 specific services

[Michael D Kinney]

* Add InitializeFloatingPointUnits() to x86 specific file
* Add GetCpuFamilyModel() to x86 specific file
* Add GetCpuSteppingId() to x86 specific file
* Move StandardSignatureIsAuthenticAMD() to x86 specific file.
* Add CpuLib library class include to all C files.

Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Laszlo Ersek 
Cc: Qing Huang 
Signed-off-by: Michael D Kinney 
---
 .../Library/BaseCpuLibNull/BaseCpuLibNull.c   | 17 +
 .../Library/BaseCpuLibNull/BaseCpuLibNull.inf |  3 +
 .../BaseCpuLibNull/X86BaseCpuLibNull.c| 64 +++
 3 files changed, 69 insertions(+), 15 deletions(-)
 create mode 100644 MdePkg/Library/BaseCpuLibNull/X86BaseCpuLibNull.c

diff --git a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c 
b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
index 3542cf6921f7..0080022b94ef 100644
--- a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
+++ b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.c
@@ -6,6 +6,8 @@
 
 **/
 
+#include 
+
 /**
   Places the CPU in a sleep state until an interrupt is received.
 
@@ -35,18 +37,3 @@ CpuFlushTlb (
   )
 {
 }
-
-/**
-  Determine if the standard CPU signature is "AuthenticAMD".
-
-  @retval TRUE  The CPU signature matches.
-  @retval FALSE The CPU signature does not match.
-**/
-BOOLEAN
-EFIAPI
-StandardSignatureIsAuthenticAMD (
-  VOID
-  )
-{
-  return FALSE;
-}
diff --git a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.inf 
b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.inf
index a9e8399038a6..9f20d6833f56 100644
--- a/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.inf
+++ b/MdePkg/Library/BaseCpuLibNull/BaseCpuLibNull.inf
@@ -22,5 +22,8 @@ [Defines]
 [Sources]
   BaseCpuLibNull.c
 
+[Sources.IA32, Sources.X64]
+  X86BaseCpuLibNull.c
+
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/MdePkg/Library/BaseCpuLibNull/X86BaseCpuLibNull.c 
b/MdePkg/Library/BaseCpuLibNull/X86BaseCpuLibNull.c
new file mode 100644
index ..4469bcc767cf
--- /dev/null
+++ b/MdePkg/Library/BaseCpuLibNull/X86BaseCpuLibNull.c
@@ -0,0 +1,64 @@
+/** @file
+  Null instance of CPU Library for IA32/X64 specific services.
+
+  Copyright (c) 2024, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+/**
+  Initializes floating point units for requirement of UEFI specification.
+  This function initializes floating-point control word to 0x027F (all 
exceptions
+  masked,double-precision, round-to-nearest) and multimedia-extensions control 
word
+  (if supported) to 0x1F80 (all exceptions masked, round-to-nearest, flush to 
zero
+  for masked underflow).
+**/
+VOID
+EFIAPI
+InitializeFloatingPointUnits (
+  VOID
+  )
+{
+}
+
+/**
+  Determine if the standard CPU signature is "AuthenticAMD".
+  @retval TRUE  The CPU signature matches.
+  @retval FALSE The CPU signature does not match.
+**/
+BOOLEAN
+EFIAPI
+StandardSignatureIsAuthenticAMD (
+  VOID
+  )
+{
+  return FALSE;
+}
+
+/**
+  Return the 32bit CPU family and model value.
+  @return CPUID[01h].EAX with Processor Type and Stepping ID cleared.
+**/
+UINT32
+EFIAPI
+GetCpuFamilyModel (
+  VOID
+  )
+{
+  return 0;
+}
+
+/**
+  Return the CPU stepping ID.
+  @return CPU stepping ID value in CPUID[01h].EAX.
+**/
+UINT8
+EFIAPI
+GetCpuSteppingId (
+  VOID
+  )
+{
+  return 0;
+}
-- 
2.40.1.windows.1



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

Re: [edk2-devel] Resources for Creating Packages

[Michael D Kinney]

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of ryderkeys
> via groups.io
> Sent: Monday, January 22, 2024 10:25 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] Resources for Creating Packages
> 
> Hello,
> 
> (Originally sent to edk2 discuss but it looks like my message has been
> stuck in moderation for a week, so I thought I would try here instead.)
> 
> I am new to UEFI and trying to learn how to use EDK 2. I have been able
> to build EmulatorPkg with stuart but I had a couple questions on where
> to go from here. I was hoping someone might be able to give some
> guidance or pointers. Any help is much appreciated.
> 
> 1. How can I build a UEFI application with a new package? I see the
> https://github.com/tianocore/tianocore.github.io/wiki/Getting-Started-
> Writing-Simple-Application suggests to edit an existing package DSC file
> with the INF file for my module. Which works fine. But where would I
> begin if I wanted to create my own package without commandeering the
> build for an already existing package? Would I just have to create a DSC
> file on my own? Is there a resource I can read on how to create new
> packages with EDK 2, or is this not the recommended way to get started
> building applications?

There are some detailed instructions in the following document that is
focused on writing UEFI Drivers, but the instructions apply equally well
to UEFI Applications.  Look at the "Building UEFI Drivers" chapter.

* 
https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf
* https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/
* 
https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/30_building_uefi_drivers/#30-building-uefi-drivers

There is also a wizard to help with creating packages and libraries:

* https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Wizard

> 
> 2. What exactly is in MdeModulePkg? I just noticed it has a similar name
> to MdePkg and wondered what the difference between the two was. The wiki
> (https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg)
> says "This package provides the modules that conform to UEFI/PI Industry
> standards. It also provides the defintions(including
> PPIs/PROTOCOLs/GUIDs and library classes) and libraries instances, which
> are used for those modules." but I'm not completely sure what this
> means. Is someone able to elaborate?

* MdePkg is include files and libraries for Industry Standard/Pubic 
specifications
* MdeModulePkg is module implementations that only depend on includes from 
MdePkg
  and any EDK II specific extensions defined in MdeModulePkg. 

> 
> Thank you,
> Ryder
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] MdePkg: Update ReceiveData and SendData function description

[Michael D Kinney]

 100ns units, 
to use for the execution

  339@param  This Indicates a pointer to the 
calling context.
  340:   @param  MediaId  ID of the medium to receive data 
from.
  341@param  Timeout  The timeout, in 100ns units, to 
use for the execution

  419@param  This Indicates a pointer to the 
calling context.
  420:   @param  MediaId  ID of the medium to receive data 
from.
  421@param  Timeout  The timeout, in 100ns units, to 
use for the execution

SecurityPkg\Tcg\Opal\OpalPassword\OpalPasswordPei.c:
   51@param  This Indicates a pointer to the 
calling context.
   52:   @param  MediaId  ID of the medium to receive data 
from.
   53@param  Timeout  The timeout, in 100ns units, to 
use for the execution

  150@param  This Indicates a pointer to the 
calling context.
  151:   @param  MediaId  ID of the medium to receive data 
from.
  152@param  Timeout  The timeout, in 100ns units, to 
use for the execution

Thanks,

Mike


> -Original Message-
> From: Tan, Ming 
> Sent: Wednesday, January 10, 2024 11:26 PM
> To: devel@edk2.groups.io
> Cc: Shang, Qingyu ; Kinney, Michael D
> ; Gao, Liming ;
> Liu, Zhiguang 
> Subject: [PATCH] MdePkg: Update ReceiveData and SendData function
> description
> 
> From: Qingyu Shang 
> 
> Refer to Uefi spec 2.10 section 13.14, update the parameter 'MediaId'
> description for EFI_STORAGE_SECURITY_COMMAND_PROTOCOL function
> ReceiveData
> and SendData.
> 
> Signed-off-by: Qingyu Shang 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/Protocol/StorageSecurityCommand.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/StorageSecurityCommand.h
> b/MdePkg/Include/Protocol/StorageSecurityCommand.h
> index 810af59b85..206ae79aff 100644
> --- a/MdePkg/Include/Protocol/StorageSecurityCommand.h
> +++ b/MdePkg/Include/Protocol/StorageSecurityCommand.h
> @@ -59,7 +59,9 @@ typedef struct _EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
> EFI_STORAGE_SECURITY_COMMA
>function shall return EFI_DEVICE_ERROR.
> 
> 
> 
>@param  This Indicates a pointer to the
> calling context.
> 
> -  @param  MediaId  ID of the medium to receive data
> from.
> 
> +  @param  MediaId  ID of the medium to receive data
> from. If there is no
> 
> +   block IO protocol supported by
> the physical device, the
> 
> +   value of MediaId is undefined.
> 
>@param  Timeout  The timeout, in 100ns units, to
> use for the execution
> 
> of the security protocol
> command. A Timeout value of 0
> 
> means that this function will
> wait indefinitely for the
> 
> @@ -138,7 +140,9 @@ EFI_STATUS
>shall return EFI_DEVICE_ERROR.
> 
> 
> 
>@param  This Indicates a pointer to the
> calling context.
> 
> -  @param  MediaId  ID of the medium to receive data
> from.
> 
> +  @param  MediaId  ID of the medium to receive data
> from. If there is no
> 
> +   block IO protocol supported by
> the physical device, the
> 
> +   value of MediaId is undefined.
> 
>@param  Timeout  The timeout, in 100ns units, to
> use for the execution
> 
> of the security protocol
> command. A Timeout value of 0
> 
> means that this function will
> wait indefinitely for the
> 
> --
> 2.39.1.windows.1



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

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add FdtLib gmock support

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Jeff Brasen 
> Sent: Tuesday, January 23, 2024 3:13 PM
> To: devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; Kinney, Michael D
> ; Liu, Zhiguang ;
> Jeff Brasen 
> Subject: [PATCH v2 1/1] MdePkg: Add FdtLib gmock support
> 
> Add Google Mock Library for FdtLib
> 
> Signed-off-by: Jeff Brasen 
> ---
>  .../GoogleTest/MockFdtLib/MockFdtLib.inf  |  28 +++
>  .../Include/GoogleTest/Library/MockFdtLib.h   | 164 ++
>  .../GoogleTest/MockFdtLib/MockFdtLib.cpp  |  34 
>  3 files changed, 226 insertions(+)
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
>  create mode 100644
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
> 
> diff --git
> a/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> new file mode 100644
> index ..b227bcbae963
> --- /dev/null
> +++ b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> @@ -0,0 +1,28 @@
> +## @file
> +# Google Test mocks for FdtLib
> +#
> +# Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +# Copyright (c) 2023, Intel Corporation. All rights reserved.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = MockFdtLib
> +  FILE_GUID  = 0f5471bc-fc2c-4cf4-b9f7-c1396d32831c
> +  MODULE_TYPE= HOST_APPLICATION
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = FdtLib
> +
> +[Sources]
> +  MockFdtLib.cpp
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> +
> +[LibraryClasses]
> +  GoogleTestLib
> +
> +[BuildOptions]
> +  MSFT:*_*_*_CC_FLAGS = /EHsc /bigobj
> diff --git a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> new file mode 100644
> index ..73da571910df
> --- /dev/null
> +++ b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> @@ -0,0 +1,164 @@
> +/** @file
> +  Google Test mocks for FdtLib
> +
> +  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef MOCK_FDT_LIB_H_
> +#define MOCK_FDT_LIB_H_
> +
> +#include 
> +#include 
> +extern "C" {
> +  #include 
> +  #include 
> +}
> +
> +struct MockFdtLib {
> +  MOCK_INTERFACE_DECLARATION (MockFdtLib);
> +
> +  MOCK_FUNCTION_DECLARATION (
> +UINT16,
> +Fdt16ToCpu,
> +(IN UINT16 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT16,
> +CpuToFdt16,
> +(IN UINT16 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT32,
> +Fdt32ToCpu,
> +(IN UINT32 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT32,
> +CpuToFdt32,
> +(IN UINT32 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT64,
> +Fdt64ToCpu,
> +(IN UINT64 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT64,
> +CpuToFdt64,
> +(IN UINT64 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtCheckHeader,
> +(IN CONST VOID  *Fdt)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtCreateEmptyTree,
> +(IN VOID*Buffer,
> + IN UINT32  BufferSize)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNextNode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset,
> + IN INT32   *Depth)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtFirstSubnode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNextSubnode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtSubnodeOffsetNameLen,
> +(IN CONST VOID   *Fdt,
> + IN INT32ParentOffset,
> + IN CONST CHAR8  *Name,
> + IN INT32NameLength)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNodeOffsetByPropValue,
> +(IN CONST VOID   *Fdt,
> + IN INT32StartOffset,
> + IN CONST CHAR8  *PropertyName,
&g

Re: [edk2-devel] [PATCH v2 1/1] MdePkg/BaseFdtLib: Rename standard functions

[Michael D Kinney]

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Jeff
> Brasen via groups.io
> Sent: Tuesday, January 23, 2024 3:16 PM
> To: devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; Kinney, Michael D
> ; Liu, Zhiguang ;
> Jeff Brasen 
> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg/BaseFdtLib: Rename standard
> functions
> 
> Rename the standard functions in the LibFdtSupport to remove conflicts
> with other libraries that define them.
> 
> Signed-off-by: Jeff Brasen 
> ---
>  MdePkg/Library/BaseFdtLib/LibFdtSupport.h |  7 +--
>  MdePkg/Library/BaseFdtLib/LibFdtWrapper.c | 25 ++-
>  2 files changed, 7 insertions(+), 25 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> index 393019324b73..8a26fbfc3251 100644
> --- a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> +++ b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> @@ -63,13 +63,13 @@ strchr (
>);
> 
>  char *
> -strrchr(
> +fdt_strrchr(
>const char *,
>int
>);
> 
>  unsigned long
> -strtoul (
> +fdt_strtoul (
>const char *,
>char **,
>int
> @@ -93,7 +93,10 @@ strcpy (
>  #define strnlen(str, count) (size_t)(AsciiStrnLenS(str,
> count))
>  #define strncpy(strDest, strSource, count)  AsciiStrnCpyS(strDest,
> MAX_STRING_SIZE, strSource, (UINTN)count)
>  #define strcat(strDest, strSource)  AsciiStrCatS(strDest,
> MAX_STRING_SIZE, strSource)
> +#define strchr(str, ch) ScanMem8(str, AsciiStrSize
> (str), (UINT8)ch)
>  #define strcmp(string1, string2, count) (int)(AsciiStrCmp(string1,
> string2))
>  #define strncmp(string1, string2, count)(int)(AsciiStrnCmp(string1,
> string2, (UINTN)(count)))
> +#define strrchr(str, ch)fdt_strrchr(str, ch)
> +#define strtoul(ptr, end_ptr, base) fdt_strtoul(ptr, end_ptr,
> base)
> 
>  #endif /* FDT_LIB_SUPPORT_H_ */
> diff --git a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> index ef6452914f5b..1a4cd573fdaf 100644
> --- a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> +++ b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> @@ -18,28 +18,7 @@
>  // so the code gets a bit clunky to handle that case specifically.
> 
>  char *
> -strchr (
> -  const char  *Str,
> -  int Char
> -  )
> -{
> -  char  *S;
> -
> -  S = (char *)Str;
> -
> -  for ( ; ; S++) {
> -if (*S == Char) {
> -  return S;
> -}
> -
> -if (*S == '\0') {
> -  return NULL;
> -}
> -  }
> -}
> -
> -char *
> -strrchr (
> +fdt_strrchr (
>const char  *Str,
>int Char
>)
> @@ -71,7 +50,7 @@ __isspace (
>  }
> 
>  unsigned long
> -strtoul (
> +fdt_strtoul (
>const char  *Nptr,
>char**EndPtr,
>int Base
> --
> 2.34.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add FdtLib gmock support

[Michael D Kinney]

Hi Jeff,

I just noticed that the DSC file in MdePkg/Test has not been updated to
make sure this mock lib always builds.  I added as part of PR to run
EDK II CI.

EDK II CI did fail.  

https://github.com/tianocore/edk2/pull/5293
https://github.com/tianocore/edk2/pull/5293/checks?check_run_id=20795099585
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=115123&view=logs&jobId=9701361e-2546-5093-77e5-58c75d95b7ce&j=9701361e-2546-5093-77e5-58c75d95b7ce&t=27131ef8-75e1-57c3-3236-d806181f2f1f

Comment below that details the failure.

Please fix and send V3 with MdePkg/Test DSC update and the 
FdtGetName() fix.

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, January 23, 2024 3:19 PM
> To: Jeff Brasen ; devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; Liu, Zhiguang ;
> Kinney, Michael D 
> Subject: RE: [PATCH v2 1/1] MdePkg: Add FdtLib gmock support
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Jeff Brasen 
> > Sent: Tuesday, January 23, 2024 3:13 PM
> > To: devel@edk2.groups.io
> > Cc: gaolim...@byosoft.com.cn; Kinney, Michael D
> > ; Liu, Zhiguang ;
> > Jeff Brasen 
> > Subject: [PATCH v2 1/1] MdePkg: Add FdtLib gmock support
> >
> > Add Google Mock Library for FdtLib
> >
> > Signed-off-by: Jeff Brasen 
> > ---
> >  .../GoogleTest/MockFdtLib/MockFdtLib.inf  |  28 +++
> >  .../Include/GoogleTest/Library/MockFdtLib.h   | 164
> ++
> >  .../GoogleTest/MockFdtLib/MockFdtLib.cpp  |  34 
> >  3 files changed, 226 insertions(+)
> >  create mode 100644
> > MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> >  create mode 100644
> > MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> >  create mode 100644
> > MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
> >
> > diff --git
> > a/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > new file mode 100644
> > index ..b227bcbae963
> > --- /dev/null
> > +++ b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > @@ -0,0 +1,28 @@
> > +## @file
> > +# Google Test mocks for FdtLib
> > +#
> > +# Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> > reserved.
> > +# Copyright (c) 2023, Intel Corporation. All rights reserved.
> > +# SPDX-License-Identifier: BSD-2-Clause-Patent
> > +##
> > +
> > +[Defines]
> > +  INF_VERSION= 0x00010005
> > +  BASE_NAME  = MockFdtLib
> > +  FILE_GUID  = 0f5471bc-fc2c-4cf4-b9f7-
> c1396d32831c
> > +  MODULE_TYPE= HOST_APPLICATION
> > +  VERSION_STRING = 1.0
> > +  LIBRARY_CLASS  = FdtLib
> > +
> > +[Sources]
> > +  MockFdtLib.cpp
> > +
> > +[Packages]
> > +  MdePkg/MdePkg.dec
> > +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> > +
> > +[LibraryClasses]
> > +  GoogleTestLib
> > +
> > +[BuildOptions]
> > +  MSFT:*_*_*_CC_FLAGS = /EHsc /bigobj
> > diff --git a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> > b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> > new file mode 100644
> > index ..73da571910df
> > --- /dev/null
> > +++ b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> > @@ -0,0 +1,164 @@
> > +/** @file
> > +  Google Test mocks for FdtLib
> > +
> > +  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> > reserved.
> > +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +**/
> > +
> > +#ifndef MOCK_FDT_LIB_H_
> > +#define MOCK_FDT_LIB_H_
> > +
> > +#include 
> > +#include 
> > +extern "C" {
> > +  #include 
> > +  #include 
> > +}
> > +
> > +struct MockFdtLib {
> > +  MOCK_INTERFACE_DECLARATION (MockFdtLib);
> > +
> > +  MOCK_FUNCTION_DECLARATION (
> > +UINT16,
> > +Fdt16ToCpu,
> > +(IN UINT16 Value)
> > +);
> > +  MOCK_FUNCTION_DECLARATION (
> > +UINT16,
> > +CpuToFdt16,
> > +(IN UINT16 Value)
> > +);
> > +  MOCK_FUNCTION_DECLARATION (
> > +UINT32,
> > +Fdt32ToCpu,
> > +(IN UINT32 Value)
> > +);
> > +  MOCK_FUNCTION_DECLARATION (
> > +UINT32,
> > +   

Re: [edk2-devel] [PATCH] BaseTools: Remove Duplicate sets of SkuName and SkuId from allskuset

[Michael D Kinney]

Hi Christine,

I did not see this merged yet.

Is this change also in edk2-basetools repo?  I do not see it there.

I thought the process was to do changed in edk2-basetools repo first where 
there are a large set of CI checks and then make the same change in the
edk2 repo.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yuwei
> Chen
> Sent: Sunday, January 7, 2024 4:29 PM
> To: S, Ashraf Ali ; devel@edk2.groups.io
> Cc: Rebecca Cran ; Gao, Liming
> ; Feng, Bob C ; Chan,
> Amy ; Chaganty, Rangasai V
> 
> Subject: Re: [edk2-devel] [PATCH] BaseTools: Remove Duplicate sets of
> SkuName and SkuId from allskuset
> 
> Reviewed-by: Yuwei Chen 
> 
> > -Original Message-
> > From: S, Ashraf Ali 
> > Sent: Monday, December 25, 2023 11:28 PM
> > To: devel@edk2.groups.io
> > Cc: S, Ashraf Ali ; Chen, Christine
> > ; Rebecca Cran ; Gao, Liming
> > ; Feng, Bob C ; Chan,
> > Amy ; Chaganty, Rangasai V
> > 
> > Subject: [PATCH] BaseTools: Remove Duplicate sets of SkuName and SkuId
> > from allskuset
> >
> > Currently when the platform has many SKUs then allskuset will be
> having so
> > many duplicate. and while parsing the allskuset will take longer time
> while
> > assing Pcd.SkuInfoList.
> > This patch is to eliminate those duplicate entires to reduce the build
> time
> >
> > Cc: Yuwei Chen 
> > Cc: Rebecca Cran 
> > Cc: Liming Gao 
> > Cc: Bob Feng 
> > Cc: Amy Chan 
> > Cc: Sai Chaganty 
> > Signed-off-by: Ashraf Ali S 
> > ---
> >  BaseTools/Source/Python/AutoGen/PlatformAutoGen.py | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > index 592d4824a4..dac81454a9 100644
> > --- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > +++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> > @@ -707,6 +707,8 @@ class PlatformAutoGen(AutoGen):
> >  self._DynamicPcdList.extend(list(OtherPcdArray))
> >  self._DynamicPcdList.sort()
> >  allskuset = [(SkuName, Sku.SkuId) for pcd in
> self._DynamicPcdList for
> > (SkuName, Sku) in pcd.SkuInfoList.items()]
> > +# Remove duplicate sets in the list
> > +allskuset = list(set(allskuset))
> >  for pcd in self._DynamicPcdList:
> >  if len(pcd.SkuInfoList) == 1:
> >  for (SkuName, SkuId) in allskuset:
> > --
> > 2.39.1.windows.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v4 1/1] MdeModulePkg/AcpiTableDxe: Prefer xDSDT over DSDT when installing tables

[Michael D Kinney]

Hi Liming,

I do not see any reviews of this patch.

What is the status?

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Dhaval
> Sharma
> Sent: Monday, January 8, 2024 7:00 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Liu, Zhiguang
> ; Bi, Dandan ; Pedro
> Falcato ; Chiu, Chasel 
> Subject: [edk2-devel] [PATCH v4 1/1] MdeModulePkg/AcpiTableDxe: Prefer
> xDSDT over DSDT when installing tables
> 
> As per ACPI Spec 6.5+ Table 5-9 if xDSDT is available,
> it should be used first. Handle required flow when xDSDT
> is absent or present.
> 
> Test: Tested on RISCV64 Qemu platform with xDSDT and booted to
> linux kernel.
> 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Dandan Bi 
> Cc: Pedro Falcato 
> Cc: devel@edk2.groups.io
> Signed-off-by: Dhaval Sharma 
> Acked-by: Chasel Chiu 
> ---
> 
> Notes:
> v4:
> - Fix typos and commit message adding more clarity to patch subject
> v3:
> - Added description of ACPI spec clarification based on which this
> patch is created
> - Optimizing if-else flow
> v2:
> - Added proper indentation for else if
> 
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 23
> ++--
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> index e09bc9b704f5..61af6047a2a7 100644
> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> @@ -1892,14 +1892,23 @@ InstallAcpiTableFromHob (
>}
> 
>  }
> 
> 
> 
> -if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)-
> >Dsdt != 0) {
> 
> +//
> 
> +// First check if xDSDT is available, as that is preferred as
> per
> 
> +// ACPI Spec 6.5+ Table 5-9 X_DSDT definition
> 
> +//
> 
> +if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)-
> >XDsdt != 0) {
> 
> +  TableToInstall = (VOID
> *)(UINTN)((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)-
> >XDsdt;
> 
> +} else if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE
> *)ChildTable)->Dsdt != 0) {
> 
>TableToInstall = (VOID
> *)(UINTN)((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)-
> >Dsdt;
> 
> -  Status = AddTableToList (AcpiTableInstance,
> TableToInstall, TRUE, Version, TRUE, &TableKey);
> 
> -  if (EFI_ERROR (Status)) {
> 
> -DEBUG ((DEBUG_ERROR, "InstallAcpiTableFromHob: Fail to add
> ACPI table DSDT\n"));
> 
> -ASSERT_EFI_ERROR (Status);
> 
> -break;
> 
> -  }
> 
> +} else {
> 
> +  break;
> 
> +}
> 
> +
> 
> +Status = AddTableToList (AcpiTableInstance, TableToInstall,
> TRUE, Version, TRUE, &TableKey);
> 
> +if (EFI_ERROR (Status)) {
> 
> +  DEBUG ((DEBUG_ERROR, "InstallAcpiTableFromHob: Fail to add
> ACPI table DSDT\n"));
> 
> +  ASSERT_EFI_ERROR (Status);
> 
> +  break;
> 
>  }
> 
>}
> 
>  }
> 
> --
> 2.39.2
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#113401):
> https://edk2.groups.io/g/devel/message/113401
> Mute This Topic: https://groups.io/mt/103598583/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [PATCH v3 1/1] MdePkg: Add FdtLib gmock support

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

I also see you opened a PR to run EDK II CI and it passed.

I will merge V3

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Jeff
> Brasen via groups.io
> Sent: Tuesday, January 23, 2024 7:08 PM
> To: devel@edk2.groups.io
> Cc: gaolim...@byosoft.com.cn; Kinney, Michael D
> ; Liu, Zhiguang ;
> Jeff Brasen 
> Subject: [edk2-devel] [PATCH v3 1/1] MdePkg: Add FdtLib gmock support
> 
> Add Google Mock Library for FdtLib
> 
> Signed-off-by: Jeff Brasen 
> ---
>  MdePkg/Test/MdePkgHostTest.dsc|   1 +
>  .../GoogleTest/MockFdtLib/MockFdtLib.inf  |  28 +++
>  .../Include/GoogleTest/Library/MockFdtLib.h   | 164 ++
>  .../GoogleTest/MockFdtLib/MockFdtLib.cpp  |  34 
>  4 files changed, 227 insertions(+)
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
>  create mode 100644
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
>  create mode 100644
> MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
> 
> diff --git a/MdePkg/Test/MdePkgHostTest.dsc
> b/MdePkg/Test/MdePkgHostTest.dsc
> index 583f8fc0ddd8..e36b7c55 100644
> --- a/MdePkg/Test/MdePkgHostTest.dsc
> +++ b/MdePkg/Test/MdePkgHostTest.dsc
> @@ -45,3 +45,4 @@ [Components]
> 
> MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mock
> UefiRuntimeServicesTableLib.inf
> 
> MdePkg/Test/Mock/Library/GoogleTest/MockPeiServicesLib/MockPeiServicesLi
> b.inf
>MdePkg/Test/Mock/Library/GoogleTest/MockHobLib/MockHobLib.inf
> +  MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> diff --git
> a/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> new file mode 100644
> index ..b227bcbae963
> --- /dev/null
> +++ b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> @@ -0,0 +1,28 @@
> +## @file
> +# Google Test mocks for FdtLib
> +#
> +# Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +# Copyright (c) 2023, Intel Corporation. All rights reserved.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = MockFdtLib
> +  FILE_GUID  = 0f5471bc-fc2c-4cf4-b9f7-c1396d32831c
> +  MODULE_TYPE= HOST_APPLICATION
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = FdtLib
> +
> +[Sources]
> +  MockFdtLib.cpp
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> +
> +[LibraryClasses]
> +  GoogleTestLib
> +
> +[BuildOptions]
> +  MSFT:*_*_*_CC_FLAGS = /EHsc /bigobj
> diff --git a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> new file mode 100644
> index ..5b21b232b7c7
> --- /dev/null
> +++ b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> @@ -0,0 +1,164 @@
> +/** @file
> +  Google Test mocks for FdtLib
> +
> +  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
> +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef MOCK_FDT_LIB_H_
> +#define MOCK_FDT_LIB_H_
> +
> +#include 
> +#include 
> +extern "C" {
> +  #include 
> +  #include 
> +}
> +
> +struct MockFdtLib {
> +  MOCK_INTERFACE_DECLARATION (MockFdtLib);
> +
> +  MOCK_FUNCTION_DECLARATION (
> +UINT16,
> +Fdt16ToCpu,
> +(IN UINT16 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT16,
> +CpuToFdt16,
> +(IN UINT16 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT32,
> +Fdt32ToCpu,
> +(IN UINT32 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT32,
> +CpuToFdt32,
> +(IN UINT32 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT64,
> +Fdt64ToCpu,
> +(IN UINT64 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +UINT64,
> +CpuToFdt64,
> +(IN UINT64 Value)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtCheckHeader,
> +(IN CONST VOID  *Fdt)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtCreateEmptyTree,
> +(IN VOID*Buffer,
> + IN UINT32  BufferSize)
> +);
> +  MOCK_FUNCTION_DECLARATION (
> +INT32,
> +FdtNextNode,
> +(IN CONST VOID  *Fdt,
> + IN INT32   Offset,
> 

Re: [edk2-devel] [PATCH v2 1/1] MdePkg/BaseFdtLib: Rename standard functions

[Michael D Kinney]

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

> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, January 23, 2024 3:27 PM
> To: devel@edk2.groups.io; jbra...@nvidia.com
> Cc: gaolim...@byosoft.com.cn; Liu, Zhiguang ;
> Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH v2 1/1] MdePkg/BaseFdtLib: Rename
> standard functions
> 
> Reviewed-by: Michael D Kinney 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Jeff
> > Brasen via groups.io
> > Sent: Tuesday, January 23, 2024 3:16 PM
> > To: devel@edk2.groups.io
> > Cc: gaolim...@byosoft.com.cn; Kinney, Michael D
> > ; Liu, Zhiguang ;
> > Jeff Brasen 
> > Subject: [edk2-devel] [PATCH v2 1/1] MdePkg/BaseFdtLib: Rename
> standard
> > functions
> >
> > Rename the standard functions in the LibFdtSupport to remove conflicts
> > with other libraries that define them.
> >
> > Signed-off-by: Jeff Brasen 
> > ---
> >  MdePkg/Library/BaseFdtLib/LibFdtSupport.h |  7 +--
> >  MdePkg/Library/BaseFdtLib/LibFdtWrapper.c | 25 ++
> -
> >  2 files changed, 7 insertions(+), 25 deletions(-)
> >
> > diff --git a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> > b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> > index 393019324b73..8a26fbfc3251 100644
> > --- a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> > +++ b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> > @@ -63,13 +63,13 @@ strchr (
> >);
> >
> >  char *
> > -strrchr(
> > +fdt_strrchr(
> >const char *,
> >int
> >);
> >
> >  unsigned long
> > -strtoul (
> > +fdt_strtoul (
> >const char *,
> >char **,
> >int
> > @@ -93,7 +93,10 @@ strcpy (
> >  #define strnlen(str, count)
> (size_t)(AsciiStrnLenS(str,
> > count))
> >  #define strncpy(strDest, strSource, count)  AsciiStrnCpyS(strDest,
> > MAX_STRING_SIZE, strSource, (UINTN)count)
> >  #define strcat(strDest, strSource)  AsciiStrCatS(strDest,
> > MAX_STRING_SIZE, strSource)
> > +#define strchr(str, ch) ScanMem8(str,
> AsciiStrSize
> > (str), (UINT8)ch)
> >  #define strcmp(string1, string2, count)
> (int)(AsciiStrCmp(string1,
> > string2))
> >  #define strncmp(string1, string2, count)
> (int)(AsciiStrnCmp(string1,
> > string2, (UINTN)(count)))
> > +#define strrchr(str, ch)fdt_strrchr(str, ch)
> > +#define strtoul(ptr, end_ptr, base) fdt_strtoul(ptr, end_ptr,
> > base)
> >
> >  #endif /* FDT_LIB_SUPPORT_H_ */
> > diff --git a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> > b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> > index ef6452914f5b..1a4cd573fdaf 100644
> > --- a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> > +++ b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> > @@ -18,28 +18,7 @@
> >  // so the code gets a bit clunky to handle that case specifically.
> >
> >  char *
> > -strchr (
> > -  const char  *Str,
> > -  int Char
> > -  )
> > -{
> > -  char  *S;
> > -
> > -  S = (char *)Str;
> > -
> > -  for ( ; ; S++) {
> > -if (*S == Char) {
> > -  return S;
> > -}
> > -
> > -if (*S == '\0') {
> > -  return NULL;
> > -}
> > -  }
> > -}
> > -
> > -char *
> > -strrchr (
> > +fdt_strrchr (
> >const char  *Str,
> >int Char
> >)
> > @@ -71,7 +50,7 @@ __isspace (
> >  }
> >
> >  unsigned long
> > -strtoul (
> > +fdt_strtoul (
> >const char  *Nptr,
> >char**EndPtr,
> >int Base
> > --
> > 2.34.1
> >
> >
> >
> > 
> >



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

Re: [edk2-devel] [PATCH v3 1/1] MdePkg: Add FdtLib gmock support

[Michael D Kinney]

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


> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, January 23, 2024 9:36 PM
> To: devel@edk2.groups.io; jbra...@nvidia.com
> Cc: gaolim...@byosoft.com.cn; Liu, Zhiguang ;
> Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH v3 1/1] MdePkg: Add FdtLib gmock
> support
> 
> Reviewed-by: Michael D Kinney 
> 
> I also see you opened a PR to run EDK II CI and it passed.
> 
> I will merge V3
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Jeff
> > Brasen via groups.io
> > Sent: Tuesday, January 23, 2024 7:08 PM
> > To: devel@edk2.groups.io
> > Cc: gaolim...@byosoft.com.cn; Kinney, Michael D
> > ; Liu, Zhiguang ;
> > Jeff Brasen 
> > Subject: [edk2-devel] [PATCH v3 1/1] MdePkg: Add FdtLib gmock support
> >
> > Add Google Mock Library for FdtLib
> >
> > Signed-off-by: Jeff Brasen 
> > ---
> >  MdePkg/Test/MdePkgHostTest.dsc|   1 +
> >  .../GoogleTest/MockFdtLib/MockFdtLib.inf  |  28 +++
> >  .../Include/GoogleTest/Library/MockFdtLib.h   | 164
> ++
> >  .../GoogleTest/MockFdtLib/MockFdtLib.cpp  |  34 
> >  4 files changed, 227 insertions(+)
> >  create mode 100644
> > MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> >  create mode 100644
> > MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> >  create mode 100644
> > MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
> >
> > diff --git a/MdePkg/Test/MdePkgHostTest.dsc
> > b/MdePkg/Test/MdePkgHostTest.dsc
> > index 583f8fc0ddd8..e36b7c55 100644
> > --- a/MdePkg/Test/MdePkgHostTest.dsc
> > +++ b/MdePkg/Test/MdePkgHostTest.dsc
> > @@ -45,3 +45,4 @@ [Components]
> >
> >
> MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mock
> > UefiRuntimeServicesTableLib.inf
> >
> >
> MdePkg/Test/Mock/Library/GoogleTest/MockPeiServicesLib/MockPeiServicesLi
> > b.inf
> >MdePkg/Test/Mock/Library/GoogleTest/MockHobLib/MockHobLib.inf
> > +  MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > diff --git
> > a/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > new file mode 100644
> > index ..b227bcbae963
> > --- /dev/null
> > +++ b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf
> > @@ -0,0 +1,28 @@
> > +## @file
> > +# Google Test mocks for FdtLib
> > +#
> > +# Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> > reserved.
> > +# Copyright (c) 2023, Intel Corporation. All rights reserved.
> > +# SPDX-License-Identifier: BSD-2-Clause-Patent
> > +##
> > +
> > +[Defines]
> > +  INF_VERSION= 0x00010005
> > +  BASE_NAME  = MockFdtLib
> > +  FILE_GUID  = 0f5471bc-fc2c-4cf4-b9f7-
> c1396d32831c
> > +  MODULE_TYPE= HOST_APPLICATION
> > +  VERSION_STRING = 1.0
> > +  LIBRARY_CLASS  = FdtLib
> > +
> > +[Sources]
> > +  MockFdtLib.cpp
> > +
> > +[Packages]
> > +  MdePkg/MdePkg.dec
> > +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> > +
> > +[LibraryClasses]
> > +  GoogleTestLib
> > +
> > +[BuildOptions]
> > +  MSFT:*_*_*_CC_FLAGS = /EHsc /bigobj
> > diff --git a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> > b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> > new file mode 100644
> > index ..5b21b232b7c7
> > --- /dev/null
> > +++ b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
> > @@ -0,0 +1,164 @@
> > +/** @file
> > +  Google Test mocks for FdtLib
> > +
> > +  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights
> > reserved.
> > +  Copyright (c) 2023, Intel Corporation. All rights reserved.
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +**/
> > +
> > +#ifndef MOCK_FDT_LIB_H_
> > +#define MOCK_FDT_LIB_H_
> > +
> > +#include 
> > +#include 
> > +extern "C" {
> > +  #include 
> > +  #include 
> > +}
> > +
> > +struct MockFdtLib {
> > +  MOCK_INTERFACE_DECLARATION (MockFdtLib);
> > +
> > +  MOCK_FUNCTION_DECLARATION (
> > +UINT16,
> > +Fdt16ToCpu,
> > +(IN UINT16 Value)
> > +);
> > +  MOCK_

Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

[Michael D Kinney]

Hi Laszlo,

Responses below.

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, January 24, 2024 6:17 AM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Liming Gao ; Li, Aaron
> ; Liu, Yun Y ; Andrew Fish
> 
> Subject: Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set
> MemoryTypeInfo bin range from HOB
> 
> On 1/23/24 21:24, Michael D Kinney wrote:
> > Provide an optional method for PEI to declare a specific address
> > range to use for the Memory Type Information bins. The current
> > algorithm uses heuristics that tends to place the Memory Type
> > Information bins in the same location, but memory configuration
> > changes across boots or algorithm changes across a firmware
> > updates could potentially change the Memory Type Information bin
> > location.
> >
> > If the HOB List contains a Resource Descriptor HOB that
> > describes tested system memory and has an Owner GUID of
> > gEfiMemoryTypeInformationGuid, then use the address range
> > described by the Resource Descriptor HOB as the preferred
> > location of the Memory Type Information bins. If this HOB is
> > not detected, then the current behavior is preserved.
> >
> > The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> > is ignored for the following conditions:
> > * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> >   is smaller than the Memory Type Information bins.
> > * The HOB list contains more than one Resource Descriptor HOB
> >   with an owner GUID of gEfiMemoryTypeInformationGuid.
> > * The Resource Descriptor HOB with an Owner GUID of
> >   gEfiMemoryTypeInformationGuid is the same Resource Descriptor
> >   HOB that that describes the PHIT memory range.
> 
> I feel that, while this GUID usage makes sense, it overloads the already
> existing meanings of gEfiMemoryTypeInformationGuid.
> 
> We already use this GUID for two things:
> 
> (see "MdeModulePkg/Include/Guid/MemoryTypeInformation.h"):
> 
> - UEFI variable name space GUID for the "MemoryTypeInformation" variable
> 
> - HOB of type EFI_HOB_TYPE_GUID_EXTENSION, controlling the page counts
> in the various memory type bins.
> 
> Now this new use would introduce a HOB of type
> EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, where the Owner field is
> gEfiMemoryTypeInformationGuid, and the range described by the
> PhysicalStart and ResourceLength fields would accommodate the actual
> bins. On one hand this new HOB is certainly related to the prior two
> uses, but on the other hand, we'd now have to HOBs that used the "same
> GUID" for different purposes. What distinguishes them is
> EFI_HOB_TYPE_GUID_EXTENSION vs. EFI_HOB_TYPE_RESOURCE_DESCRIPTOR --
> which I find a bit too obscure.
> 
> (1) So I'd either suggest generating a brand new GUID, *or* extending
> the
> comments in "MdeModulePkg/Include/Guid/MemoryTypeInformation.h" with the
> new usage:

I will extend the description of the GUID in MemoryTypeInformation.h

> 
> > /** @file
> >   This file defines:
> >   * Memory Type Information GUID for HOB and Variable.
> >   * Memory Type Information Variable Name.
> >   * Memory Type Information GUID HOB data structure.
> >
> >   The memory type information HOB and variable can
> >   be used to store the information for each memory type in Variable or
> HOB.
> >
> > Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> > **/
> 
> Back to the patch:
> 
> On 1/23/24 21:24, Michael D Kinney wrote:
> > Update the DxeMain initialization order to initialize GCD
> > services before any runtime allocations are performed.  This
> > is required to prevent runtime data fragmentation when the
> > UEFI System Table and UEFI Runtime Service Table is allocated.
> 
> (2) Should this be a separate patch? (First patch in the series?) This
> seems
> to effect behavior even if the new HOB is not present.

I did consider doing this as a separate patch because the change in the
order of init in DxeMain can be done independent of this new optional
feature.  I will break it out to make that clear and simpler to review.
The new feature does depend on this new order so it has to be the first
patch.

> 
> >
> > Cc: Liming Gao 
> > Cc: Aaron Li 
> > Cc: Liu Yun 
> > Cc: Andrew Fish 
> > Signed-off-by: Michael D Kinney 
> > ---
> >  MdeModulePkg/Core/Dxe/DxeMain.h |   6 ++
> >  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
> >  MdeModulePkg/Core/Dxe/Gcd/Gcd.c |  72

Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

[Michael D Kinney]

Hi Laszlo,

Yes.  I can add more details in the commit message.

The impact is for ACPI S4.  There are many reasons why the set of
HOBs passed into the DXE Core may change from boot to boot or that
allocations in the early DXE init phase should change where the
memory type information bins are allocated.

ACPI S4 does do a power cycle and it is possible to do FW updates
or FW setup config changes between an S4 save and S4 resume operation.

It is even possible for one OS to do S4 save.  Reboot the system
to boot a completely different OS.  Reboot again and do an S4 resume
of the original OS.

If a platform chooses to enable this feature, the number of scenarios
that an S4 resume can fail is reduced.

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, January 24, 2024 6:21 AM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Liming Gao ; Li, Aaron
> ; Liu, Yun Y ; Andrew Fish
> 
> Subject: Re: [edk2-devel] [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set
> MemoryTypeInfo bin range from HOB
> 
> On 1/23/24 21:24, Michael D Kinney wrote:
> > Provide an optional method for PEI to declare a specific address
> > range to use for the Memory Type Information bins. The current
> > algorithm uses heuristics that tends to place the Memory Type
> > Information bins in the same location, but memory configuration
> > changes across boots or algorithm changes across a firmware
> > updates could potentially change the Memory Type Information bin
> > location.
> 
> (5) Why is such a rearrangement of the bins -- which is likely visible
> in the UEFI memory map, too -- a problem?
> 
> Can we include a hint on that in the commit message?
> 
> I understand why it would be a problem across ACPI S4, but a memory
> config change (DIMM addition/removal?), or a firmware update, seems to
> require a full S5 power cycle.
> 
> Thanks
> Laszlo



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

Re: [edk2-devel] 回复: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

[Michael D Kinney]

Hi Liming,

The current algorithm allocates the bins from the top of the first
memory range given to the DXE Core.  This is not guaranteed to be
the top of RAM.  The heuristic will use the memory range from the
PHIT HOB if it is considered big enough.  If PHIT is not big enough
then a search of the HOBs is made for one that is considered big
enough near the top of memory that is tested.

Additional memory can be added or promoted from untested to tested
after DXE Core init and that added or promoted memory may have
a higher address than the initial memory given to the DXE Core.

With current heuristics, platforms have to carefully construct the
HOBs in PEIM phase to get the behavior where these bins are at the
top of RAM.

With this feature, it provides precise control over where the
bins are placed.

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, January 24, 2024 8:17 AM
> To: devel@edk2.groups.io; gaolim...@byosoft.com.cn; Kinney, Michael D
> 
> Cc: Li, Aaron ; Liu, Yun Y ;
> 'Andrew Fish' 
> Subject: Re: [edk2-devel] 回复: [Patch v2 1/1] MdeModulePkg/Core/Dxe:
> Set MemoryTypeInfo bin range from HOB
> 
> On 1/24/24 15:59, gaoliming via groups.io wrote:
> > Mike:
> >  Current algorithm tries to reserve the top available memory for
> memory type
> > bin range.
> >  If the platform uses new way to describe the memory range, should we
> > suggest the rule to still
> >  use the top memory resource hob for the memory type bin range?
> 
> How would that work, technically? If the platform specifies a concrete
> address range, how can that be reconciled with using the top of RAM?
> 
> Or do you mean documentation? I.e., a note for platform implementors
> that they should point their new HOB to the top of RAM?
> 
> Thanks
> Laszlo
> 
> >
> > Thanks
> > Liming
> >> -邮件原件-
> >> 发件人: Michael D Kinney 
> >> 发送时间: 2024年1月24日 4:24
> >> 收件人: devel@edk2.groups.io
> >> 抄送: Liming Gao ; Aaron Li
> >> ; Liu Yun ; Andrew Fish
> >> 
> >> 主题: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin
> >> range from HOB
> >>
> >> Provide an optional method for PEI to declare a specific address
> >> range to use for the Memory Type Information bins. The current
> >> algorithm uses heuristics that tends to place the Memory Type
> >> Information bins in the same location, but memory configuration
> >> changes across boots or algorithm changes across a firmware
> >> updates could potentially change the Memory Type Information bin
> >> location.
> >>
> >> If the HOB List contains a Resource Descriptor HOB that
> >> describes tested system memory and has an Owner GUID of
> >> gEfiMemoryTypeInformationGuid, then use the address range
> >> described by the Resource Descriptor HOB as the preferred
> >> location of the Memory Type Information bins. If this HOB is
> >> not detected, then the current behavior is preserved.
> >>
> >> The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> >> is ignored for the following conditions:
> >> * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> >>   is smaller than the Memory Type Information bins.
> >> * The HOB list contains more than one Resource Descriptor HOB
> >>   with an owner GUID of gEfiMemoryTypeInformationGuid.
> >> * The Resource Descriptor HOB with an Owner GUID of
> >>   gEfiMemoryTypeInformationGuid is the same Resource Descriptor
> >>   HOB that that describes the PHIT memory range.
> >>
> >> Update the DxeMain initialization order to initialize GCD
> >> services before any runtime allocations are performed.  This
> >> is required to prevent runtime data fragmentation when the
> >> UEFI System Table and UEFI Runtime Service Table is allocated.
> >>
> >> Cc: Liming Gao 
> >> Cc: Aaron Li 
> >> Cc: Liu Yun 
> >> Cc: Andrew Fish 
> >> Signed-off-by: Michael D Kinney 
> >> ---
> >>  MdeModulePkg/Core/Dxe/DxeMain.h |   6 ++
> >>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
> >>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c |  72 -
> >>  MdeModulePkg/Core/Dxe/Mem/Page.c| 101
> >> 
> >>  4 files changed, 190 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> >> b/MdeModulePkg/Core/Dxe/DxeMain.h
> >> index 86a7be2f5188..53e26703f8c7 100644
> >> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> >> +

Re: [edk2-devel] [PATCH 11/14] MdePkg: Test: Add gRT_GetTime Google Test Mock

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Douglas Flick [MSFT] 
> Sent: Tuesday, January 23, 2024 7:34 PM
> To: devel@edk2.groups.io
> Cc: Douglas Flick [MSFT] ; Kinney, Michael D
> ; Liming Gao ;
> Liu, Zhiguang 
> Subject: [PATCH 11/14] MdePkg: Test: Add gRT_GetTime Google Test Mock
> 
> This adds support for GetTime Google Test Mock
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> 
> Signed-off-by: Doug Flick [MSFT] 
> ---
>  .../GoogleTest/Library/MockUefiRuntimeServicesTableLib.h   | 7 +++
>  .../MockUefiRuntimeServicesTableLib.cpp| 5 +++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git
> a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> leLib.h
> b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> leLib.h
> index 241abc55c079..bcc902cb93c2 100644
> ---
> a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> leLib.h
> +++
> b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> leLib.h
> @@ -37,6 +37,13 @@ struct MockUefiRuntimeServicesTableLib {
>   IN UINTN DataSize,
> 
>   IN VOID  *Data)
> 
>  );
> 
> +
> 
> +  MOCK_FUNCTION_DECLARATION (
> 
> +EFI_STATUS,
> 
> +gRT_GetTime,
> 
> +(OUT  EFI_TIME*Time,
> 
> + OUT  EFI_TIME_CAPABILITIES   *Capabilities OPTIONAL)
> 
> +);
> 
>  };
> 
> 
> 
>  #endif
> 
> diff --git
> a/MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mo
> ckUefiRuntimeServicesTableLib.cpp
> b/MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mo
> ckUefiRuntimeServicesTableLib.cpp
> index 14296b0ccb88..8d2afd5dd63a 100644
> ---
> a/MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mo
> ckUefiRuntimeServicesTableLib.cpp
> +++
> b/MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mo
> ckUefiRuntimeServicesTableLib.cpp
> @@ -10,11 +10,12 @@ MOCK_INTERFACE_DEFINITION
> (MockUefiRuntimeServicesTableLib);
> 
> 
>  MOCK_FUNCTION_DEFINITION (MockUefiRuntimeServicesTableLib,
> gRT_GetVariable, 5, EFIAPI);
> 
>  MOCK_FUNCTION_DEFINITION (MockUefiRuntimeServicesTableLib,
> gRT_SetVariable, 5, EFIAPI);
> 
> +MOCK_FUNCTION_DEFINITION (MockUefiRuntimeServicesTableLib, gRT_GetTime,
> 2, EFIAPI);
> 
> 
> 
>  static EFI_RUNTIME_SERVICES  localRt = {
> 
> -  { 0 },  // EFI_TABLE_HEADER
> 
> +  { 0 },// EFI_TABLE_HEADER
> 
> 
> 
> -  NULL, // EFI_GET_TIME
> 
> +  gRT_GetTime,  // EFI_GET_TIME
> 
>NULL, // EFI_SET_TIME
> 
>NULL, // EFI_GET_WAKEUP_TIME
> 
>NULL, // EFI_SET_WAKEUP_TIME
> 
> --
> 2.43.0



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

Re: [edk2-devel] 回复: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin range from HOB

[Michael D Kinney]

Hi Liming,

The exact range that may or may not support S4 resume may be OS dependent.
I am not sure.

In general, a UEFI OS should not be dependent on specific UEFI memory
types being above or below specific addresses.

The only S4 requirement I know of is landing the memory types at the
same address.

If you are aware of additional constraints for specific OSes, then
that is good information, but not sure where to put it.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of gaoliming
> via groups.io
> Sent: Wednesday, January 24, 2024 5:19 PM
> To: Kinney, Michael D ; 'Laszlo Ersek'
> ; devel@edk2.groups.io
> Cc: Li, Aaron ; Liu, Yun Y ;
> 'Andrew Fish' 
> Subject: 回复: [edk2-devel] 回复: [Patch v2 1/1] MdeModulePkg/Core/Dxe:
> Set MemoryTypeInfo bin range from HOB
> 
> Mike:
>   I suggest to document the recommended usage of the specified memory
> type info bin range. I worry that someone configures the low memory
> range for the memory type info bin range. It may still cause S4 failure.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: Kinney, Michael D 
> > 发送时间: 2024年1月25日 1:53
> > 收件人: Laszlo Ersek ; devel@edk2.groups.io;
> > gaolim...@byosoft.com.cn
> > 抄送: Li, Aaron ; Liu, Yun Y
> ;
> > 'Andrew Fish' ; Kinney, Michael D
> > 
> > 主题: RE: [edk2-devel] 回复: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set
> > MemoryTypeInfo bin range from HOB
> >
> > Hi Liming,
> >
> > The current algorithm allocates the bins from the top of the first
> > memory range given to the DXE Core.  This is not guaranteed to be
> > the top of RAM.  The heuristic will use the memory range from the
> > PHIT HOB if it is considered big enough.  If PHIT is not big enough
> > then a search of the HOBs is made for one that is considered big
> > enough near the top of memory that is tested.
> >
> > Additional memory can be added or promoted from untested to tested
> > after DXE Core init and that added or promoted memory may have
> > a higher address than the initial memory given to the DXE Core.
> >
> > With current heuristics, platforms have to carefully construct the
> > HOBs in PEIM phase to get the behavior where these bins are at the
> > top of RAM.
> >
> > With this feature, it provides precise control over where the
> > bins are placed.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Laszlo Ersek 
> > > Sent: Wednesday, January 24, 2024 8:17 AM
> > > To: devel@edk2.groups.io; gaolim...@byosoft.com.cn; Kinney, Michael
> D
> > > 
> > > Cc: Li, Aaron ; Liu, Yun Y
> ;
> > > 'Andrew Fish' 
> > > Subject: Re: [edk2-devel] 回复: [Patch v2 1/1]
> MdeModulePkg/Core/Dxe:
> > > Set MemoryTypeInfo bin range from HOB
> > >
> > > On 1/24/24 15:59, gaoliming via groups.io wrote:
> > > > Mike:
> > > >  Current algorithm tries to reserve the top available memory for
> > > memory type
> > > > bin range.
> > > >  If the platform uses new way to describe the memory range, should
> we
> > > > suggest the rule to still
> > > >  use the top memory resource hob for the memory type bin range?
> > >
> > > How would that work, technically? If the platform specifies a
> concrete
> > > address range, how can that be reconciled with using the top of RAM?
> > >
> > > Or do you mean documentation? I.e., a note for platform implementors
> > > that they should point their new HOB to the top of RAM?
> > >
> > > Thanks
> > > Laszlo
> > >
> > > >
> > > > Thanks
> > > > Liming
> > > >> -邮件原件-
> > > >> 发件人: Michael D Kinney 
> > > >> 发送时间: 2024年1月24日 4:24
> > > >> 收件人: devel@edk2.groups.io
> > > >> 抄送: Liming Gao ; Aaron Li
> > > >> ; Liu Yun ; Andrew Fish
> > > >> 
> > > >> 主题: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo
> > bin
> > > >> range from HOB
> > > >>
> > > >> Provide an optional method for PEI to declare a specific address
> > > >> range to use for the Memory Type Information bins. The current
> > > >> algorithm uses heuristics that tends to place the Memory Type
> > > >> Information bins in the same location, but memory configuration
> > > >> changes across boots or algorithm changes across a firmware
> > > >> updates could potentially change the Memory Ty

Re: [edk2-devel] [PATCH v2 3/4] UefiCpuPkg/MtrrLib.h: use cache type #defines from ArchitecturalMsr.h

[Michael D Kinney]

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Thursday, January 25, 2024 12:23 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Aktas, Erdem ; Michael Roth
> ; Xu, Min M ; Gerd Hoffmann
> ; Yao, Jiewen ; Tom Lendacky
> ; Oliver Steffen 
> Subject: [edk2-devel] [PATCH v2 3/4] UefiCpuPkg/MtrrLib.h: use cache
> type #defines from ArchitecturalMsr.h
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Include/Library/MtrrLib.h | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h
> b/UefiCpuPkg/Include/Library/MtrrLib.h
> index 86cc1aab3b8e..c7d505ac06ed 100644
> --- a/UefiCpuPkg/Include/Library/MtrrLib.h
> +++ b/UefiCpuPkg/Include/Library/MtrrLib.h
> @@ -9,6 +9,8 @@
>  #ifndef  _MTRR_LIB_H_
>  #define  _MTRR_LIB_H_
> 
> +#include 
> +
>  //
>  // According to IA32 SDM, MTRRs number and MSR offset are always
> consistent
>  // for IA32 processor family
> @@ -90,12 +92,12 @@ typedef enum {
>CacheInvalid= 7
>  } MTRR_MEMORY_CACHE_TYPE;


I think the values in the above enum should also use the
MSR_IA32_MTRR_CACHE values.

> 
> -#define  MTRR_CACHE_UNCACHEABLE  0
> -#define  MTRR_CACHE_WRITE_COMBINING  1
> -#define  MTRR_CACHE_WRITE_THROUGH4
> -#define  MTRR_CACHE_WRITE_PROTECTED  5
> -#define  MTRR_CACHE_WRITE_BACK   6
> -#define  MTRR_CACHE_INVALID_TYPE 7
> +#define  MTRR_CACHE_UNCACHEABLE  MSR_IA32_MTRR_CACHE_UNCACHEABLE
> +#define  MTRR_CACHE_WRITE_COMBINING
> MSR_IA32_MTRR_CACHE_WRITE_COMBINING
> +#define  MTRR_CACHE_WRITE_THROUGHMSR_IA32_MTRR_CACHE_WRITE_THROUGH
> +#define  MTRR_CACHE_WRITE_PROTECTED
> MSR_IA32_MTRR_CACHE_WRITE_PROTECTED
> +#define  MTRR_CACHE_WRITE_BACK   MSR_IA32_MTRR_CACHE_WRITE_BACK
> +#define  MTRR_CACHE_INVALID_TYPE MSR_IA32_MTRR_CACHE_INVALID_TYPE
> 
>  typedef struct {
>UINT64BaseAddress;
> --
> 2.43.0
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized FV Migration Information

[Michael D Kinney]

Hi Fan,

The logic looks functional, but there are some names and descriptions
that could be added to help describe this feature and some code 
changes to make the code easier to understand.

1) The GUID gEdkiiToMigrateFvInfoGuid is hard to understand what
   information it conveys from the name of the GUID variable.
   I know that the intent is that it is a GUID with data that 
   tells the PEI core which FVs in temporary RAM should be 
   migrated to permanent RAM.  And that the use of this information
   is only a performance optimization to not migrate FVs that 
   are not needed after the PEI Core migrates temp RAM to 
   permanent RAM.  The name and description in comments do not
   express all these details.

2) The structure name EDKII_TO_MIGRATE_FV_INFO has the same
   issue as (1).
   a) Should FvOrgBase be a UINT64 or support temp RAM above 4GB?
   b) Since only temp RAM to perm RAM migrations are supported
  the field name "FvOrgBase" should be "FvTemporaryRamBase".


3) The #define for FLAGS_SKIP_FV_MIGRATION should have a comment
   block that describes the meaning of this bit.  What is the 
   meaning when the bit is set and what is the meaning when the
   bit is clear.

4) The #define for FLAGS_SKIP_FV_RAW_DATA_COPY should have a comment
   block that describes the meaning of this bit.  What is the 
   meaning when the bit is set and what is the meaning when the
   bit is clear.

5) Why are there 2 bits?  If an FV is skipped, then that means
   do not copy.  If an FV is not skipped, then that means do
   copy.

6) I think the variable MigrateAllFvs can be removed, and the HOB
   list check can be made for gEdkiiToMigrateFvInfoGuid can be made
   on each FV found in temporary RAM.  This looks like a performance
   optimization that makes the logic harder to understand and it
   is not clear that the performance optimization has any benefit.

7) The call to RemoveFvHobsInTemporaryMemory (Private) was removed.  Why?

8) The comment where memory is allocated for the migrated FV says
   "allocate pool" when PeiServicesAllocatePages() is used.  Please 
   update the comment.

Mike



> -Original Message-
> From: Wang, Fan 
> Sent: Monday, September 11, 2023 2:52 AM
> To: devel@edk2.groups.io
> Cc: Wang, Fan ; Kinney, Michael D
> ; Gao, Liming ;
> Jiang, Guomin ; Bi, Dandan
> 
> Subject: [PATCH V2 1/1] MdeModulePkg: Support customized FV Migration
> Information
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4533
> 
> There are use cases which not all FVs need be migrated from TempRam to
> permanent memory before TempRam tears down. This new guid is
> introduced
> to avoid unnecessary FV migration to improve boot performance.
> Platform
> can publish ToMigrateFvInfo hob with this guid to customize FV
> migration
> info, and PeiCore will only migrate FVs indicated by this Hob info.
> 
> This is a backwards compatible change, PeiCore will check
> ToMigrateFvInfo
> hob before migration. If ToMigrateFvInfo hobs exists, only migrate FVs
> recorded by hobs. If ToMigrateFvInfo hobs not exists, migrate all FVs
> to
> permanent memory.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Guomin Jiang 
> Cc: Dandan Bi 
> Signed-off-by: Wang Fan 
> ---
>  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 82 +-
> -
>  MdeModulePkg/Core/Pei/PeiMain.inf |  1 +
>  MdeModulePkg/Include/Guid/MigratedFvInfo.h| 19 +
>  MdeModulePkg/MdeModulePkg.dec |  3 +-
>  4 files changed, 79 insertions(+), 26 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> index 5f32ebb560ae..e84849ec6db1 100644
> --- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> +++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> @@ -1184,7 +1184,11 @@ EvacuateTempRam (
> 
>PEI_CORE_FV_HANDLEPeiCoreFvHandle;
>EFI_PEI_CORE_FV_LOCATION_PPI  *PeiCoreFvLocationPpi;
> +  EDKII_TO_MIGRATE_FV_INFO  *ToMigrateFvInfo;
>EDKII_MIGRATED_FV_INFOMigratedFvInfo;
> +  EFI_PEI_HOB_POINTERS  Hob;
> +  BOOLEAN   MigrateAllFvs;
> +  UINT32MigrationFlags;
> 
>ASSERT (Private->PeiMemoryInstalled);
> 
> @@ -1211,6 +1215,17 @@ EvacuateTempRam (
> 
>ConvertPeiCorePpiPointers (Private, &PeiCoreFvHandle);
> 
> +  //
> +  // Check if platform defined hobs to indicate which FVs are
> expected to migrate or keep raw data.
> +  // If ToMigrateFvInfo hobs exists, only migrate FVs recorded by
> hobs.
> +  // If ToMigrateFvInfo hobs not exists, migrate all FVs to permanent
> memory.
> +  //
> +  MigrateAllFvs = TRUE;
> +  Hob.Raw   = GetFirstGuidHob (&gEdkiiToMigrateFvInfoGui

Re: [edk2-devel] [PATCHv2 2/2] MdePkg/Test: Add DevicePathLib host test module

[Michael D Kinney]

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

Mike

> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, October 13, 2023 9:55 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Gao, Liming ; Liu, Zhiguang
> ; Kinney, Michael D
> 
> Subject: RE: [PATCHv2 2/2] MdePkg/Test: Add DevicePathLib host test
> module
> 
> Reviewed-by: Michael D Kinney 
> 
> > -Original Message-
> > From: Albecki, Mateusz 
> > Sent: Wednesday, September 27, 2023 8:51 AM
> > To: devel@edk2.groups.io
> > Cc: Albecki, Mateusz ; Kinney, Michael D
> > ; Gao, Liming
> ;
> > Liu, Zhiguang 
> > Subject: [PATCHv2 2/2] MdePkg/Test: Add DevicePathLib host test
> module
> >
> > This commit adds host-based unit tests for device path lib.
> >
> >
> >
> > Cc: Michael D Kinney 
> >
> > Cc: Liming Gao 
> >
> > Cc: Zhiguang Liu 
> >
> >
> >
> > Signed-off-by: Mateusz Albecki 
> >
> > ---
> >
> >  MdePkg/MdePkg.ci.yaml |   5 +-
> >
> >  MdePkg/Test/MdePkgHostTest.dsc|   2 +
> >
> >  .../Library/DevicePathLib/TestDevicePathLib.c | 638
> > ++
> >
> >  .../Library/DevicePathLib/TestDevicePathLib.h |  26 +
> >
> >  .../DevicePathLib/TestDevicePathLibHost.inf   |  33 +
> >
> >  .../TestDevicePathStringConversions.c | 370 ++
> >
> >  6 files changed, 1073 insertions(+), 1 deletion(-)
> >
> >  create mode 100644
> > MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.c
> >
> >  create mode 100644
> > MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.h
> >
> >  create mode 100644
> > MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLibHost.inf
> >
> >  create mode 100644
> >
> MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathStringConvers
> > ions.c
> >
> >
> >
> > diff --git a/MdePkg/MdePkg.ci.yaml b/MdePkg/MdePkg.ci.yaml
> >
> > index c3faf4913d..45f4fb537b 100644
> >
> > --- a/MdePkg/MdePkg.ci.yaml
> >
> > +++ b/MdePkg/MdePkg.ci.yaml
> >
> > @@ -74,7 +74,10 @@
> >
> >
> > "Test/UnitTest/Library/BaseSafeIntLib/TestBaseSafeIntLib.c",
> >
> >  "Library/BaseFdtLib",
> >
> >  "Library/MipiSysTLib/mipi_syst.h",
> >
> > -"Include/Register/Amd/SmramSaveStateMap.h"
> >
> > +"Include/Register/Amd/SmramSaveStateMap.h",
> >
> > +
> > "Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.c",
> >
> > +
> > "Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.h",
> >
> > +
> >
> "Test/UnitTest/Library/DevicePathLib/TestDevicePathStringConversions.c
> > "
> >
> >  ]
> >
> >  },
> >
> >  ## options defined ci/Plugin/CompilerPlugin
> >
> > diff --git a/MdePkg/Test/MdePkgHostTest.dsc
> > b/MdePkg/Test/MdePkgHostTest.dsc
> >
> > index 529ea69024..b92b564d43 100644
> >
> > --- a/MdePkg/Test/MdePkgHostTest.dsc
> >
> > +++ b/MdePkg/Test/MdePkgHostTest.dsc
> >
> > @@ -21,6 +21,7 @@
> >
> >
> >
> >  [LibraryClasses]
> >
> >SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
> >
> > +
> >
> DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibBase.i
> > nf
> >
> >
> >
> >  [Components]
> >
> >#
> >
> > @@ -29,6 +30,7 @@
> >
> >
> >
> MdePkg/Test/UnitTest/Library/BaseSafeIntLib/TestBaseSafeIntLibHost.inf
> >
> >MdePkg/Test/UnitTest/Library/BaseLib/BaseLibUnitTestsHost.inf
> >
> >
> >
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/GoogleTestBaseSafeIntLib
> > .inf
> >
> > +
> > MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLibHost.inf
> >
> >
> >
> >#
> >
> ># Build HOST_APPLICATION Libraries
> >
> > diff --git
> > a/MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.c
> > b/MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.c
> >
> > new file mode 100644
> >
> > index 00..687497278c
> >
> > --- /dev/null
> >
> > +++ b/MdePkg/Test/UnitTest/Library/DevicePathLib/TestDevicePathLib.c
> >
> > @@ -0,0 +1,638 @@
> >
> > +/** @file
> >
> > +  UEFI

Re: [edk2-devel] [PATCH V2] Maintainers.txt: Stop to be reviewer of several modules

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Monday, June 12, 2023 11:36 PM
> To: devel@edk2.groups.io
> Cc: Gao, Zhichao ; Wu, Hao A
> ; Liu, Zhiguang ; Guo, Gua
> 
> Subject: [edk2-devel] [PATCH V2] Maintainers.txt: Stop to be reviewer
> of several modules
> 
> Remove my name from reviewer list of following modules:
> * MdeModulePkg: Console and Graphics modules
> * MdeModulePkg: Reset modules
> * MdeModulePkg: Serial modules
> * MdeModulePkg: Universal Payload definitions
> 
> Signed-off-by: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Hao A Wu 
> Cc: Zhiguang Liu 
> Cc: Gua Guo 
> ---
>  Maintainers.txt | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 42e40dced3..a523fb41c1 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -294,7 +294,6 @@ F: MdeModulePkg/Library/BaseBmpSupportLib/
>  F: MdeModulePkg/Library/FrameBufferBltLib/
> 
>  F: MdeModulePkg/Universal/Console/
> 
>  R: Zhichao Gao  [ZhichaoGao]
> 
> -R: Ray Ni  [niruiyu]
> 
> 
> 
>  MdeModulePkg: Core services (PEI, DXE and Runtime) modules
> 
>  F: MdeModulePkg/*Mem*/
> 
> @@ -398,12 +397,10 @@ MdeModulePkg: Reset modules
>  F: MdeModulePkg/*Reset*/
> 
>  F: MdeModulePkg/Include/*Reset*.h
> 
>  R: Zhichao Gao  [ZhichaoGao]
> 
> -R: Ray Ni  [niruiyu]
> 
> 
> 
>  MdeModulePkg: Serial modules
> 
>  F: MdeModulePkg/*Serial*/
> 
>  F: MdeModulePkg/Include/*SerialPort*.h
> 
> -R: Ray Ni  [niruiyu]
> 
>  R: Zhichao Gao  [ZhichaoGao]
> 
> 
> 
>  MdeModulePkg: SMBIOS modules
> 
> @@ -426,7 +423,6 @@ R: Liming Gao  [lgao4]
>  MdeModulePkg: Universal Payload definitions
> 
>  F: MdeModulePkg/Include/UniversalPayload/
> 
>  R: Zhiguang Liu  [LiuZhiguang001]
> 
> -R: Ray Ni  [niruiyu]
> 
>  R: Gua Guo  [gguo11837463]
> 
> 
> 
>  MdeModulePkg: Trace Hub debug message related library instance
> 
> --
> 2.37.2.windows.2
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#106051):
> https://edk2.groups.io/g/devel/message/106051
> Mute This Topic: https://groups.io/mt/99500362/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe:
> https://edk2.groups.io/g/devel/leave/3603567/1643496/1659866329/xyzzy
> [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting Aarch64 and ARM

[Michael D Kinney]

+Ard
+Leif


> -Original Message-
> From: Jayaprakash, N 
> Sent: Friday, October 20, 2023 7:04 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran
> ; Kinney, Michael D ;
> Tyler Erickson 
> Subject: [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting
> Aarch64 and ARM
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4570
> 
> This commit is for processing the below PR on edk2-libc repo
> https://github.com/tianocore/edk2-libc/pull/3
> These are the changes introduced to StdLib to build
> an application for the UEFI shell.
> Added format macros for int types to Aarch64, ARM, and Ia32.
> Also modified the X64 macros so that everything would build
> when they are used.
> Added some macros that can be used for compatibility that define when
> socklen_t has been defined.
> Added getopt_long parser from OpenBSD to provide long and
> short option parsing capability with getopt.
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Tyler Erickson 
> ---
>  StdLib/Include/Aarch64/machine/int_fmtio.h | 211 +
>  StdLib/Include/Arm/machine/int_fmtio.h | 211 +
>  StdLib/Include/Ia32/machine/int_fmtio.h| 212 +
>  StdLib/Include/X64/machine/int_fmtio.h | 324 ++---
>  StdLib/Include/getopt.h|  76 +++
>  StdLib/Include/inttypes.h  |   2 +-
>  StdLib/Include/sys/socket.h|   6 +
>  StdLib/Include/unistd.h|   7 +-
>  StdLib/LibC/LibC.inf   |   1 +
>  StdLib/LibC/Uefi/Uefi.inf  |   1 +
>  StdLib/LibC/Uefi/compat.c  |  40 +-
>  StdLib/LibC/Uefi/getopt_long.c | 523
> +
>  12 files changed, 1406 insertions(+), 208 deletions(-)
>  create mode 100644 StdLib/Include/Aarch64/machine/int_fmtio.h
>  create mode 100644 StdLib/Include/Arm/machine/int_fmtio.h
>  create mode 100644 StdLib/Include/Ia32/machine/int_fmtio.h
>  create mode 100644 StdLib/Include/getopt.h
>  create mode 100644 StdLib/LibC/Uefi/getopt_long.c
> 
> diff --git a/StdLib/Include/Aarch64/machine/int_fmtio.h
> b/StdLib/Include/Aarch64/machine/int_fmtio.h
> new file mode 100644
> index 000..f091a7d
> --- /dev/null
> +++ b/StdLib/Include/Aarch64/machine/int_fmtio.h
> @@ -0,0 +1,211 @@
> +/*  $NetBSD: int_fmtio.h,v 1.10 2018/07/15 00:36:13 christos Exp $
> */
> +
> +/*-
> + * Copyright (c) 2001 The NetBSD Foundation, Inc.
> + * All rights reserved.
> + *
> + * This code is derived from software contributed to The NetBSD
> Foundation
> + * by Klaus Klein.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above
> copyright
> + *notice, this list of conditions and the following disclaimer in
> the
> + *documentation and/or other materials provided with the
> distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
> CONTRIBUTORS
> + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT LIMITED
> + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR
> + * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR
> CONTRIBUTORS
> + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef _ARM_INT_FMTIO_H_
> +#define _ARM_INT_FMTIO_H_
> +
> +/*
> + * 7.8.1 Macros for format specifiers
> + */
> +
> +/* fprintf macros for signed integers */
> +#define PRId8   "d" /* int8_t   */
> +#define PRId16  "d" /* int16_t  */
> +#define PRId32  "d" /* int32_t  */
> +#define PRId64  "lld"   /* int64_t  */
> +#define PRIdLEAST8  "d" /* int_least8_t */
> +#define PRIdLEAST16 "d" /* int_least16_t*/
> +#define PRIdLEAST32 "d" /* int_least32_t*/
> +#define PRIdLEAST64 "lld"   /* i

Re: [edk2-devel] [PATCH v3 0/7] Use CodeQL CLI

[Michael D Kinney]

Acked-by: Michael D Kinney 

> -Original Message-
> From: Michael Kubacki 
> Sent: Monday, October 23, 2023 11:13 AM
> To: devel@edk2.groups.io; Feng, Bob C ; Gao,
> Liming ; Kinney, Michael D
> ; Rebecca Cran ; Sean
> Brogan ; Chen, Christine
> 
> Subject: Re: [edk2-devel] [PATCH v3 0/7] Use CodeQL CLI
> 
> Another reminder. It would be nice to get this merged soon so actual
> code fixes can follow.
> 
> Thanks,
> Michael
> 
> On 10/19/2023 9:07 PM, Michael Kubacki wrote:
> > A reminder to review this series. It's been on the mailing list for
> a
> > few weeks now.
> >
> > Thanks,
> > Michael
> >
> > On 10/17/2023 9:04 PM, Michael Kubacki wrote:
> >> From: Michael Kubacki 
> >>
> >> CodeQL currently runs via the codeql-analysis.yml GitHub workflow
> >> which uses the github/codeql-action/init@v2 action (pre-build)
> >> and the github/codeql-action/analyze@v2 action (post-build) to
> >> setup the CodeQL environment and extract results.
> >>
> >> This infrastructure is removed in preparation for a new design that
> >> will directly run the CodeQL CLI as part of the build. This will
> >> allow CodeQL to be run locally as part of the normal build process
> >> with results that match 1:1 with CI builds.
> >>
> >> The CodeQL CLI design is automatically driven by a set of CodeQL
> >> plugins:
> >>
> >>    1. `CodeQlBuildPlugin` - Used to produce a CodeQL database from
> a
> >>    build.
> >>    2. `CodeQlAnalyzePlugin` - Used to analyze a CodeQL database.
> >>
> >> This approach offers the following advantages:
> >>
> >>    1. Provides exactly the same results locally as on a CI server.
> >>    2. Integrates very well into IDEs such as VS Code.
> >>    3. Very simple to use - just use normal Stuart update and build
> >>   commands.
> >>    4. Very simple to understand - minimally wraps the official
> CodeQL
> >>   CLI.
> >>    5. Very simple to integrate - works like any other Stuart build
> >>   plugin.
> >>    6. Portable - not tied to Azure DevOps specific, GitHub
> specific,
> >>   or other host infrastructure.
> >>    7. Versioned - the query and filters are versioned in source
> >>   control so easy to find and track.
> >>
> >> The appropriate CodeQL CLI is downloaded for the host OS by passing
> >> the `--codeql` argument to the update command.
> >>
> >>    `stuart_update -c .pytool/CISettings.py --codeql`
> >>
> >> After that, CodeQL can be run in a build by similarly passing the
> >> `--codeql` argument to the build command. For example:
> >>
> >>    `stuart_ci_build -c .pytool/CISettings.py --codeql`
> >>
> >> Going forward, CI will simply use those commands in CodeQL builds
> >> to get results instead of the CodeQL GitHub actions.
> >>
> >> When `--codeql` is specified in the build command, each package
> will
> >> contain two main artifacts in the Build directory.
> >>
> >>    1. The CodeQL database for the package
> >>    2. The CodeQL SARIF (result) file for the package
> >>
> >> The CodeQL database (1) can be used to run queries against without
> >> rebuilding any code. The SARIF result file (2) is the result of
> >> running enabled queries against the database.
> >>
> >> SARIF stands for Static Analysis Results Interchange Format and it
> >> is an industry standard format for output from static analysis
> tools.
> >>
> >> https://sarifweb.azurewebsites.net/
> >>
> >> The SARIF file can be opened with any standard SARIF file viewer
> >> such as this one for VS Code:
> >>
> >> https://marketplace.visualstudio.com/items?itemName=MS-
> SarifVSCode.sarif-viewer
> >>
> >> That includes the ability to jump directly to issues in the source
> >> code file with relevant code highlighted and suggestions included.
> >>
> >> This means that after simply adding `--codeql` to the normal build
> >> commands, a database will be present for future querying and a
> SARIF
> >> result file will be present to allow the developer to immediately
> >> start fixing issues.
> >>
> >> More details about the location of these and usage is in the
> >> BaseTools/Plugin/CodeQL/Readme.md included in this patch series.
> >>
> >> The CI process pushes the SARIF file to GitHub Code

Re: [edk2-devel] [PATCH v4 02/14] ArmVirtPkg: Add ImagePropertiesRecordLib Instance

[Michael D Kinney]

Hi Taylor,

I see there have been no reviews from the package maintainers for this
small update to some DSC files.  You can use my Rb for this patch
as a steward.

Reviewed-by: Michael D Kinney 

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Taylor
> Beebe
> Sent: Friday, August 4, 2023 12:47 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Leif Lindholm
> ; Sami Mujawar ; Gerd
> Hoffmann 
> Subject: [edk2-devel] [PATCH v4 02/14] ArmVirtPkg: Add
> ImagePropertiesRecordLib Instance
> 
> From: Taylor Beebe 
> 
> Add an instance of ImagePropertiesRecordLib which will be used by the
> DXE Core.
> 
> Signed-off-by: Taylor Beebe 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 2443e8351c99..b299028b9f51 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -52,6 +52,7 @@ [LibraryClasses.common]
> 
> IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
> 
> UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompr
> essLib.inf
>CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
> 
>UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
>HobLib|ArmVirtPkg/Library/ArmVirtDxeHobLib/ArmVirtDxeHobLib.inf
> --
> 2.41.0.windows.3
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v4 03/14] EmulatorPkg: Add ImagePropertiesRecordLib Instance

[Michael D Kinney]

Hi Taylor,

I see there have been no reviews from the package maintainers for this
small update to some DSC files.  You can use my Rb for this patch
as a steward.

Reviewed-by: Michael D Kinney 

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Taylor
> Beebe
> Sent: Friday, August 4, 2023 12:47 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ni, Ray 
> Subject: [edk2-devel] [PATCH v4 03/14] EmulatorPkg: Add
> ImagePropertiesRecordLib Instance
> 
> From: Taylor Beebe 
> 
> Add an instance of ImagePropertiesRecordLib which will be used by the
> DXE Core.
> 
> Signed-off-by: Taylor Beebe 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> ---
>  EmulatorPkg/EmulatorPkg.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index b44435d7e6ee..e18eeca884a5 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -126,6 +126,7 @@ [LibraryClasses]
>SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> 
> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
> 
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
> --
> 2.41.0.windows.3
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v4 04/14] OvmfPkg: Add ImagePropertiesRecordLib Instance

[Michael D Kinney]

Hi Taylor,

I see there have been no reviews from the package maintainers for this
small update to some DSC files.  You can use my Rb for this patch
as a steward.

Reviewed-by: Michael D Kinney 

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Taylor
> Beebe
> Sent: Friday, August 4, 2023 12:47 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L ;
> Gerd Hoffmann 
> Subject: [edk2-devel] [PATCH v4 04/14] OvmfPkg: Add
> ImagePropertiesRecordLib Instance
> 
> From: Taylor Beebe 
> 
> Add an instance of ImagePropertiesRecordLib which will be used by the
> DXE Core.
> 
> Signed-off-by: Taylor Beebe 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> ---
>  OvmfPkg/AmdSev/AmdSevX64.dsc| 1 +
>  OvmfPkg/Bhyve/BhyveX64.dsc  | 1 +
>  OvmfPkg/CloudHv/CloudHvX64.dsc  | 1 +
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc| 1 +
>  OvmfPkg/Microvm/MicrovmX64.dsc  | 1 +
>  OvmfPkg/OvmfPkgIa32.dsc | 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 1 +
>  OvmfPkg/OvmfPkgX64.dsc  | 1 +
>  OvmfPkg/OvmfXen.dsc | 1 +
>  OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 1 +
>  10 files changed, 10 insertions(+)
> 
> diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc
> b/OvmfPkg/AmdSev/AmdSevX64.dsc
> index 2c6ed7c9745f..e8c954a97956 100644
> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
> @@ -171,6 +171,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTd
> xLib.inf
> 
> PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.
> inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.
> inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
> 
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE
> 
> PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibD
> ebug/PeCoffExtraActionLibDebug.inf
> diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
> index 82c60ace1bbd..ee349e105787 100644
> --- a/OvmfPkg/Bhyve/BhyveX64.dsc
> +++ b/OvmfPkg/Bhyve/BhyveX64.dsc
> @@ -173,6 +173,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTd
> xLib.inf
> 
> PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.
> inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.
> inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
> 
> 
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customi
> zedDisplayLib.inf
> 
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBl
> tLib.inf
> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc
> b/OvmfPkg/CloudHv/CloudHvX64.dsc
> index e000deed9e4d..91816a10996f 100644
> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> @@ -182,6 +182,7 @@ [LibraryClasses]
> 
> MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSev
> Lib.inf
> 
> PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.
> inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.
> inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
>  !if $(SMM_REQUIRE) == FALSE
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
>  !endif
> diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> index 193657ff2d61..bee98e798717 100644
> --- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> +++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
> @@ -171,6 +171,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTd
> xLib.inf
> 
> PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.
> inf
> 
> DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.
> inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
> 
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
> 
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customi
> zedDisplayLib.inf
> diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc
> b/OvmfPkg/Microvm/MicrovmX64.dsc
> index 2f7585639374..38e0af6ae101 100644
> --- a/OvmfPkg/Microvm/MicrovmX64.dsc
> +++ b/OvmfPkg/Microvm/MicrovmX64.dsc
> @@ -185,6 +185,7 @@ [LibraryClasses]
> 
> MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTd
> xLib.inf
> 
> PeiHardwareIn

Re: [edk2-devel] [PATCH v4 05/14] UefiPayloadPkg: Add ImagePropertiesRecordLib Instance

[Michael D Kinney]

Hi Taylor,

I see there have been no reviews from the package maintainers for this
small update to some DSC files.  You can use my Rb for this patch
as a steward.

Reviewed-by: Michael D Kinney 

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Taylor
> Beebe
> Sent: Friday, August 4, 2023 12:47 PM
> To: devel@edk2.groups.io
> Cc: Dong, Guo ; Rhodes, Sean
> ; Lu, James ; Guo, Gua
> 
> Subject: [edk2-devel] [PATCH v4 05/14] UefiPayloadPkg: Add
> ImagePropertiesRecordLib Instance
> 
> From: Taylor Beebe 
> 
> Add an instance of ImagePropertiesRecordLib which will be used by the
> DXE Core.
> 
> Signed-off-by: Taylor Beebe 
> Cc: Guo Dong 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
> b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 47812048ddcf..8d237b23339a 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -277,6 +277,7 @@ [LibraryClasses]
>#
> 
> DebugPrintErrorLevelLib|UefiPayloadPkg/Library/DebugPrintErrorLevelLib
> Hob/DebugPrintErrorLevelLibHob.inf
> 
> PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLi
> bNull.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib
> /ImagePropertiesRecordLib.inf
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE
> 
> PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibD
> ebug/PeCoffExtraActionLibDebug.inf
> 
> DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLi
> bSerialPort/DebugCommunicationLibSerialPort.inf
> --
> 2.41.0.windows.3
> 
> 
> 
> 
> 



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

Re: 回复: 回复: [edk2-devel] [PATCH v4 00/14] Add ImagePropertiesRecordLib and Fix MAT Bugs

[Michael D Kinney]

Hi Taylor,

I did notice that the Signed-off-by tags in some of the commit messages do not 
look right.


Signed-off-by: Taylor Beebe mailto:t...@taylorbeebe.com>>

Please make sure those are updated.

Thanks,

Mike



From: Taylor Beebe 
Sent: Friday, October 13, 2023 3:43 PM
To: 'Ard Biesheuvel' ; Ni, Ray ; 'Leif 
Lindholm' ; Yao, Jiewen ; 
'Sami Mujawar' ; 'Gerd Hoffmann' ; 
'Andrew Fish' ; Justen, Jordan L ; 
Kumar, Rahul R ; Dong, Eric ; 
devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: Re: 回复: 回复: [edk2-devel] [PATCH v4 00/14] Add ImagePropertiesRecordLib 
and Fix MAT Bugs


Thank you Liming :)

Patches 2, 3, 4, 5, and 11 still need reviews -- 4 of them are just adding the 
new library to the package DSC files.



This bug has cost me a significant amount of hours to debug, fix, and 
unit-test. I have been

specific in the cases which cause issues and demonstrated the problem via 
testing yet this

patch has now been in flight for over 2 months. In fact, there have been no 
significant functional

changes to the series since it was originally submitted almost 3 months ago. I 
complied with

Ray's request to reshuffle the commit structure to ease the review burden but 
am still

waiting for feedback or even acknowledgement that it's being looked at.



Everyone in the "To" line of this email has the authority to push this toward 
the finish line.

Can I please get some help?

Reference: Add ImagePropertiesRecordLib and Fix MAT Bugs by TaylorBeebe · Pull 
Request #4900 · tianocore/edk2 
(github.com)

Bugzilla: 4492 – MAT Logic Incorrectly Reports Runtime Images 
(tianocore.org)

-Taylor
On 10/10/2023 7:14 PM, gaoliming via groups.io wrote:
Taylor:
 Thanks for your detail information. I understand more in the detail. The 
changes is good to me. Reviewed-by: Liming Gao 


Thanks
Liming
发件人: devel@edk2.groups.io 
 代表 Taylor Beebe
发送时间: 2023年10月9日 3:21
收件人: devel@edk2.groups.io; 
gaolim...@byosoft.com.cn; 'Ard Biesheuvel' 

抄送: 'Andrew Fish' ; 'Ard Biesheuvel' 
; 'Dandan Bi' 
; 'Eric Dong' 
; 'Gerd Hoffmann' 
; 'Guo Dong' 
; 'Gua Guo' 
; 'James Lu' 
; 'Jian J Wang' 
; 'Jiewen Yao' 
; 'Jordan Justen' 
; 'Leif Lindholm' 
; 'Rahul Kumar' 
; 'Ray Ni' 
; 'Sami Mujawar' 
; 'Sean Rhodes' 

主题: Re: 回复: [edk2-devel] [PATCH v4 00/14] Add ImagePropertiesRecordLib and Fix 
MAT Bugs


On 10/6/2023 10:57 PM, gaoliming via groups.io wrote:

Taylor:

  I agree to add new ImagePropertiesRecordLib library for DxeCore and SmmCore. 
The impact is that platform needs to update their DSC with new library.



  Frankly, I have not understood MAT code in detail. So, I have no comments on 
this part.



  Last, what test have been done to verify the current functionality?

TLDR: Patch 8 adds the unit test which invokes the lions share of the new 
library. The remaining functional changes were tested by output comparison.



To provide context on how best to review this series, where the functional 
changes are, and how they were validated, here's a breakdown of each patch:

Patch 1: Add the ImagePropertiesRecordLib definition and "blank" implementation.

Patches 2-5: Add instances of the library to the platform DSC files.

Patch 6: Updates the logic in Dxe/Misc/MemoryAttributesTable.c to use 
parameters passed in instead of referencing directly the global variables.

This functionally changes nothing but allows the logic to be 
moved to a library.

Patch 7: Move the Dxe/Misc/MemoryAttributesTable.c Image Properties Record 
manipulation logic to ImagePropertiesRecordLib -- still no functional changes.

 FUNCTIONAL CHANGES START 

Patch 8: Add ImagePropertiesRecordLibHostBasedUnitTest which tests the logic 
now in ImagePropertiesRecordLib and 3/4 of the tests fail to show that the 
logic is incorrect.

   The test calls into the SplitTable() routine which is the most 
complex and invokes almost every other function in ImagePropertiesRecordLib.

Patch 9: Fixes the issues in the logic resulting in 
ImagePropertiesRecordLibHostBasedUnitTest passing fully. The fixes change some 
logic in SpitTable() and SplitRecord() (which are tested by the unit test)

   And increases the buffer size for the split table in 
Dxe/Misc/MemoryAttributesTable.c to fi

Re: [edk2-devel] [PATCH v1 1/1] Maintainers.txt: Add .pytool maintainers to BaseTools/Plugin

[Michael D Kinney]

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Monday, October 23, 2023 5:15 PM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming
> ; Kinney, Michael D
> ; Rebecca Cran ; Sean
> Brogan ; Chen, Christine
> 
> Subject: [PATCH v1 1/1] Maintainers.txt: Add .pytool maintainers to
> BaseTools/Plugin
> 
> From: Michael Kubacki 
> 
> Plugins can be placed either in .pytool/Plugin (CI plugin) or
> BaseTools/Plugin (build plugin).
> 
> Since most of the .pytool maintainers already review many of the
> plugins placed there, the same maintainers are added for the Plugin
> directory in BaseTools to increase the total number of maintainers
> for plugin changes.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Rebecca Cran 
> Cc: Sean Brogan 
> Cc: Yuwei Chen 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> This was discussed in the October 23, 2023 Tianocore Tools and CI
> meeting. Three of the BaseTools/Plugin maintainers were present
> (Michael Kinney, Michael Kubacki, Sean Brogan) and the BaseTools
> maintainer Yuwei Chen.
> 
> Liming Gao, if you'd prefer to not be added to the
> BaseTools/Plugin
> list, please let me know and I'll remove you from this patch.
> 
>  Maintainers.txt | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e4689bdd9102..077f6d4ac1fb 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -175,6 +175,13 @@ M: Liming Gao  [lgao4]
>  R: Bob Feng  [BobCF]
>  R: Yuwei Chen  [YuweiChen1110]
> 
> +BaseTools: Plugins
> +F: BaseTools/Plugin/
> +M: Sean Brogan  [spbrogan]
> +M: Michael Kubacki  [makubacki]
> +R: Michael D Kinney  [mdkinney]
> +R: Liming Gao  [lgao4]
> +
>  CryptoPkg
>  F: CryptoPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
> --
> 2.42.0.windows.2



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

Re: [edk2-devel] [PATCH v1 3/3] OvmfPkg: Add varpolicy shell command

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao,
> Jiewen
> Sent: Monday, October 23, 2023 5:44 PM
> To: mikub...@linux.microsoft.com; devel@edk2.groups.io
> Cc: Anatol Belski ; Anthony Perard
> ; Gerd Hoffmann ;
> Jianyong Wu ; Justen, Jordan L
> ; Julien Grall 
> Subject: Re: [edk2-devel] [PATCH v1 3/3] OvmfPkg: Add varpolicy shell
> command
> 
> Acked-by: Jiewen Yao 
> 
> > -Original Message-
> > From: mikub...@linux.microsoft.com 
> > Sent: Tuesday, September 19, 2023 10:33 PM
> > To: devel@edk2.groups.io
> > Cc: Anatol Belski ; Anthony Perard
> > ; Gerd Hoffmann ;
> Jianyong
> > Wu ; Yao, Jiewen ;
> Justen,
> > Jordan L ; Julien Grall 
> > Subject: [PATCH v1 3/3] OvmfPkg: Add varpolicy shell command
> >
> > From: Michael Kubacki 
> >
> > Adds the varpolicy EFI shell command to all DSC files that
> > currently include other dynamic shell commands from ShellPkg.
> >
> > This command allows variable policies to be dumped in the EFI
> > shell for convenient auditing and debug.
> >
> > Use the command in QEMU EFI shell as follows:
> >
> > - `"varpolicy"` dumps platform variables
> > - `"varpolicy -?"` shows help text
> > - `"varpolicy -b"` pages output as expected
> > - `"varpolicy -s"` shows accurate variable statistic information
> > - `"varpolicy -p"` shows accurate UEFI variable policy information
> > - `"varpolicy-v -b"` dumps all information including variable data
> hex dump
> >
> > Cc: Anatol Belski 
> > Cc: Anthony Perard 
> > Cc: Gerd Hoffmann 
> > Cc: Jianyong Wu 
> > Cc: Jiewen Yao 
> > Cc: Jordan Justen 
> > Cc: Julien Grall 
> > Signed-off-by: Michael Kubacki 
> > ---
> >  OvmfPkg/CloudHv/CloudHvX64.dsc | 4 
> >  OvmfPkg/Microvm/MicrovmX64.dsc | 4 
> >  OvmfPkg/OvmfPkgIa32.dsc| 4 
> >  OvmfPkg/OvmfPkgIa32X64.dsc | 4 
> >  OvmfPkg/OvmfPkgX64.dsc | 4 
> >  OvmfPkg/OvmfXen.dsc| 4 
> >  6 files changed, 24 insertions(+)
> >
> > diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc
> > b/OvmfPkg/CloudHv/CloudHvX64.dsc
> > index 35942e02df93..c23c7eaf6cc2 100644
> > --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> > +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> > @@ -837,6 +837,10 @@ [Components]
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> >}
> > +
> >
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> > amicCommand.inf {
> > +
> > +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > +  }
> >
> >
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.
> i
> > nf {
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc
> > b/OvmfPkg/Microvm/MicrovmX64.dsc
> > index 0f26f2a9a97d..ea1fa3e2963f 100644
> > --- a/OvmfPkg/Microvm/MicrovmX64.dsc
> > +++ b/OvmfPkg/Microvm/MicrovmX64.dsc
> > @@ -849,6 +849,10 @@ [Components]
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> >}
> > +
> >
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> > amicCommand.inf {
> > +
> > +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > +  }
> >
> >
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.
> i
> > nf {
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index fcd3a3fda5f2..ed3a19feebe6 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -915,6 +915,10 @@ [Components]
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> >}
> > +
> >
> ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDyn
> > amicCommand.inf {
> > +
> > +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > +  }
> >
> >
> OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.
> i
> > nf {
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> > index d0ae0b996d66..16ca139b2973 100644
> > --- a/Ov

Re: [edk2-devel] [edk2-platforms PATCH] Maintainers.txt: remove Isaac Oram's email address

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: Wednesday, October 25, 2023 1:36 AM
> To: edk2-devel-groups-io 
> Cc: Abdul Lateef Attar ; Abner Chang
> ; S, Ashraf Ali ; Chiu,
> Chasel ; Dong, Eric ; Gao,
> Liming ; Desimone, Nathaniel L
> ; Nickle Wang ;
> Pedro Falcato ; Chaganty, Rangasai V
> ; Ni, Ray ; Theo Jehl
> 
> Subject: [edk2-devel] [edk2-platforms PATCH] Maintainers.txt: remove
> Isaac Oram's email address
> 
> Email to Isaac's address  bounces ("5.1.0
> Address
> rejected"); remove that address.
> 
> Cc: Abdul Lateef Attar 
> Cc: Abner Chang 
> Cc: Ashraf Ali S 
> Cc: Chasel Chiu 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Cc: Nate DeSimone 
> Cc: Nickle Wang 
> Cc: Pedro Falcato 
> Cc: Rangasai V Chaganty 
> Cc: Ray Ni 
> Cc: Sai Chaganty 
> Cc: Theo Jehl 
> Signed-off-by: Laszlo Ersek 
> ---
>  Maintainers.txt | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3e72f53afa0d..affb2632e0db 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -148,7 +148,6 @@ R: Marvin Häuser 
>  Features/Intel
>  F: Features/Intel/
>  M: Sai Chaganty 
> -M: Isaac Oram 
>  M: Nate DeSimone 
>  R: Liming Gao 
> 
> @@ -159,7 +158,6 @@ R: Liming Gao 
> 
>  Features/Intel/OutOfBandManagement/IpmiFeaturePkg
>  F: Features/Intel/OutOfBandManagement/IpmiFeaturePkg
> -M: Isaac Oram 
>  M: Nate DeSimone 
>  R: Liming Gao 
> 
> @@ -171,14 +169,12 @@ R: Liming Gao 
>  Features/ManageabilityPkg
>  F: Features/ManageabilityPkg/
>  M: Abner Chang 
> -M: Isaac Oram 
>  R: Abdul Lateef Attar 
>  R: Nickle Wang 
> 
>  Platform/Intel
>  F: Platform/Intel/
>  M: Sai Chaganty 
> -M: Isaac Oram 
>  M: Nate DeSimone 
> 
>  Platform/Intel/QuarkPlatformPkg
> @@ -196,7 +192,6 @@ R: Nate DeSimone 
>  Platform/Intel/BoardModulePkg
>  F: Platform/Intel/BoardModulePkg/
>  M: Eric Dong 
> -M: Isaac Oram 
>  R: Liming Gao 
> 
>  Platform/Intel/KabylakeOpenBoardPkg
> @@ -216,7 +211,6 @@ Platform/Intel/MinPlatformPkg
>  F: Platform/Intel/MinPlatformPkg/
>  M: Chasel Chiu 
>  M: Nate DeSimone 
> -M: Isaac Oram 
>  R: Liming Gao 
>  R: Eric Dong 
> 
> @@ -253,7 +247,6 @@ R: Saloni Kasbekar 
> 
>  Platform/Intel/WhitleyOpenBoardPkg
>  F: Platform/Intel/WhitleyOpenBoardPkg/
> -M: Isaac Oram 
>  M: Nate DeSimone 
>  M: Chasel Chiu 
> 
> @@ -279,14 +272,12 @@ M: Daniel Schaefer 
>  Silicon/Intel
>  F: Silicon/Intel/
>  M: Rangasai V Chaganty 
> -M: Isaac Oram 
>  M: Nate DeSimone 
> 
>  Silicon/Intel/IntelSiliconPkg
>  F: Silicon/Intel/IntelSiliconPkg/
>  M: Ray Ni 
>  M: Rangasai V Chaganty 
> -M: Isaac Oram 
>  R: Ashraf Ali S 
> 
>  Silicon/Intel/QuarkSocPkg
> @@ -331,7 +322,6 @@ R: Saloni Kasbekar 
> 
>  Silicon/Intel/WhitleySiliconPkg
>  F: Silicon/Intel/WhitleySiliconPkg/
> -M: Isaac Oram 
>  M: Nate DeSimone 
>  M: Chasel Chiu 
> 
> @@ -377,7 +367,6 @@ R: Meenakshi Aggarwal 
> 
>  QEMU EDK II Minimum Platform Specification implementation
>  F: Platform/Qemu/QemuOpenBoardPkg/
> -M: Isaac Oram 
>  M: Pedro Falcato 
>  R: Theo Jehl 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update

[Michael D Kinney]

Hi Vivian,

I am working on this.  However, I noticed that Patch 6/7 was
missing Signed-off-by tag.  Is that supposed to be the same
as the other 6 patches?

Signed-off-by: Vivian Nowka-Keane 

Thanks,

Mike

> -Original Message-
> From: Vivian Nowka-Keane 
> Sent: Tuesday, October 24, 2023 1:35 PM
> To: devel@edk2.groups.io; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update
> 
> Hi, following up to see if there's any update on this.
> 
> Thanks for your help,
> 
> - Vivian
> 
> On 9/27/2023 12:43 PM, Vivian Nowka-Keane wrote:
> > Hi Mike,
> >
> > Can you help merge this? Looks like it has all of the reviews.
> >
> > Thank you!
> > - Vivian
> >
> > On 9/12/2023 7:42 AM, Michael D Kinney wrote:
> >> Series Reviewed-by: Michael D Kinney
> >>
> >>> -Original Message-
> >>> From:devel@edk2.groups.io    On Behalf Of
> >>> VivianNK
> >>> Sent: Wednesday, August 16, 2023 2:15 PM
> >>> To:devel@edk2.groups.io
> >>> Subject: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update
> >>>
> >>> v1 -> v2:
> >>>   - Update commit message to explain the audit only mode change is
> >>>     temporary to prevent intermediate CI failures.
> >>>   - Format patch Cc's correctly
> >>>
> >>> v1 archive:https://edk2.groups.io/g/devel/message/107665
> >>>
> >>> VivianNK (7):
> >>>    .pytool: Set uncrustify check to audit only (temporary)
> >>>    .pytool: Add cpp support to uncrustify plugin
> >>>    MdeModulePkg: Apply uncrustify formatting to relevant files.
> >>>    MdePkg: Apply uncrustify formatting to relevant files
> >>>    SecurityPkg: Apply uncrustify formatting to relevant files
> >>>    UnitTestFrameworkPkg: Apply uncrustify formatting to relevant
> files
> >>>    .pytool: Undo uncrustify check change
> >>>
> >>>   .pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> >>> |   2 +-
> >>>   .pytool/Plugin/UncrustifyCheck/uncrustify.cfg
> >>> |   4 +-
> >>>
> MdeModulePkg/Library/UefiSortLib/GoogleTest/UefiSortLibGoogleTest.cpp
> >>> |  37 +-
> >>>
> MdeModulePkg/Test/Mock/Include/GoogleTest/Library/MockPciHostBridgeLib
> .h
> >>>
> >>> |   4 +-
> >>>
> >>>
> MdeModulePkg/Test/Mock/Library/GoogleTest/MockPciHostBridgeLib/MockPci
> HostBri
> >>>
> >>> dgeLib.cpp |   8 +-
> >>>
> >>>
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/SafeIntLibUintnIntnUnitT
> ests32.
> >>>
> >>> cpp    | 114 ++--
> >>>
> >>>
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/SafeIntLibUintnIntnUnitT
> ests64.
> >>>
> >>> cpp    | 114 ++--
> >>>
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/TestBaseSafeIntLib.cpp
> >>> | 563 ++--
> >>>   MdePkg/Test/Mock/Include/GoogleTest/Library/MockHobLib.h
> >>> |   6 +-
> >>> MdePkg/Test/Mock/Include/GoogleTest/Library/MockPeiServicesLib.h
> >>> |   6 +-
> >>>   MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiLib.h
> >>> |   4 +-
> >>>
> >>>
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> leLib.h
> >>>
> >>> |   4 +-
> >>> MdePkg/Test/Mock/Library/GoogleTest/MockHobLib/MockHobLib.cpp
> >>> |  40 +-
> >>>
> >>>
> MdePkg/Test/Mock/Library/GoogleTest/MockPeiServicesLib/MockPeiServices
> Lib.cpp
> >>>
> >>> |  52 +-
> >>> MdePkg/Test/Mock/Library/GoogleTest/MockUefiLib/MockUefiLib.cpp
> >>> |   6 +-
> >>>
> >>>
> MdePkg/Test/Mock/Library/GoogleTest/MockUefiRuntimeServicesTableLib/Mo
> ckUefiR
> >>>
> >>> untimeServicesTableLib.cpp |  12 +-
> >>>
> >>>
> SecurityPkg/Library/SecureBootVariableLib/GoogleTest/SecureBootVariabl
> eLibGoo
> >>>
> >>> gleTest.cpp    | 205 ---
> >>>
> >>>
> SecurityPkg/Test/Mock/Include/GoogleTest/Library/MockPlatformPKProtect
> ionLib.
> >>>
> >>> h  |   4 +-
> >>>
> >>>
> SecurityPkg/Test/Mock/Library/GoogleTest/MockPlatformPKProtectionLib/M
> ockPlat
> >>>

Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update

[Michael D Kinney]

I also noticed that the Author was not set correctly on
these patches.  I updated using the same name/email from
your Signed-off-by tag.

Please review your git config to match for future patches.

I have started EDK II CI with the following PR:

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

Thanks,

Mike

> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, October 25, 2023 10:11 AM
> To: Vivian Nowka-Keane ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update
> 
> Hi Vivian,
> 
> I am working on this.  However, I noticed that Patch 6/7 was
> missing Signed-off-by tag.  Is that supposed to be the same
> as the other 6 patches?
> 
> Signed-off-by: Vivian Nowka-Keane 
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Vivian Nowka-Keane 
> > Sent: Tuesday, October 24, 2023 1:35 PM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > 
> > Subject: Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> update
> >
> > Hi, following up to see if there's any update on this.
> >
> > Thanks for your help,
> >
> > - Vivian
> >
> > On 9/27/2023 12:43 PM, Vivian Nowka-Keane wrote:
> > > Hi Mike,
> > >
> > > Can you help merge this? Looks like it has all of the reviews.
> > >
> > > Thank you!
> > > - Vivian
> > >
> > > On 9/12/2023 7:42 AM, Michael D Kinney wrote:
> > >> Series Reviewed-by: Michael D Kinney
> > >>
> > >>> -Original Message-
> > >>> From:devel@edk2.groups.io    On Behalf Of
> > >>> VivianNK
> > >>> Sent: Wednesday, August 16, 2023 2:15 PM
> > >>> To:devel@edk2.groups.io
> > >>> Subject: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> update
> > >>>
> > >>> v1 -> v2:
> > >>>   - Update commit message to explain the audit only mode change
> is
> > >>>     temporary to prevent intermediate CI failures.
> > >>>   - Format patch Cc's correctly
> > >>>
> > >>> v1 archive:https://edk2.groups.io/g/devel/message/107665
> > >>>
> > >>> VivianNK (7):
> > >>>    .pytool: Set uncrustify check to audit only (temporary)
> > >>>    .pytool: Add cpp support to uncrustify plugin
> > >>>    MdeModulePkg: Apply uncrustify formatting to relevant files.
> > >>>    MdePkg: Apply uncrustify formatting to relevant files
> > >>>    SecurityPkg: Apply uncrustify formatting to relevant files
> > >>>    UnitTestFrameworkPkg: Apply uncrustify formatting to relevant
> > files
> > >>>    .pytool: Undo uncrustify check change
> > >>>
> > >>>   .pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> > >>> |   2 +-
> > >>>   .pytool/Plugin/UncrustifyCheck/uncrustify.cfg
> > >>> |   4 +-
> > >>>
> >
> MdeModulePkg/Library/UefiSortLib/GoogleTest/UefiSortLibGoogleTest.cpp
> > >>> |  37 +-
> > >>>
> >
> MdeModulePkg/Test/Mock/Include/GoogleTest/Library/MockPciHostBridgeLib
> > .h
> > >>>
> > >>> |   4 +-
> > >>>
> > >>>
> >
> MdeModulePkg/Test/Mock/Library/GoogleTest/MockPciHostBridgeLib/MockPci
> > HostBri
> > >>>
> > >>> dgeLib.cpp |   8 +-
> > >>>
> > >>>
> >
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/SafeIntLibUintnIntnUnitT
> > ests32.
> > >>>
> > >>> cpp    | 114 ++--
> > >>>
> > >>>
> >
> MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/SafeIntLibUintnIntnUnitT
> > ests64.
> > >>>
> > >>> cpp    | 114 ++--
> > >>>
> > MdePkg/Test/GoogleTest/Library/BaseSafeIntLib/TestBaseSafeIntLib.cpp
> > >>> | 563 ++--
> > >>>   MdePkg/Test/Mock/Include/GoogleTest/Library/MockHobLib.h
> > >>> |   6 +-
> > >>> MdePkg/Test/Mock/Include/GoogleTest/Library/MockPeiServicesLib.h
> > >>> |   6 +-
> > >>>   MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiLib.h
> > >>> |   4 +-
> > >>>
> > >>>
> >
> MdePkg/Test/Mock/Include/GoogleTest/Library/MockUefiRuntimeServicesTab
> > leLib.h
> > >>>
> &

Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update

[Michael D Kinney]

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


> -Original Message-
> From: Vivian Nowka-Keane 
> Sent: Thursday, October 26, 2023 2:08 PM
> To: devel@edk2.groups.io; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest update
> 
> Yes the sign-off is supposed to be the same, thanks for catching that.
> And I'll update my git config for the future!
> 
> The PR looks good
> 
> Thanks,
> - Vivian
> 
> On 10/25/2023 11:08 AM, Michael D Kinney wrote:
> > I also noticed that the Author was not set correctly on
> > these patches.  I updated using the same name/email from
> > your Signed-off-by tag.
> >
> > Please review your git config to match for future patches.
> >
> > I have started EDK II CI with the following PR:
> >
> > https://github.com/tianocore/edk2/pull/4957
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: Kinney, Michael D 
> >> Sent: Wednesday, October 25, 2023 10:11 AM
> >> To: Vivian Nowka-Keane ;
> >> devel@edk2.groups.io
> >> Cc: Kinney, Michael D 
> >> Subject: RE: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> update
> >>
> >> Hi Vivian,
> >>
> >> I am working on this.  However, I noticed that Patch 6/7 was
> >> missing Signed-off-by tag.  Is that supposed to be the same
> >> as the other 6 patches?
> >>
> >> Signed-off-by: Vivian Nowka-Keane 
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: Vivian Nowka-Keane 
> >>> Sent: Tuesday, October 24, 2023 1:35 PM
> >>> To: devel@edk2.groups.io; Kinney, Michael D
> >>> 
> >>> Subject: Re: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> >> update
> >>> Hi, following up to see if there's any update on this.
> >>>
> >>> Thanks for your help,
> >>>
> >>> - Vivian
> >>>
> >>> On 9/27/2023 12:43 PM, Vivian Nowka-Keane wrote:
> >>>> Hi Mike,
> >>>>
> >>>> Can you help merge this? Looks like it has all of the reviews.
> >>>>
> >>>> Thank you!
> >>>> - Vivian
> >>>>
> >>>> On 9/12/2023 7:42 AM, Michael D Kinney wrote:
> >>>>> Series Reviewed-by: Michael D Kinney
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From:devel@edk2.groups.io    On Behalf Of
> >>>>>> VivianNK
> >>>>>> Sent: Wednesday, August 16, 2023 2:15 PM
> >>>>>> To:devel@edk2.groups.io
> >>>>>> Subject: [edk2-devel] [PATCH v2 0/7] Uncrustify GoogleTest
> >> update
> >>>>>> v1 -> v2:
> >>>>>>    - Update commit message to explain the audit only mode
> change
> >> is
> >>>>>>      temporary to prevent intermediate CI failures.
> >>>>>>    - Format patch Cc's correctly
> >>>>>>
> >>>>>> v1 archive:https://edk2.groups.io/g/devel/message/107665
> >>>>>>
> >>>>>> VivianNK (7):
> >>>>>>     .pytool: Set uncrustify check to audit only (temporary)
> >>>>>>     .pytool: Add cpp support to uncrustify plugin
> >>>>>>     MdeModulePkg: Apply uncrustify formatting to relevant
> files.
> >>>>>>     MdePkg: Apply uncrustify formatting to relevant files
> >>>>>>     SecurityPkg: Apply uncrustify formatting to relevant files
> >>>>>>     UnitTestFrameworkPkg: Apply uncrustify formatting to
> relevant
> >>> files
> >>>>>>     .pytool: Undo uncrustify check change
> >>>>>>
> >>>>>>    .pytool/Plugin/UncrustifyCheck/UncrustifyCheck.py
> >>>>>> |   2 +-
> >>>>>>    .pytool/Plugin/UncrustifyCheck/uncrustify.cfg
> >>>>>> |   4 +-
> >>>>>>
> >>
> MdeModulePkg/Library/UefiSortLib/GoogleTest/UefiSortLibGoogleTest.cpp
> >>>>>> |  37 +-
> >>>>>>
> >>
> MdeModulePkg/Test/Mock/Include/GoogleTest/Library/MockPciHostBridgeLib
> >>> .h
> >>>>>> |   4 +-
> >>>>>>
> >>>>>>
> >>
> MdeModule

Re: [edk2-devel] [PATCH] Maintainers.txt: update Gary's email address

[Michael D Kinney]

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


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

[edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Michael D Kinney]

Over the past few months, all the of the Maintainers and
Reviewers listed in Maintainers.txt have been contacted to make
sure Maintainers.txt accurately represents the TianoCore
community members that are actively participating in their
roles.  Based on specific feedback, bounced emails, and no
responses, updates have been made.

* RISCV64: Daniel Schaefer replaced with Andrei Warkentin
* ArmVirtPkg Xen has no remaining reviewers and review
  responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
* ACPI modules related to S3 has no remaining reviewers and
  review responsibility defaults to MdeModulePkg Maintainers/
  Reviewers.
* OVMF CSM modules has no remaining reviewers and review
  responsibility defaults to OvmfPkg Maintainers/Reviewers.
* Bounce: Chan Laura 
* Many smaller updates removing individuals that are no
  longer involved or have replacement coverage.

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Catharine West 
Cc: Dandan Bi 
Cc: Daniel Schaefer 
Cc: David Woodhouse 
Cc: Debkumar De 
Cc: Eric Dong 
Cc: Guomin Jiang 
Cc: Hao A Wu 
Cc: James Bottomley 
Cc: Jian J Wang 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Peter Grehan 
Cc: Qi Zhang 
Cc: Ray Han Lim Ng 
Cc: Stefan Berger 
Cc: Wenxing Hou 
Cc: Xiaoyu Lu 
Signed-off-by: Michael D Kinney 
---
 Maintainers.txt | 53 ++---
 1 file changed, 2 insertions(+), 51 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 3f40cdeb5554..2b03ccbe54aa 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -93,7 +93,7 @@ M: Sami Mujawar  [samimujawar]
 RISCV64
 F: */RiscV64/
 M: Sunil V L  [vlsunil]
-R: Daniel Schaefer  [JohnAZoidberg]
+R: Andrei Warkentin  [andreiw]
 
 LOONGARCH64
 F: */LoongArch64/
@@ -157,16 +157,6 @@ R: Leif Lindholm  [leiflindholm]
 R: Sami Mujawar  [samimujawar]
 R: Gerd Hoffmann  [kraxel]
 
-ArmVirtPkg: modules used on Xen
-F: ArmVirtPkg/ArmVirtXen.*
-F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
-F: ArmVirtPkg/Library/XenVirtMemInfoLib/
-F: ArmVirtPkg/PrePi/
-F: ArmVirtPkg/XenAcpiPlatformDxe/
-F: ArmVirtPkg/XenPlatformHasAcpiDtDxe/
-F: ArmVirtPkg/XenioFdtDxe/
-R: Julien Grall  [jgrall]
-
 BaseTools
 F: BaseTools/
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
@@ -187,8 +177,7 @@ F: CryptoPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
 M: Jiewen Yao  [jyao1]
 M: Yi Li  [liyi77]
-R: Xiaoyu Lu  [xiaoyuxlu]
-R: Guomin Jiang  [guominjia]
+R: Wenxing Hou  [Wenxing-hou]
 
 DynamicTablesPkg
 F: DynamicTablesPkg/
@@ -202,7 +191,6 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
 M: Leif Lindholm  [leiflindholm]
 M: Ard Biesheuvel  [ardbiesheuvel]
 M: Abner Chang  [changab]
-R: Daniel Schaefer  [JohnAZoidberg]
 
 EmulatorPkg
 F: EmulatorPkg/
@@ -228,7 +216,6 @@ F: FmpDevicePkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
 M: Liming Gao  [lgao4]
 M: Michael D Kinney  [mdkinney]
-R: Guomin Jiang  [guominjia]
 R: Wei6 Xu  [xuweiintel]
 
 IntelFsp2Pkg
@@ -237,7 +224,6 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
 M: Chasel Chiu  [ChaselChiu]
 M: Nate DeSimone  [nate-desimone]
 M: Duggapu Chinni B  [cbduggap]
-M: Ray Han Lim Ng  [rayhanlimng]
 R: Star Zeng  [lzeng14]
 R: Ted Kuo  [tedkuo1]
 R: Ashraf Ali S  [AshrafAliS]
@@ -258,7 +244,6 @@ R: Susovan Mohapatra  
[susovanmohapatra]
 MdeModulePkg
 F: MdeModulePkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
-M: Jian J Wang  [jwang36]
 M: Liming Gao  [lgao4]
 
 MdeModulePkg: ACPI modules
@@ -268,15 +253,6 @@ R: Zhiguang Liu  [LiuZhiguang001]
 R: Dandan Bi  [dandanbi]
 R: Liming Gao  [lgao4]
 
-MdeModulePkg: ACPI modules related to S3
-F: MdeModulePkg/*LockBox*/
-F: MdeModulePkg/Include/*BootScript*.h
-F: MdeModulePkg/Include/*LockBox*.h
-F: MdeModulePkg/Include/*S3*.h
-F: MdeModulePkg/Library/*S3*/
-R: Hao A Wu  [hwu25]
-R: Eric Dong  [ydong10]
-
 MdeModulePkg: BDS modules
 F: MdeModulePkg/*BootManager*/
 F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
@@ -326,7 +302,6 @@ F: MdeModulePkg/Library/DxeSecurityManagementLib/
 F: MdeModulePkg/Universal/PCD/
 F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
 F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c
-R: Dandan Bi  [dandanbi]
 R: Liming Gao  [lgao4]
 
 MdeModulePkg: Device and Peripheral modules
@@ -346,12 +321,10 @@ F: MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
 F: MdeModulePkg/Include/Protocol/Ps2Policy.h
 F: MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/
 F: MdeModulePkg/Universal/PcatSingleSegmentPciCfg2Pei/
-R: Hao A Wu  [hwu25]
 R: Ray Ni  [niruiyu]
 
 MdeModulePkg: Disk modules
 F: MdeModulePkg/Universal/Disk/
-R: Hao A Wu  [hwu25]
 R: Ray Ni  [niruiyu]
 R: Zhichao Gao  [ZhichaoGao]
 
@@ -366,7 +339,6 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
 F: MdeModulePkg/Library/FmpAuthenticationLibNull/
 F: MdeModulePkg/Universal/Esrt*/
 R: Liming Gao  [lgao4]
-R: Guomin

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Michael D Kinney]

This is the Wiki page where TianoCore documents the TianoCore community
member roles.

https://github.com/tianocore/tianocore.github.io/wiki/TianoCore-Who-we-are

We can update/edit as needed to accurately reflect what all the Maintainers
and Reviewers agree are their roles and responsibilities as assigned in
Maintainers.txt.

Thanks,

Mike


> -Original Message-
> From: Yao, Jiewen 
> Sent: Sunday, October 29, 2023 9:26 AM
> To: j...@linux.ibm.com; Laszlo Ersek ;
> devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> 
> Cc: Andrew Fish ; Leif Lindholm
> ; Warkentin, Andrei
> ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse
> ; De, Debkumar ; Dong,
> Eric ; Jiang, Guomin ;
> Wu, Hao A ; Wang, Jian J ;
> Justen, Jordan L ; Julien Grall
> ; Peter Grehan ; Zhang, Qi1
> ; Ng, Ray Han Lim ;
> Stefan Berger ; Hou, Wenxing
> ; Lu, Xiaoyu1 
> Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
> 
> OK. Maintainer should do code review. I have no doubt on that.
> 
> My confusion is about "reviewer" role. What is criteria and what is
> responsibility?
> 
> Are you saying that "reviewer" just means that someone raised the hand
> and said: "I want to be notified", and there is no expectation that
> he/she would review the patch?
> 
> I would like to understand more on how that works and what that means.
> Would you please give a URL for the reviewer definition in Linux
> Kernel?
> 
> Thank you
> Yao, Jiewen
> 
> 
> 
> > -Original Message-
> > From: James Bottomley 
> > Sent: Monday, October 30, 2023 12:02 AM
> > To: Yao, Jiewen ; Laszlo Ersek
> ;
> > devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> > 
> > Cc: Andrew Fish ; Leif Lindholm
> ;
> > Warkentin, Andrei ; West, Catharine
> > ; Bi, Dandan ; Daniel
> > Schaefer ; David Woodhouse
> ;
> > De, Debkumar ; Dong, Eric
> ;
> > Jiang, Guomin ; Wu, Hao A
> ;
> > Wang, Jian J ; Justen, Jordan L
> > ; Julien Grall ; Peter
> Grehan
> > ; Zhang, Qi1 ; Ng, Ray Han
> Lim
> > ; Stefan Berger ;
> Hou,
> > Wenxing ; Lu, Xiaoyu1 
> > Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based
> on active
> > community members
> >
> > On Sun, 2023-10-29 at 15:42 +, Yao, Jiewen wrote:
> > > > I'd say that's pretty close. A reviewer role is a request for
> > > > keeping
> > > > the reviewer in the loop.
> > >
> > > [Jiewen] I am disappointed on that.
> > > To me, that is NOT a real reviewer. See below description on what
> is
> > > "code review".
> > > https://google.github.io/eng-practices/review/
> > > https://about.gitlab.com/topics/version-control/what-is-code-
> review/
> >
> > Well, that's what someone's view of what a patch review should
> consist
> > of, not what a reviewer's role in MAINTAINERS should be.
> >
> > In general, you really don't want to force people to review patches,
> > because you'd like a reviewer to be familiar with the area and
> > comfortable with the patch.  So are you saying that anyone listed as
> a
> > reviewer in a particular area should be capable of reviewing any
> patch?
> > and further that they should be expected to review every patch?
> > Because that's definitely not what the R role in the Linux Kernel
> would
> > mean.
> >
> > I know that's not what happened to me in Confidential Computing,
> > because I had a very specific area around SEV and SEV-ES secret
> > injection and really had no familiarity at all with say the memory
> > acceptance patches.
> >
> > > Our definition seems more like *a notification receiver*, instead
> of
> > > a real code reviewer. I would say, it is a very misleading
> > > definition.
> >
> > Actually, I wouldn't, but then I'm more coming from a Linux Kernel
> > background.  To us, the reviewer list is simply a list of people git
> > blame might not find who might have the expertise to review the
> patch
> > but on whom there would be no expectation that they would review the
> > patch.
> >
> > James



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

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Michael D Kinney]

There is a very good discussion here on the roles and responsibility
and potential suggestions for changes to the Wiki page that document
those roles and responsibilities.

May I suggest that someone start a new thread that discusses
the proposed changes to the Wiki page and leave this thread for the
review of the changes to Maintainers.txt?

Thanks,

Mike

> -Original Message-
> From: Yao, Jiewen 
> Sent: Sunday, October 29, 2023 7:54 PM
> To: devel@edk2.groups.io; ler...@redhat.com; pedro.falc...@gmail.com;
> Kinney, Michael D 
> Cc: Andrew Fish ; Leif Lindholm
> ; Warkentin, Andrei
> ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse
> ; De, Debkumar ; Dong,
> Eric ; Jiang, Guomin ;
> Wu, Hao A ; James Bottomley ;
> Wang, Jian J ; Justen, Jordan L
> ; Julien Grall ; Peter
> Grehan ; Zhang, Qi1 ; Ng, Ray
> Han Lim ; Stefan Berger
> ; Hou, Wenxing ; Lu,
> Xiaoyu1 
> Subject: RE: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
> 
> > I'll re-raise my point about relaxing the contribution conditions
> too --
> > given this state, I'd propose a "merge by default" approach, with a
> > reasonable timeout.
> 
> [Jiewen] Yes. I agree this approach.
> A reasonable timeout seems enough to allow people to think and
> feedback.
> 
> 
> 
> Also, I would like to propose another the contribution condition
> relax.
> 
> Currently, our agreed condition to merge is:
> 1) Reviewed-by from Maintainer.
> 2) Acked-by from Maintainer + Reviewed-by from Reviewer
> 
> I propose to change the second condition:
> 2) Acked-by from Maintainer + Reviewed-by from anyone who can be
> trusted by the maintainer.
> 
> 
> That is based upon the current situation - anyone can be a reviewer
> just because they want to be CCed and has no expectation to review the
> code.
> Restricting R-B from a reviewer does not make sense to me.
> 
> Thank you
> Yao, Jiewen
> 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of
> Laszlo Ersek
> > Sent: Sunday, October 29, 2023 9:30 PM
> > To: devel@edk2.groups.io; pedro.falc...@gmail.com; Kinney, Michael D
> > 
> > Cc: Andrew Fish ; Leif Lindholm
> ;
> > Warkentin, Andrei ; West, Catharine
> > ; Bi, Dandan ; Daniel
> > Schaefer ; David Woodhouse
> ;
> > De, Debkumar ; Dong, Eric
> ;
> > Jiang, Guomin ; Wu, Hao A
> ;
> > James Bottomley ; Wang, Jian J
> ;
> > Justen, Jordan L ; Julien Grall
> ;
> > Peter Grehan ; Zhang, Qi1 ;
> Ng,
> > Ray Han Lim ; Stefan Berger
> > ; Hou, Wenxing ; Lu,
> Xiaoyu1
> > 
> > Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based
> on active
> > community members
> >
> > On 10/29/23 03:16, Pedro Falcato wrote:
> > > On Sat, Oct 28, 2023 at 8:23 PM Michael D Kinney
> > >  wrote:
> > >>
> > >> Over the past few months, all the of the Maintainers and
> > >> Reviewers listed in Maintainers.txt have been contacted to make
> > >> sure Maintainers.txt accurately represents the TianoCore
> > >> community members that are actively participating in their
> > >> roles.  Based on specific feedback, bounced emails, and no
> > >> responses, updates have been made.
> > >>
> > >> * RISCV64: Daniel Schaefer replaced with Andrei Warkentin
> > >> * ArmVirtPkg Xen has no remaining reviewers and review
> > >>   responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
> > >> * ACPI modules related to S3 has no remaining reviewers and
> > >>   review responsibility defaults to MdeModulePkg Maintainers/
> > >>   Reviewers.
> > >> * OVMF CSM modules has no remaining reviewers and review
> > >>   responsibility defaults to OvmfPkg Maintainers/Reviewers.
> > >> * Bounce: Chan Laura 
> > >> * Many smaller updates removing individuals that are no
> > >>   longer involved or have replacement coverage.
> > >
> > > Mike,
> > >
> > > Thank you so much for doing this thankless task. Some comments:
> > >
> > >> diff --git a/Maintainers.txt b/Maintainers.txt
> > >> index 3f40cdeb5554..2b03ccbe54aa 100644
> > >> --- a/Maintainers.txt
> > >> +++ b/Maintainers.txt
> > >> @@ -93,7 +93,7 @@ M: Sami Mujawar 
> > [samimujawar]
> > >>  RISCV64
> > >>  F: */RiscV64/
> > >>  M: Sunil V L  [vlsunil]
> > >> -R: Daniel Schaefer  [JohnAZoidberg]
> > 

Re: [edk2-devel] [PATCH v1 1/1] .azurepipelines: Fix Python version (to 3.12)

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Joey Vagedes 
> Sent: Monday, October 30, 2023 9:42 AM
> To: devel@edk2.groups.io
> Cc: Sean Brogan ; Michael Kubacki
> ; Kinney, Michael D
> ; Gao, Liming 
> Subject: [PATCH v1 1/1] .azurepipelines: Fix Python version (to 3.12)
> 
> Upgrades python to 3.12 for build as it has been released and all
> supporting tools have been updated to also support 3.12.
> 
> Cc: Sean Brogan 
> Cc: Michael Kubacki 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Signed-off-by: Joey Vagedes 
> ---
>  .azurepipelines/Ubuntu-PatchCheck.yml  | 2 +-
>  .azurepipelines/templates/defaults.yml | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.azurepipelines/Ubuntu-PatchCheck.yml
> b/.azurepipelines/Ubuntu-PatchCheck.yml
> index 5e79474999b6..a397cf3f4db5 100644
> --- a/.azurepipelines/Ubuntu-PatchCheck.yml
> +++ b/.azurepipelines/Ubuntu-PatchCheck.yml
> @@ -27,7 +27,7 @@ steps:
> 
> 
>  - task: UsePythonVersion@0
> 
>inputs:
> 
> -versionSpec: '3.11'
> 
> +versionSpec: '3.12'
> 
>  architecture: 'x64'
> 
> 
> 
>  - script: |
> 
> diff --git a/.azurepipelines/templates/defaults.yml
> b/.azurepipelines/templates/defaults.yml
> index d50aa3e6d4d0..bc1cd058cc49 100644
> --- a/.azurepipelines/templates/defaults.yml
> +++ b/.azurepipelines/templates/defaults.yml
> @@ -8,5 +8,5 @@
>  ##
> 
> 
> 
>  variables:
> 
> -  default_python_version: "3.11"
> 
> +  default_python_version: "3.12"
> 
>default_linux_image: "ghcr.io/tianocore/containers/fedora-37-
> test:a0dd931"
> 
> --
> 2.34.1



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

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

[Michael D Kinney]

Hi Laszlo,

I do not support orphaned categories and that option should be
removed from Maintainer.txt. One of the motivations to get 
Maintainers.txt updated is to work on the set of tasks related to 
using GitHub PRs for code review.  If a component is orphaned,
then nobody would be assigned to a PR in that area and the PR
would be stuck and would eventually be deleted for no activity.
A terrible experience for a submitter.

If there is a feature for which there is no longer any support,
then I recommend we find a way to remove it from the head of the
repository.  The feature is still available in the history and
in previous releases when it was supported.

If there is a future need for the feature and there are those that
are willing to support it, it can always be resurrected from the
history.

If it is a critical feature that will break the entire project 
if it is removed, then we must find community members that are 
willing to own it.

The immediate backup for this scenario is the EDK II Stewards, but
They may not have the background on the specific feature to maintain
it well.  For example, I am currently helping with the NetworkPkg
because there are no maintainers and I have been recruiting without
success.

I would like the see the SignedCapulePkg removed.  There are a
couple platforms in edk2-platforms that depend on it.  There is
another task to review the actively supported platforms in 
edk2-platforms.  If those platforms are removed, then SignedCapulsePkg
could be safely removed from the head of edk2.

SourceLevelDebugPkg has a similar issues of no maintainers.  The
platforms maintained in edk2 repo do not depend on it to do source
level debug.  It is more of a physical platform debug capability.
Perhaps this feature should be moved to the edk2-platform.  There
was a brief discuss at the UEFI Plugfest to update this debug 
feature because the current one depends on very old tools.

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, October 30, 2023 4:29 AM
> To: Kinney, Michael D ; Yao, Jiewen
> ; devel@edk2.groups.io; pedro.falc...@gmail.com
> Cc: Andrew Fish ; Leif Lindholm
> ; Warkentin, Andrei
> ; West, Catharine
> ; Bi, Dandan ; Daniel
> Schaefer ; David Woodhouse
> ; De, Debkumar ; Dong,
> Eric ; Jiang, Guomin ;
> Wu, Hao A ; James Bottomley ;
> Wang, Jian J ; Justen, Jordan L
> ; Julien Grall ; Peter
> Grehan ; Zhang, Qi1 ; Ng, Ray
> Han Lim ; Stefan Berger
> ; Hou, Wenxing ; Lu,
> Xiaoyu1 
> Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on
> active community members
> 
> On 10/30/23 06:31, Kinney, Michael D wrote:
> > There is a very good discussion here on the roles and responsibility
> > and potential suggestions for changes to the Wiki page that document
> > those roles and responsibilities.
> >
> > May I suggest that someone start a new thread that discusses
> > the proposed changes to the Wiki page and leave this thread for the
> > review of the changes to Maintainers.txt?
> 
> These are connected topics, but yes, back to "Maintainers.txt" -- do
> you
> feel that "S: Orphan" sections are acceptable in general? They're a
> first (AFAICT) for edk2's "Maintainers.txt"; we've always had the
> mechanism documented (since the creation of "Maintainers.txt", or so),
> but we never seem to have put it to use.
> 
> Laszlo



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

Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

[Michael D Kinney]

[cid:image001.png@01DA0B70.D989F270]<https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUklApxtSQNDlGhaCdYgXTdMMPWYYhQ19FT/QIIMQ2VCMoxjdk4xvPAkxTdk02QDNiOzQRc2VAsixLDAVnZCsqxrPh6ybFt207LMh2EURxEHHt5CUNRlV0AIdJnPi51CxcIGXVc0k3bdd33ZBDzJY9T3PS9bBg28IFcND7RfRCpmQnJki/dJIN/Qa8jSLD%2BvQ9rqlQ0aZvsMDMNfbCUM6bqBk6Kb3xk%2BZFmWPQK0wALSI4ZlSFZdlKJo%2BjGNOHT2Mkb4NBe7jeKsOcNkEogpKFe0NnEy1YkFMkzFk0VxUUpB8CoKh1KyvsMukLKR1y/MEHVSdMdhqgCD2dg5WITHsmJhRcfx/YNTOi6rt4SjqTwOGNmbNsQduhimJYtiOK4hMFA2Dn7uQR6pBel65KhqUZTlPNFUu5VKLVbJ5IleUODMcjrtVSHtRmOYkxMtJ4iAA>

Thanks,

Andrew Fish

PS I'm still not 100% sure it is a compiler bug. Some times things like this 
are due to the order the compiler applies the optimizations, and changing the 
order can change the behavior.



On May 19, 2023, at 8:31 AM, Rebecca Cran 
mailto:rebe...@bsdio.com>> wrote:

Just to add more data, I also tried with "volatile sig_atomic_t" as someone 
suggested and both "/volatile:iso" and "/volatile:ms" with no change in results.


--

Rebecca Cran


On 5/18/23 20:53, Ni, Ray wrote:


I think all the options we considered are workarounds. These might break again 
if compiler is "cleverer" in future. Unless some Cxx spec clearly guarantees 
that.

I like Mike's idea to use assembly implementation for CpuDeadLoop. The assembly 
can simply "jmp $" then "ret".

I didn't find a dead-loop intrinsic function in MSVC.

Any better idea?

Thanks,

Ray

*From:* Andrew (EFI) Fish mailto:af...@apple.com>>
*Sent:* Friday, May 19, 2023 8:42 AM
*To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
*Cc:* Ni, Ray mailto:ray...@intel.com>>; Rebecca Cran 
mailto:rebe...@bsdio.com>>
*Subject:* Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

Mike,

Sorry static was just to scope the name to the file since it is a lib, not to 
make it work.

That is a cool site. I learned about it complaining about stuff to the compiler 
team on our internal clang Slack channel as they use it to answer my questions.

Thanks,

Andrew Fish



   On May 18, 2023, at 2:42 PM, Michael D Kinney
   mailto:michael.d.kin...@intel.com>> wrote:

   Using that tool, the following fragment seems to generate the
   right code. Volatile is required.  Static is optional.

   staticvolatileint mDeadLoopCount =0;

   void

   CpuDeadLoop(

   void

 )

   {

   while(mDeadLoopCount ==0);

   }

   GCC

   ===

   CpuDeadLoop():

   .L2:

   moveax,DWORDPTRmDeadLoopCount[rip]

   testeax,eax

   je.L2

   ret

   CLANG

   =

   CpuDeadLoop():# @CpuDeadLoop()

   .LBB0_1:  # =>This Inner Loop Header:Depth=1

   cmpdwordptr[rip+_ZL14mDeadLoopCount],0

   je.LBB0_1

   ret

   Mike

   *From:*Andrew (EFI) Fish mailto:af...@apple.com>>
   *Sent:*Thursday, May 18, 2023 1:45 PM
   *To:*edk2-devel-groups-io 
mailto:devel@edk2.groups.io>>; Andrew Fish
   mailto:af...@apple.com>>
   *Cc:*Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Ni, Ray
   mailto:ray...@intel.com>>; Rebecca Cran 
mailto:rebe...@bsdio.com>>
   *Subject:*Re: [edk2-devel] CpuDeadLoop() is optimized by compiler

   Whoops wrong compiler. Here is an update. I added the flags so
   this one reproduces the issue.

   Compiler Explorer
   
<https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIM6SuADJ4DJgAcj4ARpjEINIADqgKhE4MHt6%2B/qRJKY4CIWGRLDFx0naYDmlCBEzEBBk%2BfgEVVQI1dQSFEdGx8ba19Y1ZLYNdoT0lfZIAlLaoXsTI7BwA9KsA1AAqAJ4JmBs7C8QbaFgbCLGYpBskG7SoTOgbhhuYqqwJ9AB0JhoAgqECBsFABHLx1TAQIEbBg%2BGYbEwAdisAI26I2xEwBEWDFhPg2ACp8SwTABmVH/ZEAEQ4c1onAArLw/BwtKRUJw3NZrCDjstEWYyTxSARNHS5gBrECMjT6TiSFnijmcXgKEBysVsumkOCwJBoFgJOixciUQ3G%2BhxYBcMxcPh0AixdUQKLKqKhOo7Tgiw1sQQAeQYtG92tIWBYhmA4jD%2BCxVQAbph1WH3pUvE6fbwgZgGWHaHgosQvR4sMqCMQ8Cws3MqAZgAoAGp4TAAdwD%2B1ZIv4ghEYnYUhkgkUKnUYd09oMRhQPMs%2BkL6sgc1QCXyDBTAFoA2SNhvI0sEOTqQpJTsDJLMGrc5U1y4GO5PE09MEJsVSnpcqkBMM/PbP2vujfPp7VaNcOiGR8shA682gYcDxiKXo4hAsYfz0BQxkApCJDmBR%2BQHUUsRWHh6SZJUw05DhVAADgANg3WjJA2YBkGQDZbW%2BLgNggblLGsG5cEIO5zGFG4PCNE0ThErgZl4LUtDmCADVQCSrTNCALUkl

Re: [edk2-devel] [PATCH v1 1/1] .github/workflows: Add Stale Check

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Monday, October 30, 2023 6:41 PM
> To: devel@edk2.groups.io
> Cc: Sean Brogan ; Michael Kubacki
> ; Kinney, Michael D
> ; Laszlo Ersek 
> Subject: [PATCH v1 1/1] .github/workflows: Add Stale Check
> 
> From: Michael Kubacki 
> 
> Adds a GitHub workflow that uses the actions/stale GitHub action to
> automatically leave notifications on and close PRs that have had no
> activity for a long time.
> 
> Note: Modifications to a PR reset the staleness counter. This
>   includes pushing to the PR, adding a label to the PR,
>   commenting on the PR, etc.
> 
>   If a PR has been marked "stale", simply leaving a comment will
>   reset the counter.
> 
> Configuration choices:
> 
> 1. Do not attempt to close edk2 GitHub issues.
> 2. Mark edk2 PRs as stale if no activity in the last 60 days. Close
>PRs marked stale if no further activity in 7 days.
> 3. Do not exempt PRs with a "push" label.
> 4. Run the check once daily. Allow manual runs from those that have
>permission to run GitHub workflows.
> 5. Add the label "stale" to the PR when it enters the stale state.
> 
> Rationale:
> 
> 1. We do not use issues often enough. The limited usage of GitHub
>issues in Tianocore org GitHub projects are in another repo not
>impacted by this workflow and expected to track long term tasks.
> 2. This is the default value. In non-edk2 projects, I've seen these
>times work fairly well to identify PRs that have fallen stale.
> 3. Adding a "push" label resets the stale timer. If a PR has had a
>"push" label for 60+ days and has not been fixed for submission,
>then it is has very likely been abandoned.
> 4. This is sufficient to update PRs on the day granularity the
>configuration settings are applied against.
> 5. The label makes it easy to filter stale PRs in the PR list and
>    write automation around PRs that are stale. It's also an obvious
>visual identifier that a PR needs attention in the PR list.
> 
> Cc: Sean Brogan 
> Cc: Michael Kubacki 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> I tested this workflow on my edk2 fork:
> 
> https://github.com/makubacki/edk2/actions/runs/6700887619
> 
> Here's an example of a PR it did not mark stale there:
> 
> https://github.com/makubacki/edk2/pull/136
> 
> Here's an example of a PR it did mark stale there:
> 
> https://github.com/makubacki/edk2/pull/4
> 
>  .github/workflows/stale.yml | 44 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
> new file mode 100644
> index ..b9160b548ab3
> --- /dev/null
> +++ b/.github/workflows/stale.yml
> @@ -0,0 +1,44 @@
> +# This workflow warns and then closes issues and PRs that have had no
> activity
> +# for a specified amount of time.
> +#
> +# For more information, see:
> +# https://github.com/actions/stale
> +#
> +# Copyright (c) Microsoft Corporation.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +
> +name: Stale Check
> +
> +on:
> +  schedule:
> +# At 23:35 on every day-of-week from Sunday through Saturday
> +# https://crontab.guru/#35_23_*_*_0-6
> +- cron: '35 23 * * 0-6'
> +  workflow_dispatch:
> +
> +jobs:
> +  stale:
> +name: Stale
> +runs-on: ubuntu-latest
> +permissions:
> +  issues: write
> +  pull-requests: write
> +
> +steps:
> +- name: Check for Stale Items
> +  uses: actions/stale@v8
> +  with:
> +days-before-issue-close: -1
> +days-before-issue-stale: -1
> +days-before-pr-stale: 60
> +days-before-pr-close: 7
> +stale-pr-message: >
> +  This PR has been automatically marked as stale because it
> has not had
> +  activity in 60 days. It will be closed if no further
> activity occurs within
> +  7 days. Thank you for your contributions.
> +close-pr-message: >
> +  This pull request has been automatically been closed
> because it did not have any
> +  activity in 60 days and no follow up within 7 days after
> being marked stale.
> +  Thank you for your contributions.
> +stale-pr-label: stale
> --
> 2.42.0.windows.2



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