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] MdePkg: Update ReceiveData and SendData function description

[Michael D Kinney]

, in 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] 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]
-=-=-=-=-=-=-=-=-=-=-=-

[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] [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]
-=-=-=-=-=-=-=-=-=-=-=-

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] 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] 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 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 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]
-=-=-=-=-=-=-=-=-=-=-=-

[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 (, 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 (, 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 ();
+  MemoryTypeInformationResourceHob = NULL;
+  GuidHob  = GetFirstGuidHob 
();
   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 (, EfiMemoryTypeInformation, DataSize);
+
+  //
+  // Look

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]
-=-=-=-=-=-=-=-=-=-=-=-

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]
-=-=-=-=-=-=-=-=-=-=-=-

[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 (, 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 (, 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 ();
   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 (, EfiMemoryTypeInformation, DataSize);
+
+  //
+  // Look for Resource Descriptor HOB with a ResourceType of System Memory

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

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: 

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 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 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 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] 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] 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),
> );
> 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] 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, );
> >
> >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, );
> >
> >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, );
> >
> >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] [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]

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, );
> 
>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, );
> 
>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, );
> 
>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 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] 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)
> +

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 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 (
> + ,
> + NULL,
> + (VOID **)
> + );
> +  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] 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 

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] 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] 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),
+   >Policy
+   );
 
Here we're assuming IfrFormNvData->DhcpEnable is TRUE. Should we check it

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

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 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 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] 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 believer in "play stupid games, win

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

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] [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] 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]
-=-=-=-=-=-=-=-=-=-=-=-

[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] [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]
-=-=-=-=-=-=-=-=-=-=-=-

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] [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 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 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] [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 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] [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 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 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 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] 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 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] [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]
-=-=-=-=-=-=-=-=-=-=-=-

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

Re: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google Test components with multiple files

[Michael D Kinney]

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



> -Original Message-
> From: Kinney, Michael D 
> Sent: Saturday, December 2, 2023 4:34 PM
> To: Pedro Falcato ; devel@edk2.groups.io
> Cc: mikub...@linux.microsoft.com; Sean Brogan ;
> Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google Test
> components with multiple files
> 
> Hi Pedro,
> 
> I have reviewed the use of /NODEFAULTLIB.
> 
> It is correct for this flag to be used for FW components
> to prevent standard application libs from being linked.
> 
> For any component that links as a Windows application, this
> flag should not be used.  This applies to host based unit
> tests and to the EmulatorPkg/Host/Win.  I have verified that
> /NODEFAULTLIB can be removed from both of these use cases
> and only use /NODEFAULTLIB for FW components.
> 
> With /NODEFAULTLIB removed from UnitTestFrameworkPkgHost.dsc.inc
> This series is:
> 
> Reviewed-by: Michael D Kinney 
> 
> I have taken the branch from Michael Kubacki and added this
> one change to run through EDK II CI and added by Rb tags.
> 
> https://github.com/tianocore/edk2/pull/5098
> 
> Best regards,
> 
> Mike
> 
> 
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Friday, December 1, 2023 1:29 PM
> > To: Pedro Falcato ; devel@edk2.groups.io
> > Cc: mikub...@linux.microsoft.com; Sean Brogan
> ;
> > Kinney, Michael D 
> > Subject: RE: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google
> Test
> > components with multiple files
> >
> > Hi Pedro,
> >
> > Thanks for the follow up and debug.
> >
> > I suspect some of those flags were inherited from
> > EmulatorPkg builds and may not apply to GoogeTest
> > builds.
> >
> > I will investigate.
> >
> > Very happy to see a solution for this issue.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Pedro Falcato 
> > > Sent: Friday, December 1, 2023 12:53 PM
> > > To: devel@edk2.groups.io; pedro.falc...@gmail.com
> > > Cc: mikub...@linux.microsoft.com; Kinney, Michael D
> > > ; Sean Brogan 
> > > Subject: Re: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google
> > Test
> > > components with multiple files
> > >
> > > On Fri, Dec 1, 2023 at 8:50 PM Pedro Falcato via groups.io
> > >  wrote:
> > > >
> > > > On Fri, Dec 1, 2023 at 5:07 PM Michael Kubacki
> > > >  wrote:
> > > > >
> > > > > Hi Pedro,
> > > > >
> > > > > Visual Studio NOOPT builds result in linker errors. I combined your
> > > > > patch series with the test instruction change in this PR -
> > > > > https://github.com/tianocore/edk2/pull/5096.
> > > > >
> > > > > You can use a PR to test the VS build.
> > > >
> > > > Thanks for the heads up, but I ended up booting Windows to expedite
> the
> > > process.
> > > >
> > > > So, I noticed from the build logs that libcmtd.lib was having issues
> > > > doing a /WHOLEARCHIVE link (not unheard of, had the same problems
> with
> > > > Linux system libraries). Then I noticed in MSDN:
> > > > "The /WHOLEARCHIVE option forces the linker to include every object
> > > > file from either a specified static library, or if no library is
> > > > specified, from all static libraries specified to the LINK command"
> > > > Note the "from all static libraries specified to the LINK command".
> So
> > > > I noticed libcmtd.lib was being specified manually, and I simply
> > > > deleted
> > > >
> > > > /NODEFAULTLIB:libcmt.lib libcmtd.lib
> > >
> > > ... Forgot to mention that deleting this line allows the link to
> > > complete and /WHOLEARCHIVE has the intended effect.
> > >
> > > --
> > > Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111994): https://edk2.groups.io/g/devel/message/111994
Mute This Topic: https://groups.io/mt/102904623/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] EmulatorPkg/Win/Host: Remove /NODEFAULTLIB in WinHost.inf

[Michael D Kinney]

Update WinHost.inf to remove /NODEFAULTLIB option from DLINK_FLAGS.
WinHost builds a Windows application that depends on the compiler
default libraries. By removing /NODEFAULTLIB, fewer libraries
have to be specified on the link command line.

DLINK_FLAGS and CC_FLAGS reorganized to consolidate options
common to IA32/X64.

-Wno-microsoft-static-assert  added to CLANGPDB CC_FLAGS to
address warnings.

Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Pedro Falcato 
Signed-off-by: Michael D Kinney 
---
 EmulatorPkg/Win/Host/WinHost.inf | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.inf b/EmulatorPkg/Win/Host/WinHost.inf
index 4dac6e033e64..dbc6bfffc522 100644
--- a/EmulatorPkg/Win/Host/WinHost.inf
+++ b/EmulatorPkg/Win/Host/WinHost.inf
@@ -86,26 +86,32 @@ [Pcd]
   gEmulatorPkgTokenSpaceGuid.PcdEmuNetworkInterface|L"0"
 
 [BuildOptions]
-  MSFT:*_*_*_DLINK_FLAGS== /out:"$(BIN_DIR)\$(BASE_NAME).exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
+  MSFT:*_*_*_DLINK_FLAGS== /out:"$(BIN_DIR)\$(BASE_NAME).exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb" MSVCRTD.lib Gdi32.lib 
User32.lib Winmm.lib Advapi32.lib /NOLOGO /SUBSYSTEM:CONSOLE /IGNORE:4086 /MAP 
/OPT:REF /DEBUG /LTCG
+  MSFT:*_*_IA32_DLINK_FLAGS  = /MACHINE:I386
+  MSFT:*_*_X64_DLINK_FLAGS   = /MACHINE:AMD64
   MSFT:*_*_*_CC_FLAGS= /nologo /W4 /WX /Gy /c /D UNICODE /Od 
/Oy- /FIAutoGen.h /EHs-c- /GF /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
   MSFT:*_*_*_PP_FLAGS   == /nologo /E /TC /FIAutoGen.h
 
-  MSFT:*_VS2015_IA32_DLINK_FLAGS = /LIBPATH:"%VS2015_PREFIX%Lib" 
/LIBPATH:"%VS2015_PREFIX%VC\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib 
Advapi32.lib vcruntimed.lib ucrtd.lib
-  MSFT:*_VS2015x86_IA32_DLINK_FLAGS  = /LIBPATH:"%VS2015_PREFIX%Lib" 
/LIBPATH:"%VS2015_PREFIX%VC\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib 
Advapi32.lib vcruntimed.lib ucrtd.lib
-  MSFT:*_VS2017_IA32_DLINK_FLAGS = /LIBPATH:"%VCToolsInstallDir%lib\x86" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib 
User32.lib Winmm.lib Advapi32.lib
-  MSFT:*_VS2019_IA32_DLINK_FLAGS = /LIBPATH:"%VCToolsInstallDir%lib\x86" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib Gdi32.lib 
User32.lib Winmm.lib Advapi32.lib
+  MSFT:*_VS2015_IA32_DLINK_FLAGS = /LIBPATH:"%VS2015_PREFIX%Lib" 
/LIBPATH:"%VS2015_PREFIX%VC\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
+  MSFT:*_VS2015x86_IA32_DLINK_FLAGS  = /LIBPATH:"%VS2015_PREFIX%Lib" 
/LIBPATH:"%VS2015_PREFIX%VC\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
+  MSFT:*_VS2017_IA32_DLINK_FLAGS = /LIBPATH:"%VCToolsInstallDir%lib\x86" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
+  MSFT:*_VS2019_IA32_DLINK_FLAGS = /LIBPATH:"%VCToolsInstallDir%lib\x86" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
   MSFT:*_*_IA32_ASM_FLAGS   == /nologo /W3 /WX /c /coff /Cx /Zd /W0 /Zi
   MSFT:*_*_IA32_ASMLINK_FLAGS   == /link /nologo /tiny
 
-  MSFT:*_VS2015_X64_DLINK_FLAGS  = /LIBPATH:"%VS2015_PREFIX%VC\Lib\AMD64" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x64" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:AMD64 /LTCG Kernel32.lib MSVCRTD.lib vcruntimed.lib ucrtd.lib 
Gdi32.lib User32.lib Winmm.lib Advapi32.lib
-  MSFT:

Re: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google Test components with multiple files

[Michael D Kinney]

Hi Pedro,

I have reviewed the use of /NODEFAULTLIB.

It is correct for this flag to be used for FW components
to prevent standard application libs from being linked.

For any component that links as a Windows application, this
flag should not be used.  This applies to host based unit 
tests and to the EmulatorPkg/Host/Win.  I have verified that
/NODEFAULTLIB can be removed from both of these use cases
and only use /NODEFAULTLIB for FW components.

With /NODEFAULTLIB removed from UnitTestFrameworkPkgHost.dsc.inc
This series is:

Reviewed-by: Michael D Kinney 

I have taken the branch from Michael Kubacki and added this
one change to run through EDK II CI and added by Rb tags.

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

Best regards,

Mike



> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, December 1, 2023 1:29 PM
> To: Pedro Falcato ; devel@edk2.groups.io
> Cc: mikub...@linux.microsoft.com; Sean Brogan ;
> Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google Test
> components with multiple files
> 
> Hi Pedro,
> 
> Thanks for the follow up and debug.
> 
> I suspect some of those flags were inherited from
> EmulatorPkg builds and may not apply to GoogeTest
> builds.
> 
> I will investigate.
> 
> Very happy to see a solution for this issue.
> 
> Mike
> 
> > -Original Message-
> > From: Pedro Falcato 
> > Sent: Friday, December 1, 2023 12:53 PM
> > To: devel@edk2.groups.io; pedro.falc...@gmail.com
> > Cc: mikub...@linux.microsoft.com; Kinney, Michael D
> > ; Sean Brogan 
> > Subject: Re: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google
> Test
> > components with multiple files
> >
> > On Fri, Dec 1, 2023 at 8:50 PM Pedro Falcato via groups.io
> >  wrote:
> > >
> > > On Fri, Dec 1, 2023 at 5:07 PM Michael Kubacki
> > >  wrote:
> > > >
> > > > Hi Pedro,
> > > >
> > > > Visual Studio NOOPT builds result in linker errors. I combined your
> > > > patch series with the test instruction change in this PR -
> > > > https://github.com/tianocore/edk2/pull/5096.
> > > >
> > > > You can use a PR to test the VS build.
> > >
> > > Thanks for the heads up, but I ended up booting Windows to expedite the
> > process.
> > >
> > > So, I noticed from the build logs that libcmtd.lib was having issues
> > > doing a /WHOLEARCHIVE link (not unheard of, had the same problems with
> > > Linux system libraries). Then I noticed in MSDN:
> > > "The /WHOLEARCHIVE option forces the linker to include every object
> > > file from either a specified static library, or if no library is
> > > specified, from all static libraries specified to the LINK command"
> > > Note the "from all static libraries specified to the LINK command". So
> > > I noticed libcmtd.lib was being specified manually, and I simply
> > > deleted
> > >
> > > /NODEFAULTLIB:libcmt.lib libcmtd.lib
> >
> > ... Forgot to mention that deleting this line allows the link to
> > complete and /WHOLEARCHIVE has the intended effect.
> >
> > --
> > Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111992): https://edk2.groups.io/g/devel/message/111992
Mute This Topic: https://groups.io/mt/102904623/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] UnitTestFrameworkPkg: Fix Google Test components with multiple files

[Michael D Kinney]

Hi Pedro,

Thanks for the follow up and debug.

I suspect some of those flags were inherited from
EmulatorPkg builds and may not apply to GoogeTest
builds.  

I will investigate.

Very happy to see a solution for this issue.

Mike

> -Original Message-
> From: Pedro Falcato 
> Sent: Friday, December 1, 2023 12:53 PM
> To: devel@edk2.groups.io; pedro.falc...@gmail.com
> Cc: mikub...@linux.microsoft.com; Kinney, Michael D
> ; Sean Brogan 
> Subject: Re: [edk2-devel] [PATCH 1/2] UnitTestFrameworkPkg: Fix Google Test
> components with multiple files
> 
> On Fri, Dec 1, 2023 at 8:50 PM Pedro Falcato via groups.io
>  wrote:
> >
> > On Fri, Dec 1, 2023 at 5:07 PM Michael Kubacki
> >  wrote:
> > >
> > > Hi Pedro,
> > >
> > > Visual Studio NOOPT builds result in linker errors. I combined your
> > > patch series with the test instruction change in this PR -
> > > https://github.com/tianocore/edk2/pull/5096.
> > >
> > > You can use a PR to test the VS build.
> >
> > Thanks for the heads up, but I ended up booting Windows to expedite the
> process.
> >
> > So, I noticed from the build logs that libcmtd.lib was having issues
> > doing a /WHOLEARCHIVE link (not unheard of, had the same problems with
> > Linux system libraries). Then I noticed in MSDN:
> > "The /WHOLEARCHIVE option forces the linker to include every object
> > file from either a specified static library, or if no library is
> > specified, from all static libraries specified to the LINK command"
> > Note the "from all static libraries specified to the LINK command". So
> > I noticed libcmtd.lib was being specified manually, and I simply
> > deleted
> >
> > /NODEFAULTLIB:libcmt.lib libcmtd.lib
> 
> ... Forgot to mention that deleting this line allows the link to
> complete and /WHOLEARCHIVE has the intended effect.
> 
> --
> Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111988): https://edk2.groups.io/g/devel/message/111988
Mute This Topic: https://groups.io/mt/102904623/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] PcAtChipsetPkg: Fix AcpiTimerLib incompatibility with XhciDxe

[Michael D Kinney]

Hi Ray,

'static' is allowed and actually preferred for module globals 
that start with 'm' that are scoped to a single C file.

Globals that start with 'g' that need to be access by multiple
C files can not be static.

Since 'm' globals could be changed to 'g' globals due to
maintenance, we want to avoid symbol collisions between
'g' globals.  Prefixing all globals with a module name helps
prevent symbol collisions.

Summary

* Use lower case 'static'
* Use 'static' for 'm' globals
* Do not use 'static' for 'g' globals
* Add module/lib specific prefix to 'm' and 'g' global

Mike

> -Original Message-
> From: Ni, Ray 
> Sent: Thursday, November 30, 2023 7:13 PM
> To: Desimone, Nathaniel L ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH v1] PcAtChipsetPkg: Fix AcpiTimerLib incompatibility
> with XhciDxe
> 
> Mike,
> Does today's EDK2 C coding style spec allow using "STATIC" for global
> variables?
> Or lower case "static"?
> Or changing the variable to a name with lib name prefix, e.g.: "
> mTimerLibPerformanceCounterFrequency"?
> 
> 
> Thanks,
> Ray
> > -Original Message-
> > From: Desimone, Nathaniel L 
> > Sent: Friday, December 1, 2023 9:56 AM
> > To: devel@edk2.groups.io
> > Cc: Ni, Ray ; Kinney, Michael D
> > 
> > Subject: [PATCH v1] PcAtChipsetPkg: Fix AcpiTimerLib incompatibility with
> > XhciDxe
> >
> > The DXE & MM standalone variant of AcpiTimerLib defines a global
> > named mPerformanceCounterFrequency. A global with an identical
> > name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> >
> > Since XhciDxe has a dependency on TimerLib, this can cause link
> > errors due to the same symbol being defined twice if the platform
> > DSC chooses to use AcpiTimerLib as the TimerLib implementation for
> > any given platform.
> >
> > To resolve this, I have changed made the definition of
> > mPerformanceCounterFrequency to STATIC. Since this variable is not
> > used outside of the DxeStandaloneMmAcpiTimerLib.c compilation unit,
> > there is no reason to have it exported as a global.
> >
> > Cc: Ray Ni 
> > Cc: Michael D Kinney 
> > Signed-off-by: Nate DeSimone 
> > ---
> >  .../Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c| 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> > b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> > index 16ac48938f..41d2af7d55 100644
> > --- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> > +++
> > b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >ACPI Timer implements one instance of Timer Library.
> >
> > -  Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2013 - 2023, Intel Corporation. All rights reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -51,7 +51,7 @@ InternalCalculateTscFrequency (
> >  //
> >  // Cached performance counter frequency
> >  //
> > -UINT64  mPerformanceCounterFrequency = 0;
> > +STATIC UINT64 mPerformanceCounterFrequency = 0;
> >
> >  /**
> >Internal function to retrieves the 64-bit frequency in Hz.
> > --
> > 2.39.2.windows.1



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

Re: [edk2-devel] [edk2-platforms][PATCH v1] QuarkPlatformPkg: Fix DxeCore Build Failures

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Desimone, Nathaniel L 
> Sent: Thursday, November 30, 2023 4:18 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Ni, Ray ;
> Chaganty, Rangasai V ; Gao, Liming
> ; Kinney, Michael D ;
> Kelly Steele ; Taylor Beebe
> ; Kubacki, Michael
> 
> Subject: [edk2-platforms][PATCH v1] QuarkPlatformPkg: Fix DxeCore Build
> Failures
> 
> Commit 7284c44 in edk2 introduces an incompatibility that causes any
> project that uses DxeMain.inf to fail to build. This is due to the
> addition of ImagePropertiesRecordLib, and a new added dependency on
> that library in DxeMain. Platforms will not have this LibraryClass
> defined in their DSC yet and hence currently fail to build.
> 
> This changes addes ImagePropertiesRecordLib to QuarkPlatformPkg
> and resolves the build failure.
> 
> Cc: Chasel Chiu 
> Cc: Ray Ni 
> Cc: Sai Chaganty 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Cc: Taylor Beebe 
> Cc: Michael Kubacki 
> Signed-off-by: Nate DeSimone 
> ---
>  Platform/Intel/QuarkPlatformPkg/Quark.dsc| 1 +
>  Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> b/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> index 7cc548058a..40d9768336 100644
> --- a/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> +++ b/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> @@ -196,6 +196,7 @@
>  !endif
> 
>FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/Imag
> ePropertiesRecordLib.inf
> 
>#
># CPU
> diff --git a/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> b/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> index 59577eda4f..67472930c9 100644
> --- a/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> +++ b/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> @@ -167,6 +167,7 @@
>  !endif
> 
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/Imag
> ePropertiesRecordLib.inf
> 
>#
># CPU
> --
> 2.39.2.windows.1



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

Re: [edk2-devel] [edk2-platforms][PATCH v1] Vlv2TbltDevicePkg: Fix DxeCore Build Failures

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Desimone, Nathaniel L 
> Sent: Thursday, November 30, 2023 4:18 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Ni, Ray ;
> Chaganty, Rangasai V ; Gao, Liming
> ; Kinney, Michael D ;
> Sun, Zailiang ; Qian, Yi ;
> Taylor Beebe ; Kubacki, Michael
> 
> Subject: [edk2-platforms][PATCH v1] Vlv2TbltDevicePkg: Fix DxeCore Build
> Failures
> 
> Commit 7284c44 in edk2 introduces an incompatibility that causes any
> project that uses DxeMain.inf to fail to build. This is due to the
> addition of ImagePropertiesRecordLib, and a new added dependency on
> that library in DxeMain. Platforms will not have this LibraryClass
> defined in their DSC yet and hence currently fail to build.
> 
> This changes addes ImagePropertiesRecordLib to Vlv2TbltDevicePkg
> and resolves the build failure.
> 
> Cc: Chasel Chiu 
> Cc: Ray Ni 
> Cc: Sai Chaganty 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Zailiang Sun 
> Cc: Yi Qian 
> Cc: Taylor Beebe 
> Cc: Michael Kubacki 
> Signed-off-by: Nate DeSimone 
> ---
>  Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 +
>  Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> index 4adbaa6966..0c66705377 100644
> --- a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> +++ b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
> @@ -209,6 +209,7 @@
> 
> PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoff
> ExtraActionLibNull.inf
> 
> DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
>  !endif
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/Imag
> ePropertiesRecordLib.inf
> 
>#
># CryptLib
> diff --git a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> index c7d9733dad..0689f275f1 100644
> --- a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> +++ b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
> @@ -211,6 +211,7 @@
> 
> PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoff
> ExtraActionLibNull.inf
> 
> DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
>  !endif
> +
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/Imag
> ePropertiesRecordLib.inf
> 
>#
># CryptLib
> --
> 2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111953): https://edk2.groups.io/g/devel/message/111953
Mute This Topic: https://groups.io/mt/102906247/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/Test: Add google tests for BaseLib

[Michael D Kinney]

Hi Pedro,

I agree that silent failures are terrible.

The issue is documented with the requirement to use #include here:

https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg#googletest-configuration

Unit tests are built with their own DSC configuration extensions.  Does adding
--whole-archive to the GCC SLINK settings of the following file resolve the 
issue?

https://github.com/tianocore/edk2/blob/master/UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc

Mike

> -Original Message-
> From: Pedro Falcato 
> Sent: Thursday, November 30, 2023 12:16 PM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Savva Mitrofanov ; Gao, Liming
> ; Liu, Zhiguang 
> Subject: Re: [edk2-devel] [PATCH 2/2] MdePkg/Test: Add google tests for
> BaseLib
> 
> On Thu, Nov 30, 2023 at 7:32 PM Michael D Kinney
>  wrote:
> >
> > With one comment below addressed
> >
> > Reviewed-by: Michael D Kinney 
> >
> > > -Original Message-
> > > From: Pedro Falcato 
> > > Sent: Wednesday, November 29, 2023 6:46 PM
> > > To: devel@edk2.groups.io
> > > Cc: Savva Mitrofanov ; Pedro Falcato
> > > ; Gao, Liming ;
> Kinney,
> > > Michael D ; Liu, Zhiguang
> > > 
> > > Subject: [PATCH 2/2] MdePkg/Test: Add google tests for BaseLib
> > >
> > > Add GoogleTestBaseLib, which contains gtest unit tests for BaseLib.
> > > For now, only add checksum tests for CRC32C and CRC16; these tests
> check
> > > for correctness on various inputs using precomputed hashes.
> > >
> > > Signed-off-by: Pedro Falcato 
> > > Cc: Liming Gao 
> > > Cc: Michael D Kinney 
> > > Cc: Zhiguang Liu 
> > > ---
> > >  .../Library/BaseLib/GoogleTestBaseLib.inf | 31 +
> > >  .../Library/BaseLib/TestBaseLibMain.cpp   | 23 +++
> > >  .../Library/BaseLib/TestCheckSum.cpp  | 64 +++
> > >  .../SafeIntLibUintnIntnUnitTests64.cpp|  4 +-
> > >  MdePkg/Test/MdePkgHostTest.dsc|  5 ++
> > >  5 files changed, 125 insertions(+), 2 deletions(-)
> > >  create mode 100644
> > > MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> > >  create mode 100644
> > > MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> > >  create mode 100644
> > > MdePkg/Test/GoogleTest/Library/BaseLib/TestCheckSum.cpp
> > >
> > > diff --git
> a/MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> > > b/MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> > > new file mode 100644
> > > index ..c859e5f86b9e
> > > --- /dev/null
> > > +++ b/MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> > > @@ -0,0 +1,31 @@
> > > +## @file
> > > +# Host OS based Application that unit tests BaseLib using Google Test
> > > +#
> > > +# Copyright (c) 2023, Pedro Falcato. All rights reserved.
> > > +# SPDX-License-Identifier: BSD-2-Clause-Patent
> > > +##
> > > +
> > > +[Defines]
> > > +  INF_VERSION = 0x00010005
> > > +  BASE_NAME   = GoogleTestBaseLib
> > > +  FILE_GUID   = 34D8CBBA-2442-455F-8454-5B06B12A8B62
> > > +  MODULE_TYPE = HOST_APPLICATION
> > > +  VERSION_STRING  = 1.0
> > > +
> > > +#
> > > +# The following information is for reference only and not required by
> the
> > > build tools.
> > > +#
> > > +#  VALID_ARCHITECTURES   = IA32 X64
> > > +#
> > > +
> > > +[Sources]
> > > +  TestCheckSum.cpp
> > > +  TestBaseLibMain.cpp
> > > +
> > > +[Packages]
> > > +  MdePkg/MdePkg.dec
> > > +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> > > +
> > > +[LibraryClasses]
> > > +  GoogleTestLib
> > > +  BaseLib
> > > diff --git a/MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> > > b/MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> > > new file mode 100644
> > > index ..1a9941492be6
> > > --- /dev/null
> > > +++ b/MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> > > @@ -0,0 +1,23 @@
> > > +/** @file
> > > +  Main routine for BaseLib google tests.
> > > +
> > > +  Copyright (c) 2023 Pedro Falcato. All rights reserved
> > > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > > +**/
> > > +
> > > +#include 
> > > +
> > > +// Note: Until we can --whole-ar

Re: [edk2-devel] [PATCH 1/2] MdePkg/BaseLib: Fix CRC16-ANSI calculation

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Pedro Falcato 
> Sent: Wednesday, November 29, 2023 6:46 PM
> To: devel@edk2.groups.io
> Cc: Savva Mitrofanov ; Pedro Falcato
> ; Gao, Liming ; Kinney,
> Michael D ; Liu, Zhiguang
> 
> Subject: [PATCH 1/2] MdePkg/BaseLib: Fix CRC16-ANSI calculation
> 
> The current CalculateCrc16Ansi implementation does the following:
> 1) Invert the passed checksum
> 2) Calculate the new checksum by going through data and using the
>lookup table
> 3) Invert it back again
> 
> This emulated my design for CalculateCrc32c, where 0 is
> passed as the initial checksum, and it inverts in the end.
> However, CRC16 does not invert the checksum on input and output.
> So this is incorrect.
> 
> Fix the problem by not inverting input checksums nor output checksums.
> Callers should now pass CRC16ANSI_INIT as the initial value instead of
> "0". This is a breaking change.
> 
> This problem was found out-of-list when older ext4 filesystems
> (that use crc16 checksums) failed to mount with "corruption".
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4609
> Signed-off-by: Pedro Falcato 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Zhiguang Liu 
> ---
>  MdePkg/Include/Library/BaseLib.h  | 5 +
>  MdePkg/Library/BaseLib/CheckSum.c | 4 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 5d7067ee854e..728e89d2bf44 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -4599,6 +4599,11 @@ CalculateCrc16Ansi (
>IN  UINT16  InitialValue
>);
> 
> +//
> +// Initial value for the CRC16-ANSI algorithm, when no prior checksum has
> been calculated.
> +//
> +#define CRC16ANSI_INIT  0x
> +
>  /**
> Calculates the CRC32c checksum of the given buffer.
> 
> diff --git a/MdePkg/Library/BaseLib/CheckSum.c
> b/MdePkg/Library/BaseLib/CheckSum.c
> index b6a076573191..57d324c82b22 100644
> --- a/MdePkg/Library/BaseLib/CheckSum.c
> +++ b/MdePkg/Library/BaseLib/CheckSum.c
> @@ -678,13 +678,13 @@ CalculateCrc16Ansi (
> 
>Buf = Buffer;
> 
> -  Crc = ~InitialValue;
> +  Crc = InitialValue;
> 
>while (Length-- != 0) {
>  Crc = mCrc16LookupTable[(Crc & 0xFF) ^ *(Buf++)] ^ (Crc >> 8);
>}
> 
> -  return ~Crc;
> +  return Crc;
>  }
> 
>  GLOBAL_REMOVE_IF_UNREFERENCED STATIC CONST UINT32  mCrc32cLookupTable[256]
> = {
> --
> 2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111912): https://edk2.groups.io/g/devel/message/111912
Mute This Topic: https://groups.io/mt/102886793/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/Test: Add google tests for BaseLib

[Michael D Kinney]

With one comment below addressed

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Pedro Falcato 
> Sent: Wednesday, November 29, 2023 6:46 PM
> To: devel@edk2.groups.io
> Cc: Savva Mitrofanov ; Pedro Falcato
> ; Gao, Liming ; Kinney,
> Michael D ; Liu, Zhiguang
> 
> Subject: [PATCH 2/2] MdePkg/Test: Add google tests for BaseLib
> 
> Add GoogleTestBaseLib, which contains gtest unit tests for BaseLib.
> For now, only add checksum tests for CRC32C and CRC16; these tests check
> for correctness on various inputs using precomputed hashes.
> 
> Signed-off-by: Pedro Falcato 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Zhiguang Liu 
> ---
>  .../Library/BaseLib/GoogleTestBaseLib.inf | 31 +
>  .../Library/BaseLib/TestBaseLibMain.cpp   | 23 +++
>  .../Library/BaseLib/TestCheckSum.cpp  | 64 +++
>  .../SafeIntLibUintnIntnUnitTests64.cpp|  4 +-
>  MdePkg/Test/MdePkgHostTest.dsc|  5 ++
>  5 files changed, 125 insertions(+), 2 deletions(-)
>  create mode 100644
> MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
>  create mode 100644
> MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
>  create mode 100644
> MdePkg/Test/GoogleTest/Library/BaseLib/TestCheckSum.cpp
> 
> diff --git a/MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> b/MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> new file mode 100644
> index ..c859e5f86b9e
> --- /dev/null
> +++ b/MdePkg/Test/GoogleTest/Library/BaseLib/GoogleTestBaseLib.inf
> @@ -0,0 +1,31 @@
> +## @file
> +# Host OS based Application that unit tests BaseLib using Google Test
> +#
> +# Copyright (c) 2023, Pedro Falcato. All rights reserved.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +##
> +
> +[Defines]
> +  INF_VERSION = 0x00010005
> +  BASE_NAME   = GoogleTestBaseLib
> +  FILE_GUID   = 34D8CBBA-2442-455F-8454-5B06B12A8B62
> +  MODULE_TYPE = HOST_APPLICATION
> +  VERSION_STRING  = 1.0
> +
> +#
> +# The following information is for reference only and not required by the
> build tools.
> +#
> +#  VALID_ARCHITECTURES   = IA32 X64
> +#
> +
> +[Sources]
> +  TestCheckSum.cpp
> +  TestBaseLibMain.cpp
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
> +
> +[LibraryClasses]
> +  GoogleTestLib
> +  BaseLib
> diff --git a/MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> b/MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> new file mode 100644
> index ..1a9941492be6
> --- /dev/null
> +++ b/MdePkg/Test/GoogleTest/Library/BaseLib/TestBaseLibMain.cpp
> @@ -0,0 +1,23 @@
> +/** @file
> +  Main routine for BaseLib google tests.
> +
> +  Copyright (c) 2023 Pedro Falcato. All rights reserved
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +
> +// Note: Until we can --whole-archive libs, we're forced to include
> secondary files from the main one.
> +// Yuck.

Though I agree with this comment, it does not need to be in the source
code.

Not sure I understand how --whole-archive can help, so please start 
a new discussion or enter a BZ with the details.

> +
> +#include "TestCheckSum.cpp"
> +
> +int
> +main (
> +  int   argc,
> +  char  *argv[]
> +  )
> +{
> +  testing::InitGoogleTest (, argv);
> +  return RUN_ALL_TESTS ();
> +}
> diff --git a/MdePkg/Test/GoogleTest/Library/BaseLib/TestCheckSum.cpp
> b/MdePkg/Test/GoogleTest/Library/BaseLib/TestCheckSum.cpp
> new file mode 100644
> index ..fa97f11dfa9c
> --- /dev/null
> +++ b/MdePkg/Test/GoogleTest/Library/BaseLib/TestCheckSum.cpp
> @@ -0,0 +1,64 @@
> +/** @file
> +  Unit tests for BaseLib's checksum capabilities.
> +
> +  Copyright (c) 2023 Pedro Falcato. All rights reserved
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +extern "C" {
> +#include 
> +#include 
> +}
> +
> +// Precomputed crc32c and crc16-ansi for "hello" (without the null byte)
> +constexpr STATIC UINT32  mHelloCrc32c = 0x9A71BB4C;
> +constexpr STATIC UINT16  mHelloCrc16  = 0x34F6;
> +
> +TEST (Crc32c, BasicCheck) {
> +  // Note: The magic numbers below are precomputed checksums
> +  // Check for basic operation on even and odd numbers of bytes
> +  EXPECT_EQ (CalculateCrc32c ("hello", 5, 0), mHelloCrc32c);
> +  EXPECT_EQ (
> +CalculateCrc32c ("longlonglonglonglong", sizeof
> ("longlonglonglonglong") - 1, 0),
> +0xC50F869D
> +);
> +  EXPECT_EQ (CalculateCrc32c ("h", 1, 0), 0xB96298FC

Re: [edk2-devel] [PATCH v1 1/1] .github/workflows/codeql.yml: Add emacs output

[Michael D Kinney]

Acked-by: Michael D Kinney 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Wednesday, November 29, 2023 9:01 AM
> To: devel@edk2.groups.io
> Cc: Joey Vagedes ; Laszlo Ersek
> ; Kinney, Michael D ; Sean
> Brogan 
> Subject: [PATCH v1 1/1] .github/workflows/codeql.yml: Add emacs output
> 
> From: Michael Kubacki 
> 
> Updates the workflow to also output files that can be loaded in emacs
> to show CodeQL issues (in addition to the existing SARIF output for
> standard SARIF viewers).
> 
> The emacs files are in the SARIF zip file attached to each "CodeQL"
> run (https://github.com/tianocore/edk2/actions/workflows/codeql.yml).
> 
> The file name ends with "-emacs.txt". An MdePkg example:
>   "codeql-db-mdepkg-debug-0-emacs.txt".
> 
> Cc: Joey Vagedes 
> Cc: Laszlo Ersek 
> Cc: Michael D Kinney 
> Cc: Sean Brogan 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> An example CodeQL run with this change:
> 
> https://github.com/tianocore/edk2/actions/runs/7035482184
> 
>  .github/workflows/codeql.yml | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml
> index 72ece9dcb446..e826e67eb912 100644
> --- a/.github/workflows/codeql.yml
> +++ b/.github/workflows/codeql.yml
> @@ -92,7 +92,7 @@ jobs:
>  git config --system core.longpaths true
> 
>  - name: Install/Upgrade pip Modules
> -  run: pip install -r pip-requirements.txt --upgrade requests
> +  run: pip install -r pip-requirements.txt --upgrade requests sarif-
> tools
> 
>  - name: Determine CI Settings File Supported Operations
>id: get_ci_file_operations
> @@ -304,16 +304,26 @@ jobs:
>  PACKAGE_NAME: ${{ matrix.Package }}
>shell: python
>run: |
> +import logging
>  import os
> +from edk2toollib.utility_functions import RunCmd
> +from io import StringIO
> +from pathlib import Path
> 
>  package = os.environ['PACKAGE_NAME'].strip().lower()
>  directory_name = 'codeql-analysis-' + package + '-debug'
>  file_name = 'codeql-db-' + package + '-debug-0.sarif'
> -sarif_path = os.path.join('Build', directory_name, file_name)
> +sarif_path = Path('Build', directory_name, file_name)
> 
>  with open(os.environ['GITHUB_OUTPUT'], 'a') as fh:
> -if os.path.isfile(sarif_path):
> +if sarif_path.is_file():
> +emacs_file_path = sarif_path.with_name(sarif_path.stem +
> "-emacs.txt")
> +out_stream_buffer = StringIO()
> +exit_code = RunCmd("sarif", f"emacs {sarif_path} --output
> {emacs_file_path}",
> +   outstream=out_stream_buffer,
> +   logging_level=logging.NOTSET)
>  print(f'upload_sarif_file=true', file=fh)
> +print(f'emacs_file_path={emacs_file_path}', file=fh)
>  print(f'sarif_file_path={sarif_path}', file=fh)
>  else:
>  print(f'upload_sarif_file=false', file=fh)
> @@ -323,7 +333,9 @@ jobs:
>if: steps.env_data.outputs.upload_sarif_file == 'true'
>with:
>  name: ${{ matrix.Package }}-CodeQL-SARIF
> -path: ${{ steps.env_data.outputs.sarif_file_path }}
> +path: |
> +  ${{ steps.env_data.outputs.emacs_file_path }}
> +  ${{ steps.env_data.outputs.sarif_file_path }}
>  retention-days: 14
>  if-no-files-found: warn
> 
> --
> 2.43.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111854): https://edk2.groups.io/g/devel/message/111854
Mute This Topic: https://groups.io/mt/102875700/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-staging] DeviceSimPkg branch creation

[Michael D Kinney]

Hi Maciej,

Reviewed-by: Michael D Kinney 

I have invited you to the EDK II Staging Maintainer team that
allows you to create this new branch in the edk2-staging repo.

Mike

> -Original Message-
> From: Czajkowski, Maciej 
> Sent: Monday, November 13, 2023 7:09 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D 
> Subject: [edk2-devel][edk2-staging] DeviceSimPkg branch creation
> 
> Hello,
> 
> I would like to announce DeviceSimPkg branch creation in edk2-staging
> repository.
> Branch will be used to develop DeviceSimPkg, a package for developing OS
> executable tests
> for device focused code.
> 
> Branch owner: Maciej Czajkowski , GitHub ID:
> 81293748 (https://github.com/mczaj)
> 
> Signed-off-by: Maciej Czajkowski 
> Cc: Michael D Kinney 
> ---
>  Readme.md | 37 +
>  1 file changed, 37 insertions(+)
>  create mode 100644 Readme.md
> 
> diff --git a/Readme.md b/Readme.md
> new file mode 100644
> index ..96077d0a478c
> --- /dev/null
> +++ b/Readme.md
> @@ -0,0 +1,37 @@
> +# DeviceSimPkg
> +
> +## Introduction
> +
> +DeviceSimPkg is a package aimed at providing an environment to write OS-
> executable unit tests for code that interacts directly with devices.
> +This code is referred to as driver code below although code under test
> doesn't have to follow UEFI driver model. \
> +Branch owner: Maciej Czajkowski <>
> +
> +## How to use it
> +### Using the code
> +
> +You can refer to UnitTest modules to see the usage details. In general
> you will need to link to package libraries (instead of the ones normally
> provided by MdePkg/MdeModulePkg) and initialize your device access.
> Details of initialization will vary based on which
> REGISTER_ACCESS_INTERFACE implementer library you will
> +choose. Please refer to corresponding libraries Readmes for details.
> +
> +## General architecture
> +
> +On high-level package consists of:
> +
> +* REGISTER_ACCESS_INTERFACE - interface between device model and driver
> code
> +* REGISTER_ACCESS_INTERFACE wrappers - libraries that wrap
> REGISTER_ACCESS_INTERFACE and present it as a standard UEFI library
> +* REGISTER_ACCESS_INTERFACE implementers - libraries that implement
> REGISTER_ACCESS_INTERFACE interface
> +
> +## Wrapper libraries
> +
> +Currently package implements following wrappers:
> +
> +* IoLib in
> [RegisterAccessIoLib](DeviceSimPkg/Library/RegisterAccessIoLib/Readme.md)
> +* PciSegmentLib in RegisterAccessPciSegmentLib
> +* PCI_IO_PROTOCOL in RegisterAccessPciIoLib
> +
> +## REGISTER_ACCESS_INTERFACE implementations
> +
> +Currently only a single implementation is fully supported -
> FakeRegisterSpaceLib. Please see its Readme for more details on how to use
> it.
> +
> +## GMOCK support
> +
> +DeviceSim implements Gmock based mock object for the IoLib functions.
> Please see GmockIoLib [Readme](DeviceSimPkg/Library/MockIoLib//Readme.md)
> for details.
> --
> 2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111824): https://edk2.groups.io/g/devel/message/111824
Mute This Topic: https://groups.io/mt/102563078/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] .git-blame-ignore-revs: Ignore recent uncrustify commits

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Monday, November 27, 2023 4:17 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm
> ; Kinney, Michael D
> ; Rebecca Cran 
> Subject: [PATCH v1 1/1] .git-blame-ignore-revs: Ignore recent uncrustify
> commits
> 
> From: Michael Kubacki 
> 
> Includes two recent Uncrustify formatting commits to prevent them
> from showing in git blame.
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Rebecca Cran 
> Signed-off-by: Michael Kubacki 
> ---
>  .git-blame-ignore-revs | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs
> index b426add80cff..a39655ed1770 100644
> --- a/.git-blame-ignore-revs
> +++ b/.git-blame-ignore-revs
> @@ -50,3 +50,7 @@ e7108d0e9655b1795c94ac372b0449f28dd907df
>  40b0b23ed34f48c26d711d3e4613a4bb35eeadff
>  # ArmPkg: Apply uncrustify changes
>  429309e0c6b74792d679681a8edd0d5ae0ff850c
> +# EmulatorPkg: Format with Uncrustify 73.0.8
> +972e3b0b9d67ef2847c9c1c89e606e6074a7ddda
> +# OvmfPkg: Format with Uncrustify 73.0.8
> +0e9ce9146a6dc50a35488e3a4a7a2a4bbaf1eb1c
> --
> 2.42.0.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111776): https://edk2.groups.io/g/devel/message/111776
Mute This Topic: https://groups.io/mt/102842040/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] Maintainers.txt: Remove myself as a tools maintainer

[Michael D Kinney]

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Monday, November 27, 2023 11:45 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Chris Fernald
> ; Joey Vagedes ; Leif
> Lindholm ; Gao, Liming
> ; Kinney, Michael D
> ; Sean Brogan 
> Subject: [PATCH v1 1/1] Maintainers.txt: Remove myself as a tools
> maintainer
> 
> From: Michael Kubacki 
> 
> Replace with Joey Vagedes.
> 
> Cc: Andrew Fish 
> Cc: Chris Fernald 
> Cc: Joey Vagedes 
> Cc: Leif Lindholm 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Sean Brogan 
> Signed-off-by: Michael Kubacki 
> ---
>  Maintainers.txt | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7c0b4cb58cfd..8fdafcb6c7b3 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -104,19 +104,19 @@ EDK II Continuous Integration:
>  .azurepipelines/
>  F: .azurepipelines/
>  M: Sean Brogan  [spbrogan]
> -M: Michael Kubacki  [makubacki]
> +M: Joey Vagedes  [javagedes]
>  R: Michael D Kinney  [mdkinney]
>  R: Liming Gao  [lgao4]
> 
>  .devcontainer/
>  F: .devcontainer/
> -M: Michael Kubacki  [makubacki]
> +M: Joey Vagedes  [javagedes]
>  R: Chris Fernald  [cfernald]
> 
>  .github/
>  F: .github/
>  M: Sean Brogan  [spbrogan]
> -M: Michael Kubacki  [makubacki]
> +M: Joey Vagedes  [javagedes]
>  R: Michael D Kinney  [mdkinney]
> 
>  .mergify/
> @@ -128,7 +128,7 @@ R: Sean Brogan 
> [spbrogan]
>  .pytool/
>  F: .pytool/
>  M: Sean Brogan  [spbrogan]
> -M: Michael Kubacki  [makubacki]
> +M: Joey Vagedes  [javagedes]
>  R: Michael D Kinney  [mdkinney]
>  R: Liming Gao  [lgao4]
> 
> @@ -166,7 +166,7 @@ R: Yuwei Chen  [YuweiChen1110]
>  BaseTools: Plugins
>  F: BaseTools/Plugin/
>  M: Sean Brogan  [spbrogan]
> -M: Michael Kubacki  [makubacki]
> +M: Joey Vagedes  [javagedes]
>  R: Michael D Kinney  [mdkinney]
>  R: Liming Gao  [lgao4]
> 
> --
> 2.42.0.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111761): https://edk2.groups.io/g/devel/message/111761
Mute This Topic: https://groups.io/mt/102836632/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] [Bug] Building NetworkPkg fails due to missing SynchronizationLib dependency of BaseCryptLib

[Michael D Kinney]

Hi Sean and Michael,

The NetworkPkg.ci.yaml is pointing at a DSC file in the NetworkPkg.

If I try a local build of that DSC file, it does fail immediately with
a missing library mapping.

Any ideas on how this was not seen by CI?  Either for PR or Push actions?

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 21, 2023 7:19 AM
> To: Crossed Carpet ; devel@edk2.groups.io
> Cc: Gao, Liming 
> Subject: Re: [edk2-devel] [Bug] Building NetworkPkg fails due to
> missing SynchronizationLib dependency of BaseCryptLib
> 
> On 11/20/23 11:25, Crossed Carpet wrote:
> > Good morning Laszlo,
> > Thank you for your reply. I feared this was intentional due to
> believing
> > that it would have been caught with automated testing.
> > Doesn't the Azure Pipeline try to build all packages to make sure no
> > dependency broke?
> 
> Right, we have "NetworkPkg/NetworkPkg.ci.yaml". I'm unsure how this
> issue had slipped through.
> 
> Thanks
> Laszlo
> 
> >
> > Also Liming, would you do me the honour of creating a Bugzilla
> account
> > for this email?
> > Best regards,
> > CC
> > 
> 
> > *From:* Laszlo Ersek 
> > *Sent:* 17 November 2023 16:06
> > *To:* devel@edk2.groups.io ;
> > crossedcar...@hotmail.com 
> > *Cc:* Liming Gao (Byosoft address) 
> > *Subject:* Re: [edk2-devel] [Bug] Building NetworkPkg fails due to
> > missing SynchronizationLib dependency of BaseCryptLib
> >
> > On 11/17/23 13:49, CrossedCarpet wrote:
> >> Steps to reproduce:
> >> - download and setup edk2
> >> - run:
> >> build -a X64 -b DEBUG -t GCC -p NetworkPkg/NetworkPkg.dsc
> >>
> >> Get the error:
> >> build.py...
> >> /.../edk2/NetworkPkg/NetworkPkg.dsc(...): error 4000: Instance of
> >> library class [SynchronizationLib] is not found
> >> in [/.../edk2/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf]
> [X64]
> >> consumed by module [/.../edk2/NetworkPkg/TlsDxe/TlsDxe.inf]
> >>
> >> Adding this LibClass to NetworkPkg.dsc solves it:
> >>
> >>
> SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroni
> zationLib.inf
> >
> > This is a regression from commit 5d5be45bd111 ("CryptPkg: Enable
> > CryptoPkg BaseCryptLib ParallelHash for PEI and DXE", 2022-12-02),
> which
> > was made for  > >.
> >
> > It added a new lib class dependency to "BaseCryptLib.inf", but it
> didn't
> > ensure that all DSC files in the tree that employed the
> > "BaseCryptLib.inf" instance had a resolution for the new lib class.
> >
> > Indeed it is not just NetworkPkg.dsc but also FmpDevicePkg.dsc
> that's
> > affected:
> >
> > $ git grep -l -F CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf --
> > '**dsc*' \
> >   | xargs -- grep --files-without-match -w SynchronizationLib --
> >
> > FmpDevicePkg/FmpDevicePkg.dsc
> > NetworkPkg/NetworkPkg.dsc
> >
> > It also *seems* to affect at least one platform in edk2-platforms:
> >
> > Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeLib.dsc
> >
> > (although I realize this last DSC file is an "include" DSC, so the
> > missing dependency could be resolved in the DSC file that includes
> this
> > one.)
> >
> > Either way, thanks for catching this; the edk2 issue should be fixed
> > preferably during the current hard feature freeze (for NetworkPkg
> and
> > FmpDevicePkg).
> >
> >> I tried to open a bug in bugzilla but I wasn't able to log in or
> create
> >> an account. How should I do it next time?
> >
> > I think the bugzilla account creation was disabled due to spammer
> accounts.
> >
> > The way to request an account is described here (linked from the
> > bugzilla.tianocore.org landing page under link "Reporting issues"):
> >
> >   https://github.com/tianocore/tianocore.github.io/wiki/Reporting-
> Issues
> >  Issues>
> >
> > (I've added Liming to the CC list of this email.)
> >
> > Laszlo
> >
> >
> >>
> >
> 
> 
> 
> 
> 



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

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

[Michael D Kinney]

Series Reviewed-by: Michael D Kinney 

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


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

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

[Michael D Kinney]

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
> 
> -  #define LID_BP_INFO   0x15
> 
> +  #define LID_ERROR_INFO0x1
> 
> +  #define LID_SMART_INFO0x2
> 
> +  #define LID_FW_SLOT_INFO  0x3
> 
> +  #define LID_BP_INFO   0x15
> 
> +  #define LID_SANITIZE_STATUS_INFO  0x81
> 
>UINT32Rsvd1 : 8;
> 
>UINT32Numd  : 12;   /* Number of Dwords */
> 
>UINT32Rsvd2 : 4;/* Reserved as of Nvm Express 1.1 Spec
> */
> 
> @@ -708,6 +724,31 @@ typedef struct {
>UINT32Sv: 1;/* Save */
> 
>  } NVME_ADMIN_SET_FEATURES;
> 
> 
> 
> +//
> 
> +// NvmExpress Admin Sanitize Command
> 
> +//
> 
> +typedef struct {
> 
> +  //
> 
> +  // CDW 10
> 
> +  //
> 
> +  UINT32Sanact : 3;   /* Sanitize Action */
> 
> +  UINT32Ause   : 1;   /* Allow Unrestricted Sanitize Exit */
> 
> +  UINT32Owpass : 4;   /* Overwrite Pass Count */
> 
> +  UINT32Oipbp  : 1;   /* Overwrite Invert Pattern Between
> Passes */
> 
&g

Re: edk2-stable202311 Code freeze process violation Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

[Michael D Kinney]

Hello,

Looks like the process for permissions needs to be adjusted during soft/hard 
freeze.

Liming reduced EDK II Maintainers team to "Triage" for edk2 repo.

But from this documentation lists Triage as allowing add/remove labels.

https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization

Looks like reducing to EDK II Maintainer team to "Read" is the right setting 
for soft/hard freeze.

Mike


> -Original Message-
> From: Chang, Abner 
> Sent: Wednesday, November 15, 2023 3:55 AM
> To: Leif Lindholm ; devel@edk2.groups.io;
> Mike Maslenkin ; ig...@ami.com; Gao, Liming
> ; Kinney, Michael D
> 
> Cc: Nickle Wang 
> Subject: RE: edk2-stable202311 Code freeze process violation Re:
> [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize
> the Redfish Discover flow
> 
> [AMD Official Use Only - General]
> 
> Ok, Liming as we are going to revert that two commits. Is that
> possible to wait for Igor sending out another patch to address Leif's
> comment? This may delay the stable release a little bit.
> As without this patch, users may encounter the problem when sending
> request to Redfish service on the platform which have multiple NIC
> installed,
> 
> Let us know, thanks!
> Abner
> 
> > -Original Message-
> > From: Chang, Abner
> > Sent: Wednesday, November 15, 2023 7:07 PM
> > To: Leif Lindholm ; devel@edk2.groups.io;
> Mike
> > Maslenkin ; ig...@ami.com; Gao, Liming
> > ; Kinney, Michael D
> > 
> > Cc: Nickle Wang 
> > Subject: RE: edk2-stable202311 Code freeze process violation Re:
> [edk2-
> > devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the
> Redfish
> > Discover flow
> >
> > Hi Leif,
> > As we requested Liming to wait for this change last week, he
> accepted to wait
> > for the PR. But you are right, suppose I shouldn't be allowed to
> merge the
> > change during code freeze. Maybe only certain people have privilege
> to merge
> > the code during code freeze. If I still can merge the code then the
> mechanism
> > may be broken. I am fine if you would like to revert these commits.
> >
> > Regards,
> > Abner
> >
> > > -Original Message-
> > > From: Leif Lindholm 
> > > Sent: Wednesday, November 15, 2023 6:59 PM
> > > To: devel@edk2.groups.io; Chang, Abner ; Mike
> > > Maslenkin ; ig...@ami.com; Gao, Liming
> > > ; Kinney, Michael D
> > > 
> > > Cc: Nickle Wang 
> > > Subject: edk2-stable202311 Code freeze process violation Re:
> [edk2-devel]
> > > [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the
> Redfish
> > > Discover flow
> > >
> > > Caution: This message originated from an External Source. Use
> proper
> > caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > On 2023-11-15 03:55, Chang, Abner via groups.io wrote:
> > > > [AMD Official Use Only - General]
> > > >
> > > > Just let you know I just merged this change. Igor can help to
> follow up the
> > > suggestions given by Leif and Mike.
> > >
> > > I was under the impression merging was disabled for everyone
> except Mike
> > > and Liming during code freeze specifically to avoid this
> situation.
> > > Apparently, that isn't working.
> > >
> > > Regardless, this is a violation of the stable tag process.
> > > Liming: can you please revert these commits?
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > > Thanks
> > > > Abner
> > > >
> > > >> -Original Message-
> > > >> From: Chang, Abner
> > > >> Sent: Wednesday, November 15, 2023 9:20 AM
> > > >> To: Mike Maslenkin ;
> > devel@edk2.groups.io;
> > > >> ig...@ami.com
> > > >> Cc: Leif Lindholm ; Nickle Wang
> > > >> 
> > > >> Subject: RE: [edk2-devel] [PATCH v5 2/2] RedfishPkg:
> > RedfishDiscoverDxe:
> > > >> Optimize the Redfish Discover flow
> > > >>
> > > >> Hi Mike and Leif,
> > > >> Thanks for your comments on this change. As we are rushing to
> get this
> > > >> change to be pulled in stable release 202312 this week, I will
> just merge
> > this
> > > >> code to master branch and let the discussing keeps going.
> > > >> I think there is no functionality difference base on your
> suggestions, but
> > it's
> > > >> about the coding practice and readability.
> > > >>
> > > >> Hi Igor,
> > > >> Could you please resend the V6 after stable tag is released if
> Mike and
> > Leif's
> > > >> comment is reasonable to you?
> > > >>
> > > >> Thanks
> > > >> Abner
> > > >>
> > > >>> -Original Message-
> > > >>> From: Mike Maslenkin 
> > > >>> Sent: Wednesday, November 15, 2023 7:53 AM
> > > >>> To: devel@edk2.groups.io; ig...@ami.com
> > > >>> Cc: Leif Lindholm ; Chang, Abner
> > > >>> ; Nickle Wang 
> > > >>> Subject: Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg:
> > RedfishDiscoverDxe:
> > > >>> Optimize the Redfish Discover flow
> > > >>>
> > > >>> Caution: This message originated from an External Source. Use
> proper
> > > >> caution
> > > >>> when opening attachments, clicking links, 

Re: [edk2-devel] [PATCH v2 4/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix NULL_RETURNS Coverity issue

[Michael D Kinney]

Hi Ranbir,

First I want to recognize your efforts to collect Coverity issues and propose 
changes to address
them.

I still disagree with adding CpuDealLoop() for any static analysis issues.

There have been previous discussions about adding a PANIC() or FATAL() macro 
that would
perform platform specific actions if a condition is detected where the boot of 
the platform
can not continue.  A platform get to make the choice to log or reboot or hang, 
etc.  Not the
code that detected the condition.

https://edk2.groups.io/g/devel/message/86597

Unfortunately, in order to fix some of these static analysis issues correctly, 
we are going
to have to identify the use of ASSERT() that really is a fatal condition that 
can not continue
and introduce an implementation approach that provides a platform handler and
satisfies the static analysis tools.

We also have to evaluate if a return error status with a DEBUG_ERROR message 
would be a better
choice than an ASSERT() that can be filtered out by build options.

Best regards,

Mike


From: devel@edk2.groups.io  On Behalf Of Ranbir Singh
Sent: Tuesday, November 14, 2023 7:08 AM
To: Laszlo Ersek 
Cc: devel@edk2.groups.io; Ni, Ray ; Veeresh Sangolli 

Subject: Re: [edk2-devel] [PATCH v2 4/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix 
NULL_RETURNS Coverity issue



On Mon, Nov 13, 2023 at 4:58 PM Laszlo Ersek 
mailto:ler...@redhat.com>> wrote:
On 11/10/23 07:11, Ranbir Singh wrote:
> EFI_NOT_READY was listed as one of the error return values in the
> function header of StartPciDevices(). So, I considered it here.
>
> Maybe we can go by a dual approach, including CpuDeadLoop() in
> StartPciDevices() as well as add return value check at the call site in
> PciBusDriverBindingStart().

I don't think this makes much sense, given that execution is not
supposed to continue past CpuDeadLoop(), so the new error check would
not be reached.

I think two options are realistic:

- replace the assert() with a CpuDeadLoop() -- this is my preference

- keep the assert, add the "if", and in the caller, handle the
EFI_NOT_READY error. This is workable too. (Keeping the assert is goog
because it shows that we don't expect the "if" to fire.)

Anyway, now that we have no way to verify the change against Coverity, I
don't know if this patch is worth the churn. :( As I said, this ASSERT()
is one of those few justified ones in edk2 core that can indeed never
fail, IMO.

Laszlo

See, Does the following change look acceptable to you ?

ASSERT (RootBridge != NULL);
+  if (RootBridge == NULL) {
+CpuDeadLoop ();
+return EFI_NOT_READY;
+  }
+

which retains the existing assert, adds the NULL pointer check and includes 
CpuDeadLoop () within the if block. As a result of CpuDeadLoop (), the return 
statement afterwards will never reach execution (=> no need to handle this 
return value at the call sites), but will satisfy static analysis tools as the 
"RootBridge" dereference scenario doesn't arise thereafter.


>
> On Tue, Nov 7, 2023 at 10:18 PM Laszlo Ersek 
> mailto:ler...@redhat.com>
> >> wrote:
>
> On 11/7/23 07:19, Ranbir Singh wrote:
> > From: Ranbir Singh 
> mailto:ranbir.sin...@dell.com>>
> >
> > The function StartPciDevices has a check
> >
> > ASSERT (RootBridge != NULL);
> >
> > but this comes into play only in DEBUG mode. In Release mode, there
> > is no handling if the RootBridge value is NULL and the code proceeds
> > to unconditionally dereference "RootBridge" which will lead to CRASH.
> >
> > Hence, for safety add NULL pointer checks always and return
> > EFI_NOT_READY if RootBridge value is NULL which is one of the return
> > values as mentioned in the function description header.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> 
> >
> > Cc: Ray Ni mailto:ray...@intel.com> 
> >>
> > Co-authored-by: Veeresh Sangolli 
> mailto:veeresh.sango...@dellteam.com>
> 
> >>
> > Signed-off-by: Ranbir Singh 
> mailto:ranbir.sin...@dell.com>>
> > Signed-off-by: Ranbir Singh 
> mailto:rsi...@ventanamicro.com>
> >>
> > ---
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > index 581e9075ad41..3de80d98370e 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
> > @@ -772,7 +772,10 @@ StartPciDevices (
> >LIST_ENTRY *CurrentLink;
> >
> >RootBridge = 

Re: [edk2-devel] edk2 uncrustify update (73.0.8)?

[Michael D Kinney]

Hi Michael,

Have you tried to upstream the edk2 specific elements to the
uncrustify project?  That would be a path to remove the fork
and eventually all the distros would catch up.

Mike

> -Original Message-
> From: Michael Kubacki 
> Sent: Monday, November 13, 2023 12:22 PM
> To: Pedro Falcato ; devel@edk2.groups.io;
> ler...@redhat.com
> Cc: Kinney, Michael D ; Andrew Fish
> ; Marcin Juszkiewicz ;
> Leif Lindholm (Quic) 
> Subject: Re: [edk2-devel] edk2 uncrustify update (73.0.8)?
> 
> On 11/13/2023 2:07 PM, Pedro Falcato wrote:
> > On Mon, Nov 13, 2023 at 11:58 AM Laszlo Ersek 
> wrote:
> >>
> >> Hi Michael,
> >>
> >> recently I encountered an uncrustify failure on github.
> >>
> >> The reason was that my local uncrustify was *more recent* (73.0.8)
> than
> >> the one we use in edk2 CI (which is 73.0.3, per the edk2 file
> >> ".pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml").
> >
> > Wait, you can use upstream uncrustify? I'm just using whatever
> > uncrustify version I took from the project-mu fork...
> >
> The fork version is needed for edk2 specific conventions. More details
> are here -
> https://dev.azure.com/projectmu/uncrustify?anchor=edk-ii-poc-details
> 
> >>
> >> Updating the version number in the YAML file (i.e., advancing edk2
> to
> >> version 73.0.8) seems easy enough, but:
> >>
> >> - Do you think 73.0.8 is mature enough for adoption in edk2?
> >>
> >>This upstream uncrustify release was tagged in April (and I
> can't see
> >>any more recent commits), so I assume it should be stable.
> >>
> >> - Would the version update require a whole-tree re-
> uncrustification?
> >
> > Please, no. I didn't mind doing an initial reformatting at first,
> but
> > doing this continuously is both 1) problem-prone 2) just amazing
> > amounts of churn.
> > Let's say I have version N, you have version N+1 - we may never get
> > any final, formatted output as your version formats it differently
> > from mine.
> >
> > I don't know how the CI is doing its thing atm (I haven't merged
> > anything myself to edk2), but the uncrustify check should be relaxed
> > to just a warning. There's nothing wrong with what my uncrustify
> > version is formatting to, there's nothing wrong with yours either,
> and
> > CI isn't necessarily wrong either.
> >
> > And, to be fair, I already find uncrustify a large pain in the butt
> to
> > use (requiring a custom fork really does not help), but I find the
> > benefits worth it *locally*, as my coding style is also quite
> > different from the NT-esque style.
> >
> It should be simple to update and ensure everyone is using the same
> version. This requires stuart commands to be used
> (https://github.com/tianocore/edk2-pytool-extensions). I know there's
> aversion to stuart but that's how these extensions plug into the edk2
> build process right now.
> 
> If you use it, as an end user, you just run "stuart_update -c
> .pytool/CISettings.py" and it will get the Uncrustify binary for your
> host OS with the version used by the project.
> 
> ---
> 
> The version pulled and the source feed used by stuart are defined in
> edk2 here:
> https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/Uncrustif
> yCheck/uncrustify_ext_dep.yaml
> 
> That file and command are used locally, in CI, and the file is checked
> into edk2. At any given point in time, a user at a given point in edk2
> history should be using the same version and configuration.
> 
> More details, for those interested, are here
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-
> Formatting.
> That tries to cover some niche use cases so it may seem more
> overwhelming than it actually is to just get and use the executable.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81): https://edk2.groups.io/g/devel/message/81
Mute This Topic: https://groups.io/mt/102559740/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 0/5] BaseTools/Scripts/GetMaintainer: Handle reviewer only case

[Michael D Kinney]

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

> -Original Message-
> From: Rebecca Cran 
> Sent: Friday, November 10, 2023 12:36 PM
> To: Leif Lindholm ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Feng, Bob C ; Chen,
> Christine 
> Subject: Re: [PATCH v3 0/5] BaseTools/Scripts/GetMaintainer: Handle
> reviewer only case
> 
> For the series:
> 
> Acked-by: Rebecca Cran 
> 
> 
> On 11/10/23 12:30, Leif Lindholm wrote:
> > OK, so this a bit of a backwards review, but I figured I might as
> > well show how I would prefer the split. I'm adding a patch that
> > changes internal returns to dictionaries instead of multiple return
> > values.
> >
> > There are no functional differences between the original submission
> > and this for 1-2,4-5/5, so I'm happy to give
> > Reviewed-by: Leif Lindholm 
> > for those. 3/5 is new and requires review by someone else.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4593
> >
> > Fix logic bug where maintainers was incorrectly added to lists.
> >
> > If a package only has reviewers and no maintainers, then also
> > return the  maintainers.
> >
> > In order to detect this case, get_maintainers() is updated to
> > return maintainers, reviews, and lists separately instead of
> > a single merged list.  This also allows this module to be used
> > by other scripts that need to distinguish between maintainers,
> > reviewers, and lists.
> >
> > Simplify logic that accumulates maintainers, reviewers, lists.
> >
> > Sort the list of output addresses alphabetically and use set()
> > instead of OrderedDict() to accumulate unique addresses.
> >
> > Changes since v2:
> > - Reworked internal return logic to use dictionaries.
> > - Reordered cleanup before new functionality.
> > Changes since v1:
> > - Split into patch series
> >
> > Cc: Rebecca Cran 
> > Cc: Liming Gao 
> > Cc: Bob Feng 
> > Cc: Yuwei Chen 
> > Cc: Michael D Kinney 
> >
> > Leif Lindholm (1):
> >BaseTools/Scripts/GetMaintainer: refactor internal returns as
> dicts
> >
> > Michael D Kinney (4):
> >BaseTools/Scripts/GetMaintainer: Fix logic bug collecting
> maintainers
> >BaseTools/Scripts/GetMaintainer: Simplify logic
> >BaseTools/Scripts/GetMaintainer: Handle reviewer only case
> >BaseTools/Scripts/GetMaintainer: Sort output addresses
> >
> >   BaseTools/Scripts/GetMaintainer.py | 43 +++---
> 
> >   1 file changed, 27 insertions(+), 16 deletions(-)
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#11): https://edk2.groups.io/g/devel/message/11
Mute This Topic: https://groups.io/mt/102513765/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 3/5] BaseTools/Scripts/GetMaintainer: refactor internal returns as dicts

[Michael D Kinney]

Hi Leif,

Thank you for the addition cleanup.

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Leif Lindholm 
> Sent: Friday, November 10, 2023 11:31 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Rebecca Cran
> ; Gao, Liming ; Feng, Bob
> C ; Chen, Christine 
> Subject: [PATCH v3 3/5] BaseTools/Scripts/GetMaintainer: refactor
> internal returns as dicts
> 
> To clean up interfaces, change the lookup functions to return
> dictionaries
> rather than multiple values.
> 
> Cc: Rebecca Cran 
> Cc: Liming Gao 
> Cc: Bob Feng 
> Cc: Yuwei Chen 
> Cc: Michael D Kinney 
> Signed-off-by: Leif Lindholm 
> ---
>  BaseTools/Scripts/GetMaintainer.py | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/BaseTools/Scripts/GetMaintainer.py
> b/BaseTools/Scripts/GetMaintainer.py
> index cdcdff750635..cb3aadbbefb1 100644
> --- a/BaseTools/Scripts/GetMaintainer.py
> +++ b/BaseTools/Scripts/GetMaintainer.py
> @@ -96,7 +96,7 @@ def get_section_maintainers(path, section):
>  else:
>  lists += [address]
> 
> -return maintainers, lists
> +return {'maintainers': maintainers, 'lists': lists}
> 
>  def get_maintainers(path, sections, level=0):
>  """For 'path', iterates over all sections, returning maintainers
> @@ -104,22 +104,24 @@ def get_maintainers(path, sections, level=0):
>  maintainers = []
>  lists = []
>  for section in sections:
> -tmp_maint, tmp_lists = get_section_maintainers(path, section)
> -maintainers += tmp_maint
> -lists += tmp_lists
> +recipients = get_section_maintainers(path, section)
> +maintainers += recipients['maintainers']
> +lists += recipients['lists']
> 
>  if not maintainers:
>  # If no match found, look for match for (nonexistent) file
>  # REPO.working_dir/
>  print('"%s": no maintainers found, looking for default' %
> path)
>  if level == 0:
> -maintainers = get_maintainers('', sections,
> level=level + 1)
> +recipients = get_maintainers('', sections,
> level=level + 1)
> +maintainers += recipients['maintainers']
> +lists += recipients['lists']
>  else:
>  print("No  maintainers set for project.")
>  if not maintainers:
>  return None
> 
> -return maintainers + lists
> +return {'maintainers': maintainers, 'lists': lists}
> 
>  def parse_maintainers_line(line):
>  """Parse one line of Maintainers.txt, returning any match group
> and its key."""
> @@ -184,9 +186,8 @@ if __name__ == '__main__':
> 
>  for file in FILES:
>  print(file)
> -addresslist = get_maintainers(file, SECTIONS)
> -if addresslist:
> -ADDRESSES += addresslist
> +recipients = get_maintainers(file, SECTIONS)
> +ADDRESSES += recipients['maintainers'] + recipients['lists']
> 
>  for address in list(OrderedDict.fromkeys(ADDRESSES)):
>  if '<' in address and '>' in address:
> --
> 2.39.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111069): https://edk2.groups.io/g/devel/message/111069
Mute This Topic: https://groups.io/mt/102513771/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] [edk2-stable202311][Patch v2 2/4] BaseTools/Scripts/GetMaintainer: Handle reviewer only case

[Michael D Kinney]

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

If a package only has reviewers and no maintainers, then also
return the  maintainers.

In order to detect this case, get_maintainers() is updated to
return maintainers, reviews, and lists separately instead of
a single merged list.  This also allows this module to be used
by other scripts that need to distinguish between maintainers,
reviewers, and lists.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index 2a3147c059b5..081460451e9b 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -76,6 +76,7 @@ def get_section_maintainers(path, section):
 """Returns a list with email addresses to any M: and R: entries
matching the provided path in the provided section."""
 maintainers = []
+reviewers = []
 lists = []
 nowarn_status = ['Supported', 'Maintained']
 
@@ -83,12 +84,18 @@ def get_section_maintainers(path, section):
 for status in section['status']:
 if status not in nowarn_status:
 print('WARNING: Maintained status for "%s" is \'%s\'!' % 
(path, status))
-for address in section['maintainer'], section['reviewer']:
+for address in section['maintainer']:
 # Convert to list if necessary
 if isinstance(address, list):
 maintainers += address
 else:
 maintainers += [address]
+for address in section['reviewer']:
+# Convert to list if necessary
+if isinstance(address, list):
+reviewers += address
+else:
+reviewers += [address]
 for address in section['list']:
 # Convert to list if necessary
 if isinstance(address, list):
@@ -96,17 +103,20 @@ def get_section_maintainers(path, section):
 else:
 lists += [address]
 
-return maintainers, lists
+return maintainers, reviewers, lists
 
 def get_maintainers(path, sections, level=0):
 """For 'path', iterates over all sections, returning maintainers
for matching ones."""
 maintainers = []
+reviewers = []
 lists = []
 for section in sections:
-tmp_maint, tmp_lists = get_section_maintainers(path, section)
+tmp_maint, tmp_review, tmp_lists = get_section_maintainers(path, 
section)
 if tmp_maint:
 maintainers += tmp_maint
+if tmp_review:
+reviewers += tmp_review
 if tmp_lists:
 lists += tmp_lists
 
@@ -115,13 +125,15 @@ def get_maintainers(path, sections, level=0):
 # REPO.working_dir/
 print('"%s": no maintainers found, looking for default' % path)
 if level == 0:
-maintainers = get_maintainers('', sections, level=level + 
1)
+maintainers, tmp_review, tmp_lists = get_maintainers('', 
sections, level=level + 1)
+reviewers += tmp_review
+lists += tmp_lists
 else:
 print("No  maintainers set for project.")
 if not maintainers:
 return None
 
-return maintainers + lists
+return maintainers, reviewers, lists
 
 def parse_maintainers_line(line):
 """Parse one line of Maintainers.txt, returning any match group and its 
key."""
@@ -186,9 +198,9 @@ if __name__ == '__main__':
 
 for file in FILES:
 print(file)
-addresslist = get_maintainers(file, SECTIONS)
-if addresslist:
-ADDRESSES += addresslist
+maintainers, reviewers, lists = get_maintainers(file, SECTIONS)
+if maintainers or reviewers or lists:
+ADDRESSES += (maintainers + reviewers + lists)
 
 for address in list(OrderedDict.fromkeys(ADDRESSES)):
 if '<' in address and '>' in address:
-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111046): https://edk2.groups.io/g/devel/message/111046
Mute This Topic: https://groups.io/mt/102510794/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] [edk2-stable202311][Patch v2 1/4] BaseTools/Scripts/GetMaintainer: Fix logic bug collecting maintainers

[Michael D Kinney]

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

Fix logic bug where maintainers is incorrectly added to lists.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index d1e042c0afe4..2a3147c059b5 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -88,7 +88,7 @@ def get_section_maintainers(path, section):
 if isinstance(address, list):
 maintainers += address
 else:
-lists += [address]
+maintainers += [address]
 for address in section['list']:
 # Convert to list if necessary
 if isinstance(address, list):
-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111043): https://edk2.groups.io/g/devel/message/111043
Mute This Topic: https://groups.io/mt/102510789/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] [edk2-stable202311][Patch v2 3/4] BaseTools/Scripts/GetMaintainer: Simplify logic

[Michael D Kinney]

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

get_section_maintainers() either returns a list with
valid entries or an empty list.  It never returns None.
Simplify logic that accumulates maintainers, reviewers,
and lists by unconditionally appending lists returned
from get_section_maintainers().

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index 081460451e9b..a887962dd1bd 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -113,12 +113,9 @@ def get_maintainers(path, sections, level=0):
 lists = []
 for section in sections:
 tmp_maint, tmp_review, tmp_lists = get_section_maintainers(path, 
section)
-if tmp_maint:
-maintainers += tmp_maint
-if tmp_review:
-reviewers += tmp_review
-if tmp_lists:
-lists += tmp_lists
+maintainers += tmp_maint
+reviewers += tmp_review
+lists += tmp_lists
 
 if not maintainers:
 # If no match found, look for match for (nonexistent) file
-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111044): https://edk2.groups.io/g/devel/message/111044
Mute This Topic: https://groups.io/mt/102510791/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] [edk2-stable202311][Patch v2 4/4] BaseTools/Scripts/GetMaintainer: Sort output addresses

[Michael D Kinney]

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

Sort the list of output addresses alphabetically so this
script produces the same output even if the order of patches
in a patch series is modified such that that order of files
processed by this script changes.

Use set() logic instead of OrderedDict to accumulate the
list of unique addresses that are sorted alphabetically.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index a887962dd1bd..b33546b10f21 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -191,15 +191,16 @@ if __name__ == '__main__':
 else:
 FILES = get_modified_files(REPO, ARGS)
 
-ADDRESSES = []
-
+# Accumulate a sorted list of addresses
+ADDRESSES = set([])
 for file in FILES:
 print(file)
 maintainers, reviewers, lists = get_maintainers(file, SECTIONS)
-if maintainers or reviewers or lists:
-ADDRESSES += (maintainers + reviewers + lists)
+ADDRESSES |= set(maintainers + reviewers + lists)
+ADDRESSES = list(ADDRESSES)
+ADDRESSES.sort()
 
-for address in list(OrderedDict.fromkeys(ADDRESSES)):
+for address in ADDRESSES:
 if '<' in address and '>' in address:
 address = address.split('>', 1)[0] + '>'
 print('  %s' % address)
-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111045): https://edk2.groups.io/g/devel/message/111045
Mute This Topic: https://groups.io/mt/102510793/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] [edk2-stable202311][Patch v2 0/4] BaseTools/Scripts/GetMaintainer: Handle reviewer only case

[Michael D Kinney]

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

New in V2: Split into patch series

Fix logic bug where maintainers was incorrectly added to lists.

If a package only has reviewers and no maintainers, then also
return the  maintainers.

In order to detect this case, get_maintainers() is updated to
return maintainers, reviews, and lists separately instead of
a single merged list.  This also allows this module to be used
by other scripts that need to distinguish between maintainers,
reviewers, and lists.

Simplify logic that accumulates maintainers, reviewers, lists.

Sort the list of output addresses alphabetically and use set()
instead of OrderedDict() to accumulate unique addresses.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 

Michael D Kinney (4):
  BaseTools/Scripts/GetMaintainer: Fix logic bug collecting maintainers
  BaseTools/Scripts/GetMaintainer: Handle reviewer only case
  BaseTools/Scripts/GetMaintainer: Simplify logic
  BaseTools/Scripts/GetMaintainer: Sort output addresses

 BaseTools/Scripts/GetMaintainer.py | 42 ++
 1 file changed, 26 insertions(+), 16 deletions(-)

-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111042): https://edk2.groups.io/g/devel/message/111042
Mute This Topic: https://groups.io/mt/102510788/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 1/1] BaseTools/Scripts: Handle reviewer only case in GetMaintainer.py

[Michael D Kinney]

Hi Leif,

Agree with your points.  I was trying to make minimal changes to address
the reviewers with no maintainers case.  Returning a dictionary would make
more sense.

A couple questions:

1) Do you want to see this patch broken up into a series, with the
   logic fix, reviewers with no maintainers feature, and code clean
   up in separate patches?

2) Is this change approved for edk2-stable202311?

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif
> Lindholm
> Sent: Friday, November 10, 2023 4:44 AM
> To: Kinney, Michael D 
> Cc: devel@edk2.groups.io; Rebecca Cran ; Gao,
> Liming ; Feng, Bob C ;
> Chen, Christine 
> Subject: Re: [edk2-devel] [edk2-stable202311][Patch 1/1]
> BaseTools/Scripts: Handle reviewer only case in GetMaintainer.py
> 
> On Wed, Nov 08, 2023 at 12:43:23 -0800, Michael D Kinney wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4593
> >
> > If a package only has reviewers and no maintainers, then also
> > return the  maintainers.
> >
> > Update get_maintainers() to return maintainers, reviews, and
> > lists separately instead of a single merged list to allow this
> > module to be used by other scripts and distinguish types.
> >
> > Sort the list of output addresses alphabetically.
> >
> > Fix logic bug where maintainers was incorrectly added to lists.
> >
> > Cc: Rebecca Cran 
> > Cc: Liming Gao 
> > Cc: Bob Feng 
> > Cc: Yuwei Chen 
> > Cc: Leif Lindholm 
> > Signed-off-by: Michael D Kinney 
> > ---
> >  BaseTools/Scripts/GetMaintainer.py | 42 ++-
> ---
> >  1 file changed, 26 insertions(+), 16 deletions(-)
> >
> > diff --git a/BaseTools/Scripts/GetMaintainer.py
> b/BaseTools/Scripts/GetMaintainer.py
> > index d1e042c0afe4..b33546b10f21 100644
> > --- a/BaseTools/Scripts/GetMaintainer.py
> > +++ b/BaseTools/Scripts/GetMaintainer.py
> > @@ -76,6 +76,7 @@ def get_section_maintainers(path, section):
> >  """Returns a list with email addresses to any M: and R: entries
> > matching the provided path in the provided section."""
> >  maintainers = []
> > +reviewers = []
> >  lists = []
> >  nowarn_status = ['Supported', 'Maintained']
> >
> > @@ -83,12 +84,18 @@ def get_section_maintainers(path, section):
> >  for status in section['status']:
> >  if status not in nowarn_status:
> >  print('WARNING: Maintained status for "%s" is
> \'%s\'!' % (path, status))
> > -for address in section['maintainer'], section['reviewer']:
> > +for address in section['maintainer']:
> >  # Convert to list if necessary
> >  if isinstance(address, list):
> >  maintainers += address
> >  else:
> > -lists += [address]
> > +maintainers += [address]
> 
> That's a bugfix. Ought to be separate.
> (Cleverly hidden by concatentaing the results when we didn't care
> about keeping them separate other than for seeing if we'd found any
> humans.)
> 
> > +for address in section['reviewer']:
> > +# Convert to list if necessary
> > +if isinstance(address, list):
> > +reviewers += address
> > +else:
> > +reviewers += [address]
> >  for address in section['list']:
> >  # Convert to list if necessary
> >  if isinstance(address, list):
> > @@ -96,32 +103,34 @@ def get_section_maintainers(path, section):
> >  else:
> >  lists += [address]
> >
> > -return maintainers, lists
> > +return maintainers, reviewers, lists
> >
> >  def get_maintainers(path, sections, level=0):
> >  """For 'path', iterates over all sections, returning
> maintainers
> > for matching ones."""
> >  maintainers = []
> > +reviewers = []
> >  lists = []
> >  for section in sections:
> > -tmp_maint, tmp_lists = get_section_maintainers(path,
> section)
> > -if tmp_maint:
> > -maintainers += tmp_maint
> > -if tmp_lists:
> > -lists += tmp_lists
> > +tmp_maint, tmp_review, tmp_lists =
> get_section_maintainers(path, section)
> > +maintainers += tmp_maint
> > +reviewers += tmp_review
> > +lists += tmp_lists
> 
> Minor niggle at coding style cleanup as part of functional rew

Re: [edk2-devel] [PATCH v4] UefiCpuPkg/PiSmmCpuDxeSmm: Fix CP Exception when CET enable

[Michael D Kinney]

I approve this change for edk2-stable202311

The PR looks out of sync with this email patch.

Can you please update PR with latest patch and commit
message that was reviewed and add review tags?

Mike

> -Original Message-
> From: Wu, Jiaxin 
> Sent: Thursday, November 9, 2023 4:01 PM
> To: Laszlo Ersek ; devel@edk2.groups.io; Gao,
> Liming ; Kinney, Michael D
> 
> Cc: Dong, Eric ; Ni, Ray ;
> Zeng, Star ; Gerd Hoffmann ;
> Kumar, Rahul R 
> Subject: RE: [edk2-devel] [PATCH v4] UefiCpuPkg/PiSmmCpuDxeSmm: Fix CP
> Exception when CET enable
> 
> Hi Liming & Mike,
> 
> Could you help approve & merge this patch into stable tag? It has got
> below reviewed-by:
> 
> Reviewed-by: Laszlo Ersek 
> Reviewed-by: Ray Ni 
> Reviewed-by: Eric Dong 
> 
> I also created the PR: https://github.com/tianocore/edk2/pull/4867
> 
> Thanks,
> Jiaxin
> 
> 
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Wednesday, November 8, 2023 9:17 AM
> > To: Laszlo Ersek ; devel@edk2.groups.io; Gao,
> Liming
> > ; Kinney, Michael D
> > 
> > Cc: Dong, Eric ; Ni, Ray ;
> Zeng, Star
> > ; Gerd Hoffmann ; Kumar,
> Rahul R
> > 
> > Subject: RE: [edk2-devel] [PATCH v4] UefiCpuPkg/PiSmmCpuDxeSmm: Fix
> CP
> > Exception when CET enable
> >
> > Hi Liming & Mike & Ray,
> >
> > Could you help approve this change for the coming edk2 stable tag?
> This is
> > critical bug fix in smm cpu driver to handler the CET check failure,
> I think we
> > need this change for the stable tag.
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: Laszlo Ersek 
> > > Sent: Wednesday, November 8, 2023 2:57 AM
> > > To: devel@edk2.groups.io; Wu, Jiaxin 
> > > Cc: Dong, Eric ; Ni, Ray ;
> Zeng, Star
> > > ; Gerd Hoffmann ; Kumar,
> Rahul
> > R
> > > 
> > > Subject: Re: [edk2-devel] [PATCH v4] UefiCpuPkg/PiSmmCpuDxeSmm:
> Fix
> > CP
> > > Exception when CET enable
> > >
> > > On 11/7/23 02:24, Wu, Jiaxin wrote:
> > > > Root cause:
> > > > 1. Before DisableReadonlyPageWriteProtect() is called, the
> return
> > > > address (#1) is pushed in shadow stack.
> > > > 2. CET is disabled.
> > > > 3. DisableReadonlyPageWriteProtect() returns to #1.
> > > > 4. Page table is modified.
> > > > 5. EnableReadonlyPageWriteProtect() is called, but the return
> > > > address (#2) is not pushed in shadow stack.
> > > > 6. CET is enabled.
> > > > 7. EnableReadonlyPageWriteProtect() returns to #2.
> > > > #CP exception happens because the actual return address (#2)
> > > > doesn't match the return address stored in shadow stack (#1).
> > > >
> > > > Analysis:
> > > > Shadow stack will stop update after CET disable (DisableCet() in
> > > > DisableReadOnlyPageWriteProtect), but normal smi stack will be
> > > > continue updated with the function called and return
> > > > (DisableReadOnlyPageWriteProtect &
> EnableReadOnlyPageWriteProtect),
> > > > thus leading stack mismatch after CET re-enabled (EnableCet() in
> > > > EnableReadOnlyPageWriteProtect).
> > > >
> > > > According SDM Vol 3, 6.15-Control Protection Exception:
> > > > Normal smi stack and shadow stack must be matched when CET
> enable,
> > > > otherwise CP Exception will happen, which is caused by a near
> RET
> > > > instruction.
> > > >
> > > > CET is disabled in DisableCet(), while can be enabled in
> > > > EnableCet(). This way won't cause the problem because they are
> > > > implemented in a way that return address of DisableCet() is
> > > > poped out from shadow stack (Incsspq performs a pop to increases
> > > > the shadow stack) and EnableCet() doesn't use "RET" but "JMP" to
> > > > return to caller. So calling EnableCet() and DisableCet()
> doesn't
> > > > have the same issue as calling DisableReadonlyPageWriteProtect()
> > > > and EnableReadonlyPageWriteProtect().
> > > >
> > > > With above root cause & analysis, define below 2 macros instead
> of
> > > > functions for WP & CET operation:
> > > > WRITE_UNPROTECT_RO_PAGES (Wp, Cet)
> > > > WRITE_PROTECT_RO_PAGES (Wp, Cet)
> > > > Because DisableCet() & EnableCet() must be in the same function
> > > > to avoid shadow stack and normal SMI stack mismatch.
> > > >
> > > > Note: WRITE_UNPROTECT_RO_PAGES () must be called pair with
> > > > WRITE_PROTECT_RO_PAGES () in same function.
> > > >
> > > > Cc: Eric Dong 
> > > > Cc: Ray Ni 
> > > > Cc: Zeng Star 
> > > > Cc: Gerd Hoffmann 
> > > > Cc: Rahul Kumar 
> > > > Cc: Laszlo Ersek 
> > > > Signed-off-by: Jiaxin Wu 
> > > > ---
> > > >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 59
> > > +
> > > >  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 73
> > > +-
> > > >  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  7 ++-
> > > >  3 files changed, 81 insertions(+), 58 deletions(-)
> > >
> > > Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111002): https://edk2.groups.io/g/devel/message/111002
Mute This Topic: https://groups.io/mt/102434876/21656

Re: [edk2-devel] [PATCH v3 1/2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe: Fix OVERRUN Coverity issues

[Michael D Kinney]

Hi Ranbir,

A deadloop without even a debug print is not good behavior.

If this condition really represents a condition where it is not possible
to complete the PCI resource allocation/assignment, then an error status
code should be returned to the caller of NotifyPhase().  Perhaps
EFI_OUT_OF_RESOURCES.  The other ASSERT() conditions in this API should
likely be updated to do the same.

This may also require the caller of this service, the PCI Bus Driver,
to be reviewed to make sure it handles error conditions from NotifyPhase().

I recommend you get help on the proposed code changes from the PCI
subsystem maintainers.

Thanks,

Mike



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ranbir
> Singh
> Sent: Thursday, November 9, 2023 9:39 AM
> To: devel@edk2.groups.io; rsi...@ventanamicro.com
> Cc: Ni, Ray ; Veeresh Sangolli
> 
> Subject: [edk2-devel] [PATCH v3 1/2]
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe: Fix OVERRUN Coverity issues
> 
> From: Ranbir Singh 
> 
> The function NotifyPhase has a check
> 
> ASSERT (Index < TypeMax);
> 
> but this comes into play only in DEBUG mode. In Release mode, there is
> no handling if the Index value is within array limits or not. If for
> whatever reasons, the Index does not get re-assigned to Index2 at line
> 937, then it remains at TypeMax as assigned earlier at line 929. This
> poses array overrun risk at lines 942 and 943. It is better to deploy
> a safety check on Index limit before accessing array elements.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4212
> 
> Cc: Ray Ni 
> Co-authored-by: Veeresh Sangolli 
> Signed-off-by: Ranbir Singh 
> Signed-off-by: Ranbir Singh 
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> index d573e532bac8..c2c143068cd2 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> @@ -939,6 +939,11 @@ NotifyPhase (
>  }
> 
> 
> 
>  ASSERT (Index < TypeMax);
> 
> +
> 
> +if (Index == TypeMax) {
> 
> +  CpuDeadLoop ();
> 
> +}
> 
> +
> 
>  ResNodeHandled[Index] = TRUE;
> 
>  Alignment = RootBridge-
> >ResAllocNode[Index].Alignment;
> 
>  BitsOfAlignment   = LowBitSet64 (Alignment + 1);
> 
> --
> 2.34.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#110993):
> https://edk2.groups.io/g/devel/message/110993
> Mute This Topic: https://groups.io/mt/102490513/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 (#110999): https://edk2.groups.io/g/devel/message/110999
Mute This Topic: https://groups.io/mt/102490513/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: Remove unused OvmfPkg Confidential Computing path

[Michael D Kinney]

Merged: 
https://github.com/tianocore/edk2/pull/5027
https://github.com/tianocore/edk2/commit/35c0c63edbab6a37d6c019d613a4b06529941a80

Mike

> -Original Message-
> From: gaoliming 
> Sent: Thursday, November 9, 2023 5:44 AM
> To: devel@edk2.groups.io; quic_llind...@quicinc.com; Kinney, Michael D
> 
> Cc: 'Andrew Fish' ; Aktas, Erdem
> ; Yao, Jiewen ; Xu, Min M
> ; 'Tom Lendacky' ;
> 'Michael Roth' 
> Subject: 回复: [edk2-devel] [Patch 1/1] Maintainers.txt: Remove unused
> OvmfPkg Confidential Computing path
> 
> I agree to merge it for this stable tag.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Leif Lindholm
> > 发送时间: 2023年11月9日 17:51
> > 收件人: Michael D Kinney ;
> > devel@edk2.groups.io
> > 抄送: Andrew Fish ; Erdem Aktas
> > ; Jiewen Yao ; Min Xu
> > ; Tom Lendacky ;
> > Michael Roth 
> > 主题: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Remove unused
> OvmfPkg
> > Confidential Computing path
> >
> > Reviewed-by: Leif Lindholm 
> >
> > I see no issues with this going in during soft freeze.
> >
> > /
> >  Leif
> >
> > On 2023-11-08 03:49, Michael D Kinney wrote:
> > > The following commit removed PlatformBootManagerLibGub from
> > > OvmfPkg.  Update Maintainers.txt to remove reference to
> > > deleted directory.
> > >
> > >
> > https://github.com/tianocore/edk2/commit/6fb2760dc8939b16a906b8e6bb2
> > 24764907168f3
> > >
> > > Cc: Andrew Fish 
> > > Cc: Leif Lindholm 
> > > Cc: Erdem Aktas 
> > > Cc: Jiewen Yao 
> > > Cc: Min Xu 
> > > Cc: Tom Lendacky 
> > > Cc: Michael Roth 
> > > Signed-off-by: Michael D Kinney 
> > > ---
> > >   Maintainers.txt | 1 -
> > >   1 file changed, 1 deletion(-)
> > >
> > > diff --git a/Maintainers.txt b/Maintainers.txt
> > > index cfbde42f2e04..7c0b4cb58cfd 100644
> > > --- a/Maintainers.txt
> > > +++ b/Maintainers.txt
> > > @@ -497,7 +497,6 @@ F:
> > OvmfPkg/Include/Guid/ConfidentialComputingSecret.h
> > >   F: OvmfPkg/Include/Library/MemEncryptSevLib.h
> > >   F: OvmfPkg/IoMmuDxe/CcIoMmu.*
> > >   F: OvmfPkg/Library/BaseMemEncryptSevLib/
> > > -F: OvmfPkg/Library/PlatformBootManagerLibGrub/
> > >   F: OvmfPkg/Library/CcExitLib/
> > >   F: OvmfPkg/PlatformPei/AmdSev.c
> > >   F: OvmfPkg/ResetVector/
> >
> >
> >
> > 
> >
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110998): https://edk2.groups.io/g/devel/message/110998
Mute This Topic: https://groups.io/mt/102493816/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] BaseTools/tools_def: drop -mgeneral-regs-only for AArch64 CLANGDWARF

[Michael D Kinney]

Merged:
https://github.com/tianocore/edk2/pull/5023
https://github.com/tianocore/edk2/commit/e077ccff6d0f2e8c3fc44b3e2ab71aff66927c3b

Mike


> -Original Message-
> From: Leif Lindholm 
> Sent: Thursday, November 9, 2023 6:39 AM
> To: devel@edk2.groups.io; Gao, Liming 
> Cc: 'Yeping Song (QUIC)' ; 'Rebecca Cran'
> ; Feng, Bob C ; Chen,
> Christine ; 'Ard Biesheuvel'
> ; 'Sami Mujawar' ;
> Kinney, Michael D 
> Subject: Re: 回复: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop -
> mgeneral-regs-only for AArch64 CLANGDWARF
> 
> Thanks!
> 
> https://github.com/tianocore/edk2/pull/5023 raised.
> 
> /
> Leif
> 
> On Thu, Nov 09, 2023 at 21:42:38 +0800, gaoliming via groups.io wrote:
> > Leif:
> >   Sure. This patch can be merged for this stable tag.
> >
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Leif
> Lindholm
> > > 发送时间: 2023年11月7日 21:13
> > > 收件人: Yeping Song (QUIC) ;
> > > devel@edk2.groups.io; Liming Gao 
> > > 抄送: Rebecca Cran ; Bob Feng
> > > ; Yuwei Chen ; Ard
> > > Biesheuvel ; Sami Mujawar
> > > ; Kinney, Michael D
> 
> > > 主题: Re: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop
> > > -mgeneral-regs-only for AArch64 CLANGDWARF
> > >
> > > Liming,
> > >
> > > You reviewed this patch before the stable tag. Am I OK to stage a
> github
> > > PR for this change?
> > >
> > > Reviewed-by: Leif Lindholm 
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > On 2023-11-07 13:11, Yeping Song (QUIC) wrote:
> > > > Hi all,
> > > > I would like for this to be include in stable tag. Please help
> to review and
> > > merge this patch into stable release.
> > > > Thanks
> > > > Yepings
> > > >
> > > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of
> Yeping
> > > Song
> > > > Sent: Saturday, November 4, 2023 12:38 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Yeping Song (QUIC) ; Rebecca Cran
> > > ; Liming Gao ; Bob
> Feng
> > > ; Yuwei Chen ; Ard
> > > Biesheuvel ; Leif Lindholm (QUIC)
> > > ; Sami Mujawar 
> > > > Subject: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop
> > > -mgeneral-regs-only for AArch64 CLANGDWARF
> > > >
> > > > WARNING: This email originated from outside of Qualcomm. Please
> be wary
> > > of any links or attachments, and do not enable macros.
> > > >
> > > > Commit 0df6c8c157af9 ("BaseTools/tools_def AARCH64:
> > > > avoid SIMD registers in XIP code")
> > > > adds -mgeneral-regs-only to GCC_AARCH64_CC_XIPFLAGS, in order to
> avoid
> > > a bug present in certain versions of GCC.
> > > > This was never a problem for clang.
> > > > That's given the history of what the problem is.
> > > > Then we can describe how we fix it:
> > > > Change *_CLANGDWARF_AARCH64_CC_XIPFLAGS to set the required
> > > -mstrict-align option instead of importing the whole GCC variable.
> > > >
> > > > Signed-off-by: Yeping Song 
> > > > Cc: Rebecca Cran 
> > > > Cc: Liming Gao 
> > > > Cc: Bob Feng 
> > > > Cc: Yuwei Chen 
> > > > Cc: Ard Biesheuvel 
> > > > Cc: Leif Lindholm 
> > > > Cc: Sami Mujawar 
> > > > ---
> > > >   BaseTools/Conf/tools_def.template | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/BaseTools/Conf/tools_def.template
> > > b/BaseTools/Conf/tools_def.template
> > > > index 5bd5283655ea..c34ecfd557c5 100755
> > > > --- a/BaseTools/Conf/tools_def.template
> > > > +++ b/BaseTools/Conf/tools_def.template
> > > > @@ -2015,7 +2015,7 @@ DEFINE CLANGDWARF_AARCH64_DLINK_FLAGS
> > > = DEF(CLANGDWARF_AARCH64_TARGET) DEF(GCC_
> > > >   *_CLANGDWARF_AARCH64_RC_FLAGS   =
> > > DEF(GCC_AARCH64_RC_FLAGS) DEF(GCC_AARCH64_RC_BTI_FLAGS)
> > > >   *_CLANGDWARF_AARCH64_VFRPP_FLAGS=
> > > DEF(GCC_VFRPP_FLAGS) DEF(CLANGDWARF_AARCH64_TARGET)
> > > $(PLATFORM_FLAGS)
> > > >   *_CLANGDWARF_AARCH64_ASLPP_FLAGS=
> > > DEF(GCC_ASLPP_FLAGS) DEF(CLANGDWARF_AARCH64_TARGET)
> > > > -*_CLANGDWARF_AARCH64_CC_XIPFLAGS=
> > > DEF(GCC_AARCH64_CC_XIPFLAGS)
> > > > +*_CLANGDWARF_AARCH64_CC_XIPFLAGS= -mstrict-align
> > > >
> > > > DEBUG_CLANGDWARF_AARCH64_CC_FLAGS=
> > > DEF(CLANGDWARF_AARCH64_CC_FLAGS) $(PLATFORM_FLAGS) -flto -O1
> > > > DEBUG_CLANGDWARF_AARCH64_DLINK_FLAGS =
> > > DEF(CLANGDWARF_AARCH64_DLINK_FLAGS) -flto -Wl,-O1 -fuse-ld=lld
> > > -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64
> > > -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wl,--no-pie,--no-
> relax
> > > > --
> > > > 2.25.1
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > 
> >
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110996): https://edk2.groups.io/g/devel/message/110996
Mute This Topic: https://groups.io/mt/102485456/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] Sync BSP's APIC mode to APs in MP init flow

[Michael D Kinney]

+Ray

Unless I missed it, I do not see review of the patch series Ray sent back in 
July.

Mike

From: devel@edk2.groups.io  On Behalf Of Aaron Young via 
groups.io
Sent: Thursday, November 9, 2023 8:29 AM
To: Gerd Hoffmann ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 0/4] Sync BSP's APIC mode to APs in MP init 
flow




 Hello, is this issue/patch still being worked/considered? If so, is there an 
ETA?

 Without this fix, one cannot hotplug beyond 255 vcpus with OVMF and we need 
this capability.

 NOTE: Gerd's original fix (https://edk2.groups.io/g/devel/message/100801), 
does allow hotplug beyond 255 vcpus. So, that fix seems viable. Should it be 
re-evaluated?

 We would gladly test a fix if that would be helpful.

 Thanks in advance!

 -Aaron Young (aaron.yo...@oracle.com)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110995): https://edk2.groups.io/g/devel/message/110995
Mute This Topic: https://groups.io/mt/10874/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] [edk2-stable202311][Patch 1/1] BaseTools/Scripts: Handle reviewer only case in GetMaintainer.py

[Michael D Kinney]

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

If a package only has reviewers and no maintainers, then also
return the  maintainers.

Update get_maintainers() to return maintainers, reviews, and
lists separately instead of a single merged list to allow this
module to be used by other scripts and distinguish types.

Sort the list of output addresses alphabetically.

Fix logic bug where maintainers was incorrectly added to lists.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 42 ++
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index d1e042c0afe4..b33546b10f21 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -76,6 +76,7 @@ def get_section_maintainers(path, section):
 """Returns a list with email addresses to any M: and R: entries
matching the provided path in the provided section."""
 maintainers = []
+reviewers = []
 lists = []
 nowarn_status = ['Supported', 'Maintained']
 
@@ -83,12 +84,18 @@ def get_section_maintainers(path, section):
 for status in section['status']:
 if status not in nowarn_status:
 print('WARNING: Maintained status for "%s" is \'%s\'!' % 
(path, status))
-for address in section['maintainer'], section['reviewer']:
+for address in section['maintainer']:
 # Convert to list if necessary
 if isinstance(address, list):
 maintainers += address
 else:
-lists += [address]
+maintainers += [address]
+for address in section['reviewer']:
+# Convert to list if necessary
+if isinstance(address, list):
+reviewers += address
+else:
+reviewers += [address]
 for address in section['list']:
 # Convert to list if necessary
 if isinstance(address, list):
@@ -96,32 +103,34 @@ def get_section_maintainers(path, section):
 else:
 lists += [address]
 
-return maintainers, lists
+return maintainers, reviewers, lists
 
 def get_maintainers(path, sections, level=0):
 """For 'path', iterates over all sections, returning maintainers
for matching ones."""
 maintainers = []
+reviewers = []
 lists = []
 for section in sections:
-tmp_maint, tmp_lists = get_section_maintainers(path, section)
-if tmp_maint:
-maintainers += tmp_maint
-if tmp_lists:
-lists += tmp_lists
+tmp_maint, tmp_review, tmp_lists = get_section_maintainers(path, 
section)
+maintainers += tmp_maint
+reviewers += tmp_review
+lists += tmp_lists
 
 if not maintainers:
 # If no match found, look for match for (nonexistent) file
 # REPO.working_dir/
 print('"%s": no maintainers found, looking for default' % path)
 if level == 0:
-maintainers = get_maintainers('', sections, level=level + 
1)
+maintainers, tmp_review, tmp_lists = get_maintainers('', 
sections, level=level + 1)
+reviewers += tmp_review
+lists += tmp_lists
 else:
 print("No  maintainers set for project.")
 if not maintainers:
 return None
 
-return maintainers + lists
+return maintainers, reviewers, lists
 
 def parse_maintainers_line(line):
 """Parse one line of Maintainers.txt, returning any match group and its 
key."""
@@ -182,15 +191,16 @@ if __name__ == '__main__':
 else:
 FILES = get_modified_files(REPO, ARGS)
 
-ADDRESSES = []
-
+# Accumulate a sorted list of addresses
+ADDRESSES = set([])
 for file in FILES:
 print(file)
-addresslist = get_maintainers(file, SECTIONS)
-if addresslist:
-ADDRESSES += addresslist
+maintainers, reviewers, lists = get_maintainers(file, SECTIONS)
+ADDRESSES |= set(maintainers + reviewers + lists)
+ADDRESSES = list(ADDRESSES)
+ADDRESSES.sort()
 
-for address in list(OrderedDict.fromkeys(ADDRESSES)):
+for address in ADDRESSES:
 if '<' in address and '>' in address:
 address = address.split('>', 1)[0] + '>'
 print('  %s' % address)
-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110925): https://edk2.groups.io/g/devel/message/110925
Mute This Topic: https://groups.io/mt/102472591/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 2/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix MISSING_BREAK Coverity issues

[Michael D Kinney]

Hi Ranbir,

Ignoring false positive in static analysis tools is typically a burden.

It is better to avoid false positives with code changes as long as the code 
changes do not make the implementation confusing and hard to maintain.

I think depending on fall through case statements is confusing and removing 
them will make the code easier to understand and maintain.

Mike

From: Ranbir Singh 
Sent: Tuesday, November 7, 2023 7:51 PM
To: Kinney, Michael D 
Cc: devel@edk2.groups.io; ler...@redhat.com; Ni, Ray ; 
Veeresh Sangolli 
Subject: Re: [edk2-devel] [PATCH v2 2/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix 
MISSING_BREAK Coverity issues

As mentioned in the commit message, the comment helps in making it explicit and 
evident that the missing break is not a human miss, but intentional.
Hence, the comment should be considered as being added for the human code 
readers / developers.

So even if some static analysis tool flags such an issue, it can be fairly easy 
now to ignore that on manual inspection. If desired this can also be stated in 
the comment itself like -

+  //
+  // No break here as this is an intentional fall through.
+  // Ignore any static tool issue if pointed.
+  //

Yes, there can be other solutions (which may or may not be worth the effort), 
but for now I went with the least code change approach.

On Tue, Nov 7, 2023 at 11:29 PM Kinney, Michael D 
mailto:michael.d.kin...@intel.com>> wrote:
This comment style only works with Coverity.

Other static analysis tools may flag the same issue again.

It is better to update the logic so no static analysis tool will
flag this issue.

Mike

> -Original Message-
> From: devel@edk2.groups.io 
> mailto:devel@edk2.groups.io>> On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 7, 2023 8:23 AM
> To: devel@edk2.groups.io; 
> rsi...@ventanamicro.com
> Cc: Ni, Ray mailto:ray...@intel.com>>; Veeresh Sangolli
> mailto:veeresh.sango...@dellteam.com>>
> Subject: Re: [edk2-devel] [PATCH v2 2/5]
> MdeModulePkg/Bus/Pci/PciBusDxe: Fix MISSING_BREAK Coverity issues
>
> On 11/7/23 07:19, Ranbir Singh wrote:
> > From: Ranbir Singh mailto:ranbir.sin...@dell.com>>
> >
> > The function UpdatePciInfo has switch-case code in which there are
> fall
> > through from case 32: to case 64:. While this is seeemingly
> intentional,
> > it is not evident to any general code reader why there is no break;
> in
> > between. Adding
> >
> > // No break; here as this is an intentional fallthrough.
> >
> > as comment in between makes it explicit. Incidentally, the comment
> > satisfies Coverity as well.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4239
> >
> > Cc: Ray Ni mailto:ray...@intel.com>>
> > Co-authored-by: Veeresh Sangolli 
> > mailto:veeresh.sango...@dellteam.com>>
> > Signed-off-by: Ranbir Singh 
> > mailto:ranbir.sin...@dell.com>>
> > Signed-off-by: Ranbir Singh 
> > mailto:rsi...@ventanamicro.com>>
> > ---
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > index 6594b8eae83f..eda97285ee18 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
> > @@ -1428,6 +1428,9 @@ UpdatePciInfo (
> >switch (Ptr->AddrSpaceGranularity) {
> >  case 32:
> >PciIoDevice->PciBar[BarIndex].BarType =
> PciBarTypeMem32;
> > +  //
> > +  // No break; here as this is an intentional fall
> through.
> > +  //
> >  case 64:
> >PciIoDevice->PciBar[BarIndex].BarTypeFixed =
> TRUE;
> >break;
> > @@ -1440,6 +1443,9 @@ UpdatePciInfo (
> >switch (Ptr->AddrSpaceGranularity) {
> >  case 32:
> >PciIoDevice->PciBar[BarIndex].BarType =
> PciBarTypePMem32;
> > +  //
> > +  // No break; here as this is an intentional fall
> through.
> > +  //
> >  case 64:
> >PciIoDevice->PciBar[BarIndex].BarTypeFixed =
> TRUE;
> >break;
>
> Agree, but the semicolon's placement is awkward. I propose
>
>   No break here, as this is an intentional fall through.
>
> Reviewed-by: Laszlo Ersek mailto:ler...@redhat.com>>
>
>
>
> 
>


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

[edk2-devel] [Patch 1/1] Maintainers.txt: Remove unused OvmfPkg Confidential Computing path

[Michael D Kinney]

The following commit removed PlatformBootManagerLibGub from
OvmfPkg.  Update Maintainers.txt to remove reference to
deleted directory.

https://github.com/tianocore/edk2/commit/6fb2760dc8939b16a906b8e6bb224764907168f3

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Erdem Aktas 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Michael D Kinney 
---
 Maintainers.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index cfbde42f2e04..7c0b4cb58cfd 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -497,7 +497,6 @@ F: OvmfPkg/Include/Guid/ConfidentialComputingSecret.h
 F: OvmfPkg/Include/Library/MemEncryptSevLib.h
 F: OvmfPkg/IoMmuDxe/CcIoMmu.*
 F: OvmfPkg/Library/BaseMemEncryptSevLib/
-F: OvmfPkg/Library/PlatformBootManagerLibGrub/
 F: OvmfPkg/Library/CcExitLib/
 F: OvmfPkg/PlatformPei/AmdSev.c
 F: OvmfPkg/ResetVector/
-- 
2.40.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110889): https://edk2.groups.io/g/devel/message/110889
Mute This Topic: https://groups.io/mt/102458044/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] MdeModulePkg/PciHostBridgeDxe: Add readback after final Cfg-Write

[Michael D Kinney]

Hi Jose,


  1.  This logic needs to move into an AARCH64 specific directory/file.  Other 
architectures handle this in other ways.
  2.  There are many places throughout edk2 sources that perform PCI config 
write operations.  You are only fixing it in a single location.  You may want 
to look at the MdePkg PciLibs to see if it can be addressed there with an 
AARCH64 specific dir/file, but that still may not address all possible PCI 
config write accesses.  Fill analysis of the target platform sources may be 
required to make sure it is fixes for all locations.

Mike

From: Jose Lopez 
Sent: Tuesday, November 7, 2023 10:59 AM
To: devel@edk2.groups.io
Cc: Leif Lindholm ; Ard Biesheuvel 
; Gao, Liming ; Michael 
Brown ; Pedro Falcato ; Ni, Ray 
; Wu, Hao A ; Wang, Jian J 
; Sami Mujawar ; 
ler...@redhat.com; Kinney, Michael D 
Subject: Re: [PATCH v2] MdeModulePkg/PciHostBridgeDxe: Add readback after final 
Cfg-Write

++ Laszlo and Michael

On Tue, Nov 7, 2023 at 10:54 AM Jose Lopez 
mailto:jlo...@gmail.com>> wrote:
++ CC'd


On Mon, Nov 6, 2023 at 6:02 PM Joe Lopez 
mailto:jlo...@gmail.com>> wrote:
From: joelopez333 mailto:jlo...@gmail.com>>

REF:https://edk2.groups.io/g/devel/topic/102310377#110456

Problem Report:

On AARCH64, there is no ordering guarantee between configuration
space (ECAM) writes and memory space reads (MMIO). ARM AMBA CHI
only guarantees ordering for reads and writes within a single address 
region,
however, on some systems MMIO and ECAM may be split into separate
address regions.

A problem may arise when an ECAM write is issued a completion before a 
subsequent
MMIO read is issued and receives a completion.

For example, a typical PCI software flow is the following:

1. ECAM write to device command register to enable memory space
2. MMIO read from device memory space for which access was enabled
in step 1.

There is no guarantee that step 2. will not begin before the completion of 
step 1.
on systems where ECAM/MMIO are specified as separate address regions, even
if both spaces have the memory attributes device-nGnRnE.

Fix:

- Add a read after the final PCI Configuration space write
  in RootBridgeIoPciAccess.

- When configuration space is strongly ordered, this ensures
  that program execution cannot continue until the completion
  is received for the previous Cfg-Write, which may have side-effects.

- Risk of reading a "write-only" register and causing a CA which leaves the 
device
  unresponsive. The expectation based on the PCI Base Spec v6.1 section 7.4 
is that
  all PCI Spec-defined registers will be readable, however, there may exist
  design-specific registers that fall into this category.

Cc: Leif Lindholm 
mailto:quic_llind...@quicinc.com>>
Cc: Ard Biesheuvel 
mailto:ardb%2btianoc...@kernel.org>>
Cc: Sami Mujawar mailto:sami.muja...@arm.com>>
Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Ray Ni mailto:ray...@intel.com>>
Cc: Pedro Falcato mailto:pedro.falc...@gmail.com>>
Cc: Michael Brown mailto:mc...@ipxe.org>>
Signed-off-by: Joe Lopez mailto:jlot...@gmail.com>>
---
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
index 157a0ada80..c2dc2018d6 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
@@ -1238,6 +1238,14 @@ RootBridgeIoPciAccess (
 }
   }

+  //
+  // Perform readback after write to confirm completion was received for the 
last write
+  // before subsequent memory operations can be issued.
+  //
+  if (!Read) {
+PciSegmentRead8 (Address - InStride);
+  }
+
   return EFI_SUCCESS;
 }

--
2.25.1


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