Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler

[Ni, Ray]

Felix, I remember you mentioned to me about the usage of SMI handler 
unregistering itself.

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang 
> Sent: Wednesday, January 24, 2024 12:03 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Liming Gao
> ; Wu, Jiaxin ; Ni, Ray
> 
> Subject: [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler
> inside SMI handler
> 
> To support unregister SMI handler inside SMI handler itself,
> get next node before SMI handler is executed, since LIST_ENTRY that
> Link points to may be freed if unregister SMI handler in SMI handler
> itself.
> 
> Cc: Liming Gao 
> Cc: Jiaxin Wu 
> Cc: Ray Ni 
> Signed-off-by: Zhiguang Liu 
> ---
>  MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index 2985f989c3..a75e52b1ae 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -134,8 +134,14 @@ SmiManage (
> 
>Head = &SmiEntry->SmiHandlers;
> 
> -  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
> +  for (Link = Head->ForwardLink; Link != Head;) {
>  SmiHandler = CR (Link, SMI_HANDLER, Link,
> SMI_HANDLER_SIGNATURE);
> +//
> +// To support unregiser SMI handler inside SMI handler itself,
> +// get next node before handler is executed, since LIST_ENTRY that
> +// Link points to may be freed if unregister SMI handler.
> +//
> +Link = Link->ForwardLink;
> 
>  Status = SmiHandler->Handler (
> (EFI_HANDLE)SmiHandler,
> --
> 2.31.1.windows.1



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

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

[Michael D Kinney]

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


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

Re: [edk2-devel] [PATCH 00/14] Security Patches for EDK II Network Stack

[Pedro Falcato]

On Wed, Jan 24, 2024 at 5:20 AM Doug Flick via groups.io
 wrote:
>
> The security patches contained in this series with the exception of
> "MdePkg/Test: Add gRT_GetTime Google Test Mock" and
> "NetworkPkg: : Adds a SecurityFix.yaml file" have been reviewed
> during GHSA-hc6x-cw6p-gj7h infosec review.
>
> This patch series contains the following security patches for the
> security vulnerabilities found by QuarksLab in the EDK II Network
> Stack:
>
> CVE-2023-45229
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Read
>
> CVE-2023-45230
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations within the Bounds
>  of a Memory Buffer
>
> CVE-2023-45231
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Read
>
> CVE-2023-45232
> CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
>
> CVE-2023-45233
> CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
>
> CVE-2023-45234
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations within the Bounds
>  of a Memory Buffer
>
> CVE-2023-45235
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations within the Bounds
>  of a Memory Buffer
>
> NetworkPkg:
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
>
> MdePkg:
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
>
> Doug Flick (8):
>   NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45231 - Patch
>   NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45231 - Unit Tests
>   NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45232 Patch
>   NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45232 Unit Tests
>   NetworkPkg: UefiPxeBcDxe: SECURITY PATCH CVE-2023-45234 Patch
>   NetworkPkg: UefiPxeBcDxe: SECURITY PATCH CVE-2023-45234 Unit Tests
>   NetworkPkg: UefiPxeBcDxe: SECURITY PATCH CVE-2023-45235 Patch
>   NetworkPkg: UefiPxeBcDxe: SECURITY PATCH CVE-2023-45235 Unit Tests
>
> Douglas Flick [MSFT] (6):
>   NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45230 Patch
>   NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45230 Unit Tests
>   NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45229 Patch
>   NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45229 Unit Tests
>   MdePkg: Test: Add gRT_GetTime Google Test Mock
>   NetworkPkg: : Adds a SecurityFix.yaml file

Thanks for the patches. Please rewrite the commit messages for each
specific patch to contain relevant details on the problem and fix. The
commits as-is are somewhat useless unless one wants to track down the
CVEs. Thanks!

-- 
Pedro


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

Re: [edk2-devel] [PATCH v3 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib

[Ni, Ray]

> +//
> +// Number of self-tests to perform.
> +//
> +#define NUMBER_OF_SELF_TESTS \
> +  (FixedPcdGet32 (PcdNestedInterruptNumberOfSelfTests))

1. can we avoid defining a PCD? I do not see a need that each platform needs
to use a different count. How about just define it as 1?

> +
> +STATIC
> +VOID
> +NestedInterruptSelfTest (
> +  IN NESTED_INTERRUPT_STATE  *IsrState
> +  );
> +
>  /**
>Raise the task priority level to TPL_HIGH_LEVEL.
> 
> @@ -211,6 +223,16 @@ NestedInterruptRestoreTPL (
>  //
>  DisableInterrupts ();
> 
> +///
> +/// Perform a limited number of self-tests on the first few
> +/// invocations.

2. the comment could mention that the self-test only is performed when
no nested interrupt happens in gBS->RestoreTpl() call in above.

> +///
> +if ((IsrState->DeferredRestoreTPL == FALSE) &&
> + (IsrState->SelfTestCount < NUMBER_OF_SELF_TESTS)) {

3. might have coding style issue.

> +  //
> +  // The test has failed and we will halt the system.  Disable
> +  // interrupts now so that any test-induced interrupt storm does not
> +  // prevent the fatal error messages from being displayed correctly.
> +  //

4. The comment might be wrong. It does not indicate the test has failed.
It's possible that the timer period is very long that causes no timer interrupt 
happens till now.
In that case, IsrState->DeferredRestoreTPL is FALSE. That's not an issue IMO.

Or, how about we stall for ever to wait for the timer interrupt instead of 
waiting just 1 second.
We could wait for the IsrState->DeferredRestoreTPL is TRUE.

> +  DisableInterrupts();
> +
> +  //
> +  // If we observe that DeferredRestoreTPL is TRUE then this indicates
> +  // that an interrupt did occur and NestedInterruptRestoreTPL() chose
> +  // to defer the RestoreTPL() call to the outer handler, but that
> +  // DisableInterruptsOnIret() failed to cause interrupts to be
> +  // disabled after the IRET or equivalent instruction.

5. The comment "failed to cause interrupts to be disabled after IRET" can be 
inside the if-condition.

> +  //
> +  // This error represents a bug in the architecture-specific
> +  // implementation of DisableInterruptsOnIret().
> +  //
> +  if (IsrState->DeferredRestoreTPL == TRUE) {
> +DEBUG ((
> +  DEBUG_ERROR,
> +  "Nested interrupt self-test %u/%u failed: interrupts still enabled\n",
> +  SelfTestCount,
> +  NUMBER_OF_SELF_TESTS
> +  ));
> +ASSERT (FALSE);
> +  }
> +


> +  //
> +  // If no timer interrupt occurred then this indicates that the timer
> +  // interrupt handler failed to rearm the timer before calling
> +  // NestedInterruptRestoreTPL().  This would prevent nested
> +  // interrupts from occurring at all, which would break
> +  // e.g. callbacks at TPL_CALLBACK that themselves wait on further
> +  // timer events.
> +  //
> +  // This error represents a bug in the platform-specific timer
> +  // interrupt handler.
> +  //
> +  DEBUG ((
> +DEBUG_ERROR,
> +"Nested interrupt self-test %u/%u failed: no nested interrupt\n",
> +SelfTestCount,
> +NUMBER_OF_SELF_TESTS
> +));
> +  ASSERT (FALSE);

6. If we change the above code to wait forever until the DeferredRestoreTPL is 
TRUE,
the above debug message and ASSERT() can be removed. Agree?

> +}
> --
> 2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114272): https://edk2.groups.io/g/devel/message/114272
Mute This Topic: https://groups.io/mt/103911608/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 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib

[Ni, Ray]

Thank you for adding the self-test code!

Thanks,
Ray
> -Original Message-
> From: Ni, Ray
> Sent: Wednesday, January 24, 2024 6:25 PM
> To: Michael Brown ; devel@edk2.groups.io
> Cc: Gerd Hoffmann ; Laszlo Ersek 
> Subject: RE: [PATCH v3 4/5] MdeModulePkg: Add self-tests for
> NestedInterruptTplLib
> 
> > +//
> > +// Number of self-tests to perform.
> > +//
> > +#define NUMBER_OF_SELF_TESTS \
> > +  (FixedPcdGet32 (PcdNestedInterruptNumberOfSelfTests))
> 
> 1. can we avoid defining a PCD? I do not see a need that each platform needs
> to use a different count. How about just define it as 1?
> 
> > +
> > +STATIC
> > +VOID
> > +NestedInterruptSelfTest (
> > +  IN NESTED_INTERRUPT_STATE  *IsrState
> > +  );
> > +
> >  /**
> >Raise the task priority level to TPL_HIGH_LEVEL.
> >
> > @@ -211,6 +223,16 @@ NestedInterruptRestoreTPL (
> >  //
> >  DisableInterrupts ();
> >
> > +///
> > +/// Perform a limited number of self-tests on the first few
> > +/// invocations.
> 
> 2. the comment could mention that the self-test only is performed when
> no nested interrupt happens in gBS->RestoreTpl() call in above.
> 
> > +///
> > +if ((IsrState->DeferredRestoreTPL == FALSE) &&
> > +   (IsrState->SelfTestCount < NUMBER_OF_SELF_TESTS)) {
> 
> 3. might have coding style issue.
> 
> > +  //
> > +  // The test has failed and we will halt the system.  Disable
> > +  // interrupts now so that any test-induced interrupt storm does not
> > +  // prevent the fatal error messages from being displayed correctly.
> > +  //
> 
> 4. The comment might be wrong. It does not indicate the test has failed.
> It's possible that the timer period is very long that causes no timer 
> interrupt
> happens till now.
> In that case, IsrState->DeferredRestoreTPL is FALSE. That's not an issue IMO.
> 
> Or, how about we stall for ever to wait for the timer interrupt instead of
> waiting just 1 second.
> We could wait for the IsrState->DeferredRestoreTPL is TRUE.
> 
> > +  DisableInterrupts();
> > +
> > +  //
> > +  // If we observe that DeferredRestoreTPL is TRUE then this indicates
> > +  // that an interrupt did occur and NestedInterruptRestoreTPL() chose
> > +  // to defer the RestoreTPL() call to the outer handler, but that
> > +  // DisableInterruptsOnIret() failed to cause interrupts to be
> > +  // disabled after the IRET or equivalent instruction.
> 
> 5. The comment "failed to cause interrupts to be disabled after IRET" can be
> inside the if-condition.
> 
> > +  //
> > +  // This error represents a bug in the architecture-specific
> > +  // implementation of DisableInterruptsOnIret().
> > +  //
> > +  if (IsrState->DeferredRestoreTPL == TRUE) {
> > +DEBUG ((
> > +  DEBUG_ERROR,
> > +  "Nested interrupt self-test %u/%u failed: interrupts still
> enabled\n",
> > +  SelfTestCount,
> > +  NUMBER_OF_SELF_TESTS
> > +  ));
> > +ASSERT (FALSE);
> > +  }
> > +
> 
> 
> > +  //
> > +  // If no timer interrupt occurred then this indicates that the timer
> > +  // interrupt handler failed to rearm the timer before calling
> > +  // NestedInterruptRestoreTPL().  This would prevent nested
> > +  // interrupts from occurring at all, which would break
> > +  // e.g. callbacks at TPL_CALLBACK that themselves wait on further
> > +  // timer events.
> > +  //
> > +  // This error represents a bug in the platform-specific timer
> > +  // interrupt handler.
> > +  //
> > +  DEBUG ((
> > +DEBUG_ERROR,
> > +"Nested interrupt self-test %u/%u failed: no nested interrupt\n",
> > +SelfTestCount,
> > +NUMBER_OF_SELF_TESTS
> > +));
> > +  ASSERT (FALSE);
> 
> 6. If we change the above code to wait forever until the DeferredRestoreTPL
> is TRUE,
> the above debug message and ASSERT() can be removed. Agree?
> 
> > +}
> > --
> > 2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114273): https://edk2.groups.io/g/devel/message/114273
Mute This Topic: https://groups.io/mt/103911608/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 07/14] NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45232 Patch

[Pedro Falcato]

On Wed, Jan 24, 2024 at 5:20 AM Doug Flick via groups.io
 wrote:
>
> From: Doug Flick 
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4537
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4538
>
> SECURITY PATCH - Patch
>
> TCBZ4537
> CVE-2023-45232
> CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
>
> TCBZ4538
> CVE-2023-45233
> CVSS 7.5 : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
> CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop')
>
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
>
> Signed-off-by: Doug Flick [MSFT] 
> ---
>  NetworkPkg/Ip6Dxe/Ip6Option.h | 89 +++
>  NetworkPkg/Ip6Dxe/Ip6Option.c | 76 +-
>  2 files changed, 154 insertions(+), 11 deletions(-)
>
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Option.h b/NetworkPkg/Ip6Dxe/Ip6Option.h
> index bd8e223c8a67..5d786073ebcb 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Option.h
> +++ b/NetworkPkg/Ip6Dxe/Ip6Option.h
> @@ -12,6 +12,95 @@
>
>  #define IP6_FRAGMENT_OFFSET_MASK  (~0x3)
>
> +//
> +// Per RFC8200 Section 4.2
> +//
> +//   Two of the currently-defined extension headers -- the Hop-by-Hop
> +//   Options header and the Destination Options header -- carry a variable
> +//   number of type-length-value (TLV) encoded "options", of the following
> +//   format:
> +//
> +//  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
> +//  |  Option Type  |  Opt Data Len |  Option Data
> +//  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
> +//
> +//  Option Type  8-bit identifier of the type of option.
> +//
> +//  Opt Data Len 8-bit unsigned integer.  Length of the Option
> +//   Data field of this option, in octets.
> +//
> +//  Option Data  Variable-length field.  Option-Type-specific
> +//   data.
> +//

Why isn't this just a

struct Ipv6Option {
  UINT8 OptionType;
  UINT8 OptionLength;
  UINT8 OptionData[];
};

? You'd skip all of the weird obfuscated math below.

> +#define IP6_SIZE_OF_OPT_TYPE  (sizeof(UINT8))
> +#define IP6_SIZE_OF_OPT_LEN   (sizeof(UINT8))

sizeof(UINT8) can just be replaced by 1
> +#define IP6_COMBINED_SIZE_OF_OPT_TAG_AND_LEN  (IP6_SIZE_OF_OPT_TYPE + 
> IP6_SIZE_OF_OPT_LEN)
> +#define IP6_OFFSET_OF_OPT_LEN(a)  (a + IP6_SIZE_OF_OPT_TYPE)
> +STATIC_ASSERT (
> +  IP6_OFFSET_OF_OPT_LEN (0) == 1,
> +  "The Length field should be 1 octet (8 bits) past the start of the option"
> +  );
> +
> +#define IP6_NEXT_OPTION_OFFSET(offset, length)  (offset + 
> IP6_COMBINED_SIZE_OF_OPT_TAG_AND_LEN + length)
> +STATIC_ASSERT (
> +  IP6_NEXT_OPTION_OFFSET (0, 0) == 2,
> +  "The next option is minimally the combined size of the option tag and 
> length"
> +  );
> +
> +//
> +// For more information see RFC 8200, Section 4.3, 4.4, and 4.6
> +//
> +//  This example format is from section 4.6
> +//  This does not apply to fragment headers
> +//
> +// +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +//|  Next Header  |  Hdr Ext Len  |   |
> +//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +
> +//|   |
> +//.   .
> +//.  Header-Specific Data .
> +//.   .
> +//|   |
> +//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> +//
> +//  Next Header   8-bit selector.  Identifies the type of
> +//header immediately following the extension
> +//header.  Uses the same values as the IPv4
> +//Protocol field [IANA-PN].
> +//
> +//  Hdr Ext Len   8-bit unsigned integer.  Length of the
> +//Destination Options header in 8-octet units,
> +//not including the first 8 octets.
> +
> +//
> +// These defines apply to the following:
> +//   1. Hop by Hop
> +//   2. Routing
> +//   3. Destination
> +//

Same comment as above (why is this not a struct?)

> +#define IP6_SIZE_OF_EXT_NEXT_HDR  (sizeof(UINT8))
> +#define IP6_SIZE_OF_HDR_EXT_LEN   (sizeof(UINT8))

Same for sizeof(UINT8) here.

> +
> +#define IP6_COMBINED_SIZE_OF_NEXT_HDR_AND_LEN  (IP6_SIZE_OF_EXT_NEXT_HDR + 
> IP6_SIZE_OF_HDR_EXT_LEN)
> +STATIC_ASSERT (
> +  IP6_COMBINED_SIZE_OF_NEXT_HDR_AND_LEN == 2,
> +  "The combined size of Next Header and Len is two 8 bit fields"
> +  );
> +
> +//
> +// The "+ 1" in this calculation is because of the "not including the first 
> 8 octets"
> +// part of the definition (meaning the value of 0 represents 64 bits)
> +//
> +#define IP6_HDR_EXT_LEN(a)  (((

Re: [edk2-devel] [PATCH 01/14] NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45230 Patch

[Gerd Hoffmann]

On Tue, Jan 23, 2024 at 07:33:24PM -0800, Doug Flick via groups.io wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535
> 
> SECURITY PATCH - Patch

Not needed, the CVE number below implies that.

> TCBZ4535

Not needed, the link to tianocore bugzilla is above.

> CVE-2023-45230
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations within the Bounds
>  of a Memory Buffer

Good.  Given that this series of bugs got a fancy name I think it makes
sense to include that too ("pixiefail bug #1").

Please include a description of the bug and how it is fixed.

[ the same applies to the following patches ]

> -UINT8 *
> +EFI_STATUS
>  Dhcp6AppendOption (
> -  IN OUT UINT8   *Buf,
> -  IN UINT16  OptType,
> -  IN UINT16  OptLen,
> -  IN UINT8   *Data
> +  IN OUT EFI_DHCP6_PACKET  *Packet,
> +  IN OUT UINT8 **PacketCursor,
> +  IN UINT16OptType,
> +  IN UINT16OptLen,
> +  IN UINT8 *Data
>);

Dhcp6AppendOption() and variants can return errors now.  All callsites
are adapted accordingly.

It gets passed in EFI_DHCP6_PACKET as additional parameter ...

> +  //
> +  // Verify the PacketCursor is within the packet
> +  //
> +  if (  (*PacketCursor < Packet->Dhcp6.Option)
> + || (*PacketCursor >= Packet->Dhcp6.Option + (Packet->Size - sizeof 
> (EFI_DHCP6_HEADER
> +  {
> +return EFI_INVALID_PARAMETER;
> +  }

... so it can look at Packet->Size when checking buffer space.
Also to allow Packet->Length updates.

Lots of checks added.

The code changes look good to me.  The key changes should be highlighted
in the commit message.

thanks,
  Gerd



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

Re: [edk2-devel] [PATCH 02/14] NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45230 Unit Tests

[Gerd Hoffmann]

On Tue, Jan 23, 2024 at 07:33:25PM -0800, Doug Flick via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4535
> 
> SECURITY PATCH - Unit Tests
> 
> TCBZ4535
> CVE-2023-45230
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations within the Bounds
>  of a Memory Buffer

I don't think this is needed here, this patch doesn't fix CVE-2023-45230
after all.  A description of what the tests are checking would be more
useful.

> diff --git a/NetworkPkg/NetworkPkg.ci.yaml b/NetworkPkg/NetworkPkg.ci.yaml
> index 07dc7abd6938..0060f7a2cb8f 100644
> --- a/NetworkPkg/NetworkPkg.ci.yaml
> +++ b/NetworkPkg/NetworkPkg.ci.yaml
> @@ -7,73 +7,65 @@
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  ##
>  {
> -"LicenseCheck": {
> -"IgnoreFiles": []
> -},
> +"LicenseCheck": { "IgnoreFiles": [] },

I guess this patch hooks the unit tests into CI.  The whitespace changes
make changes file hard to read though.  Two options to deal with that:

  (1) avoid to reformat the file, or
  (2) split the patch into two, one with only the whitespace changes
  and one with the functional change.

thanks & take care,
  Gerd



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

Re: [edk2-devel] [PATCH 03/14] NetworkPkg: Dhcp6Dxe: SECURITY PATCH CVE-2023-45229 Patch

[Gerd Hoffmann]

On Tue, Jan 23, 2024 at 07:33:26PM -0800, Doug Flick via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534
> 
> SECURITY PATCH - Patch
> 
> TCBZ4534
> CVE-2023-45229
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Read
> 
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 

Code changes look good to me, commit message should be improved simliar
ti patch #1.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 05/14] NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45231 - Patch

[Gerd Hoffmann]

On Tue, Jan 23, 2024 at 07:33:28PM -0800, Doug Flick via groups.io wrote:
> From: Doug Flick 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4536
> 
> SECURITY PATCH - Patch
> 
> TCBZ4536
> CVE-2023-45231
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Read

Same comment for the commit message as for patch #1.

> +  //
> +  // Cannot process truncated options.
> +  // Cannot process options with a length of 0 as there is no Type field.
> +  //
> +  if (OptionLen < sizeof (IP6_OPTION_HEADER)) {
> +return FALSE;
> +  }

Code change is good (and the commit message describing the change can be
as short as the patch itself ;)

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 07/14] NetworkPkg: Ip6Dxe: SECURITY PATCH CVE-2023-45232 Patch

[Gerd Hoffmann]

  Hi,

> Why isn't this just a
> 
> struct Ipv6Option {
>   UINT8 OptionType;
>   UINT8 OptionLength;
>   UINT8 OptionData[];
> };

That makes sense indeed (for dhcpv6 we have that,
see EFI_DHCP6_PACKET_OPTION).

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 09/14] NetworkPkg: UefiPxeBcDxe: SECURITY PATCH CVE-2023-45234 Patch

[Gerd Hoffmann]

On Tue, Jan 23, 2024 at 07:33:32PM -0800, Doug Flick via groups.io wrote:
> From: Doug Flick 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4539
> 
> SECURITY PATCH - Patch
> 
> TCBZ4539
> CVE-2023-45234
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations within the Bounds of
>  a Memory Buffer
> 
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
> 
> Signed-off-by: Doug Flick [MSFT] 

Code change looks good to me, commit message should be improved (see
patch #1 comments).

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v3] UefiCpuPkg: Fix issue that IsModified is wrongly set in PageTableMap

[Ni, Ray]

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang 
> Sent: Tuesday, January 23, 2024 3:16 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Ni, Ray ; Laszlo
> Ersek ; Kumar, Rahul R ; Gerd
> Hoffmann ; Lee, Crystal ;
> Pedro Falcato 
> Subject: [PATCH v3] UefiCpuPkg: Fix issue that IsModified is wrongly set in
> PageTableMap
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4614
> 
> About the IsModified, current function doesn't consider that hardware
> also may change the pagetable. The issue is that in the first call of
> internal function PageTableLibMapInLevel, the function assume page
> table is not changed, and add ASSERT to check. But hardware may change
> the page table, which cause the ASSERT happens.
> Fix the issue by adding addtional condition to only check if the page
> table is changed when the software want to modify the page table.
> Also, add more comment to explain this behavior.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Crystal Lee 
> Cc: Pedro Falcato 
> Signed-off-by: Zhiguang Liu 
> ---
>  .../Library/CpuPageTableLib/CpuPageTableMap.c  | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 36b2c4e6a3..ea6547970a 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -274,7 +274,7 @@ IsAttributesAndMaskValidForNonPresentEntry (
>  Page table entries that map the linear 
> address range are
> reset to 0 before set to the new attribute
>  when a new physical base address is set.
>@param[in]  Mask  The mask used for attribute. The 
> corresponding
> field in Attribute is ignored if that in Mask is 0.
> -  @param[out] IsModifiedTRUE means page table is modified. FALSE
> means page table is not modified.
> +  @param[in, out] IsModifiedChange IsModified to True if page table 
> is
> modified and input parameter Modify is TRUE.
> 
>@retval RETURN_INVALID_PARAMETER  For non-present range, Mask-
> >Bits.Present is 0 but some other attributes are provided.
>@retval RETURN_INVALID_PARAMETER  For non-present range, Mask-
> >Bits.Present is 1, Attribute->Bits.Present is 1 but some other attributes are
> not provided.
> @@ -294,7 +294,7 @@ PageTableLibMapInLevel (
>IN UINT64  Offset,
>IN IA32_MAP_ATTRIBUTE  *Attribute,
>IN IA32_MAP_ATTRIBUTE  *Mask,
> -  OUTBOOLEAN *IsModified
> +  IN OUT BOOLEAN *IsModified
>)
>  {
>RETURN_STATUS   Status;
> @@ -567,7 +567,10 @@ PageTableLibMapInLevel (
>  OriginalCurrentPagingEntry.Uint64 = CurrentPagingEntry->Uint64;
>  PageTableLibSetPle (Level, CurrentPagingEntry, Offset, Attribute,
> &CurrentMask);
> 
> -if (OriginalCurrentPagingEntry.Uint64 != CurrentPagingEntry->Uint64) 
> {
> +if (Modify && (OriginalCurrentPagingEntry.Uint64 != 
> CurrentPagingEntry-
> >Uint64)) {
> +  //
> +  // The page table entry can be changed by this function only when
> Modify is true.
> +  //
>*IsModified = TRUE;
>  }
>}
> @@ -609,7 +612,10 @@ PageTableLibMapInLevel (
>// Check if ParentPagingEntry entry is modified here is enough. Except the
> changes happen in leaf PagingEntry during
>// the while loop, if there is any other change happens in page table, the
> ParentPagingEntry must has been modified.
>//
> -  if (OriginalParentPagingEntry.Uint64 != ParentPagingEntry->Uint64) {
> +  if (Modify && (OriginalParentPagingEntry.Uint64 != ParentPagingEntry-
> >Uint64)) {
> +//
> +// The page table entry can be changed by this function only when Modify
> is true.
> +//
>  *IsModified = TRUE;
>}
> 
> @@ -633,7 +639,9 @@ PageTableLibMapInLevel (
>   Page table entries that map the linear 
> address range are reset
> to 0 before set to the new attribute
>   when a new physical base address is set.
>@param[in]  Mask   The mask used for attribute. The 
> corresponding
> field in Attribute is ignored if that in Mask is 0.
> -  @param[out] IsModified TRUE means page table is modified. FALSE
> means page table is not modified.
> +  @param[out] IsModified TRUE means page table is modified by
> software or hardware. FALSE means page table is not modified by software.
> + If the output IsModified is FALSE, there is 
> possibility that the
> page table is changed by hardware. It is ok
> + because page table can be changed by 
> hardware anytime,
> and caller don't need to Flush TLB.
> 
>@retval RETURN_UNSUPPORTED

Re: [edk2-devel] [PATCH] MdeModulePkg/PciBusDxe: Add feedback status for PciIoMap

[Ni, Ray]

Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Huang, Jenny 
> Sent: Tuesday, January 23, 2024 11:26 AM
> To: Sheng, W ; devel@edk2.groups.io
> Cc: Ni, Ray ; Chiang, Chris 
> Subject: RE: [PATCH] MdeModulePkg/PciBusDxe: Add feedback status for
> PciIoMap
> 
> Reviewed by Jenny Huang 
> 
> -Original Message-
> From: Sheng, W 
> Sent: Sunday, January 21, 2024 10:47 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Huang, Jenny ;
> Chiang, Chris 
> Subject: [PATCH] MdeModulePkg/PciBusDxe: Add feedback status for
> PciIoMap
> 
> PciIoMap () need to feedback the status of
> mIoMmuProtocol->SetAttribute () return value.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4652
> 
> Cc: Ray Ni 
> Cc: Huang Jenny 
> Cc: Chiang Chris 
> Signed-off-by: Sheng Wei 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> index 14bed54729..e85544d08d 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> @@ -1024,12 +1024,12 @@ PciIoMap (
>return EFI_INVALID_PARAMETER;
>}
> 
> -  mIoMmuProtocol->SetAttribute (
> -mIoMmuProtocol,
> -PciIoDevice->Handle,
> -*Mapping,
> -IoMmuAttribute
> -);
> +  Status = mIoMmuProtocol->SetAttribute (
> + mIoMmuProtocol,
> + PciIoDevice->Handle,
> + *Mapping,
> + IoMmuAttribute
> + );
>  }
>}
> 
> --
> 2.26.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114282): https://edk2.groups.io/g/devel/message/114282
Mute This Topic: https://groups.io/mt/103881889/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 2/4] StandaloneMmPkg/Hob: Integer Overflow in CreateHob()

[Gerd Hoffmann]

On Fri, Jan 12, 2024 at 08:56:02AM +, Ni, Ray wrote:
> It's strange to me that ARM's MM env still allows modifying HOBs.

Yes.

But fixing that is beyond the scope of this patch, which just
fixes the integer overflow in CreateHob().

Can we please move forward and get the remaining CreateHob()
fixes merged?

thanks & take care,
  Gerd



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

Re: [edk2-devel] [PATCH v3 0/4] Bz4166: Integer Overflow in CreateHob()

[Gerd Hoffmann]

On Tue, Jan 23, 2024 at 03:16:32PM +, Guo, Gua wrote:
> For MdeModulePkg, I think no need to change because no any logic change.
> 
> For StandaloneMmPkg and EmbeddedPkg
> - Don't have enough abilities to close Sami Mujawar and Ni Ray open 
> currently, so hold on the change until I find how to introduce Panic. So give 
> up these two packages patch currently.

On StandaloneMmPkg: I think the patch is fine, I've replied in that
subthread.

On EmbeddedPkg:  I think the BuildGuidDataHob() callsites need review
whenever they do:

  (a) check the return value properly, or
  (b) allocate a fixed size HOB so the new check in CreateHob() can't
  fail.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

[Laszlo Ersek]

On 1/23/24 17:11, Gerd Hoffmann wrote:
>   Hi,
> 
> Well, it's OVMF in a virtual machine.  No boot guard involved.
> So we could probably go for a OVMF-specific patch here.
>
> But I'd prefer to figure what exactly is happening here before going
> down that route.  An extreme slowdown just because we flip that bit
> doesn't make sense to me.
>
>> Why is boot time increasing?
>
> Not clear.  It seems to be the lzma uncompress of the firmware volume
> in rom / pflash which is very slow.  Also it is apparently only
> triggered in case pci device assignment is used.

 I've seen extreme slowness on physical platforms when we've mixed up the
 MTRRs or page tables, causing code to be mapped uncached.

 Lzma uncompress of ROM could be pretty slow as well, if the ROM is being
 read uncached.  Lzma probably reads the data a byte at a time, which is the
 worst case for uncached accesses.  Since this is a VM, it's not actually
 uncached at the hardware level, but I don't know how QEMU/KVM handles
 uncached guest mappings It may be doing a VMEXIT for every byte.

 Anyway, I suggest double-checking your page tables and MTRRs.
>>>
>>> It happens very early at boot, before MTRRs are setup, running on the
>>> initial page tables created by the OVMF reset vector.  The initial page
>>> tables have just 'accessed', 'dirty', 'read/write' and 'present' bits
>>> set for the 0-4G identity mapping.
>>>
>>> It seems to have something to do with EPT.  It does not happen on AMD
>>> processors.  It also does not happen when disabling EPT support in kvm
>>> on the host machine.
>>>
>>> looked at kvm kernel traces, I don't see excessive vmexits.
>>
>> This discussion evokes vague memories in me. I'll dump them here, but I
>> have no idea if they will be useful. (They probably won't.)
>>
>> - edk2 commit 98f378a7be12 ("OvmfPkg/ResetVector: enable caching in
>> initial page tables", 2013-09-24)
>>
>> - Linux (host) commit 879ae1880449 ("KVM: x86: obey
>> KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0()", 2015-11-04)
> 
> I actually waded through the source code in both places ;)
> 
> Turned out kvm propagates guest MTRR settings to EPT memory types,
> but only in case kvm_arch_has_noncoherent_dma() is true, which why
> this triggers only with a mdev device assigned.

... I should not have stopped myself. :)

(I'm aware that this is on edk2-devel, but a public reference to
virt-staff cannot hurt.)

So, yesterday I read your status on virt-staff, and I found an entry in
it that resembled this upstream thread pretty closely. However, your
status was the *only* mention of "mdev" specifically, and so I wasn't
sure if *mdev* meant the same thing as the more generic upstream
expression "pci device assignment" (see it above in the context).

Furthermore, I saw kvm_arch_has_noncoherent_dma() in my linux commit
879ae1880449, which superficially resembled device assignment, but... I
dismissed it. In the end, I only managed (and even that, only
reluctantly) the above pointers... Thanks for tracking it down!

But then, next question: why has this problem *not* been reported
repeatedly? There's a whole bunch of users (gamers) that run Windows
guests with device (GPU) assignment. I'm sure they'd absolutely complain
about very slow OVMF boot (like they actually have, in the past, about
similar LZMA slowdowns due to improper caching setup).

Something must be special about Min's assigned device.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114285): https://edk2.groups.io/g/devel/message/114285
Mute This Topic: https://groups.io/mt/100367559/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] MdeModulePkg: Do nothing on NestedInterruptRestoreTPL(TPL_HIGH_LEVEL)

[Laszlo Ersek]

On 1/23/24 17:59, Michael Brown wrote:
> On 23/01/2024 16:32, Laszlo Ersek wrote:
>> On 1/23/24 16:31, Michael Brown wrote:
>>> At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
>>> specification) and so we should never encounter a situation in which
>>> an interrupt occurs at TPL_HIGH_LEVEL.
>>>
>>> Restoring TPL to TPL_HIGH_LEVEL is always a no-op.  Return immediately
>>> from NestedInterruptRestoreTPL(TPL_HIGH_LEVEL), so that we do not need
>>> to consider the effect of this possible invariant violation on the
>>> remainder of the logic.
>>
>> Feels like the handling logic might as well be "panic" here (except edk2
>> does not have a central panic API that's suitable for all platforms). I
>> probably missed the previous discussion that led to this patch. Either
>> way, it seems reasonable.
>>
>> Acked-by: Laszlo Ersek 
> 
> Thank you.  We can't panic because there are some bootloaders (*cough*
> Microsoft *cough*) that illegally call RaiseTPL(TPL_HIGH_LEVEL) and then
> even more illegally enable interrupts via STI.  Gerd tracked this down
> before, which lead to commit
> 
>   https://github.com/tianocore/edk2/commit/bee67e0c1
> 
> I found another way to trigger a RestoreTPL(TPL_HIGH_LEVEL) while I was
> testing the self-tests by deliberately breaking
> DisableInterruptsOnIret() to fail to disable interrupts.  This also
> induces a situation in which we end up at TPL_HIGH_LEVEL with interrupts
> enabled.
> 
> This ended up triggering an assertion (due to the invariant violation)
> in NestedInterruptRestoreTPL() before reaching the point in the
> self-test that would have reported a more meaningful error message.
> 
> Adding the bypass is justifiable on its own merits (as per the reasoning
> in the commit), and it avoids needing to add clutter to the complex
> logic in NestedInterruptRestoreTPL() just to ensure that the self-test
> fails on the desired ASSERT().
> 
> I decided against trying to explain all that in the commit message, but
> I can have a go if you think it needs to be captured.  :)

Ugh, no, thanks :) This should suffice! :)
Laszlo



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

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

[Marcin Juszkiewicz]

W dniu 19.01.2024 o 20:18, Leif Lindholm pisze:

On Tue, Jan 16, 2024 at 08:48:32 +0100, Marcin Juszkiewicz wrote:

This library provides functions to check for hardware information.
For now it covers CPU ones:

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

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

Signed-off-by: Marcin Juszkiewicz 
---
  Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   3 +-
  .../SbsaQemuHardwareInfoLib.inf |  32 +++
  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h |   2 +
  .../Include/Library/SbsaQemuHardwareInfoLib.h   |  45 +
  .../SbsaQemuHardwareInfoLib.c   | 100 
  5 files changed, 181 insertions(+), 1 deletion(-)





diff --git 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
new file mode 100644
index ..4df973fda75e
--- /dev/null
+++ 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
@@ -0,0 +1,100 @@
+/** @file
+*
+*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*  Copyright (c) Linaro Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Get CPU count from information passed by Qemu.
+
+**/
+VOID
+SbsaQemuGetCpuCount (
+  VOID
+  )
+{
+  UINTN  Arg0;
+  UINTN  SmcResult;
+  RETURN_STATUS  Result;
+
+  SmcResult = ArmCallSmc0 (SIP_SVC_GET_CPU_COUNT, &Arg0, NULL, NULL);
+  if (SmcResult != SMC_ARCH_CALL_SUCCESS) {


So, this may sound a little bit bonkers, but SMCCC doesn't define
return codes for SiP functions. And the SMC_ARCH_CALL_SUCCESS macro
denotes an Arm Architectural function.
Could you #define an SMC_SIP_CALL_SUCCESS *as* SMC_ARCH_CALL_SUCCESS
in some platform-specific header and then use that?


Added it in Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
and used.




+DEBUG ((DEBUG_INFO, "Too old TF-A. We have to get cpu info from DT.\n"));


We don't *know* the TF-A is too old. Rather print which call failed
(and that we need to attempt to get the cpu count from DT).


Changed:

DEBUG ((DEBUG_INFO, "SIP_SVC_GET_CPU_COUNT call failed. We have to 
get cpu info from DT.\n"));




+Arg0 = FdtHelperCountCpus();


We should probably assert this as != 0? Or is that done in the function?


Added code to stop going if we do not have cpu information. In such case 
we will not be back here with wrong info.





+  }
+
+  Result = PcdSet32S (PcdCoreCount, Arg0);
+  ASSERT_RETURN_ERROR (Result);
+
+  Arg0 = PcdGet32 (PcdCoreCount);


Seems redundant to re-set it to the value we know it already holds.


Done


+
+  DEBUG ((DEBUG_INFO, "We have %d cpus.\n", Arg0));
+}
+
+/**
+  Get MPIDR for a given cpu from device tree passed by Qemu.
+
+  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
+
+  @retvalMPIDR value of CPU at index 
+**/
+UINT64
+SbsaQemuGetMpidr (
+  IN UINTN   CpuId
+  )
+{
+  UINTN SmcResult;
+  UINTN Arg0;
+  UINTN Arg1;
+
+  Arg0 = CpuId;
+
+  SmcResult = ArmCallSmc0 (SIP_SVC_GET_CPU_NODE, &Arg0, &Arg1, NULL);
+  if (SmcResult != SMC_ARCH_CALL_SUCCESS) {
+DEBUG ((DEBUG_INFO, "Too old TF-A. We have to get cpu info from DT.\n"));


We don't *know* the TF-A is too old. Rather print which call failed
(and that we need to attempt to get the cpu date from DT).


done


+UINT64
+SbsaQemuGetCpuNumaNode (
+  IN UINTN   CpuId
+  )
+{
+  UINTN SmcResult;
+  UINTN Arg0;
+  UINTN Arg1;
+
+  Arg0 = CpuId;
+
+  SmcResult = ArmCallSmc0 (SIP_SVC_GET_CPU_NODE, &Arg0, &Arg1, NULL);


It does seem a bit wasteful we're making the same call twice per core,
discarding one of the results.
Could we have an init function that allocates an array and
prepopulates it, with the Get-functions just returning values from the array?


good idea, will look into


+  if (SmcResult != SMC_ARCH_CALL_SUCCESS) {
+/* No fallback to DeviceTree as we did not had that info earlier. */


We don't *know* the TF-A is too old. Rather print which call failed
(and that we need to attempt to get the cpu count from DT).


done



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

Re: [edk2-devel] [PATCH edk2-platforms v2 3/4] Platform/SbsaQemu: use PcdCoreCount directly

[Marcin Juszkiewicz]

W dniu 19.01.2024 o 20:20, Leif Lindholm pisze:

On Tue, Jan 16, 2024 at 08:48:34 +0100, Marcin Juszkiewicz wrote:

During platform initialization we read amount of cpu cores and set
PcdCoreCount so there is no need to call FdtHandler.

Signed-off-by: Marcin Juszkiewicz 
---
  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  6 ++
  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 10 --
  .../Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c  | 12 +++-
  3 files changed, 9 insertions(+), 19 deletions(-)



diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 9fb17151d7b8..7ef314ae9f67 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -255,7 +255,7 @@ AddMadtTable (
   // Initialize GIC Redistributor Structure
EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
  
-  // Get CoreCount which was determined eariler after parsing device tree

+  // Get CoreCount which was determined earlier from TF-A


Where we got the information from no longer matters, since we've
abstracted that away.


dropped comment



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

Re: [edk2-devel] [PATCH v3 4/5] MdeModulePkg: Add self-tests for NestedInterruptTplLib

[Laszlo Ersek]

On 1/23/24 18:41, Michael Brown wrote:
> On 23/01/2024 16:55, Laszlo Ersek wrote:
>>> +  ///
>>> +  /// Number of self-tests performed.
>>> +  ///
>>> +  UINTN  SelfTestCount;
>>>   } NESTED_INTERRUPT_STATE;
>>>     /**
>>
>> I suggest that the new field be UINT32. The (exclusive) limit is a
>> 32-bit PCD. Making the counter (potentially) wider than the limit is not
>> useful, but it's also a bit of a complication for the debug messages
>> (see below).
> 
> Great suggestion, thanks!
> 
>>> +    ///
>>> +    /// Perform a limited number of self-tests on the first few
>>> +    /// invocations.
>>> +    ///
>>> +    if ((IsrState->DeferredRestoreTPL == FALSE) &&
>>
>> This comment applies to several locations in the patch:
>>
>> BOOLEANs should not be checked using explicit "== TRUE" and "== FALSE"
>> operators / comparisons; they should only be evaluated in their logical
>> contexts:
> 
> We've had this conversation before :)
> 
>   https://edk2.groups.io/g/devel/message/104369

Oops, sorry :)

> 
> I personally find that the "!" operators get visually lost in the EDK2
> coding style with its very long variable and function names.  That said,
> I'm happy to omit all of the explicit comparisons, but I should then add
> a precursor patch that changes the existing code style first.  Thoughts?

I'm unsure.

Some people prefer (! Expression) over (!Expression), i.e., the extra
space, but I'm unsure if uncrustify tolerates that, and whether it
matches the edk2 coding style, regardless of uncrustify. How about:

  !(Expression)

such as

  if (!(IsrState->DeferredRestoreTPL) &&

? Does that make it more readable? (I believe this form would not trip
up uncrustify, and that it would satisfy the coding style too.)

With none of those working, the explicit ==TRUE / ==FALSE would not
"break" the coding style any stronger either, so in that case, feel free
(from my side) to just stick with the syntax in the patch (and in the
pre-patch code).

> 
>>> +VOID
>>> +NestedInterruptSelfTest (
>>> +  IN NESTED_INTERRUPT_STATE  *IsrState
>>> +  )
>>> +{
>>> +  UINTN SelfTestCount;
>>> +  UINTN TimeOut;
>>
>> Did this pass the uncrustify check? I think uncrustify would insist on
>> inserting two spaces here.
>>
>> For running uncrustify locally:
> 
> You are right, and thank you for reminding me how to run the EDK2
> version of uncrustify.  I've fixed up everything it identified.
> 
>>> +  // This error represents a bug in the platform-specific timer
>>> +  // interrupt handler.
>>> +  //
>>> +  DEBUG ((
>>> +    DEBUG_ERROR,
>>> +    "Nested interrupt self-test %u/%u failed: no nested interrupt\n",
>>> +    SelfTestCount,
>>> +    NUMBER_OF_SELF_TESTS
>>> +    ));
>>> +  ASSERT (FALSE);
>>> +}
>>
>> I'd prefer something stronger than just ASSERT (FALSE) here, but -- per
>> previous discussion -- we don't have a generally accepted "panic" API
>> yet, and CpuDeadLoop() is not suitable for all platforms, so this
>> should do.
>>
>> With my trivial comments addressed:
>>
>> Acked-by: Laszlo Ersek 
>>
>> Comment on the general idea: I much like that the self-test is active on
>> every boot (without high costs).
> 
> Thank you!
> 
>> Side idea: technically we could merge the first two patches in
>> separation (pending MdeModulePkg maintainer approval), and then consider
>> the last three patches as new improvements (possibly needing longer
>> review). This kind of splitting has both advantages and disadvantages;
>> the advantage is that the code movement / upstreaming to MdeModulePkg is
>> not blocked by (somewhat) unrelated discussion. The disadvantages are
>> that more admin work is needed (more posting, and more PRs), and that
>> patches in the series that one might consider to belong together will
>> fly apart in the git history. So I just figured I'd raise the option.
> 
> I'm happy to work either way, and shall await instruction.
> 
> In the absence of any instruction to the contrary, I'll send out a v4
> tomorrow with everyone's suggestions and tags included, but without the
> above-mentioned precursor patch to remove the boolean comparisons.

A v4 like that sounds good (as far as I'm aware, the first two patches
have no maintainer review yet, anyway).

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114289): https://edk2.groups.io/g/devel/message/114289
Mute This Topic: https://groups.io/mt/103911608/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/Library/BaseCpuLibNull: Add missing X86 specific services

[Laszlo Ersek]

On 1/23/24 23:52, Michael D Kinney wrote:
> * 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;
> +}

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114290): https://edk2.groups.io/g/devel/message/114290
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] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler

[Laszlo Ersek]

On 1/24/24 09:11, Ni, Ray wrote:
> Felix, I remember you mentioned to me about the usage of SMI handler 
> unregistering itself.

I wanted to ask: is this something that the PI spec comments on? I.e.,
is this usage expected by the spec (in which case this bugfix is a
conformance fix), or is the spec silent on it (in which case I guess we
can call this a quality-of-implementation improvement)?

> 
> Reviewed-by: Ray Ni 

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> Thanks,
> Ray
>> -Original Message-
>> From: Liu, Zhiguang 
>> Sent: Wednesday, January 24, 2024 12:03 PM
>> To: devel@edk2.groups.io
>> Cc: Liu, Zhiguang ; Liming Gao
>> ; Wu, Jiaxin ; Ni, Ray
>> 
>> Subject: [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler
>> inside SMI handler
>>
>> To support unregister SMI handler inside SMI handler itself,
>> get next node before SMI handler is executed, since LIST_ENTRY that
>> Link points to may be freed if unregister SMI handler in SMI handler
>> itself.
>>
>> Cc: Liming Gao 
>> Cc: Jiaxin Wu 
>> Cc: Ray Ni 
>> Signed-off-by: Zhiguang Liu 
>> ---
>>  MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
>> b/MdeModulePkg/Core/PiSmmCore/Smi.c
>> index 2985f989c3..a75e52b1ae 100644
>> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
>> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
>> @@ -134,8 +134,14 @@ SmiManage (
>>
>>Head = &SmiEntry->SmiHandlers;
>>
>> -  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
>> +  for (Link = Head->ForwardLink; Link != Head;) {
>>  SmiHandler = CR (Link, SMI_HANDLER, Link,
>> SMI_HANDLER_SIGNATURE);
>> +//
>> +// To support unregiser SMI handler inside SMI handler itself,
>> +// get next node before handler is executed, since LIST_ENTRY that
>> +// Link points to may be freed if unregister SMI handler.
>> +//
>> +Link = Link->ForwardLink;
>>
>>  Status = SmiHandler->Handler (
>> (EFI_HANDLE)SmiHandler,
>> --
>> 2.31.1.windows.1
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114291): https://edk2.groups.io/g/devel/message/114291
Mute This Topic: https://groups.io/mt/103925794/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] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

[Gerd Hoffmann]

  Hi,

> So, yesterday I read your status on virt-staff, and I found an entry in
> it that resembled this upstream thread pretty closely. However, your
> status was the *only* mention of "mdev" specifically, and so I wasn't
> sure if *mdev* meant the same thing as the more generic upstream
> expression "pci device assignment" (see it above in the context).
> 
> Furthermore, I saw kvm_arch_has_noncoherent_dma() in my linux commit
> 879ae1880449, which superficially resembled device assignment, but... I
> dismissed it. In the end, I only managed (and even that, only
> reluctantly) the above pointers... Thanks for tracking it down!
> 
> But then, next question: why has this problem *not* been reported
> repeatedly? There's a whole bunch of users (gamers) that run Windows
> guests with device (GPU) assignment. I'm sure they'd absolutely complain
> about very slow OVMF boot (like they actually have, in the past, about
> similar LZMA slowdowns due to improper caching setup).

static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
{
[ ... ]
 * When there is no need to deal with noncoherent DMA (e.g., no VT-d
 * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.  The
 * EPT memory type is set to WB.  The effective memory type is forced
 * WB.
 *
 * Otherwise, we trust guest.  Guest CD/MTRR/PAT are all honored.  The
 * EPT memory type is used to emulate guest CD/MTRR.
[ ... ]

> Something must be special about Min's assigned device.

Yep.  I think the magic word is "snoop control".  When pci-assigning a
*real* pci device VT-d (aka iommu) handles cache control that way.  When
assigning a mdev device this is not the case.

mdev is a virtual pci device emulated by the kernel.  This can be purely
virtual (see samples/vfio-mdev/mtty.c in the linux kernel, which can be
used to reproduce this).  More typical is hardware-assisted device
partitioning, used for some intel and nvidia gpus.  Roughly comparable
with SR/IOV, but not implemented completely in hardware, the kernel has
some device-specific support code instead.

take care,
  Gerd



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

Re: [edk2-devel] Resources for Creating Packages

[Laszlo Ersek]

meta (CC Mike):

On 1/22/24 19:25, ryderkeys via groups.io wrote:
> (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'm now checking the moderation queue for edk2-discuss; I seem to have
found your original message there. I'll allow it through in a minute.

Problem: moderators don't get email notifications from groups.io about
new items to moderate. (I certainly don't.) Other mailing list software
tends to send out 1 reminder message per day, IIRC (e.g. Mailman2). This
effectively requires moderators to check the WebUI daily, which is very
annoying -- most of the time, there is nothing to moderate (or just junk
mail to delete), so a daily check is a waste of time.

Problem: on the actual WebUI, a few minutes ago I opened the Pending
box, and it showed me 3 (three) messages. All of those were pending
moderation for edk2-devel. I deleted them (they were all spam), and
logged out. I have now logged back in, and am seeing 8 (eight) messages
pending moderation -- this time for edk2-discuss. The issue is that the
WebUI does not show a *summary* page to moderators -- I happen to be a
moderator for 4 edk2 lists (devel, announce, discuss, rfc), and for
covering all of those, I need to separately select *each list* first,
and then check for pending items. In other words, multiply the annoyance
described in the prior paragraph by four. :/

So, sorry about the delay. This is very easy to miss. Until 2021,
checking all four moderation queues had been part of my daily (morning)
routine, but since then, I've forgotten about it.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114293): https://edk2.groups.io/g/devel/message/114293
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 edk2-platforms v3 1/5] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

[Marcin Juszkiewicz]

This library provides functions to check for hardware information.
For now it covers CPU ones:

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

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

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
 .../SbsaQemuHardwareInfoLib.inf  | 32 +++
 .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 15 ++-
 .../Include/Library/SbsaQemuHardwareInfoLib.h| 45 +
 .../SbsaQemuHardwareInfoLib.c| 98 
 5 files changed, 189 insertions(+), 4 deletions(-)

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

[edk2-devel] [PATCH edk2-platforms v3 2/5] Platform/SbsaQemu: read amount of cpus during init

[Marcin Juszkiewicz]

We read it once and store in Pcd for future use.

Signed-off-by: Marcin Juszkiewicz 
---
 .../SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf | 4 +++-
 .../SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c   | 9 +
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf
index 19534b7a274a..9752694a432b 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  This driver effectuates SbsaQemu platform configuration settings
 #
-#  Copyright (c) 2019, Linaro Ltd. All rights reserved.
+#  Copyright (c) Linaro Ltd. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -32,6 +32,7 @@ [LibraryClasses]
   PcdLib
   DebugLib
   NonDiscoverableDeviceRegistrationLib
+  SbsaQemuHardwareInfoLib
   UefiDriverEntryPoint
 
 [Pcd]
@@ -46,6 +47,7 @@ [Pcd]
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicRedistributorsBase
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
 
 
 [Depex]
diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
index 4ebbe7c93a19..14e1ec7eab29 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
@@ -1,7 +1,7 @@
 /** @file
-*  FDT client protocol driver for qemu,mach-virt-ahci DT node
+*  SbsaQemu Platform Initialization
 *
-*  Copyright (c) 2019, Linaro Ltd. All rights reserved.
+*  Copyright (c) Linaro Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -12,13 +12,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
-
 EFI_STATUS
 EFIAPI
 InitializeSbsaQemuPlatformDxe (
@@ -123,5 +122,7 @@ InitializeSbsaQemuPlatformDxe (
 }
   }
 
+  SbsaQemuGetCpuCount ();
+
   return EFI_SUCCESS;
 }

-- 
2.43.0



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

[edk2-devel] [PATCH edk2-platforms v3 3/5] Platform/SbsaQemu: use PcdCoreCount directly

[Marcin Juszkiewicz]

During platform initialization we read amount of cpu cores and set
PcdCoreCount so there is no need to call FdtHandler.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf  |  6 ++
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c| 10 --
 .../Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 11 ++-
 3 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
index a34f54d431d4..8e2bf8c512f1 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
@@ -3,7 +3,7 @@
 #
 #Copyright (c) 2021, NUVIA Inc. All rights reserved.
 #Copyright (c) 2018, Hisilicon Limited. All rights reserved.
-#Copyright (c) 2018, Linaro Limited. All rights reserved.
+#Copyright (c) 2023, Linaro Ltd. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -29,8 +29,6 @@ [Packages]
 
 [LibraryClasses]
   BaseMemoryLib
-  FdtLib
-  FdtHelperLib
   IoLib
   PcdLib
 
@@ -40,7 +38,6 @@ [Guids]
 [Pcd]
   gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
   gArmTokenSpaceGuid.PcdSystemBiosRelease
-  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
 
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemSerialNumber
@@ -56,3 +53,4 @@ [Pcd]
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisManufacturer
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisAssetTag
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisSKU
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
index c38f2851904f..ab97768b5ddc 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
@@ -2,7 +2,7 @@
 *  OemMiscLib.c
 *
 *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*  Copyright (c) Linaro Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -12,14 +12,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 /** Returns whether the specified processor is present or not.
 
@@ -33,7 +31,7 @@ OemIsProcessorPresent (
   UINTN ProcessorIndex
   )
 {
-  if (ProcessorIndex < FdtHelperCountCpus ()) {
+  if (ProcessorIndex < PcdGet32 (PcdCoreCount)) {
 return TRUE;
   }
 
@@ -76,7 +74,7 @@ OemGetProcessorInformation (
 {
   UINT16 ProcessorCount;
 
-  ProcessorCount = FdtHelperCountCpus ();
+  ProcessorCount = PcdGet32 (PcdCoreCount);
 
   if (ProcessorIndex < ProcessorCount) {
 ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
@@ -121,7 +119,7 @@ OemGetMaxProcessors (
   VOID
   )
 {
-  return FdtHelperCountCpus ();
+  return PcdGet32 (PcdCoreCount);
 }
 
 /** Gets information about the cache at the specified cache level.
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index 9fb17151d7b8..59536ea9575e 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -1,7 +1,7 @@
 /** @file
 *  This file is an ACPI driver for the Qemu SBSA platform.
 *
-*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*  Copyright (c) Linaro Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -255,7 +255,6 @@ AddMadtTable (
  // Initialize GIC Redistributor Structure
   EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
 
-  // Get CoreCount which was determined eariler after parsing device tree
   NumCores = PcdGet32 (PcdCoreCount);
 
   // Calculate the new table size based on the number of cores
@@ -291,7 +290,7 @@ AddMadtTable (
   New += sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER);
 
   // Add new GICC structures for the Cores
-  for (CoreIndex = 0; CoreIndex < PcdGet32 (PcdCoreCount); CoreIndex++) {
+  for (CoreIndex = 0; CoreIndex < NumCores; CoreIndex++) {
 EFI_ACPI_6_0_GIC_STRUCTURE *GiccPtr;
 
 CopyMem (New, &Gicc, sizeof (EFI_ACPI_6_0_GIC_STRUCTURE));
@@ -758,12 +757,6 @@ InitializeSbsaQemuAcpiDxe (
 {
   EFI_STATUS Status;
   EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
-  UINT32 NumCores;
-
-  // Parse the device tree and get the number of CPUs
-  NumCores = FdtHelperCountCpus ();
-  Status = PcdSet32S (PcdCoreCount, NumCores);
-  ASSERT_RETURN_ERROR (Status);
 
   // Check if ACPI Table Protocol has been installed
   Status = gBS->LocateProtocol (

-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1

[edk2-devel] [PATCH edk2-platforms v3 4/5] Platform/SbsaQemu: move FdtHandlerLib to SbsaQemuHardwareInfoLib

[Marcin Juszkiewicz]

There is no need for EDK2 to know that there is DeviceTree around.
All hardware information is read using functions from
SbsaQemuHardwareInfoLib library.

Library fallbacks to parsing DT if needed (used with too old TF-A).

Signed-off-by: Marcin Juszkiewicz 
Reviewed-by: Leif Lindholm 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   1 -
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   4 +-
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf  |  33 ---
 .../SbsaQemuHardwareInfoLib.inf |   2 +
 .../Qemu/SbsaQemu/Include/Library/FdtHelperLib.h|  36 ---
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |   2 +-
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c|  98 --
 .../SbsaQemuHardwareInfoLib.c   | 104 
 8 files changed, 109 insertions(+), 171 deletions(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 07cb3490f4cf..bde61651da2e 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -126,7 +126,6 @@ [LibraryClasses.common]
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
-  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
   OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
   
SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
 
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 291743b19115..9bf0a13de5d1 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  This driver modifies ACPI tables for the Qemu SBSA platform
 #
-#  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+#  Copyright (c) Linaro Ltd. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -35,9 +35,9 @@ [LibraryClasses]
   BaseLib
   DebugLib
   DxeServicesLib
-  FdtHelperLib
   PcdLib
   PrintLib
+  SbsaQemuHardwareInfoLib
   UefiDriverEntryPoint
   UefiLib
   UefiRuntimeServicesTableLib
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
deleted file mode 100644
index 9c059f3e5851..
--- a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
+++ /dev/null
@@ -1,33 +0,0 @@
-#/** @file
-#
-#  Component description file for FdtHelperLib module
-#
-#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-#
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-#**/
-
-[Defines]
-  INF_VERSION= 1.29
-  BASE_NAME  = FdtHelperLib
-  FILE_GUID  = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = FdtHelperLib
-
-[Sources.common]
-  FdtHelperLib.c
-
-[Packages]
-  EmbeddedPkg/EmbeddedPkg.dec
-  MdePkg/MdePkg.dec
-  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
-
-[LibraryClasses]
-  DebugLib
-  FdtLib
-  PcdLib
-
-[FixedPcd]
-  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
diff --git 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
index 8c2def1878e6..5358dd339eb3 100644
--- 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
+++ 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
@@ -27,6 +27,8 @@ [LibraryClasses]
   ArmSmcLib
   BaseMemoryLib
   DebugLib
+  FdtLib
 
  [Pcd]
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
deleted file mode 100644
index ea9159857215..
--- a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/** @file
-*  FdtHelperLib.h
-*
-*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-*
-*  SPDX-License-Identifier: BSD-2-Clause-Patent
-*
-**/
-
-#ifndef FDT_HELPER_LIB_
-#define FDT_HELPER_LIB_
-
-/**
-  Get MPIDR for a given cpu from device tree passed by Qemu.
-
-  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
-
-  @retvalMPIDR value of CPU at index 
-**/
-UINT64
-FdtHelperGetMpidr (
-  IN UINTN   CpuId
-  );
-
-/** Walks through the Device Tree created by Qemu and counts the number
-of CPUs present in it.
-
-@return The number of CPUs present.
-**/
-EFIAPI
-UINT32
-FdtHelperCountCpus (
-  VOID
-  );
-
-#endif /* FDT_HELPER_LIB_ */
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiD

[edk2-devel] [PATCH edk2-platforms v3 5/5] Platform/SbsaQemu: hang if there is no cpu information

[Marcin Juszkiewicz]

In case we do not have cpu information (SMC call fails,
our minimal DT lacks info) we hang.

TODO: shutdown instead

Signed-off-by: Marcin Juszkiewicz 
---
 .../SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
index 6315cce3fb7f..923997edb2f1 100644
--- 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
+++ 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
@@ -95,6 +95,9 @@ FdtHelperCountCpus (
   Node = fdt_path_offset (DeviceTreeBase, "/cpus");
   if (Node <= 0) {
 DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in DeviceTree\n"));
+// as we do not have information about cpu count we panic here
+// TODO: shutdown rather than hang
+CpuDeadLoop();
 return 0;
   }
 

-- 
2.43.0



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

[edk2-devel] [PATCH edk2-platforms v3 0/5] get rid of DeviceTree from SbsaQemu

[Marcin Juszkiewicz]

We want to stop parsing DeviceTree to gather hardware information.

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

If TF-A answer to SMC call would be not success then we assume that it
is old version and go back to parsing DeviceTree data directly. Just now
it is present in one place (SbsaQemuHardwareInfoLib) together with new
code for handling SMC stuff.

I hope that we can drop FdtHandler part as part of 202411 release.

TF-A part: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/25707

After this change the only place where DT data is parsed directly is
checking for memory nodes. Patches for that code will be sent once we
get SMC calls into TF-A.

Signed-off-by: Marcin Juszkiewicz 
---
Changes in v3:
- added SMC_SIP_CALL_SUCCESS
- on SMC call fail tell that SMC call failed instead of blaming TF-A
- hang when there is no cpu information (TODO: shutdown instead)
- Link to v2: 
https://openfw.io/edk2-devel/20240116-no-dt-for-cpu-v2-0-6cf078d9a...@linaro.org/T/#t

---
Marcin Juszkiewicz (5):
  Platform/SbsaQemu: add SbsaQemuHardwareInfoLib
  Platform/SbsaQemu: read amount of cpus during init
  Platform/SbsaQemu: use PcdCoreCount directly
  Platform/SbsaQemu: move FdtHandlerLib to SbsaQemuHardwareInfoLib
  Platform/SbsaQemu: hang if there is no cpu information

 Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   4 +-
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf|   6 +-
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   4 +-
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf |   4 +-
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf  |  33 
 .../SbsaQemuHardwareInfoLib.inf |  34 
 .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h |  15 +-
 .../Qemu/SbsaQemu/Include/Library/FdtHelperLib.h|  36 
 .../Include/Library/SbsaQemuHardwareInfoLib.h   |  45 +
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c  |  10 +-
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |  13 +-
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c   |   9 +-
 .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c|  98 --
 .../SbsaQemuHardwareInfoLib.c   | 205 
 14 files changed, 317 insertions(+), 199 deletions(-)
---
base-commit: 82c4c4b038659843adb519d2e94ad83d77332c26
change-id: 20240115-no-dt-for-cpu-2c511393df93

Best regards,
-- 
Marcin Juszkiewicz 



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

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

[Laszlo Ersek]

On 1/23/24 21:24, Michael D Kinney wrote:
> Provide an optional method for PEI to declare a specific address
> range to use for the Memory Type Information bins. The current
> algorithm uses heuristics that tends to place the Memory Type
> Information bins in the same location, but memory configuration
> changes across boots or algorithm changes across a firmware
> updates could potentially change the Memory Type Information bin
> location.
>
> If the HOB List contains a Resource Descriptor HOB that
> describes tested system memory and has an Owner GUID of
> gEfiMemoryTypeInformationGuid, then use the address range
> described by the Resource Descriptor HOB as the preferred
> location of the Memory Type Information bins. If this HOB is
> not detected, then the current behavior is preserved.
>
> The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> is ignored for the following conditions:
> * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
>   is smaller than the Memory Type Information bins.
> * The HOB list contains more than one Resource Descriptor HOB
>   with an owner GUID of gEfiMemoryTypeInformationGuid.
> * The Resource Descriptor HOB with an Owner GUID of
>   gEfiMemoryTypeInformationGuid is the same Resource Descriptor
>   HOB that that describes the PHIT memory range.

I feel that, while this GUID usage makes sense, it overloads the already
existing meanings of gEfiMemoryTypeInformationGuid.

We already use this GUID for two things:

(see "MdeModulePkg/Include/Guid/MemoryTypeInformation.h"):

- UEFI variable name space GUID for the "MemoryTypeInformation" variable

- HOB of type EFI_HOB_TYPE_GUID_EXTENSION, controlling the page counts
in the various memory type bins.

Now this new use would introduce a HOB of type
EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, where the Owner field is
gEfiMemoryTypeInformationGuid, and the range described by the
PhysicalStart and ResourceLength fields would accommodate the actual
bins. On one hand this new HOB is certainly related to the prior two
uses, but on the other hand, we'd now have to HOBs that used the "same
GUID" for different purposes. What distinguishes them is
EFI_HOB_TYPE_GUID_EXTENSION vs. EFI_HOB_TYPE_RESOURCE_DESCRIPTOR --
which I find a bit too obscure.

(1) So I'd either suggest generating a brand new GUID, *or* extending the
comments in "MdeModulePkg/Include/Guid/MemoryTypeInformation.h" with the
new usage:

> /** @file
>   This file defines:
>   * Memory Type Information GUID for HOB and Variable.
>   * Memory Type Information Variable Name.
>   * Memory Type Information GUID HOB data structure.
>
>   The memory type information HOB and variable can
>   be used to store the information for each memory type in Variable or HOB.
>
> Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/

Back to the patch:

On 1/23/24 21:24, Michael D Kinney wrote:
> Update the DxeMain initialization order to initialize GCD
> services before any runtime allocations are performed.  This
> is required to prevent runtime data fragmentation when the
> UEFI System Table and UEFI Runtime Service Table is allocated.

(2) Should this be a separate patch? (First patch in the series?) This seems
to effect behavior even if the new HOB is not present.

>
> Cc: Liming Gao 
> Cc: Aaron Li 
> Cc: Liu Yun 
> Cc: Andrew Fish 
> Signed-off-by: Michael D Kinney 
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.h |   6 ++
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c |  72 -
>  MdeModulePkg/Core/Dxe/Mem/Page.c| 101 
>  4 files changed, 190 insertions(+), 12 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
> index 86a7be2f5188..53e26703f8c7 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> @@ -277,6 +277,12 @@ CoreInitializePool (
>VOID
>);
>
> +VOID
> +CoreSetMemoryTypeInformationRange (
> +  IN EFI_PHYSICAL_ADDRESS  Start,
> +  IN UINT64Length
> +  );
> +
>  /**
>Called to initialize the memory map and add descriptors to
>the current descriptor list.
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c 
> b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> index 0e0f9769b99d..17d510a287e5 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> @@ -276,6 +276,18 @@ DxeMain (
>
>MemoryProfileInit (HobStart);
>
> +  //
> +  // Start the Image Services.
> +  //
> +  Status = CoreInitializeImageServices (HobStart);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Initialize the Global Coherency Domain Services
> +  //
> +  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress, 
> MemoryLength);
> +  ASSERT_EFI_ERROR (Status);
> +
>//
>// Allocate the EFI System Table and EFI Runtime Service Table from 
> EfiRuntimeServicesData
>

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

[Laszlo Ersek]

On 1/23/24 21:24, Michael D Kinney wrote:
> Provide an optional method for PEI to declare a specific address
> range to use for the Memory Type Information bins. The current
> algorithm uses heuristics that tends to place the Memory Type
> Information bins in the same location, but memory configuration
> changes across boots or algorithm changes across a firmware
> updates could potentially change the Memory Type Information bin
> location.

(5) Why is such a rearrangement of the bins -- which is likely visible
in the UEFI memory map, too -- a problem?

Can we include a hint on that in the commit message?

I understand why it would be a problem across ACPI S4, but a memory
config change (DIMM addition/removal?), or a firmware update, seems to
require a full S5 power cycle.

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Dhaval Sharma]

"The CpuDxe interface will be the wrapper." Yes, of course. It needs to be
added. I was just saying that maybe any CMO checking is not required there
as cmo library will take care of it.

On Tue, Jan 23, 2024 at 10:24 PM Sunil V L  wrote:

> On Tue, Jan 23, 2024 at 11:42:57AM +0530, Dhaval Sharma wrote:
> > Sunil,
> > I thought "WriteBackDataCacheRange not supported" is more explicit over
> > "CMO not available".
> >
> Okay.
>
> > @Pedro Falcato  For the example you mentioned,
> is
> > your concern more about someone not being able to notice the problem
> (that
> > the system is non-coherent) at the time of development and later ending
> up
> > with corrupted data during production? And you are suggesting that an
> > Assert helps address that problem by making that problem more visible to
> > the developer and a verbose warning does not?
> >
> > I can create a patch for CpuFlushCpuDataCache but I think we should avoid
> > CMO based return in there. Because in case of InvalidateDataCacheRange we
> > have an alternate implementation of fence in the absence of CMO. So it is
> > better to let riscvcache decide the right implementation.
> >
> The CpuDxe interface will be the wrapper. See Arm's implementation.
> Since CMO support is added now, the CpuDxe interface should be updated.
>
> Thanks,
> Sunil
>


-- 
Thanks!
=D


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

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Sunil V L]

On Wed, Jan 24, 2024 at 07:57:27PM +0530, Dhaval Sharma wrote:
> "The CpuDxe interface will be the wrapper." Yes, of course. It needs to be
> added. I was just saying that maybe any CMO checking is not required there
> as cmo library will take care of it.
> 
That's correct.

> On Tue, Jan 23, 2024 at 10:24 PM Sunil V L  wrote:
> 
> > On Tue, Jan 23, 2024 at 11:42:57AM +0530, Dhaval Sharma wrote:
> > > Sunil,
> > > I thought "WriteBackDataCacheRange not supported" is more explicit over
> > > "CMO not available".
> > >
> > Okay.
> >
> > > @Pedro Falcato  For the example you mentioned,
> > is
> > > your concern more about someone not being able to notice the problem
> > (that
> > > the system is non-coherent) at the time of development and later ending
> > up
> > > with corrupted data during production? And you are suggesting that an
> > > Assert helps address that problem by making that problem more visible to
> > > the developer and a verbose warning does not?
> > >
> > > I can create a patch for CpuFlushCpuDataCache but I think we should avoid
> > > CMO based return in there. Because in case of InvalidateDataCacheRange we
> > > have an alternate implementation of fence in the absence of CMO. So it is
> > > better to let riscvcache decide the right implementation.
> > >
> > The CpuDxe interface will be the wrapper. See Arm's implementation.
> > Since CMO support is added now, the CpuDxe interface should be updated.
> >
> > Thanks,
> > Sunil
> >
> 
> 
> -- 
> Thanks!
> =D


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

Re: [edk2-devel] pixiefail

[Laszlo Ersek]

On 1/23/24 19:49, Doug Flick via groups.io wrote:
> Gerd,
> 
> As a new EDK2 developer, I'm working through getting the patches up
> to EDK2 but I have to follow the EDK2 patch process which is not the
> fastest thing to follow and also not my day job. If you want to see
> where I am you can look at the CI Pipeline. The patches were reviewed
> during the GHSA process by the Infosec group and have been shipping
> in devices already. I'm hoping to have the patches on the mailing
> list by EOD. This is a great topic for ways we can speed up the
> review process and contribution process - particularly for security
> patches and it would be great to get more people actively involved in
> reviews and testing during creation and delivery of patches.

The review process for embargoed security patches has never been worked
out, to my knowledge. Bugzilla is unsuitable for that. (I'm speaking
from experience. It is impossible to comment sensibly on patches
attached to bugzilla tickets, and in particular incremental reviews are
terrible.)

In some other projects, email based patch review remains the process for
embargoed patches too, with one difference to the normal process: either
no mailing list is included (that is, the email thread, including the
initial posting of the series, keeps addressing the same fixed set of
humans), or else, a mailing list with no public archives, and with
hand-moderated memberships, is included. This permits for the same
tooling (git-am for local testing, and inline review comments) as the
normal, public workflow.

However, some of the edk2 participants don't consider such an
email-based process secure enough for circulating embargoed patches. A
closed organization on github.com might be used as a replacement. That
would have its own problems, though (inconsistency with the normal patch
review process, extra management of memberships, disappearance of early
(hence, not merged) versions of security patch sets, etc).

I figure the most flexible approach for those that dislike email-based
review for embargoed patches would be if github.com supported locked
down *PRs* (i.e., not private organizatons). In other words, if those
PRs would be submitted against the same base repository and master
branch as every other PR, *but* they wouldn't be visible to anyone
except to a restricted group, and could never be merged. (For merging,
the approved version of the series would have to be posted publicly,
after the embargo.)

... Technically, the last paragraph could be implemented with current
github.com features: create a locked-down organization, fork edk2 under
that organization (without adding any non-upstream changes to the fork),
and submit the embargoed patch series as a PR against the fork. Never
merge the patch set into the fork (only use the fork for patch review).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114304): https://edk2.groups.io/g/devel/message/114304
Mute This Topic: https://groups.io/mt/103913088/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] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

[Laszlo Ersek]

On 1/24/24 14:26, Gerd Hoffmann wrote:
>   Hi,
> 
>> So, yesterday I read your status on virt-staff, and I found an entry in
>> it that resembled this upstream thread pretty closely. However, your
>> status was the *only* mention of "mdev" specifically, and so I wasn't
>> sure if *mdev* meant the same thing as the more generic upstream
>> expression "pci device assignment" (see it above in the context).
>>
>> Furthermore, I saw kvm_arch_has_noncoherent_dma() in my linux commit
>> 879ae1880449, which superficially resembled device assignment, but... I
>> dismissed it. In the end, I only managed (and even that, only
>> reluctantly) the above pointers... Thanks for tracking it down!
>>
>> But then, next question: why has this problem *not* been reported
>> repeatedly? There's a whole bunch of users (gamers) that run Windows
>> guests with device (GPU) assignment. I'm sure they'd absolutely complain
>> about very slow OVMF boot (like they actually have, in the past, about
>> similar LZMA slowdowns due to improper caching setup).
> 
> static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> {
> [ ... ]
>  * When there is no need to deal with noncoherent DMA (e.g., no VT-d
>  * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.  The
>  * EPT memory type is set to WB.  The effective memory type is forced
>  * WB.
>  *
>  * Otherwise, we trust guest.  Guest CD/MTRR/PAT are all honored.  The
>  * EPT memory type is used to emulate guest CD/MTRR.
> [ ... ]
> 
>> Something must be special about Min's assigned device.
> 
> Yep.  I think the magic word is "snoop control".  When pci-assigning a
> *real* pci device VT-d (aka iommu) handles cache control that way.  When
> assigning a mdev device this is not the case.
> 
> mdev is a virtual pci device emulated by the kernel.  This can be purely
> virtual (see samples/vfio-mdev/mtty.c in the linux kernel, which can be
> used to reproduce this).  More typical is hardware-assisted device
> partitioning, used for some intel and nvidia gpus.  Roughly comparable
> with SR/IOV, but not implemented completely in hardware, the kernel has
> some device-specific support code instead.

Very interesting, thanks! ... But, given that mdev is emulated in the
kernel: isn't that *all the more reason* for treating the guest memory
as writeback-cacheable? With a physical assigned device, the IOMMU has
to implement this "snoop control" with extra gymnastics. With an mdev (a
device emulated in the host kernel), there is just one "coherency
domain" -- we'd have to do extra gymnastics for *breaking* cache
coherence (or put differently, for simulating noncoherent DMA). It seems
to me that with only mdevs assigned, DMA should be assumed coherent (=
"snoop control" should be assumed).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114305): https://edk2.groups.io/g/devel/message/114305
Mute This Topic: https://groups.io/mt/100367559/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 v4 1/1] MdeModulePkg/AcpiTableDxe: Prefer xDSDT over DSDT when installing tables

[gaoliming via groups.io]

Mike:
  Seemly, I miss this patch. 

Dhaval:
  I add one comment below. 
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Michael D
> Kinney
> 发送时间: 2024年1月24日 10:24
> 收件人: devel@edk2.groups.io; dha...@rivosinc.com
> 抄送: Gao, Liming ; Liu, Zhiguang
> ; Bi, Dandan ; Pedro Falcato
> ; Chiu, Chasel ; Kinney,
> Michael D 
> 主题: Re: [edk2-devel] [PATCH v4 1/1] MdeModulePkg/AcpiTableDxe: Prefer
> xDSDT over DSDT when installing tables
> 
> Hi Liming,
> 
> I do not see any reviews of this patch.
> 
> What is the status?
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Dhaval
> > Sharma
> > Sent: Monday, January 8, 2024 7:00 AM
> > To: devel@edk2.groups.io
> > Cc: Gao, Liming ; Liu, Zhiguang
> > ; Bi, Dandan ; Pedro
> > Falcato ; Chiu, Chasel 
> > Subject: [edk2-devel] [PATCH v4 1/1] MdeModulePkg/AcpiTableDxe: Prefer
> > xDSDT over DSDT when installing tables
> >
> > As per ACPI Spec 6.5+ Table 5-9 if xDSDT is available,
> > it should be used first. Handle required flow when xDSDT
> > is absent or present.
> >
> > Test: Tested on RISCV64 Qemu platform with xDSDT and booted to
> > linux kernel.
> >
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Dandan Bi 
> > Cc: Pedro Falcato 
> > Cc: devel@edk2.groups.io
> > Signed-off-by: Dhaval Sharma 
> > Acked-by: Chasel Chiu 
> > ---
> >
> > Notes:
> > v4:
> > - Fix typos and commit message adding more clarity to patch subject
> > v3:
> > - Added description of ACPI spec clarification based on which this
> > patch is created
> > - Optimizing if-else flow
> > v2:
> > - Added proper indentation for else if
> >
> >  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 23
> > ++--
> >  1 file changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git
> > a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > index e09bc9b704f5..61af6047a2a7 100644
> > --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > @@ -1892,14 +1892,23 @@ InstallAcpiTableFromHob (
> >}
> >
> >  }
> >
> >
> >
> > -if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE
> *)ChildTable)-
> > >Dsdt != 0) {
> >
> > +//
> >
> > +// First check if xDSDT is available, as that is preferred as
> > per
> >
> > +// ACPI Spec 6.5+ Table 5-9 X_DSDT definition
> >
> > +//
> >
> > +if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE
> *)ChildTable)-
> > >XDsdt != 0) {
> >
> > +  TableToInstall = (VOID
> > *)(UINTN)((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)-
> > >XDsdt;
> >
> > +} else if (((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE
> > *)ChildTable)->Dsdt != 0) {
> >
> >TableToInstall = (VOID
> > *)(UINTN)((EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *)ChildTable)-
> > >Dsdt;
> >
> > -  Status = AddTableToList (AcpiTableInstance,
> > TableToInstall, TRUE, Version, TRUE, &TableKey);
> >
> > -  if (EFI_ERROR (Status)) {
> >
> > -DEBUG ((DEBUG_ERROR, "InstallAcpiTableFromHob: Fail to
> add
> > ACPI table DSDT\n"));
> >
> > -ASSERT_EFI_ERROR (Status);
> >
> > -break;
> >
> > -  }
> >
> > +} else {
> >
> > +  break;

[Liming] If XDsdt and Dsdt are both zero, here is break. The previous logic
will continue to look when Dsdt is zero. 
Please check whether this change is by purpose. If this change is by design,
I still think the return Status should be set to EFI_NOT_FOUND.

Thanks
Liming
> >
> > +}
> >
> > +
> >
> > +Status = AddTableToList (AcpiTableInstance, TableToInstall,
> > TRUE, Version, TRUE, &TableKey);
> >
> > +if (EFI_ERROR (Status)) {
> >
> > +  DEBUG ((DEBUG_ERROR, "InstallAcpiTableFromHob: Fail to
> add
> > ACPI table DSDT\n"));
> >
> > +  ASSERT_EFI_ERROR (Status);
> >
> > +  break;
> >
> >  }
> >
> >}
> >
> >  }
> >
> > --
> > 2.39.2
> >
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> > View/Reply Online (#113401):
> > https://edk2.groups.io/g/devel/message/113401
> > Mute This Topic: https://groups.io/mt/103598583/1643496
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe: https://edk2.groups.io/g/devel/unsub
> > [michael.d.kin...@intel.com]
> > -=-=-=-=-=-=
> >
> 
> 
> 
> 
> 





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

Re: [edk2-devel] pixiefail

[Laszlo Ersek]

On 1/24/24 15:35, Laszlo Ersek wrote:

> I figure the most flexible approach for those that dislike email-based
> review for embargoed patches would be if github.com supported locked
> down *PRs* (i.e., not private organizatons). In other words, if those
> PRs would be submitted against the same base repository and master
> branch as every other PR, *but* they wouldn't be visible to anyone
> except to a restricted group, and could never be merged. (For merging,
> the approved version of the series would have to be posted publicly,
> after the embargo.)
> 
> ... Technically, the last paragraph could be implemented with current
> github.com features: create a locked-down organization, fork edk2 under
> that organization (without adding any non-upstream changes to the fork),
> and submit the embargoed patch series as a PR against the fork. Never
> merge the patch set into the fork (only use the fork for patch review).

Well, running the usual CI checks on the embargoed patch set, *inside
the fork*, would be an extra problem... I don't know how github.com
accounts for CI minutes in forks. Especially closed forks.

Laszlo



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

[gaoliming via groups.io]

Mike:
 Current algorithm tries to reserve the top available memory for memory type
bin range. 
 If the platform uses new way to describe the memory range, should we
suggest the rule to still 
 use the top memory resource hob for the memory type bin range?

Thanks
Liming
> -邮件原件-
> 发件人: Michael D Kinney 
> 发送时间: 2024年1月24日 4:24
> 收件人: devel@edk2.groups.io
> 抄送: Liming Gao ; Aaron Li
> ; Liu Yun ; Andrew Fish
> 
> 主题: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin
> range from HOB
> 
> Provide an optional method for PEI to declare a specific address
> range to use for the Memory Type Information bins. The current
> algorithm uses heuristics that tends to place the Memory Type
> Information bins in the same location, but memory configuration
> changes across boots or algorithm changes across a firmware
> updates could potentially change the Memory Type Information bin
> location.
> 
> If the HOB List contains a Resource Descriptor HOB that
> describes tested system memory and has an Owner GUID of
> gEfiMemoryTypeInformationGuid, then use the address range
> described by the Resource Descriptor HOB as the preferred
> location of the Memory Type Information bins. If this HOB is
> not detected, then the current behavior is preserved.
> 
> The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
> is ignored for the following conditions:
> * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
>   is smaller than the Memory Type Information bins.
> * The HOB list contains more than one Resource Descriptor HOB
>   with an owner GUID of gEfiMemoryTypeInformationGuid.
> * The Resource Descriptor HOB with an Owner GUID of
>   gEfiMemoryTypeInformationGuid is the same Resource Descriptor
>   HOB that that describes the PHIT memory range.
> 
> Update the DxeMain initialization order to initialize GCD
> services before any runtime allocations are performed.  This
> is required to prevent runtime data fragmentation when the
> UEFI System Table and UEFI Runtime Service Table is allocated.
> 
> Cc: Liming Gao 
> Cc: Aaron Li 
> Cc: Liu Yun 
> Cc: Andrew Fish 
> Signed-off-by: Michael D Kinney 
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.h |   6 ++
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c |  72 -
>  MdeModulePkg/Core/Dxe/Mem/Page.c| 101
> 
>  4 files changed, 190 insertions(+), 12 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> b/MdeModulePkg/Core/Dxe/DxeMain.h
> index 86a7be2f5188..53e26703f8c7 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> @@ -277,6 +277,12 @@ CoreInitializePool (
>VOID
>);
> 
> +VOID
> +CoreSetMemoryTypeInformationRange (
> +  IN EFI_PHYSICAL_ADDRESS  Start,
> +  IN UINT64Length
> +  );
> +
>  /**
>Called to initialize the memory map and add descriptors to
>the current descriptor list.
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> index 0e0f9769b99d..17d510a287e5 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> @@ -276,6 +276,18 @@ DxeMain (
> 
>MemoryProfileInit (HobStart);
> 
> +  //
> +  // Start the Image Services.
> +  //
> +  Status = CoreInitializeImageServices (HobStart);
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Initialize the Global Coherency Domain Services
> +  //
> +  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress,
> MemoryLength);
> +  ASSERT_EFI_ERROR (Status);
> +
>//
>// Allocate the EFI System Table and EFI Runtime Service Table from
> EfiRuntimeServicesData
>// Use the templates to initialize the contents of the EFI System Table
and
> EFI Runtime Services Table
> @@ -289,16 +301,9 @@ DxeMain (
>gDxeCoreST->RuntimeServices = gDxeCoreRT;
> 
>//
> -  // Start the Image Services.
> +  // Update DXE Core Loaded Image Protocol with allocated UEFI System
> Table
>//
> -  Status = CoreInitializeImageServices (HobStart);
> -  ASSERT_EFI_ERROR (Status);
> -
> -  //
> -  // Initialize the Global Coherency Domain Services
> -  //
> -  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress,
> MemoryLength);
> -  ASSERT_EFI_ERROR (Status);
> +  gDxeCoreLoadedImage->SystemTable = gDxeCoreST;
> 
>//
>// Call constructor for all libraries
> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> index 792cd2e0af23..c450d1bf2531 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -2238,6 +2238,8 @@ CoreInitializeMemoryServices (
>EFI_HOB_HANDOFF_INFO_TABLE   *PhitHob;
>EFI_HOB_RESOURCE_DESCRIPTOR  *ResourceHob;
>EFI_HOB_RESOURCE_DESCRIPTOR  *PhitResourceHob;
> +  EFI_HOB_RESOURCE_DESCRIPTOR
> *MemoryTypeInformationResourceHob;
> +  UINTNCount;
>EFI_PHYSICAL_ADDRESS BaseAddress;
>  

[edk2-devel] [PATCH 1/1] OvmfPkg/Sec: Setup MTRR early in the boot process.

[Gerd Hoffmann]

Specifically before running lzma uncompress of the main firmware volume.
This is needed to make sure caching is enabled, otherwise the uncompress
can be extremely slow.

Adapt the ASSERTs in PlatformInitLib to the changes.

Background:  In some virtual machine configurations with assigned
devices kvm uses EPT memory types to apply guest MTRR settings.
In case MTRRs are disabled kvm will use the uncachable memory type
for all mappings.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Library/PlatformInitLib/MemDetect.c |  8 --
 OvmfPkg/Sec/SecMain.c   | 32 +
 2 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index f042517bb64a..cb2ae0f3d79d 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -1082,11 +1082,13 @@ PlatformQemuInitializeRam (
 MtrrGetAllMtrrs (&MtrrSettings);
 
 //
-// MTRRs disabled, fixed MTRRs disabled, default type is uncached
+// Fixed MTRRs disabled, default type is uncached or write back (see 
SecMtrrSetup())
 //
-ASSERT ((MtrrSettings.MtrrDefType & BIT11) == 0);
 ASSERT ((MtrrSettings.MtrrDefType & BIT10) == 0);
-ASSERT ((MtrrSettings.MtrrDefType & 0xFF) == 0);
+ASSERT (
+  (MtrrSettings.MtrrDefType & 0xFF) == 0x0 ||
+  (MtrrSettings.MtrrDefType & 0xFF) == 0x6
+  );
 
 //
 // flip default type to writeback
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 31da5d0ace51..a672751b046a 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "AmdSev.h"
 
 #define SEC_IDT_ENTRY_COUNT  34
@@ -744,6 +746,31 @@ FindAndReportEntryPoints (
   return;
 }
 
+//
+// Enable MTRR early, set default type to write back.
+// Needed to make sure caching is enabled,
+// without this lzma decompress can be very slow.
+//
+STATIC
+VOID
+SecMtrrSetup (
+  VOID
+  )
+{
+  CPUID_VERSION_INFO_EDX   Edx;
+  MSR_IA32_MTRR_DEF_TYPE_REGISTER  DefType;
+
+  AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, NULL, &Edx.Uint32);
+  if (!Edx.Bits.MTRR) {
+return;
+  }
+
+  DefType.Uint64= 0;
+  DefType.Bits.Type = 6; /* write back */
+  DefType.Bits.E= 1; /* enable */
+  AsmWriteMsr64 (MSR_IA32_MTRR_DEF_TYPE, DefType.Uint64);
+}
+
 VOID
 EFIAPI
 SecCoreStartupWithStack (
@@ -942,6 +969,11 @@ SecCoreStartupWithStack (
   InitializeApicTimer (0, MAX_UINT32, TRUE, 5);
   DisableApicTimerInterrupt ();
 
+  //
+  // Initialize MTRR
+  //
+  SecMtrrSetup ();
+
   //
   // Initialize Debug Agent to support source level debug in SEC/PEI phases 
before memory ready.
   //
-- 
2.43.0



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

Re: [edk2-devel] pixiefail

[vincent zimmer]

I agree on your sentiment about Bugzilla (bz) not being ideal for this.
This space has been a multi-year journey from usrt-based tickets, bespoke
advisories, bz, etc into today's world of tianocore infosec, tianocore as
its own CVE Naming Authority (CNA) and working to leverage the extant
features of github. On that latter point, there is work afoot to evolve
from the present bz-based process
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues
to a github-based one
https://github.com/tianocore/tianocore.github.io/wiki/GHSA-GitHub-Security-Advisories-Proceess-(Draft).
Things are in transition now and I'd echo Doug's sentiment that getting
more feedback and engagement from the community would be valuable in
getting the various parts tested, evolved, documented, reviewed, etc.
Vincent

On Wed, Jan 24, 2024 at 6:57 AM Laszlo Ersek  wrote:

> On 1/24/24 15:35, Laszlo Ersek wrote:
>
> > I figure the most flexible approach for those that dislike email-based
> > review for embargoed patches would be if github.com supported locked
> > down *PRs* (i.e., not private organizatons). In other words, if those
> > PRs would be submitted against the same base repository and master
> > branch as every other PR, *but* they wouldn't be visible to anyone
> > except to a restricted group, and could never be merged. (For merging,
> > the approved version of the series would have to be posted publicly,
> > after the embargo.)
> >
> > ... Technically, the last paragraph could be implemented with current
> > github.com features: create a locked-down organization, fork edk2 under
> > that organization (without adding any non-upstream changes to the fork),
> > and submit the embargoed patch series as a PR against the fork. Never
> > merge the patch set into the fork (only use the fork for patch review).
>
> Well, running the usual CI checks on the embargoed patch set, *inside
> the fork*, would be an extra problem... I don't know how github.com
> accounts for CI minutes in forks. Especially closed forks.
>
> Laszlo
>
>
>
> 
>
>
>


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

Re: [edk2-devel] pixiefail

[Laszlo Ersek]

On 1/24/24 16:20, Vincent Zimmer wrote:
> I agree on your sentiment about Bugzilla (bz) not being ideal for this.
> This space has been a multi-year journey from usrt-based tickets,
> bespoke advisories, bz, etc into today's world of tianocore infosec,
> tianocore as its own CVE Naming Authority (CNA) and working to leverage
> the extant features of github. On that latter point, there is work afoot
> to evolve from the present bz-based process
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues
>  
> 
>  to a github-based one 
> https://github.com/tianocore/tianocore.github.io/wiki/GHSA-GitHub-Security-Advisories-Proceess-(Draft)
>  
> .
>  Things are in transition now and I'd echo Doug's sentiment that getting more 
> feedback and engagement from the community would be valuable in getting the 
> various parts tested, evolved, documented, reviewed, etc.
> Vincent

The wiki article (draft) on the GHSA process looks great! I didn't know!

Thanks!
Laszlo

> 
> On Wed, Jan 24, 2024 at 6:57 AM Laszlo Ersek  > wrote:
> 
> On 1/24/24 15:35, Laszlo Ersek wrote:
> 
> > I figure the most flexible approach for those that dislike email-based
> > review for embargoed patches would be if github.com
>  supported locked
> > down *PRs* (i.e., not private organizatons). In other words, if those
> > PRs would be submitted against the same base repository and master
> > branch as every other PR, *but* they wouldn't be visible to anyone
> > except to a restricted group, and could never be merged. (For merging,
> > the approved version of the series would have to be posted publicly,
> > after the embargo.)
> >
> > ... Technically, the last paragraph could be implemented with current
> > github.com  features: create a locked-down
> organization, fork edk2 under
> > that organization (without adding any non-upstream changes to the
> fork),
> > and submit the embargoed patch series as a PR against the fork. Never
> > merge the patch set into the fork (only use the fork for patch
> review).
> 
> Well, running the usual CI checks on the embargoed patch set, *inside
> the fork*, would be an extra problem... I don't know how github.com
> 
> accounts for CI minutes in forks. Especially closed forks.
> 
> Laszlo
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114311): https://edk2.groups.io/g/devel/message/114311
Mute This Topic: https://groups.io/mt/103913088/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] OvmfPkg/ResetVector: send post codes to qemu debug console

[Gerd Hoffmann]

Neat when doing ResetVector coding.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/ResetVector/DebugCon.asm  | 43 +++
 OvmfPkg/ResetVector/ResetVector.nasmb |  2 +-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 OvmfPkg/ResetVector/DebugCon.asm

diff --git a/OvmfPkg/ResetVector/DebugCon.asm b/OvmfPkg/ResetVector/DebugCon.asm
new file mode 100644
index ..9c57d1a52c75
--- /dev/null
+++ b/OvmfPkg/ResetVector/DebugCon.asm
@@ -0,0 +1,43 @@
+;--
+; @file
+; qemu debug console support macros (based on serial port macros)
+;
+; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+%macro  outToDebugPort 1
+mov dx, 0x402
+mov al, %1
+out dx, al
+%endmacro
+
+%macro  debugShowCharacter 1
+outToDebugPort %1
+%endmacro
+
+%macro  debugShowHexDigit 1
+  %if (%1 < 0xa)
+debugShowCharacter BYTE ('0' + (%1))
+  %else
+debugShowCharacter BYTE ('a' + ((%1) - 0xa))
+  %endif
+%endmacro
+
+%macro  debugNewline 0
+debugShowCharacter `\r`
+debugShowCharacter `\n`
+%endmacro
+
+%macro  debugShowPostCode 1
+debugShowHexDigit (((%1) >> 4) & 0xf)
+debugShowHexDigit ((%1) & 0xf)
+debugNewline
+%endmacro
+
+BITS16
+
+%macro  debugInitialize 0
+; not required
+%endmacro
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 5832aaa8abf7..f1655ddfcde3 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -41,7 +41,7 @@
 %elifdef DEBUG_SERIAL
   %include "SerialDebug.asm"
 %else
-  %include "DebugDisabled.asm"
+  %include "DebugCon.asm"
 %endif
 
 %include "Ia32/SearchForBfvBase.asm"
-- 
2.43.0



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

Re: [edk2-devel] [PATCH v3 2/4] StandaloneMmPkg/Hob: Integer Overflow in CreateHob()

[Sami Mujawar]

Hi All,

Please see my response inline marked [SAMI].

Regards,

Sami Mujawar

On 24/01/2024, 12:41, "Gerd Hoffmann" mailto:kra...@redhat.com>> wrote:


On Fri, Jan 12, 2024 at 08:56:02AM +, Ni, Ray wrote:
> It's strange to me that ARM's MM env still allows modifying HOBs.
[SAMI] We are investigating the possibility of removing the HOB modification 
code for Arm. However, this may involve changes at multiple places in the 
software stack.
Therefore, it may not be possible to immediately remove that support. 
[/SAMI]

Yes.


But fixing that is beyond the scope of this patch, which just
[SAMI] I agree, it is beyond the scope of this patch.

fixes the integer overflow in CreateHob().

Can we please move forward and get the remaining CreateHob()
fixes merged?


thanks & take care,
Gerd







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

[edk2-devel] [PATCH 1/1] MdeModulePkg/VirtualMemory: drop 5-level paging assert

[Gerd Hoffmann]

The ResetVector decides at runtime (depending in CPU capabilities)
whenever it uses 5-level paging or not.  Firmware builds with 5-level
paging enabled (PcdUse5LevelPageTable=TRUE) may run run in 4-level
paging mode.  The code handles that just fine, by looking at the la57
bit in cr4 instead of checking PcdUse5LevelPageTable.

The ASSERT is not correct, remove it.

Signed-off-by: Gerd Hoffmann 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 980c2002d4f5..575e396eeffd 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -745,7 +745,6 @@ CreateIdentityMappingPageTables (
 //
 Cr4.UintN = AsmReadCr4 ();
 Page5LevelSupport = (Cr4.Bits.LA57 != 0);
-ASSERT (PcdGetBool (PcdUse5LevelPageTable) == Page5LevelSupport);
   } else {
 //
 // If cpu runs in 32bit protected mode PEI, Page table Level in DXE is 
decided by PCD and feature capability.
-- 
2.43.0



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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/Sec: Setup MTRR early in the boot process.

[Laszlo Ersek]

On 1/24/24 16:15, Gerd Hoffmann wrote:
> Specifically before running lzma uncompress of the main firmware volume.
> This is needed to make sure caching is enabled, otherwise the uncompress
> can be extremely slow.
> 
> Adapt the ASSERTs in PlatformInitLib to the changes.
> 
> Background:  In some virtual machine configurations with assigned
> devices kvm uses EPT memory types to apply guest MTRR settings.
> In case MTRRs are disabled kvm will use the uncachable memory type
> for all mappings.

I suggest mentioning mdev and noncoherent DMA here (the linux code you
quoted elsewhere would be welcome too).

> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c |  8 --
>  OvmfPkg/Sec/SecMain.c   | 32 +
>  2 files changed, 37 insertions(+), 3 deletions(-)

The original report 
claims that commit e8aa4c6546ad ("UefiCpuPkg/ResetVector: Cache Disable
should not be set by default in CR0", 2023-08-30) triggered the symptom.

I still don't understand how that is possible. Assuming we have
noncoherent DMA due to mdev assignment, KVM will honor "Guest
CD/MTRR/PAT". Let's consider each in turn:

- CD (cache disable): set to zero in recent commit e8aa4c6546ad.

- MTRR: we set DefType to WB, in this patch, but not enabled upstream,
at present

- PAT: IIUC, we don't deal with that at all in edk2

- PCD: not set, minimally through edk2 commit 98f378a7be12
("OvmfPkg/ResetVector: enable caching in initial page tables", 2013-09-24)

I don't understand how *clearing* CD in CR0, could make guest memory
*less* cacheable. I understand the point about MTRR, but exactly the
MTRR's currently upstream state should have masked any changes to CD.

(1) Is the initial report wrong?

> 
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index f042517bb64a..cb2ae0f3d79d 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -1082,11 +1082,13 @@ PlatformQemuInitializeRam (
>  MtrrGetAllMtrrs (&MtrrSettings);
>  
>  //
> -// MTRRs disabled, fixed MTRRs disabled, default type is uncached
> +// Fixed MTRRs disabled, default type is uncached or write back (see 
> SecMtrrSetup())
>  //
> -ASSERT ((MtrrSettings.MtrrDefType & BIT11) == 0);
>  ASSERT ((MtrrSettings.MtrrDefType & BIT10) == 0);
> -ASSERT ((MtrrSettings.MtrrDefType & 0xFF) == 0);
> +ASSERT (
> +  (MtrrSettings.MtrrDefType & 0xFF) == 0x0 ||
> +  (MtrrSettings.MtrrDefType & 0xFF) == 0x6
> +  );
>  
>  //
>  // flip default type to writeback

This code comes (originally) from commit 79d274b8b6b1 ("OvmfPkg:
PlatformPei: invert MTRR setup in QemuInitializeRam()", 2015-06-26).

The purpose(s) of that commit include "setting the default to writeback"
-- even in the context quoted above, we see the comment "flip default
type to writeback". A wider context is:

//
// flip default type to writeback
//
SetMem (&MtrrSettings.Fixed, sizeof MtrrSettings.Fixed, 0x06);
ZeroMem (&MtrrSettings.Variables, sizeof MtrrSettings.Variables);
MtrrSettings.MtrrDefType |= BIT11 | BIT10 | 6;
MtrrSetAllMtrrs (&MtrrSettings);

So:

(2) We already assume (minimally since 2015) that MTRRs are supported by
the processor. This means that (a) the CPUID check in SecMtrrSetup() is
superfluous, and that (b) we need not / should not permit

  (MtrrSettings.MtrrDefType & 0xFF) == 0x0

in the ASSERT(), going forward.

(3) The rest of the code and *comments* here -- in
PlatformQemuInitializeRam() -- should be updated such that we only
enable the fixed MTRRs (BIT10) on top of what SEC does earlier (which
is: BIT11 (general enable) and DefType=6).

Something like:

  ASSERT ((MtrrSettings.MtrrDefType & BIT11) != 0);
  ASSERT ((MtrrSettings.MtrrDefType & BIT10) == 0);
  ASSERT ((MtrrSettings.MtrrDefType & 0xFF) == 6);

  ...

  MtrrSettings.MtrrDefType |= BIT10;

> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index 31da5d0ace51..a672751b046a 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -30,6 +30,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 

(4) with the CPUID gone, the second header should not be needed

>  #include "AmdSev.h"
>  
>  #define SEC_IDT_ENTRY_COUNT  34
> @@ -744,6 +746,31 @@ FindAndReportEntryPoints (
>return;
>  }
>  
> +//
> +// Enable MTRR early, set default type to write back.
> +// Needed to make sure caching is enabled,
> +// without this lzma decompress can be very slow.
> +//
> +STATIC
> +VOID
> +SecMtrrSetup (
> +  VOID
> +  )
> +{
> +  CPUID_VERSION_INFO_EDX   Edx;
> +  MSR_IA32_MTRR_DEF_TYPE_REGISTER  DefType;
> +
> +  AsmCpuid (CPUID_VERSION_INFO, NULL, NULL, NULL, &Edx.Uint32);
> +  if (!Edx.Bits.MTRR) {
> +return;
> +  }
> +
> +  DefType.Uint64= 0;

(5) Can we first read the MSR, instead of expl

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

[Laszlo Ersek]

On 1/24/24 15:59, gaoliming via groups.io wrote:
> Mike:
>  Current algorithm tries to reserve the top available memory for memory type
> bin range. 
>  If the platform uses new way to describe the memory range, should we
> suggest the rule to still 
>  use the top memory resource hob for the memory type bin range?

How would that work, technically? If the platform specifies a concrete
address range, how can that be reconciled with using the top of RAM?

Or do you mean documentation? I.e., a note for platform implementors
that they should point their new HOB to the top of RAM?

Thanks
Laszlo

> 
> Thanks
> Liming
>> -邮件原件-
>> 发件人: Michael D Kinney 
>> 发送时间: 2024年1月24日 4:24
>> 收件人: devel@edk2.groups.io
>> 抄送: Liming Gao ; Aaron Li
>> ; Liu Yun ; Andrew Fish
>> 
>> 主题: [Patch v2 1/1] MdeModulePkg/Core/Dxe: Set MemoryTypeInfo bin
>> range from HOB
>>
>> Provide an optional method for PEI to declare a specific address
>> range to use for the Memory Type Information bins. The current
>> algorithm uses heuristics that tends to place the Memory Type
>> Information bins in the same location, but memory configuration
>> changes across boots or algorithm changes across a firmware
>> updates could potentially change the Memory Type Information bin
>> location.
>>
>> If the HOB List contains a Resource Descriptor HOB that
>> describes tested system memory and has an Owner GUID of
>> gEfiMemoryTypeInformationGuid, then use the address range
>> described by the Resource Descriptor HOB as the preferred
>> location of the Memory Type Information bins. If this HOB is
>> not detected, then the current behavior is preserved.
>>
>> The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
>> is ignored for the following conditions:
>> * The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
>>   is smaller than the Memory Type Information bins.
>> * The HOB list contains more than one Resource Descriptor HOB
>>   with an owner GUID of gEfiMemoryTypeInformationGuid.
>> * The Resource Descriptor HOB with an Owner GUID of
>>   gEfiMemoryTypeInformationGuid is the same Resource Descriptor
>>   HOB that that describes the PHIT memory range.
>>
>> Update the DxeMain initialization order to initialize GCD
>> services before any runtime allocations are performed.  This
>> is required to prevent runtime data fragmentation when the
>> UEFI System Table and UEFI Runtime Service Table is allocated.
>>
>> Cc: Liming Gao 
>> Cc: Aaron Li 
>> Cc: Liu Yun 
>> Cc: Andrew Fish 
>> Signed-off-by: Michael D Kinney 
>> ---
>>  MdeModulePkg/Core/Dxe/DxeMain.h |   6 ++
>>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c |  23 +++---
>>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c |  72 -
>>  MdeModulePkg/Core/Dxe/Mem/Page.c| 101
>> 
>>  4 files changed, 190 insertions(+), 12 deletions(-)
>>
>> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
>> b/MdeModulePkg/Core/Dxe/DxeMain.h
>> index 86a7be2f5188..53e26703f8c7 100644
>> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
>> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
>> @@ -277,6 +277,12 @@ CoreInitializePool (
>>VOID
>>);
>>
>> +VOID
>> +CoreSetMemoryTypeInformationRange (
>> +  IN EFI_PHYSICAL_ADDRESS  Start,
>> +  IN UINT64Length
>> +  );
>> +
>>  /**
>>Called to initialize the memory map and add descriptors to
>>the current descriptor list.
>> diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
>> b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
>> index 0e0f9769b99d..17d510a287e5 100644
>> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
>> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
>> @@ -276,6 +276,18 @@ DxeMain (
>>
>>MemoryProfileInit (HobStart);
>>
>> +  //
>> +  // Start the Image Services.
>> +  //
>> +  Status = CoreInitializeImageServices (HobStart);
>> +  ASSERT_EFI_ERROR (Status);
>> +
>> +  //
>> +  // Initialize the Global Coherency Domain Services
>> +  //
>> +  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress,
>> MemoryLength);
>> +  ASSERT_EFI_ERROR (Status);
>> +
>>//
>>// Allocate the EFI System Table and EFI Runtime Service Table from
>> EfiRuntimeServicesData
>>// Use the templates to initialize the contents of the EFI System Table
> and
>> EFI Runtime Services Table
>> @@ -289,16 +301,9 @@ DxeMain (
>>gDxeCoreST->RuntimeServices = gDxeCoreRT;
>>
>>//
>> -  // Start the Image Services.
>> +  // Update DXE Core Loaded Image Protocol with allocated UEFI System
>> Table
>>//
>> -  Status = CoreInitializeImageServices (HobStart);
>> -  ASSERT_EFI_ERROR (Status);
>> -
>> -  //
>> -  // Initialize the Global Coherency Domain Services
>> -  //
>> -  Status = CoreInitializeGcdServices (&HobStart, MemoryBaseAddress,
>> MemoryLength);
>> -  ASSERT_EFI_ERROR (Status);
>> +  gDxeCoreLoadedImage->SystemTable = gDxeCoreST;
>>
>>//
>>// Call constructor for all libraries
>> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
>> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
>> index 792cd2e0af2

Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler

[Ni, Ray]

spec does not say the unregistration is allowed inside handler. it's just to 
improve the qualiquali the code.

thanks,
ray

From: Laszlo Ersek 
Sent: Wednesday, January 24, 2024 9:06:13 PM
To: devel@edk2.groups.io ; Ni, Ray ; 
Liu, Zhiguang 
Cc: Liming Gao ; Wu, Jiaxin ; 
POLUDOV, FELIX 
Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to unregister SMI 
handler inside SMI handler

On 1/24/24 09:11, Ni, Ray wrote:
> Felix, I remember you mentioned to me about the usage of SMI handler 
> unregistering itself.

I wanted to ask: is this something that the PI spec comments on? I.e.,
is this usage expected by the spec (in which case this bugfix is a
conformance fix), or is the spec silent on it (in which case I guess we
can call this a quality-of-implementation improvement)?

>
> Reviewed-by: Ray Ni 

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

>
> Thanks,
> Ray
>> -Original Message-
>> From: Liu, Zhiguang 
>> Sent: Wednesday, January 24, 2024 12:03 PM
>> To: devel@edk2.groups.io
>> Cc: Liu, Zhiguang ; Liming Gao
>> ; Wu, Jiaxin ; Ni, Ray
>> 
>> Subject: [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler
>> inside SMI handler
>>
>> To support unregister SMI handler inside SMI handler itself,
>> get next node before SMI handler is executed, since LIST_ENTRY that
>> Link points to may be freed if unregister SMI handler in SMI handler
>> itself.
>>
>> Cc: Liming Gao 
>> Cc: Jiaxin Wu 
>> Cc: Ray Ni 
>> Signed-off-by: Zhiguang Liu 
>> ---
>>  MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
>> b/MdeModulePkg/Core/PiSmmCore/Smi.c
>> index 2985f989c3..a75e52b1ae 100644
>> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
>> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
>> @@ -134,8 +134,14 @@ SmiManage (
>>
>>Head = &SmiEntry->SmiHandlers;
>>
>> -  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
>> +  for (Link = Head->ForwardLink; Link != Head;) {
>>  SmiHandler = CR (Link, SMI_HANDLER, Link,
>> SMI_HANDLER_SIGNATURE);
>> +//
>> +// To support unregiser SMI handler inside SMI handler itself,
>> +// get next node before handler is executed, since LIST_ENTRY that
>> +// Link points to may be freed if unregister SMI handler.
>> +//
>> +Link = Link->ForwardLink;
>>
>>  Status = SmiHandler->Handler (
>> (EFI_HANDLE)SmiHandler,
>> --
>> 2.31.1.windows.1
>
>
>
> 
>
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114317): https://edk2.groups.io/g/devel/message/114317
Mute This Topic: https://groups.io/mt/103925794/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] MdeModulePkg/VirtualMemory: drop 5-level paging assert

[Laszlo Ersek]

On 1/24/24 16:49, Gerd Hoffmann wrote:
> The ResetVector decides at runtime (depending in CPU capabilities)

(1) s/depending in/dependent on/

> whenever it uses 5-level paging or not.  Firmware builds with 5-level
> paging enabled (PcdUse5LevelPageTable=TRUE) may run run in 4-level

(2) typo: "run run"

(3) Suggest the following wording improvement:

  Firmware that intends to enable 5-level paging may run in 4-level ...

Justification:

- the expression "firmware builds" suggests a fixed-at-build PCD, but
this PCD is declared as [PcdsFixedAtBuild, PcdsPatchableInModule,
PcdsDynamic, PcdsDynamicEx]. So it may be a runtime decision even to
*request* 5-level paging.

- "intends" rather than "enabled" because the PCD is just an expression
of intent. Per DEC file:

>   ## Indicates if 5-Level Paging will be enabled in long mode. 5-Level Paging 
> will not be enabled
>   #  when the PCD is TRUE but CPU doesn't support 5-Level Paging.

Back to the patch:

On 1/24/24 16:49, Gerd Hoffmann wrote:
> paging mode.  The code handles that just fine, by looking at the la57
> bit in cr4 instead of checking PcdUse5LevelPageTable.
>
> The ASSERT is not correct,

I agree, but...

> remove it.

I have a better idea, I believe:

>
> Signed-off-by: Gerd Hoffmann 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> index 980c2002d4f5..575e396eeffd 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> @@ -745,7 +745,6 @@ CreateIdentityMappingPageTables (
>  //
>  Cr4.UintN = AsmReadCr4 ();
>  Page5LevelSupport = (Cr4.Bits.LA57 != 0);
> -ASSERT (PcdGetBool (PcdUse5LevelPageTable) == Page5LevelSupport);

In my opinion, what the code originally wanted to express here was not
*equivalence*, but *implication* (that is, only one direction, not both
directions). The idea is, if we find the LA57 bit set, then the platform
must have requested 5-level paging. As a logical predicate:

  Page5LevelSupport ==> PcdGetBool (PcdUse5LevelPageTable)

In C, we don't have an "implies" operator, but

  A ==> B

is just

  !(A) || (B)

(4) Therefore I suggest the following update (rather than deletion):

ASSERT (!Page5LevelSupport || PcdGetBool (PcdUse5LevelPageTable));

Alternatively (equivalently):

if (Page5LevelSupport) {
  ASSERT (PcdGetBool (PcdUse5LevelPageTable));
}

This variant adds a bit of useless code to RELEASE builds, but in those
builds, the empty body of the "if" should cause the "if" itself to be
optimized away, too. So pick whichever you like.

(If the assertion fails, then the first variant's error message in the
log is more informative, FWIW!)

(5) At the same time, the subject should become "*fix* 5-level paging
assert".

(6) "Page5LevelSupport" is a misnomer to begin with! In my opinion, the
right name would be "Page5LevelEnabled"; after all, it comes from CR4
(it's active!), not from some MSR. Please consider renaming the variable
in a separate patch (ahead of fixing the logic bug).

>} else {
>  //
>  // If cpu runs in 32bit protected mode PEI, Page table Level in DXE is 
> decided by PCD and feature capability.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114318): https://edk2.groups.io/g/devel/message/114318
Mute This Topic: https://groups.io/mt/103934284/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 00/11] OvmfPkg: tweak shell builds

[Gerd Hoffmann]

- Create include files to reduce duplication.
- Fix varpolicy command.
- Little CI tweak.

Gerd Hoffmann (11):
  OvmfPkg: add ShellComponents.dsc.inc
  OvmfPkg: add ShellLibs.dsc.inc
  OvmfPkg: add ShellDxe.fdf.inc
  OvmfPkg: Shell*.inc: allow building without network support
  OvmfPkg: ShellDxe.fdf.inc: add VariablePolicyDynamicCommand to FV
  OvmfPkg: switch OvmfPkgIa32 to new shell include files
  OvmfPkg: switch OvmfPkgIa32X64 to new shell include files
  OvmfPkg: switch AmdSevX64 to new shell include files
  OvmfPkg: switch IntelTdxX64 to new shell include files
  OvmfPkg: switch MicrovmX64 to new shell include files
  OvmfPkg/CI: copy shell to virtual drive

 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 53 
 OvmfPkg/Include/Dsc/ShellLibs.dsc.inc   | 11 +
 OvmfPkg/AmdSev/AmdSevX64.dsc| 32 +---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc| 33 ++---
 OvmfPkg/Microvm/MicrovmX64.dsc  | 55 +
 OvmfPkg/OvmfPkgIa32.dsc | 49 +-
 OvmfPkg/OvmfPkgIa32X64.dsc  | 54 +++-
 OvmfPkg/OvmfPkgX64.dsc  | 54 +++-
 OvmfPkg/AmdSev/AmdSevX64.fdf|  8 +--
 OvmfPkg/IntelTdx/IntelTdxX64.fdf|  9 +---
 OvmfPkg/Microvm/MicrovmX64.fdf  |  9 +---
 OvmfPkg/OvmfPkgIa32.fdf | 11 +
 OvmfPkg/OvmfPkgIa32X64.fdf  | 11 +
 OvmfPkg/OvmfPkgX64.fdf  | 11 +
 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc| 17 +++
 OvmfPkg/PlatformCI/PlatformBuildLib.py  | 12 -
 16 files changed, 135 insertions(+), 294 deletions(-)
 create mode 100644 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
 create mode 100644 OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
 create mode 100644 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc

-- 
2.43.0



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

[edk2-devel] [PATCH 03/11] OvmfPkg: add ShellDxe.fdf.inc

[Gerd Hoffmann]

Move EFI Shell firmware volume files to
the new ShellDxe.fdf.inc file.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/OvmfPkgX64.fdf   | 11 ++-
 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc | 14 ++
 2 files changed, 16 insertions(+), 9 deletions(-)
 create mode 100644 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index f47ab1727e4c..eb3fb90cb8b6 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -319,15 +319,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
 INF  OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
 
-!if $(BUILD_SHELL) == TRUE && $(TOOL_CHAIN_TAG) != "XCODE5"
-INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
-INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
-INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
-!endif
-!if $(BUILD_SHELL) == TRUE
-INF  ShellPkg/Application/Shell/Shell.inf
-!endif
-
 INF MdeModulePkg/Logo/LogoDxe.inf
 
 INF OvmfPkg/TdxDxe/TdxDxe.inf
@@ -402,6 +393,8 @@ [FV.DXEFV]
 #
 !include OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
 
+!include OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+
 

 
 [FV.FVMAIN_COMPACT]
diff --git a/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc 
b/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
new file mode 100644
index ..0935f06fa368
--- /dev/null
+++ b/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
@@ -0,0 +1,14 @@
+##
+#SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+!if $(BUILD_SHELL) == TRUE
+
+!if $(TOOL_CHAIN_TAG) != "XCODE5"
+INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
+INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
+!endif
+
+INF  ShellPkg/Application/Shell/Shell.inf
+!endif
-- 
2.43.0



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

[edk2-devel] [PATCH 02/11] OvmfPkg: add ShellLibs.dsc.inc

[Gerd Hoffmann]

Move EFI Shell libraries from OvmfPkgX64.dsc to
the new ShellComponents.dsc.inc include file.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Dsc/ShellLibs.dsc.inc | 11 +++
 OvmfPkg/OvmfPkgX64.dsc| 11 +--
 2 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 OvmfPkg/Include/Dsc/ShellLibs.dsc.inc

diff --git a/OvmfPkg/Include/Dsc/ShellLibs.dsc.inc 
b/OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
new file mode 100644
index ..2e0bac74a261
--- /dev/null
+++ b/OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
@@ -0,0 +1,11 @@
+##
+#SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+!if $(BUILD_SHELL) == TRUE
+
+[LibraryClasses]
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
+
+!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 043b0a7a67e0..eae025bd0163 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -258,16 +258,12 @@ [LibraryClasses]
   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
 !endif
 
-!if $(BUILD_SHELL) == TRUE
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-!endif
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
 
 !include OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
+!include OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -960,7 +956,10 @@ [Components]
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-  OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
+  OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf {
+
+ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
+  }
 !endif
 
   OvmfPkg/PlatformDxe/Platform.inf
-- 
2.43.0



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

[edk2-devel] [PATCH 04/11] OvmfPkg: Shell*.inc: allow building without network support

[Gerd Hoffmann]

Add NETWORK_ENABLE conditionals for the components
which need network support.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 4 
 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc| 2 ++
 2 files changed, 6 insertions(+)

diff --git a/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc 
b/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
index 1a3a349a9de5..248b4b454b70 100644
--- a/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
+++ b/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
@@ -5,6 +5,7 @@
 !if $(BUILD_SHELL) == TRUE
 
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(NETWORK_ENABLE) == TRUE
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
@@ -13,6 +14,7 @@
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
+!endif
   
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 {
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
@@ -32,7 +34,9 @@
   
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
+!if $(NETWORK_ENABLE) == TRUE
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
+!endif
 !if $(NETWORK_IP6_ENABLE) == TRUE
   
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
 !endif
diff --git a/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc 
b/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
index 0935f06fa368..6536c30c5413 100644
--- a/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+++ b/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
@@ -5,8 +5,10 @@
 !if $(BUILD_SHELL) == TRUE
 
 !if $(TOOL_CHAIN_TAG) != "XCODE5"
+!if $(NETWORK_ENABLE) == TRUE
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
 INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
+!endif
 INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 !endif
 
-- 
2.43.0



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

[edk2-devel] [PATCH 01/11] OvmfPkg: add ShellComponents.dsc.inc

[Gerd Hoffmann]

Move EFI Shell components from OvmfPkgX64.dsc to
the new ShellComponents.dsc.inc include file.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 49 +
 OvmfPkg/OvmfPkgX64.dsc  | 43 +-
 2 files changed, 50 insertions(+), 42 deletions(-)
 create mode 100644 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc

diff --git a/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc 
b/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
new file mode 100644
index ..1a3a349a9de5
--- /dev/null
+++ b/OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
@@ -0,0 +1,49 @@
+##
+#SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+!if $(BUILD_SHELL) == TRUE
+
+!if $(TOOL_CHAIN_TAG) != "XCODE5"
+  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
+  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
+  
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
+  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
+!endif
+
+  ShellPkg/Application/Shell/Shell.inf {
+
+  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
+  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
+!if $(NETWORK_IP6_ENABLE) == TRUE
+  
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
+!endif
+  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
+
+
+  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
+  }
+
+!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index bf4c7906c460..043b0a7a67e0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -956,48 +956,7 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
-  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-!endif
-!if $(BUILD_SHELL) == TRUE
-  ShellPkg/Application/Shell/Shell.inf {
-
-  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
-!if $(NETWORK_IP6_ENABLE) == TRUE
-  
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
-!endif
-  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
-
-
-  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
-  gEfiShellPkgTokenSpaceGuid.PcdShel

[edk2-devel] [PATCH 07/11] OvmfPkg: switch OvmfPkgIa32X64 to new shell include files

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/OvmfPkgIa32X64.dsc | 54 +-
 OvmfPkg/OvmfPkgIa32X64.fdf | 11 ++--
 2 files changed, 8 insertions(+), 57 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5e9eee628aea..4d57026bb1ed 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -242,16 +242,12 @@ [LibraryClasses]
   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
 !endif
 
-!if $(BUILD_SHELL) == TRUE
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-!endif
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
 
 !include OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
+!include OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -888,52 +884,14 @@ [Components.X64]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
-  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-!endif
-!if $(BUILD_SHELL) == TRUE
-  ShellPkg/Application/Shell/Shell.inf {
-
-  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
-!if $(NETWORK_IP6_ENABLE) == TRUE
-  
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
-!endif
-  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
-
-
-  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
-  }
-!endif
+!include OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-  OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
+  OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf {
+
+ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
+  }
 !endif
 
   OvmfPkg/PlatformDxe/Platform.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 74cfb58f06cd..ee8068ad55dc 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -294,15 +294,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
 INF  OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
 
-!if $(BUILD_SHELL) == TRUE && $(TOOL_CHAIN_TAG) != "XCODE5"
-INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
-INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
-INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
-!endif
-!if $(BUILD_SHELL) == TRUE
-INF  ShellPkg/Application/Shell/Shell.inf
-!endif
-
 INF MdeModulePkg/Logo/LogoDxe.inf
 
 #
@@ -368,6 +359,8 @@ [FV.DXEFV]
 #
 !include OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
 
+!include OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+
 

 
 [FV.FVMAIN_COMPACT]
-- 
2.43.0



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

[edk2-devel] [PATCH 09/11] OvmfPkg: switch IntelTdxX64 to new shell include files

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 33 +++-
 OvmfPkg/IntelTdx/IntelTdxX64.fdf |  9 ++---
 2 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 82e3e41cfc57..57072116e43e 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -201,10 +201,6 @@ [LibraryClasses]
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
-!if $(BUILD_SHELL) == TRUE
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-!endif
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
@@ -212,6 +208,8 @@ [LibraryClasses]
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
 
+!include OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
+
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
   CcExitLib|OvmfPkg/Library/CcExitLib/CcExitLib.inf
@@ -717,32 +715,7 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
-  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-!endif
-!if $(BUILD_SHELL) == TRUE
-  ShellPkg/Application/Shell/Shell.inf {
-
-  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
-
-
-  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
-  }
-!endif
+!include OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
index e844a0988d68..f3b5126254c6 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
@@ -307,13 +307,6 @@ [FV.NCCFV]
 INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
 INF  OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
 
-!if $(BUILD_SHELL) == TRUE && $(TOOL_CHAIN_TAG) != "XCODE5"
-INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
-!endif
-!if $(BUILD_SHELL) == TRUE
-INF  ShellPkg/Application/Shell/Shell.inf
-!endif
-
 INF MdeModulePkg/Logo/LogoDxe.inf
 
 #
@@ -332,6 +325,8 @@ [FV.NCCFV]
 INF  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
 INF  OvmfPkg/PlatformDxe/Platform.inf
 
+!include OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+
 

 
 [FV.FVMAIN_COMPACT]
-- 
2.43.0



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

[edk2-devel] [PATCH 11/11] OvmfPkg/CI: copy shell to virtual drive

[Gerd Hoffmann]

Place the EFI shell as EFI/BOOT/BOOT{ARCH}.EFI on the virtual drive.
This allows the "run to shell" CI test case to work even in case the
shell is not included in the firmware image.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/PlatformCI/PlatformBuildLib.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
b/OvmfPkg/PlatformCI/PlatformBuildLib.py
index f829738cdda4..00d454954bff 100644
--- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
+++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
@@ -5,6 +5,7 @@
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 import os
+import shutil
 import logging
 import io
 
@@ -181,7 +182,8 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
 
 def FlashRomImage(self):
 VirtualDrive = os.path.join(self.env.GetValue("BUILD_OUTPUT_BASE"), 
"VirtualDrive")
-os.makedirs(VirtualDrive, exist_ok=True)
+VirtualDriveBoot = os.path.join(VirtualDrive, "EFI", "BOOT")
+os.makedirs(VirtualDriveBoot, exist_ok=True)
 OutputPath_FV = os.path.join(self.env.GetValue("BUILD_OUTPUT_BASE"), 
"FV")
 
 if (self.env.GetValue("QEMU_SKIP") and
@@ -189,6 +191,14 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
 logging.info("skipping qemu boot test")
 return 0
 
+# copy shell to VirtualDrive
+for arch in self.env.GetValue("TARGET_ARCH").split():
+src = os.path.join(self.env.GetValue("BUILD_OUTPUT_BASE"), arch, 
"Shell.efi")
+dst = os.path.join(VirtualDriveBoot, f'BOOT{arch}.EFI')
+if os.path.exists(src):
+logging.info("copy %s -> %s", src, dst)
+shutil.copyfile(src, dst)
+
 #
 # QEMU must be on the path
 #
-- 
2.43.0



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

[edk2-devel] [PATCH 08/11] OvmfPkg: switch AmdSevX64 to new shell include files

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 32 ++--
 OvmfPkg/AmdSev/AmdSevX64.fdf |  8 ++--
 2 files changed, 4 insertions(+), 36 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a31a89344a60..41c61467253f 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -194,16 +194,12 @@ [LibraryClasses]
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
 
-!if $(BUILD_SHELL) == TRUE
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-!endif
-
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
 
 !include OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
+!include OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -729,34 +725,10 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
-  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-!endif
   OvmfPkg/AmdSev/SecretDxe/SecretDxe.inf
   OvmfPkg/AmdSev/Grub/Grub.inf
-!if $(BUILD_SHELL) == TRUE
-  ShellPkg/Application/Shell/Shell.inf {
-
-  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
-
-  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
-  }
-!endif
+!include OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
 
   OvmfPkg/PlatformDxe/Platform.inf
   OvmfPkg/AmdSevDxe/AmdSevDxe.inf {
diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index 9dd409596780..b84981e7ba04 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -277,14 +277,8 @@ [FV.DXEFV]
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
-INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
-!endif
 INF OvmfPkg/AmdSev/SecretDxe/SecretDxe.inf
 INF  OvmfPkg/AmdSev/Grub/Grub.inf
-!if $(BUILD_SHELL) == TRUE
-INF  ShellPkg/Application/Shell/Shell.inf
-!endif
 
 INF MdeModulePkg/Logo/LogoDxe.inf
 
@@ -320,6 +314,8 @@ [FV.DXEFV]
 #
 !include OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
 
+!include OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+
 

 
 [FV.FVMAIN_COMPACT]
-- 
2.43.0



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

[edk2-devel] [PATCH 10/11] OvmfPkg: switch MicrovmX64 to new shell include files

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Microvm/MicrovmX64.dsc | 55 --
 OvmfPkg/Microvm/MicrovmX64.fdf |  9 ++
 2 files changed, 14 insertions(+), 50 deletions(-)

diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 063324cd0572..2f2b95c9f0fa 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -33,6 +33,11 @@ [Defines]
   DEFINE SMM_REQUIRE = FALSE
   DEFINE SOURCE_DEBUG_ENABLE = FALSE
 
+  #
+  # Shell can be useful for debugging but should not be enabled for production
+  #
+  DEFINE BUILD_SHELL = TRUE
+
   #
   # Network definition
   #
@@ -230,8 +235,6 @@ [LibraryClasses]
   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
 !endif
 
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
@@ -239,6 +242,8 @@ [LibraryClasses]
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
 
+!include OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
+
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
   CcExitLib|OvmfPkg/Library/CcExitLib/CcExitLib.inf
@@ -837,50 +842,14 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
-  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-!endif
-  ShellPkg/Application/Shell/Shell.inf {
-
-  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
-!if $(NETWORK_IP6_ENABLE) == TRUE
-  
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
-!endif
-  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
-
-
-  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
-  }
+!include OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
-  OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
+  OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf {
+
+ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
+  }
 !endif
 
   OvmfPkg/PlatformDxe/Platform.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.fdf b/OvmfPkg/Microvm/MicrovmX64.fdf
index c877b3f088f9..825bf9f5e41f 100644
--- a/OvmfPkg/Microvm/MicrovmX64.fdf
+++ b/OvmfPkg/Microvm/MicrovmX64.fdf
@@ -257,13 +257,6 @@ [FV.DXEFV]
 INF  EmbeddedPkg/Drivers/FdtClientDxe/FdtClientDxe.inf
 INF  OvmfPkg/Fdt/VirtioFdtDxe/VirtioFdtDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5"
-INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
-INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
-INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
-!endif
-INF  ShellPkg/Application/Shell/Shell.inf
-
 INF MdeModulePkg/Logo/LogoDxe.inf
 
 #
@@ -302,6 +295,8 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
 INF  MdeModulePkg/Universal/Variable/RuntimeDxe/V

[edk2-devel] [PATCH 06/11] OvmfPkg: switch OvmfPkgIa32 to new shell include files

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/OvmfPkgIa32.dsc | 49 ++---
 OvmfPkg/OvmfPkgIa32.fdf | 11 ++---
 2 files changed, 4 insertions(+), 56 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 28379961a78e..23f949fd9845 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -237,16 +237,12 @@ [LibraryClasses]
   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
 !endif
 
-!if $(BUILD_SHELL) == TRUE
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-!endif
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-
   
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
 
 !include OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc
+!include OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -874,48 +870,7 @@ [Components]
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
 
-!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE
-  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
-
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  }
-!endif
-!if $(BUILD_SHELL) == TRUE
-  ShellPkg/Application/Shell/Shell.inf {
-
-  
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
-!if $(NETWORK_IP6_ENABLE) == TRUE
-  
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
-!endif
-  
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
-
-
-  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
-  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
-  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
-  }
-!endif
+!include OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 501b4de4695e..6c56c5e53f21 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -293,15 +293,6 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
 INF  OvmfPkg/VirtioFsDxe/VirtioFsDxe.inf
 
-!if $(BUILD_SHELL) == TRUE && $(TOOL_CHAIN_TAG) != "XCODE5"
-INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
-INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
-INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
-!endif
-!if $(BUILD_SHELL) == TRUE
-INF  ShellPkg/Application/Shell/Shell.inf
-!endif
-
 INF MdeModulePkg/Logo/LogoDxe.inf
 
 #
@@ -361,6 +352,8 @@ [FV.DXEFV]
 #
 !include OvmfPkg/Include/Fdf/OvmfTpmDxe.fdf.inc
 
+!include OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+
 !if $(LOAD_X64_ON_IA32_ENABLE) == TRUE
 INF  OvmfPkg/CompatImageLoaderDxe/CompatImageLoaderDxe.inf
 !endif
-- 
2.43.0



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

[edk2-devel] [PATCH 05/11] OvmfPkg: ShellDxe.fdf.inc: add VariablePolicyDynamicCommand to FV

[Gerd Hoffmann]

Needed to make the new 'varpolicy' EFI shell command
actually available in the OVMF firmware builds.

Fixes: fe6cd1c18721 ("OvmfPkg: Add varpolicy shell command")
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc 
b/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
index 6536c30c5413..3081ac41780a 100644
--- a/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
+++ b/OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
@@ -9,6 +9,7 @@
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
 INF  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
 !endif
+INF  
ShellPkg/DynamicCommand/VariablePolicyDynamicCommand/VariablePolicyDynamicCommand.inf
 INF  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf
 !endif
 
-- 
2.43.0



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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/ResetVector: send post codes to qemu debug console

[Laszlo Ersek]

On 1/24/24 16:31, Gerd Hoffmann wrote:
> Neat when doing ResetVector coding.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/ResetVector/DebugCon.asm  | 43 +++
>  OvmfPkg/ResetVector/ResetVector.nasmb |  2 +-
>  2 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 OvmfPkg/ResetVector/DebugCon.asm
> 
> diff --git a/OvmfPkg/ResetVector/DebugCon.asm 
> b/OvmfPkg/ResetVector/DebugCon.asm
> new file mode 100644
> index ..9c57d1a52c75
> --- /dev/null
> +++ b/OvmfPkg/ResetVector/DebugCon.asm
> @@ -0,0 +1,43 @@
> +;--
> +; @file
> +; qemu debug console support macros (based on serial port macros)
> +;
> +; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> +;
> +;--
> +
> +%macro  outToDebugPort 1
> +mov dx, 0x402
> +mov al, %1
> +out dx, al
> +%endmacro
> +
> +%macro  debugShowCharacter 1
> +outToDebugPort %1
> +%endmacro
> +
> +%macro  debugShowHexDigit 1
> +  %if (%1 < 0xa)
> +debugShowCharacter BYTE ('0' + (%1))
> +  %else
> +debugShowCharacter BYTE ('a' + ((%1) - 0xa))
> +  %endif
> +%endmacro
> +
> +%macro  debugNewline 0
> +debugShowCharacter `\r`
> +debugShowCharacter `\n`
> +%endmacro
> +
> +%macro  debugShowPostCode 1
> +debugShowHexDigit (((%1) >> 4) & 0xf)
> +debugShowHexDigit ((%1) & 0xf)
> +debugNewline
> +%endmacro
> +
> +BITS16
> +
> +%macro  debugInitialize 0
> +; not required
> +%endmacro
> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
> b/OvmfPkg/ResetVector/ResetVector.nasmb
> index 5832aaa8abf7..f1655ddfcde3 100644
> --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb
> @@ -41,7 +41,7 @@
>  %elifdef DEBUG_SERIAL
>%include "SerialDebug.asm"
>  %else
> -  %include "DebugDisabled.asm"
> +  %include "DebugCon.asm"
>  %endif
>  
>  %include "Ia32/SearchForBfvBase.asm"

(1) How much output does this produce? Trapping to QEMU for every single
character written to the debug console is very slow. If it only produces
a few bytes, that should be OK.

(2) debugInitialize could actually be put to use; the presence of the
QEMU debug console is detectable. We'd need to allocate a single byte
somewhere, detect the console in debugInitialize, save the result in
that byte, then check the byte in debugShowPostCode. Eliminates even
those few (?) traps if there is no debug console configured.

(3) I'm already hating myself for asking about this, but... is there a
way for only customizing debugInitialize and debugShowCharacter? The
rest is common with "SerialDebug.asm", and I wish I hadn't had to review
those (unchanged) macros, they make my eyes bleed :/

Anyway, if you think any of these (or all of these!) means too much
work, I'm OK with the patch going-in as is.

I'm a bit concerned about (1), TBH.

Laszlo



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

[Gerd Hoffmann]

On Wed, Jan 24, 2024 at 07:20:34AM -0800, Vincent Zimmer wrote:
> I agree on your sentiment about Bugzilla (bz) not being ideal for this.
> This space has been a multi-year journey from usrt-based tickets, bespoke
> advisories, bz, etc into today's world of tianocore infosec, tianocore as
> its own CVE Naming Authority (CNA) and working to leverage the extant
> features of github. On that latter point, there is work afoot to evolve
> from the present bz-based process
> https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues
> to a github-based one
> https://github.com/tianocore/tianocore.github.io/wiki/GHSA-GitHub-Security-Advisories-Proceess-(Draft).
> Things are in transition now and I'd echo Doug's sentiment that getting
> more feedback and engagement from the community would be valuable in
> getting the various parts tested, evolved, documented, reviewed, etc.

The GHSA process certainly is an improvement over using patches attached
to bugzilla.  There still is room for improvement though.  Community
engagement is a problem indeed, and my overall impression is that it is
even worse than on the edk2 devel list.

I think part of the problem might be lack of notifications.  I can't
remember being notified in case the "tianocore infosec team" group is
added to a new GHSA, so it's hard to learn about new advisories ...

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

[Gerd Hoffmann]

  Hi,

> > static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> > {
> > [ ... ]
> >  * When there is no need to deal with noncoherent DMA (e.g., no VT-d
> >  * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.  
> > The
> >  * EPT memory type is set to WB.  The effective memory type is 
> > forced
> >  * WB.
> >  *
> >  * Otherwise, we trust guest.  Guest CD/MTRR/PAT are all honored.  
> > The
> >  * EPT memory type is used to emulate guest CD/MTRR.
> > [ ... ]
> > 
> >> Something must be special about Min's assigned device.
> > 
> > Yep.  I think the magic word is "snoop control".  When pci-assigning a
> > *real* pci device VT-d (aka iommu) handles cache control that way.  When
> > assigning a mdev device this is not the case.
> > 
> > mdev is a virtual pci device emulated by the kernel.  This can be purely
> > virtual (see samples/vfio-mdev/mtty.c in the linux kernel, which can be
> > used to reproduce this).  More typical is hardware-assisted device
> > partitioning, used for some intel and nvidia gpus.  Roughly comparable
> > with SR/IOV, but not implemented completely in hardware, the kernel has
> > some device-specific support code instead.
> 
> Very interesting, thanks! ... But, given that mdev is emulated in the
> kernel: isn't that *all the more reason* for treating the guest memory
> as writeback-cacheable?

For a 100% emulated device this would make sense indeed.  When making
some GPU resources available to VMs (including giving the GPU DMA access
to guest memory) not so much.  The later is the case with the
intel/nvidia gpu mdev devices.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v4 01/10] ArmPkg/ArmScmiDxe: Rename PERFORMANCE_PROTOCOL_VERSION

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
These changes look good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


Rename PERFORMANCE_PROTOCOL_VERSION to reflect the different
versions of the protocol. The macro is neither used in edk2 nor
in edk2-platforms.


Reviewed-by: Leif Lindholm mailto:quic_llind...@quicinc.com>>
Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
.../Include/Protocol/ArmScmiPerformanceProtocol.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)


diff --git a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
index 7e548e4765c2..a28f0f766e37 100644
--- a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
@@ -1,12 +1,12 @@
/** @file






- Copyright (c) 2017-2021, Arm Limited. All rights reserved.


+ Copyright (c) 2017-2023, Arm Limited. All rights reserved.






SPDX-License-Identifier: BSD-2-Clause-Patent






- System Control and Management Interface V1.0


- http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/ 



- DEN0056A_System_Control_and_Management_Interface.pdf


+ System Control and Management Interface V3.2, latest version at:


+ - https://developer.arm.com/documentation/den0056/latest/ 



+


**/






#ifndef ARM_SCMI_PERFORMANCE_PROTOCOL_H_


@@ -14,7 +14,10 @@




#include 






-#define PERFORMANCE_PROTOCOL_VERSION 0x1


+/// Arm Scmi performance protocol versions.


+#define PERFORMANCE_PROTOCOL_VERSION_V1 0x1


+#define PERFORMANCE_PROTOCOL_VERSION_V2 0x2


+#define PERFORMANCE_PROTOCOL_VERSION_V3 0x3






#define ARM_SCMI_PERFORMANCE_PROTOCOL_GUID { \


0x9b8ba84, 0x3dd3, 0x49a6, {0xa0, 0x5a, 0x31, 0x34, 0xa5, 0xf0, 0x7b, 0xad} \


-- 
2.25.1







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

Re: [edk2-devel] [PATCH v4 02/10] ArmPkg/ArmScmiDxe: Add PERFORMANCE_DESCRIBE_FASTCHANNEL support

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
These changes look good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


The PERFORMANCE_DESCRIBE_FASTCHANNEL Scmi command is available
since SCMI v2.0 and allows to query information about the supported
fast-channels of the Scmi performance protocol.
Add support for this command.


Also move SCMI_MESSAGE_ID_PERFORMANCE enum definition up in the file
to use it in SCMI_PERFORMANCE_DESCRIBE_FASTCHANNEL function
declaration.


Reviewed-by: Leif Lindholm mailto:quic_llind...@quicinc.com>>
Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
.../ArmScmiDxe/ScmiPerformanceProtocol.c | 80 +++--
.../Protocol/ArmScmiPerformanceProtocol.h | 88 +--
2 files changed, 154 insertions(+), 14 deletions(-)


diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c 
b/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
index 0f89808fbdf9..91efce4bf22d 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
@@ -1,12 +1,12 @@
/** @file






- Copyright (c) 2017-2021, Arm Limited. All rights reserved.


+ Copyright (c) 2017-2023, Arm Limited. All rights reserved.






SPDX-License-Identifier: BSD-2-Clause-Patent






- System Control and Management Interface V1.0


- http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/ 



- DEN0056A_System_Control_and_Management_Interface.pdf


+ System Control and Management Interface V3.2, latest version at:


+ - https://developer.arm.com/documentation/den0056/latest/ 



+


**/






#include 


@@ -416,6 +416,75 @@ PerformanceLevelGet (
return EFI_SUCCESS;


}






+/** Discover the attributes of the FastChannel for the specified


+ performance domain and the specified message.


+


+ @param[in] This A Pointer to SCMI_PERFORMANCE_PROTOCOL Instance.


+ @param[in] DomainId Identifier for the performance domain.


+ @param[in] MessageId Message Id of the FastChannel to discover.


+ Must be one of:


+ - PERFORMANCE_LIMITS_SET


+ - PERFORMANCE_LIMITS_GET


+ - PERFORMANCE_LEVEL_SET


+ - PERFORMANCE_LEVEL_GET


+ @param[out] FastChannel If success, contains the FastChannel description.


+


+ @retval EFI_SUCCESS Performance level got successfully.


+ @retval EFI_DEVICE_ERROR SCP returns an SCMI error.


+ @retval EFI_INVALID_PARAMETER Invalid parameter.


+ @retval EFI_TIMEOUT Time out.


+ @retval EFI_UNSUPPORTED Unsupported.


+**/


+EFI_STATUS


+DescribeFastchannel (


+ IN SCMI_PERFORMANCE_PROTOCOL *This,


+ IN UINT32 DomainId,


+ IN SCMI_MESSAGE_ID_PERFORMANCE MessageId,


+ OUT SCMI_PERFORMANCE_FASTCHANNEL *FastChannel


+ )


+{


+ EFI_STATUS Status;


+ SCMI_COMMAND Cmd;


+ UINT32 PayloadLength;


+ UINT32 *ReturnValues;


+ UINT32 *MessageParams;


+


+ if ((This == NULL) ||


+ (FastChannel == NULL))


+ {


+ return EFI_INVALID_PARAMETER;


+ }


+


+ Status = ScmiCommandGetPayload (&MessageParams);


+ if (EFI_ERROR (Status)) {


+ return Status;


+ }


+


+ *MessageParams++ = DomainId;


+ *MessageParams = MessageId;


+


+ Cmd.ProtocolId = ScmiProtocolIdPerformance;


+ Cmd.MessageId = ScmiMessageIdPerformanceDescribeFastchannel;


+ PayloadLength = sizeof (DomainId) + sizeof (MessageId);


+


+ Status = ScmiCommandExecute (


+ &Cmd,


+ &PayloadLength,


+ &ReturnValues


+ );


+ if (EFI_ERROR (Status)) {


+ return Status;


+ }


+


+ CopyMem (


+ FastChannel,


+ ReturnValues,


+ sizeof (SCMI_PERFORMANCE_FASTCHANNEL)


+ );


+


+ return Status;


+}


+


// Instance of the SCMI performance management protocol.


STATIC CONST SCMI_PERFORMANCE_PROTOCOL PerformanceProtocol = {


PerformanceGetVersion,


@@ -425,7 +494,8 @@ STATIC CONST SCMI_PERFORMANCE_PROTOCOL PerformanceProtocol 
= {
PerformanceLimitsSet,


PerformanceLimitsGet,


PerformanceLevelSet,


- PerformanceLevelGet


+ PerformanceLevelGet,


+ DescribeFastchannel,


};






/** Initialize performance management protocol and install on a given Handle.


diff --git a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
index a28f0f766e37..c69efe7408e1 100644
--- a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
@@ -79,8 +79,58 @@ typedef struct {
UINT32 RangeMin;


} SCMI_PERFORMANCE_LIMITS;






+/// Doorbell Support bit.


+#define SCMI_PERF_FC_ATTRIB_HAS_DOORBELL BIT0


+


+/// Performance protocol describe fastchannel


+typedef struct {


+ /// Attributes.


+ UINT32 Attributes;


+


+ /// Rate limit.


+ UINT32 RateLimit;


+


+ /// Lower 32 bits of the FastChannel address.


+ UINT32 ChanAddrLow;


+


+ /// Higher 32 bits of the FastChannel address.


+ UINT32 ChanAddrHigh;


+


+ /// Size of 

Re: [edk2-devel] [PATCH v4 03/10] DynamicTablesPkg: Use new CPC revision macro

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
These changes look good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


Make use of the newly added CPC revision macro.


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
index a6db34fb970f..ad7809e76e61 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -3523,7 +3523,7 @@ AmlCreateCpcNode (
}






// Revision 3 per ACPI 6.4 specification


- if (CpcInfo->Revision == 3) {


+ if (CpcInfo->Revision == EFI_ACPI_6_5_AML_CPC_REVISION) {


// NumEntries 23 per ACPI 6.4 specification


NumberOfEntries = 23;


} else {


-- 
2.25.1







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

Re: [edk2-devel] [PATCH v4 04/10] DynamicTablesPkg: Rename AmlCpcInfo.h to AcpiObjects.h

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
These changes look good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


The DynamicTables framework uses the AmlLib to generate some
Aml objects. It is done by using structured known by both
frameworks, e.g. the AML_CPC_INFO/CM_ARM_CPC_INFO structures.


To prepare adding similar structures (e.g. representing _PSD
information), rename AmlCpcInfo.h to AcpiObjects.h. This new
file will contain all the structures used by the AmlLib and
the DynamicTables framework.


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
DynamicTablesPkg/Include/{AmlCpcInfo.h => AcpiObjects.h} | 0
DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 2 +-
DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h | 2 +-
DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c | 2 +-
4 files changed, 3 insertions(+), 3 deletions(-)
rename DynamicTablesPkg/Include/{AmlCpcInfo.h => AcpiObjects.h} (100%)


diff --git a/DynamicTablesPkg/Include/AmlCpcInfo.h 
b/DynamicTablesPkg/Include/AcpiObjects.h
similarity index 100%
rename from DynamicTablesPkg/Include/AmlCpcInfo.h
rename to DynamicTablesPkg/Include/AcpiObjects.h
diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 8c00bdac20bb..453cc3fe83fa 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -13,7 +13,7 @@
#ifndef ARM_NAMESPACE_OBJECTS_H_


#define ARM_NAMESPACE_OBJECTS_H_






-#include 


+#include 


#include 






#pragma pack(1)


diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index 71e8539b306c..be78c00b6109 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -36,7 +36,7 @@
@}


*/






-#include 


+#include 


#include 






#ifndef AML_HANDLE


diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
index ad7809e76e61..2483272480ee 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -11,7 +11,7 @@
#include 






#include 


-#include 


+#include 


#include 


#include 


#include 


-- 
2.25.1







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

Re: [edk2-devel] [PATCH v4 05/10] DynamicTablesPkg: Add CM_ARM_PSD_INFO object

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
Please see my response inline marked [SAMI].

Regards,

Sami Mujawar

On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


Add an object describing _PSD information, cf. ACPI 6.5,
s8.4.5.5 _PSD (P-State Dependency).
Also add the corresponding CmObjParser.


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
DynamicTablesPkg/Include/AcpiObjects.h | 20 +++
.../Include/ArmNameSpaceObjects.h | 10 ++
.../ConfigurationManagerObjectParser.c | 11 ++
3 files changed, 41 insertions(+)


diff --git a/DynamicTablesPkg/Include/AcpiObjects.h 
b/DynamicTablesPkg/Include/AcpiObjects.h
index 8981c229544a..2bdabb2724bd 100644
--- a/DynamicTablesPkg/Include/AcpiObjects.h
+++ b/DynamicTablesPkg/Include/AcpiObjects.h
@@ -1,6 +1,7 @@
/** @file






Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights reserved.


+ Copyright (c) 2022 - 2023, Arm Limited. All rights reserved.






SPDX-License-Identifier: BSD-2-Clause-Patent


**/


@@ -119,6 +120,25 @@ typedef struct AmlCpcInfo {
UINT32 NominalFrequencyInteger;


} AML_CPC_INFO;






+/** A structure that describes a


+ P-State Dependency (PSD) Info.


+


+ Cf. ACPI 6.5, s8.4.5.5 _PSD (P-State Dependency).


+*/


+typedef struct AmlPsdInfo {


+ /// Revision.


+ UINT8 Revision;


+


+ /// Domain Id.


+ UINT32 Domain;


+


+ /// Coordination type.


+ UINT32 CoordType;


+


+ /// Number of processors belonging to the Domain.


+ UINT32 NumProc;


+} AML_PSD_INFO;


+


#pragma pack()






#endif //AML_CPC_INFO_H_


diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 453cc3fe83fa..3748cb7c8085 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -72,6 +72,7 @@ typedef enum ArmObjectID {
EArmObjPccSubspaceType4Info, ///< 47 - Pcc Subspace Type 4 Info


EArmObjPccSubspaceType5Info, ///< 48 - Pcc Subspace Type 5 Info


EArmObjEtInfo, ///< 49 - Embedded Trace Extension/Module Info


+ EArmObjPsdInfo, ///< 50 - P-State Dependency (PSD) Info


EArmObjMax


} EARM_OBJECT_ID;






@@ -1327,6 +1328,15 @@ typedef struct CmArmEtInfo {
ARM_ET_TYPE EtType;


} CM_ARM_ET_INFO;






+/** A structure that describes a


+ P-State Dependency (PSD) Info.


+


+ Cf. ACPI 6.5, s8.4.5.5 _PSD (P-State Dependency).


+


+ ID: EArmObjPsdInfo


+*/


+typedef AML_PSD_INFO CM_ARM_PSD_INFO;


+


#pragma pack()






#endif // ARM_NAMESPACE_OBJECTS_H_


diff --git 
a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
 
b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
index ce494816ed88..cceff56756fc 100644
--- 
a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
+++ 
b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
@@ -669,6 +669,15 @@ STATIC CONST CM_OBJ_PARSER CmArmEtInfo[] = {
{ "EtType", sizeof (ARM_ET_TYPE), "0x%x", NULL }


};






+/** A parser for EArmObjPsdInfo.


+*/


+STATIC CONST CM_OBJ_PARSER CmArmPsdInfoParser[] = {


+ { "Revision", 1, "0x%llx", NULL },
[SAMI] I think the format specifier should be 0x%x. If you agree I can fix this 
before merging.


+ { "DomainId", 4, "0x%x", NULL },


+ { "CoordType", 4, "0x%x", NULL },


+ { "NumProc", 4, "0x%x", NULL },


+};


+


/** A parser for Arm namespace objects.


*/


STATIC CONST CM_OBJ_PARSER_ARRAY ArmNamespaceObjectParser[] = {


@@ -767,6 +776,8 @@ STATIC CONST CM_OBJ_PARSER_ARRAY ArmNamespaceObjectParser[] 
= {
ARRAY_SIZE (CmArmPccSubspaceType5InfoParser) },


{ "EArmObjEtInfo", CmArmEtInfo,


ARRAY_SIZE (CmArmEtInfo) },


+ { "EArmObjPsdInfo", CmArmPsdInfoParser,


+ ARRAY_SIZE (CmArmPsdInfoParser) },


{ "EArmObjMax", NULL, 0 },


};






-- 
2.25.1







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

Re: [edk2-devel] [PATCH v4 06/10] DynamicTablesPkg: Add PsdToken field to CM_ARM_GICC_INFO object

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
I have a minor suggestion that I will fix before merging.
Otherwise, this patch looks good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 12/12/2023, 09:30, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


The _PSD object (cf. ACPI 6.5, s8.4.5.5 _PSD (P-State Dependency)
allows to describe CPU's power state dependencies. Add a PsdToken
field to the CM_ARM_GICC_INFO object so that interdependent CPUs
can reference the same CM_ARM_PSD_INFO object.


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 5 +
.../Common/TableHelperLib/ConfigurationManagerObjectParser.c | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)


diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 3748cb7c8085..3805c5824773 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -218,6 +218,11 @@ typedef struct CmArmGicCInfo {
i.e. a token referencing a CM_ARM_ET_INFO object.


*/


CM_OBJECT_TOKEN EtToken;


+


+ /** Optional field: Reference Token for the Psd info of this processor.


+ i.e. a token referencing a CM_ARM_PSD_INFO object.


+ */


+ CM_OBJECT_TOKEN PsdToken;


} CM_ARM_GICC_INFO;






/** A structure that describes the


diff --git 
a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
 
b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
index cceff56756fc..178e1821393d 100644
--- 
a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
+++ 
b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
@@ -85,7 +85,8 @@ STATIC CONST CM_OBJ_PARSER CmArmGicCInfoParser[] = {
{ "AffinityFlags", 4, "0x%x", NULL },


{ "CpcToken", sizeof (CM_OBJECT_TOKEN), "0x%p", NULL },


{ "TRBEInterrupt", 2, "0x%x", NULL },


- { "EtToken", sizeof (CM_OBJECT_TOKEN), "0x%p", NULL }


+ { "EtToken", sizeof (CM_OBJECT_TOKEN), "0x%p", NULL },


+ { "PsdToken", sizeof (CM_OBJECT_TOKEN), "0x%p", NULL },

[SAMI] Nit, the comma at the end is not required. I will drop it before merging.
};






/** A parser for EArmObjGicDInfo.


-- 
2.25.1







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

Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler

[Felix Polyudov via groups.io]

In my opinion this is not a spec conformance fix, but it is a bug fix.
The spec does not explicitly mentions unregistering from within the handler,
but by applying a principle that everything that's not forbidden is legal,
it's fair for a caller to expect that unregistering works fine in any valid 
context
including from within the MM handler.

The spec does mention that UEFI/PI interfaces are not reentrant,
however, reentrancy typically implies repetitive invocation of the same 
interface,
not a call to one MM Core interface while another MM Core interface is in 
progress.

From: Ni, Ray 
Sent: Wednesday, January 24, 2024 11:17 AM
To: Laszlo Ersek ; devel@edk2.groups.io; Liu, Zhiguang 

Cc: Liming Gao ; Wu, Jiaxin ; 
Felix Polyudov 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to 
unregister SMI handler inside SMI handler


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**
spec does not say the unregistration is allowed inside handler. it's just to 
improve the qualiquali the code.

thanks,
ray

From: Laszlo Ersek mailto:ler...@redhat.com>>
Sent: Wednesday, January 24, 2024 9:06:13 PM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; Ni, Ray 
mailto:ray...@intel.com>>; Liu, Zhiguang 
mailto:zhiguang@intel.com>>
Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>; Wu, 
Jiaxin mailto:jiaxin...@intel.com>>; POLUDOV, FELIX 
mailto:fel...@ami.com>>
Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to unregister SMI 
handler inside SMI handler

On 1/24/24 09:11, Ni, Ray wrote:
> Felix, I remember you mentioned to me about the usage of SMI handler 
> unregistering itself.

I wanted to ask: is this something that the PI spec comments on? I.e.,
is this usage expected by the spec (in which case this bugfix is a
conformance fix), or is the spec silent on it (in which case I guess we
can call this a quality-of-implementation improvement)?

>
> Reviewed-by: Ray Ni mailto:ray...@intel.com>>

Reviewed-by: Laszlo Ersek mailto:ler...@redhat.com>>

Thanks
Laszlo

>
> Thanks,
> Ray
>> -Original Message-
>> From: Liu, Zhiguang mailto:zhiguang@intel.com>>
>> Sent: Wednesday, January 24, 2024 12:03 PM
>> To: devel@edk2.groups.io
>> Cc: Liu, Zhiguang mailto:zhiguang@intel.com>>; 
>> Liming Gao
>> mailto:gaolim...@byosoft.com.cn>>; Wu, Jiaxin 
>> mailto:jiaxin...@intel.com>>; Ni, Ray
>> mailto:ray...@intel.com>>
>> Subject: [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler
>> inside SMI handler
>>
>> To support unregister SMI handler inside SMI handler itself,
>> get next node before SMI handler is executed, since LIST_ENTRY that
>> Link points to may be freed if unregister SMI handler in SMI handler
>> itself.
>>
>> Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
>> Cc: Jiaxin Wu mailto:jiaxin...@intel.com>>
>> Cc: Ray Ni mailto:ray...@intel.com>>
>> Signed-off-by: Zhiguang Liu 
>> mailto:zhiguang@intel.com>>
>> ---
>>  MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
>> b/MdeModulePkg/Core/PiSmmCore/Smi.c
>> index 2985f989c3..a75e52b1ae 100644
>> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
>> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
>> @@ -134,8 +134,14 @@ SmiManage (
>>
>>Head = &SmiEntry->SmiHandlers;
>>
>> -  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
>> +  for (Link = Head->ForwardLink; Link != Head;) {
>>  SmiHandler = CR (Link, SMI_HANDLER, Link,
>> SMI_HANDLER_SIGNATURE);
>> +//
>> +// To support unregiser SMI handler inside SMI handler itself,
>> +// get next node before handler is executed, since LIST_ENTRY that
>> +// Link points to may be freed if unregister SMI handler.
>> +//
>> +Link = Link->ForwardLink;
>>
>>  Status = SmiHandler->Handler (
>> (EFI_HANDLE)SmiHandler,
>> --
>> 2.31.1.windows.1
>
>
>
> 
>
>
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


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

Re: [edk2-devel] [PATCH v4 08/10] DynamicTablesPkg: Generate _PSD in SsdtCpuTopologyGenerator

[Sami Mujawar]

Hi Pierre,

Thank you for this patch.
These changes look good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 12/12/2023, 09:30, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


Make use of the newly added AmlCreatePsdNode() to generate
_PSD objects.


_PSD objects allow to describe 'performance control, P-state
or CPPC, logical processor dependency', Cf. ACPI 6.4,
s8.4.5.5 _PSD (P-State Dependency).


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
.../SsdtCpuTopologyGenerator.c | 96 +++
1 file changed, 96 insertions(+)


diff --git 
a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
index 724f33c660a8..9e3efb49e630 100644
--- 
a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
+++ 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
@@ -42,6 +42,7 @@ Requirements:
- EArmObjCmRef (OPTIONAL)


- EArmObjLpiInfo (OPTIONAL)


- GetEArmObjEtInfo (OPTIONAL)


+ - EArmObjPsdInfo (OPTIONAL)


*/






/** This macro expands to a function that retrieves the GIC


@@ -103,6 +104,16 @@ GET_OBJECT_LIST (
CM_ARM_ET_INFO


);






+/**


+ This macro expands to a function that retrieves the PSD


+ information from the Configuration Manager.


+*/


+GET_OBJECT_LIST (


+ EObjNameSpaceArm,


+ EArmObjPsdInfo,


+ CM_ARM_PSD_INFO


+ );


+


/** Initialize the TokenTable.






One entry should be allocated for each CM_ARM_PROC_HIERARCHY_INFO


@@ -256,6 +267,75 @@ WriteAslName (
return EFI_SUCCESS;


}






+/** Create and add an _PSD Node to Cpu Node.


+


+ For instance, transform an AML node from:


+ Device (C002)


+ {


+ Name (_UID, 2)


+ Name (_HID, "ACPI0007")


+ }


+


+ To:


+ Device (C002)


+ {


+ Name (_UID, 2)


+ Name (_HID, "ACPI0007")


+ Name (_PSD, Package()


+ {


+ NumEntries, // Integer


+ Revision, // Integer


+ Domain, // Integer


+ CoordType, // Integer


+ NumProcessors, // Integer


+ })


+ }


+


+ @param [in] Generator The SSDT Cpu Topology generator.


+ @param [in] CfgMgrProtocol Pointer to the Configuration Manager


+ Protocol Interface.


+ @param [in] GicCInfo Pointer to the CM_ARM_GICC_INFO object


+ describing the Cpu.


+ @param [in] Node CPU Node to which the _CPC node is


+ attached.


+


+ @retval EFI_SUCCESS The function completed successfully.


+ @retval EFI_INVALID_PARAMETER Invalid parameter.


+ @retval EFI_OUT_OF_RESOURCES Failed to allocate memory.


+**/


+STATIC


+EFI_STATUS


+EFIAPI


+CreateAmlPsdNode (


+ IN ACPI_CPU_TOPOLOGY_GENERATOR *Generator,


+ IN CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL *CONST CfgMgrProtocol,


+ IN CM_ARM_GICC_INFO *GicCInfo,


+ IN AML_OBJECT_NODE_HANDLE *Node


+ )


+{


+ EFI_STATUS Status;


+ CM_ARM_PSD_INFO *PsdInfo;


+


+ Status = GetEArmObjPsdInfo (


+ CfgMgrProtocol,


+ GicCInfo->PsdToken,


+ &PsdInfo,


+ NULL


+ );


+ if (EFI_ERROR (Status)) {


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+


+ Status = AmlCreatePsdNode (


+ PsdInfo,


+ Node,


+ NULL


+ );


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+}


+


/** Create and add an _CPC Node to Cpu Node.






For instance, transform an AML node from:


@@ -842,6 +922,14 @@ CreateAmlCpuFromProcHierarchy (
}


}






+ if (GicCInfo->PsdToken != CM_NULL_TOKEN) {


+ Status = CreateAmlPsdNode (Generator, CfgMgrProtocol, GicCInfo, CpuNode);


+ if (EFI_ERROR (Status)) {


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+ }


+


// If a CPC info is associated with the


// GicCinfo, create an _CPC method returning them.


if (GicCInfo->CpcToken != CM_NULL_TOKEN) {


@@ -1299,6 +1387,14 @@ CreateTopologyFromGicC (
break;


}






+ if (GicCInfo->PsdToken != CM_NULL_TOKEN) {


+ Status = CreateAmlPsdNode (Generator, CfgMgrProtocol, GicCInfo, CpuNode);


+ if (EFI_ERROR (Status)) {


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+ }


+


// If a CPC info is associated with the


// GicCinfo, create an _CPC method returning them.


if (GicCInfo[Index].CpcToken != CM_NULL_TOKEN) {


-- 
2.25.1







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

Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler

[Laszlo Ersek]

On 1/24/24 18:15, Felix Polyudov via groups.io wrote:
> In my opinion this is not a spec conformance fix, but it is a bug fix.
> 
> The spec does not explicitly mentions unregistering from within the handler,
> 
> but by applying a principle that everything that’s not forbidden is legal,
> 
> it’s fair for a caller to expect that unregistering works fine in any
> valid context
> 
> including from within the MM handler.
> 
>  
> 
> The spec does mention that UEFI/PI interfaces are not reentrant,
> 
> however, reentrancy typically implies repetitive invocation of the same
> interface,
> 
> not a call to one MM Core interface while another MM Core interface is
> in progress.

Sure, I'm not contesting any of that; it's great that you and Ray seem
to agree. I just wanted to understand. My R-b stands.

Thanks!
Laszlo

> *From:*Ni, Ray 
> *Sent:* Wednesday, January 24, 2024 11:17 AM
> *To:* Laszlo Ersek ; devel@edk2.groups.io; Liu,
> Zhiguang 
> *Cc:* Liming Gao ; Wu, Jiaxin
> ; Felix Polyudov 
> *Subject:* [EXTERNAL] Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support
> to unregister SMI handler inside SMI handler
> 
>  
> 
>  
> 
> ***CAUTION:*The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following
> guidance.**
> 
> spec does not say the unregistration is allowed inside handler. it's
> just to improve the qualiquali the code.
> 
>  
> 
> thanks,
> 
> ray
> 
> 
> 
> *From:*Laszlo Ersek mailto:ler...@redhat.com>>
> *Sent:* Wednesday, January 24, 2024 9:06:13 PM
> *To:* devel@edk2.groups.io 
> mailto:devel@edk2.groups.io>>; Ni, Ray
> mailto:ray...@intel.com>>; Liu, Zhiguang
> mailto:zhiguang@intel.com>>
> *Cc:* Liming Gao  >; Wu, Jiaxin  >; POLUDOV, FELIX  >
> *Subject:* Re: [edk2-devel] [PATCH] MdeModulePkg/SMM: Support to
> unregister SMI handler inside SMI handler
> 
>  
> 
> On 1/24/24 09:11, Ni, Ray wrote:
>> Felix, I remember you mentioned to me about the usage of SMI handler 
>> unregistering itself.
> 
> I wanted to ask: is this something that the PI spec comments on? I.e.,
> is this usage expected by the spec (in which case this bugfix is a
> conformance fix), or is the spec silent on it (in which case I guess we
> can call this a quality-of-implementation improvement)?
> 
>> 
>> Reviewed-by: Ray Ni mailto:ray...@intel.com>>
> 
> Reviewed-by: Laszlo Ersek mailto:ler...@redhat.com>>
> 
> Thanks
> Laszlo
> 
>> 
>> Thanks,
>> Ray
>>> -Original Message-
>>> From: Liu, Zhiguang mailto:zhiguang@intel.com>>
>>> Sent: Wednesday, January 24, 2024 12:03 PM
>>> To: devel@edk2.groups.io 
>>> Cc: Liu, Zhiguang mailto:zhiguang@intel.com>>; 
>>> Liming Gao
>>> mailto:gaolim...@byosoft.com.cn>>; Wu, Jiaxin
> mailto:jiaxin...@intel.com>>; Ni, Ray
>>> mailto:ray...@intel.com>>
>>> Subject: [PATCH] MdeModulePkg/SMM: Support to unregister SMI handler
>>> inside SMI handler
>>>
>>> To support unregister SMI handler inside SMI handler itself,
>>> get next node before SMI handler is executed, since LIST_ENTRY that
>>> Link points to may be freed if unregister SMI handler in SMI handler
>>> itself.
>>>
>>> Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
>>> Cc: Jiaxin Wu mailto:jiaxin...@intel.com>>
>>> Cc: Ray Ni mailto:ray...@intel.com>>
>>> Signed-off-by: Zhiguang Liu >> >
>>> ---
>>>  MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
>>> b/MdeModulePkg/Core/PiSmmCore/Smi.c
>>> index 2985f989c3..a75e52b1ae 100644
>>> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
>>> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
>>> @@ -134,8 +134,14 @@ SmiManage (
>>>
>>>    Head = &SmiEntry->SmiHandlers;
>>>
>>> -  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
>>> +  for (Link = Head->ForwardLink; Link != Head;) {
>>>  SmiHandler = CR (Link, SMI_HANDLER, Link,
>>> SMI_HANDLER_SIGNATURE);
>>> +    //
>>> +    // To support unregiser SMI handler inside SMI handler itself,
>>> +    // get next node before handler is executed, since LIST_ENTRY that
>>> +    // Link points to may be freed if unregister SMI handler.
>>> +    //
>>> +    Link = Link->ForwardLink;
>>>
>>>  Status = SmiHandler->Handler (
>>> (EFI_HANDLE)SmiHandler,
>>> --
>>> 2.31.1.windows.1
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -The information contained in this message may be confidential and
> proprietary to American Megatrends (AMI). This communication is intended
> to be read only by the individual or entity to whom it is addressed or
> by their designee. If the reader of this message is not the intended
> recipient, you are on notice that any distribution of this message, in
> any form, is strictly 

Re: [edk2-devel] [PATCH v4 07/10] DynamicTablesPkg: Add AmlCreatePsdNode() to generate _PSD

[Sami Mujawar]

Hi Pierre,

Please see my feedback inline marked [SAMI].

Regards,

Sami Mujawar

On 12/12/2023, 09:29, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


Add AmlCreatePsdNode() to the AmlLib to generate _PSD objects.
_PSD objects allow to describe 'performance control, P-state
or CPPC, logical processor dependency', Cf. ACPI 6.5,
s8.4.5.5 _PSD (P-State Dependency).


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
.../Include/Library/AmlLib/AmlLib.h | 35 +++-
.../Common/AmlLib/CodeGen/AmlCodeGen.c | 188 +-
2 files changed, 221 insertions(+), 2 deletions(-)


diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index be78c00b6109..fb1b0e24faf3 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -1,7 +1,7 @@
/** @file


AML Lib.






- Copyright (c) 2019 - 2021, Arm Limited. All rights reserved.


+ Copyright (c) 2019 - 2023, Arm Limited. All rights reserved.






SPDX-License-Identifier: BSD-2-Clause-Patent


**/


@@ -1628,4 +1628,37 @@ AmlAddNameStringToNamedPackage (
IN AML_OBJECT_NODE_HANDLE NamedNode


);






+/** Create a _PSD node.


+


+ Creates and optionally adds the following node


+ Name(_PSD, Package()


+ {


+ NumEntries, // Integer


+ Revision, // Integer


+ Domain, // Integer


+ CoordType, // Integer


+ NumProc, // Integer


+ })


+


+ Cf. ACPI 6.5, s8.4.5.5 _PSD (P-State Dependency)


+


+ @ingroup CodeGenApis


+


+ @param [in] PsdInfo PsdInfo object


+ @param [in] ParentNode If provided, set ParentNode as the parent


+ of the node created.


+ @param [out] NewPsdNode If success and provided, contains the created node.


+


+ @retval EFI_SUCCESS The function completed successfully.


+ @retval EFI_INVALID_PARAMETER Invalid parameter.


+ @retval EFI_OUT_OF_RESOURCES Failed to allocate memory.


+**/


+EFI_STATUS


+EFIAPI


+AmlCreatePsdNode (


+ IN AML_PSD_INFO *PsdInfo,


+ IN AML_NODE_HANDLE ParentNode OPTIONAL,


+ OUT AML_OBJECT_NODE_HANDLE *NewPsdNode OPTIONAL


+ );


+


#endif // AML_LIB_H_


diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
index 2483272480ee..2b370320d244 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -1,7 +1,7 @@
/** @file


AML Code Generation.






- Copyright (c) 2020 - 2022, Arm Limited. All rights reserved.


+ Copyright (c) 2020 - 2023, Arm Limited. All rights reserved.






SPDX-License-Identifier: BSD-2-Clause-Patent


**/


@@ -3849,3 +3849,189 @@ exit_handler:




return Status;


}


+


+/** Create a _PSD node.


+


+ Creates and optionally adds the following node


+ Name(_PSD, Package()


+ {


+ NumEntries, // Integer


+ Revision, // Integer


+ Domain, // Integer


+ CoordType, // Integer


+ NumProc, // Integer


+ })


+


+ Cf. ACPI 6.5, s8.4.5.5 _PSD (P-State Dependency)


+


+ @ingroup CodeGenApis


+


+ @param [in] PsdInfo PsdInfo object


+ @param [in] ParentNode If provided, set ParentNode as the parent


+ of the node created.


+ @param [out] NewPsdNode If success and provided, contains the created node.


+


+ @retval EFI_SUCCESS The function completed successfully.


+ @retval EFI_INVALID_PARAMETER Invalid parameter.


+ @retval EFI_OUT_OF_RESOURCES Failed to allocate memory.


+**/


+EFI_STATUS


+EFIAPI


+AmlCreatePsdNode (


+ IN AML_PSD_INFO *PsdInfo,


+ IN AML_NODE_HANDLE ParentNode OPTIONAL,


+ OUT AML_OBJECT_NODE_HANDLE *NewPsdNode OPTIONAL


+ )


+{


+ EFI_STATUS Status;


+ AML_OBJECT_NODE_HANDLE PsdNode;


+ AML_OBJECT_NODE_HANDLE PsdPackage;


+ AML_OBJECT_NODE_HANDLE IntegerNode;


+ UINT32 NumberOfEntries;


+


+ if ((PsdInfo == NULL) ||


+ ((ParentNode == NULL) && (NewPsdNode == NULL)))


+ {


+ Status = EFI_INVALID_PARAMETER;


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+


+ // Revision 3 per ACPI 6.5 specification


+ if (PsdInfo->Revision == EFI_ACPI_6_5_AML_PSD_REVISION) {


+ // NumEntries 5 per ACPI 6.5 specification


+ NumberOfEntries = 5;


+ } else {


+ Status = EFI_INVALID_PARAMETER;


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+


+ if (((PsdInfo->CoordType != ACPI_AML_COORD_TYPE_SW_ALL) &&


+ (PsdInfo->CoordType != ACPI_AML_COORD_TYPE_SW_ANY) &&


+ (PsdInfo->CoordType != ACPI_AML_COORD_TYPE_HW_ALL)) ||


+ (PsdInfo->NumProc == 0))


+ {


+ Status = EFI_INVALID_PARAMETER;


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+


+ Status = AmlCodeGenNamePackage ("_PSD", NULL, &PsdNode);


+ if (EFI_ERROR (Status)) {


+ ASSERT_EFI_ERROR (Status);


+ return Status;


+ }


+


+ // Get the Package object node of the _PSD node,


+ // which is the 2nd fixed argument (i.e. index 1).


+ PsdPackage = (AML_OBJECT_NODE_HANDLE)AmlGetFixedArgument (


+ PsdNode,


+ EAmlParseIndexTerm1


+ );


+ if

Re: [edk2-devel] [PATCH v4 10/10] DynamicTablesPkg: Remove check for _CPC field

[Sami Mujawar]

Hi Pierre,

I think we should not relax the checks as this may lead to a production 
platform ignoring the mandatory fields.
Maybe we need to define a pre-processor e.g. DEVELOPMENT_PLATFORM_RELAXATIONS 
and add additional warnings to say that the platform is not spec compliant.

Regards,

Sami Mujawar


On 12/12/2023, 09:30, "Pierre Gondois" mailto:pierre.gond...@arm.com>> wrote:


When generating _CPC objects, some fields are mandatory by spec [1].
Some fields cannot be supported by a the Juno platform, which is used
to test the _CPC generation. Therefore, don't prevent the generation
of _CPC objects if the fields below are missing, and let the OS handle
the missing information.


_CPC fields that are exempted from checks:
- PerformanceLimitedRegister
- ReferencePerformanceCounterRegister
- DeliveredPerformanceCounterRegister


Also warn if one of the following optional fields is missing:
- HighestPerformance[Buffer|Integer]
- NominalPerformance[Buffer|Integer]


[1] Cf. non-optional fields in:
ACPI 6.5, s8.4.6.1 '_CPC (Continuous Performance Control)'


Signed-off-by: Pierre Gondois mailto:pierre.gond...@arm.com>>
---
.../Common/AmlLib/CodeGen/AmlCodeGen.c | 30 ---
1 file changed, 26 insertions(+), 4 deletions(-)


diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
index 2b370320d244..cc258127b62e 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -3531,6 +3531,22 @@ AmlCreateCpcNode (
return EFI_INVALID_PARAMETER;


}






+ // The following fields are theoretically mandatory, but not supported


+ // by some platforms. Just warn if they are missing:


+ // - PerformanceLimitedRegister


+ // - ReferencePerformanceCounterRegister


+ // - DeliveredPerformanceCounterRegister


+ if (IsNullGenericAddress (&CpcInfo->PerformanceLimitedRegister) ||


+ IsNullGenericAddress (&CpcInfo->ReferencePerformanceCounterRegister) ||


+ IsNullGenericAddress (&CpcInfo->DeliveredPerformanceCounterRegister))


+ {


+ DEBUG ((


+ DEBUG_WARN,


+ "Missing PerformanceLimited|ReferencePerformanceCounter|"


+ "DeliveredPerformanceCounter field in _CPC object\n"


+ ));


+ }


+


if ((IsNullGenericAddress (&CpcInfo->HighestPerformanceBuffer) &&


(CpcInfo->HighestPerformanceInteger == 0)) ||


(IsNullGenericAddress (&CpcInfo->NominalPerformanceBuffer) &&


@@ -3539,13 +3555,19 @@ AmlCreateCpcNode (
(CpcInfo->LowestNonlinearPerformanceInteger == 0)) ||


(IsNullGenericAddress (&CpcInfo->LowestPerformanceBuffer) &&


(CpcInfo->LowestPerformanceInteger == 0)) ||


- IsNullGenericAddress (&CpcInfo->DesiredPerformanceRegister) ||


- IsNullGenericAddress (&CpcInfo->ReferencePerformanceCounterRegister) ||


- IsNullGenericAddress (&CpcInfo->DeliveredPerformanceCounterRegister) ||


- IsNullGenericAddress (&CpcInfo->PerformanceLimitedRegister))


+ IsNullGenericAddress (&CpcInfo->DesiredPerformanceRegister))


{


ASSERT (0);


return EFI_INVALID_PARAMETER;


+ } else if ((IsNullGenericAddress (&CpcInfo->HighestPerformanceBuffer) &&


+ (CpcInfo->HighestPerformanceInteger == 0)) ||


+ (IsNullGenericAddress (&CpcInfo->NominalPerformanceBuffer) &&


+ (CpcInfo->NominalPerformanceInteger == 0)))


+ {


+ DEBUG ((


+ DEBUG_WARN,


+ "Missing Reference|Delivered performance field in _CPC object\n"


+ ));


}






CpcPackage = NULL;


-- 
2.25.1







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

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

[Michael D Kinney]

Hi Laszlo,

Responses below.

Mike

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

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

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

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

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

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

[Michael D Kinney]

Hi Laszlo,

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

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

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

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

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

Mike

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



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

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

[Michael D Kinney]

Hi Liming,

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

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

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

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

Mike

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

Re: [edk2-devel] AArch64 with HeapGuard: page allocations wrongly aligned

[Oliver Smith-Denny]

On 1/22/2024 6:14 PM, Rebecca Cran wrote:
Thanks! I wonder if the same problem occurs on LoongArch64, which also 
defines the runtime page allocation granularity to be 0x1?




Yes, it should have exactly the same problem


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

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

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

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



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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/ResetVector: send post codes to qemu debug console

[Lendacky, Thomas via groups.io]

On 1/24/24 10:47, Laszlo Ersek wrote:

On 1/24/24 16:31, Gerd Hoffmann wrote:

Neat when doing ResetVector coding.

Signed-off-by: Gerd Hoffmann 
---
  OvmfPkg/ResetVector/DebugCon.asm  | 43 +++
  OvmfPkg/ResetVector/ResetVector.nasmb |  2 +-
  2 files changed, 44 insertions(+), 1 deletion(-)
  create mode 100644 OvmfPkg/ResetVector/DebugCon.asm

diff --git a/OvmfPkg/ResetVector/DebugCon.asm b/OvmfPkg/ResetVector/DebugCon.asm
new file mode 100644
index ..9c57d1a52c75
--- /dev/null
+++ b/OvmfPkg/ResetVector/DebugCon.asm
@@ -0,0 +1,43 @@
+;--
+; @file
+; qemu debug console support macros (based on serial port macros)
+;
+; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+%macro  outToDebugPort 1
+mov dx, 0x402
+mov al, %1
+out dx, al
+%endmacro
+
+%macro  debugShowCharacter 1
+outToDebugPort %1
+%endmacro
+
+%macro  debugShowHexDigit 1
+  %if (%1 < 0xa)
+debugShowCharacter BYTE ('0' + (%1))
+  %else
+debugShowCharacter BYTE ('a' + ((%1) - 0xa))
+  %endif
+%endmacro
+
+%macro  debugNewline 0
+debugShowCharacter `\r`
+debugShowCharacter `\n`
+%endmacro
+
+%macro  debugShowPostCode 1
+debugShowHexDigit (((%1) >> 4) & 0xf)
+debugShowHexDigit ((%1) & 0xf)
+debugNewline
+%endmacro
+
+BITS16
+
+%macro  debugInitialize 0
+; not required
+%endmacro
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 5832aaa8abf7..f1655ddfcde3 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -41,7 +41,7 @@
  %elifdef DEBUG_SERIAL
%include "SerialDebug.asm"
  %else
-  %include "DebugDisabled.asm"
+  %include "DebugCon.asm"
  %endif
  
  %include "Ia32/SearchForBfvBase.asm"


(1) How much output does this produce? Trapping to QEMU for every single
character written to the debug console is very slow. If it only produces
a few bytes, that should be OK.

(2) debugInitialize could actually be put to use; the presence of the
QEMU debug console is detectable. We'd need to allocate a single byte
somewhere, detect the console in debugInitialize, save the result in
that byte, then check the byte in debugShowPostCode. Eliminates even
those few (?) traps if there is no debug console configured.

(3) I'm already hating myself for asking about this, but... is there a
way for only customizing debugInitialize and debugShowCharacter? The
rest is common with "SerialDebug.asm", and I wish I hadn't had to review
those (unchanged) macros, they make my eyes bleed :/

Anyway, if you think any of these (or all of these!) means too much
work, I'm OK with the patch going-in as is.


My concern would be around SEV-ES/SEV-SNP guest usage. The in and out 
instruction will generate a #VC and would require a #VC handler to be in 
place.


I'm pretty sure this will cause issues for those types of guests, but it 
might be a few days before I can get to it to verify. @Gerd, were you able 
to test this with those types of guests?


Thanks,
Tom



I'm a bit concerned about (1), TBH.

Laszlo




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

Re: [edk2-devel] [PATCH v4 1/3] ArmPkg: Update GenericWatchdogDxe to allow setting full 48-bit offset

[Rebecca Cran via groups.io]

On 1/23/2024 7:10 AM, Sami Mujawar wrote:


@@ -310,6 +318,7 @@ GenericWatchdogEntry (
{
EFI_STATUS Status;
EFI_HANDLE Handle;
+ UINT32 WatchdogIId;
[SAMI] Minor, the above variable name should be WatchdogIid to comply with the 
coding standard.


I was wondering about the naming, since it's the "Watchdog Interface 
ID". Since the second "I" is for another word, should it still be 
lower-case?


--
Rebecca Cran



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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/ResetVector: send post codes to qemu debug console

[Lendacky, Thomas via groups.io]

On 1/24/24 13:24, Tom Lendacky wrote:

On 1/24/24 10:47, Laszlo Ersek wrote:

On 1/24/24 16:31, Gerd Hoffmann wrote:

Neat when doing ResetVector coding.

Signed-off-by: Gerd Hoffmann 
---
  OvmfPkg/ResetVector/DebugCon.asm  | 43 +++
  OvmfPkg/ResetVector/ResetVector.nasmb |  2 +-
  2 files changed, 44 insertions(+), 1 deletion(-)
  create mode 100644 OvmfPkg/ResetVector/DebugCon.asm

diff --git a/OvmfPkg/ResetVector/DebugCon.asm 
b/OvmfPkg/ResetVector/DebugCon.asm

new file mode 100644
index ..9c57d1a52c75
--- /dev/null
+++ b/OvmfPkg/ResetVector/DebugCon.asm
@@ -0,0 +1,43 @@
+;--
+; @file
+; qemu debug console support macros (based on serial port macros)
+;
+; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+%macro  outToDebugPort 1
+    mov dx, 0x402
+    mov al, %1
+    out dx, al
+%endmacro
+
+%macro  debugShowCharacter 1
+    outToDebugPort %1
+%endmacro
+
+%macro  debugShowHexDigit 1
+  %if (%1 < 0xa)
+    debugShowCharacter BYTE ('0' + (%1))
+  %else
+    debugShowCharacter BYTE ('a' + ((%1) - 0xa))
+  %endif
+%endmacro
+
+%macro  debugNewline 0
+    debugShowCharacter `\r`
+    debugShowCharacter `\n`
+%endmacro
+
+%macro  debugShowPostCode 1
+    debugShowHexDigit (((%1) >> 4) & 0xf)
+    debugShowHexDigit ((%1) & 0xf)
+    debugNewline
+%endmacro
+
+BITS    16
+
+%macro  debugInitialize 0
+    ; not required
+%endmacro
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb

index 5832aaa8abf7..f1655ddfcde3 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -41,7 +41,7 @@
  %elifdef DEBUG_SERIAL
    %include "SerialDebug.asm"
  %else
-  %include "DebugDisabled.asm"
+  %include "DebugCon.asm"
  %endif
  %include "Ia32/SearchForBfvBase.asm"


(1) How much output does this produce? Trapping to QEMU for every single
character written to the debug console is very slow. If it only produces
a few bytes, that should be OK.

(2) debugInitialize could actually be put to use; the presence of the
QEMU debug console is detectable. We'd need to allocate a single byte
somewhere, detect the console in debugInitialize, save the result in
that byte, then check the byte in debugShowPostCode. Eliminates even
those few (?) traps if there is no debug console configured.

(3) I'm already hating myself for asking about this, but... is there a
way for only customizing debugInitialize and debugShowCharacter? The
rest is common with "SerialDebug.asm", and I wish I hadn't had to review
those (unchanged) macros, they make my eyes bleed :/

Anyway, if you think any of these (or all of these!) means too much
work, I'm OK with the patch going-in as is.


My concern would be around SEV-ES/SEV-SNP guest usage. The in and out 
instruction will generate a #VC and would require a #VC handler to be in 
place.


I'm pretty sure this will cause issues for those types of guests, but it 
might be a few days before I can get to it to verify. @Gerd, were you able 
to test this with those types of guests?


Had a meeting get canceled and so got a chance to test this. As I thought, 
this causes SEV-ES/SEV-SNP guest failures.


Thanks,
Tom



Thanks,
Tom



I'm a bit concerned about (1), TBH.

Laszlo




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

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

[Sam Kaynor]

This adds an additional option to the dmem UEFI shell command for verbose 
dumping of a couple of UEFI tables.

The tables specified are the RT Properties Table, the Image Execution Table, 
and the Conformance Profiles table.

Supporting objects are added in the .inf and .uni files relating to Dmem.c and 
an additional header file for the Conformance Profiles table was added.

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

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

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

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

-- 
2.25.1

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

[Sam Kaynor]

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

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

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

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

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

[Sam Kaynor]

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

Implemented dumping of the Image Execution Table using Dmem.c

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

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

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

[Sam Kaynor]

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

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

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

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

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

[gaoliming via groups.io]

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: Laszlo Ersek 
> 发送时间: 2024年1月24日 21:00
> 收件人: Michael D Kinney ;
> devel@edk2.groups.io
> 抄送: Liming Gao ; Zhiguang Liu
> ; Qing Huang 
> 主题: Re: [Patch 1/1] MdePkg/Library/BaseCpuLibNull: Add missing X86
> specific services
> 
> On 1/23/24 23:52, Michael D Kinney wrote:
> > * 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;
> > +}
> 
> Reviewed-by: Laszlo Ersek 





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

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

[gaoliming via groups.io]

Mike:
  I suggest to document the recommended usage of the specified memory type info 
bin range. I worry that someone configures the low memory range for the memory 
type info bin range. It may still cause S4 failure. 

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

Re: [edk2-devel] [PATCH v3 2/4] StandaloneMmPkg/Hob: Integer Overflow in CreateHob()

[Ni, Ray]

Agree.
Reviewed-by: Ray Ni 

Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann 
> Sent: Wednesday, January 24, 2024 8:41 PM
> To: Ni, Ray 
> Cc: Guo, Gua ; devel@edk2.groups.io; Marc Beatove
> ; Ard Biesheuvel ;
> Sami Mujawar ; Mathews, John
> 
> Subject: Re: RE: [PATCH v3 2/4] StandaloneMmPkg/Hob: Integer Overflow in
> CreateHob()
> 
> On Fri, Jan 12, 2024 at 08:56:02AM +, Ni, Ray wrote:
> > It's strange to me that ARM's MM env still allows modifying HOBs.
> 
> Yes.
> 
> But fixing that is beyond the scope of this patch, which just
> fixes the integer overflow in CreateHob().
> 
> Can we please move forward and get the remaining CreateHob()
> fixes merged?
> 
> thanks & take care,
>   Gerd



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

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

[Michael D Kinney]

Hi Liming,

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

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

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

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

Mike

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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/ResetVector: send post codes to qemu debug console

[Erdem Aktas via groups.io]

Same for TDX, I did not run it but it should cause failure
as debugShowPostCode is called OvmfPkg/ResetVector/Ia32/IntelTdx.asm before
actually the #VE handlers are installed.

-Erdem

On Wed, Jan 24, 2024 at 11:55 AM Tom Lendacky 
wrote:

> On 1/24/24 13:24, Tom Lendacky wrote:
> > On 1/24/24 10:47, Laszlo Ersek wrote:
> >> On 1/24/24 16:31, Gerd Hoffmann wrote:
> >>> Neat when doing ResetVector coding.
> >>>
> >>> Signed-off-by: Gerd Hoffmann 
> >>> ---
> >>>   OvmfPkg/ResetVector/DebugCon.asm  | 43
> +++
> >>>   OvmfPkg/ResetVector/ResetVector.nasmb |  2 +-
> >>>   2 files changed, 44 insertions(+), 1 deletion(-)
> >>>   create mode 100644 OvmfPkg/ResetVector/DebugCon.asm
> >>>
> >>> diff --git a/OvmfPkg/ResetVector/DebugCon.asm
> >>> b/OvmfPkg/ResetVector/DebugCon.asm
> >>> new file mode 100644
> >>> index ..9c57d1a52c75
> >>> --- /dev/null
> >>> +++ b/OvmfPkg/ResetVector/DebugCon.asm
> >>> @@ -0,0 +1,43 @@
> >>>
> +;--
> >>> +; @file
> >>> +; qemu debug console support macros (based on serial port macros)
> >>> +;
> >>> +; Copyright (c) 2008 - 2018, Intel Corporation. All rights
> reserved.
> >>> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> >>> +;
> >>>
> +;--
> >>> +
> >>> +%macro  outToDebugPort 1
> >>> +mov dx, 0x402
> >>> +mov al, %1
> >>> +out dx, al
> >>> +%endmacro
> >>> +
> >>> +%macro  debugShowCharacter 1
> >>> +outToDebugPort %1
> >>> +%endmacro
> >>> +
> >>> +%macro  debugShowHexDigit 1
> >>> +  %if (%1 < 0xa)
> >>> +debugShowCharacter BYTE ('0' + (%1))
> >>> +  %else
> >>> +debugShowCharacter BYTE ('a' + ((%1) - 0xa))
> >>> +  %endif
> >>> +%endmacro
> >>> +
> >>> +%macro  debugNewline 0
> >>> +debugShowCharacter `\r`
> >>> +debugShowCharacter `\n`
> >>> +%endmacro
> >>> +
> >>> +%macro  debugShowPostCode 1
> >>> +debugShowHexDigit (((%1) >> 4) & 0xf)
> >>> +debugShowHexDigit ((%1) & 0xf)
> >>> +debugNewline
> >>> +%endmacro
> >>> +
> >>> +BITS16
> >>> +
> >>> +%macro  debugInitialize 0
> >>> +; not required
> >>> +%endmacro
> >>> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> b/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> index 5832aaa8abf7..f1655ddfcde3 100644
> >>> --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb
> >>> @@ -41,7 +41,7 @@
> >>>   %elifdef DEBUG_SERIAL
> >>> %include "SerialDebug.asm"
> >>>   %else
> >>> -  %include "DebugDisabled.asm"
> >>> +  %include "DebugCon.asm"
> >>>   %endif
> >>>   %include "Ia32/SearchForBfvBase.asm"
> >>
> >> (1) How much output does this produce? Trapping to QEMU for every single
> >> character written to the debug console is very slow. If it only produces
> >> a few bytes, that should be OK.
> >>
> >> (2) debugInitialize could actually be put to use; the presence of the
> >> QEMU debug console is detectable. We'd need to allocate a single byte
> >> somewhere, detect the console in debugInitialize, save the result in
> >> that byte, then check the byte in debugShowPostCode. Eliminates even
> >> those few (?) traps if there is no debug console configured.
> >>
> >> (3) I'm already hating myself for asking about this, but... is there a
> >> way for only customizing debugInitialize and debugShowCharacter? The
> >> rest is common with "SerialDebug.asm", and I wish I hadn't had to review
> >> those (unchanged) macros, they make my eyes bleed :/
> >>
> >> Anyway, if you think any of these (or all of these!) means too much
> >> work, I'm OK with the patch going-in as is.
> >
> > My concern would be around SEV-ES/SEV-SNP guest usage. The in and out
> > instruction will generate a #VC and would require a #VC handler to be in
> > place.
> >
> > I'm pretty sure this will cause issues for those types of guests, but it
> > might be a few days before I can get to it to verify. @Gerd, were you
> able
> > to test this with those types of guests?
>
> Had a meeting get canceled and so got a chance to test this. As I thought,
> this causes SEV-ES/SEV-SNP guest failures.
>
> Thanks,
> Tom
>
> >
> > Thanks,
> > Tom
> >
> >>
> >> I'm a bit concerned about (1), TBH.
> >>
> >> Laszlo
> >>
>


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

Re: [edk2-devel] [PATCH 00/11] OvmfPkg: tweak shell builds

[Yao, Jiewen]

Always good to reduce duplication!
Thanks for doing that.

Acked-by: Jiewen Yao 

> -Original Message-
> From: Gerd Hoffmann 
> Sent: Thursday, January 25, 2024 12:38 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Ard Biesheuvel
> ; Michael Roth ; Gerd
> Hoffmann ; Laszlo Ersek ; Aktas,
> Erdem ; Xu, Min M ; Tom
> Lendacky ; Oliver Steffen 
> Subject: [PATCH 00/11] OvmfPkg: tweak shell builds
> 
> - Create include files to reduce duplication.
> - Fix varpolicy command.
> - Little CI tweak.
> 
> Gerd Hoffmann (11):
>   OvmfPkg: add ShellComponents.dsc.inc
>   OvmfPkg: add ShellLibs.dsc.inc
>   OvmfPkg: add ShellDxe.fdf.inc
>   OvmfPkg: Shell*.inc: allow building without network support
>   OvmfPkg: ShellDxe.fdf.inc: add VariablePolicyDynamicCommand to FV
>   OvmfPkg: switch OvmfPkgIa32 to new shell include files
>   OvmfPkg: switch OvmfPkgIa32X64 to new shell include files
>   OvmfPkg: switch AmdSevX64 to new shell include files
>   OvmfPkg: switch IntelTdxX64 to new shell include files
>   OvmfPkg: switch MicrovmX64 to new shell include files
>   OvmfPkg/CI: copy shell to virtual drive
> 
>  OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 53 
>  OvmfPkg/Include/Dsc/ShellLibs.dsc.inc   | 11 +
>  OvmfPkg/AmdSev/AmdSevX64.dsc| 32 +---
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc| 33 ++---
>  OvmfPkg/Microvm/MicrovmX64.dsc  | 55 +
>  OvmfPkg/OvmfPkgIa32.dsc | 49 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 54 +++-
>  OvmfPkg/OvmfPkgX64.dsc  | 54 +++-
>  OvmfPkg/AmdSev/AmdSevX64.fdf|  8 +--
>  OvmfPkg/IntelTdx/IntelTdxX64.fdf|  9 +---
>  OvmfPkg/Microvm/MicrovmX64.fdf  |  9 +---
>  OvmfPkg/OvmfPkgIa32.fdf | 11 +
>  OvmfPkg/OvmfPkgIa32X64.fdf  | 11 +
>  OvmfPkg/OvmfPkgX64.fdf  | 11 +
>  OvmfPkg/Include/Fdf/ShellDxe.fdf.inc| 17 +++
>  OvmfPkg/PlatformCI/PlatformBuildLib.py  | 12 -
>  16 files changed, 135 insertions(+), 294 deletions(-)
>  create mode 100644 OvmfPkg/Include/Dsc/ShellComponents.dsc.inc
>  create mode 100644 OvmfPkg/Include/Dsc/ShellLibs.dsc.inc
>  create mode 100644 OvmfPkg/Include/Fdf/ShellDxe.fdf.inc
> 
> --
> 2.43.0



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

[edk2-devel] [PATCH v1] UefiPayloadPkg/Crypto: Make crypto driver as optional

[Guo, Gua]

From: Gua Guo 

Crypto in serveral case will use old version, treat as optional
will make customer easy to upgrade it.

Cc: Guo Dong 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Gua Guo 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 3 +++
 UefiPayloadPkg/UefiPayloadPkg.fdf | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 4f195c1e52..01e1684e27 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -38,6 +38,7 @@
   DEFINE SD_ENABLE= TRUE
   DEFINE PS2_MOUSE_ENABLE = TRUE
   DEFINE CRYPTO_PROTOCOL_SUPPORT  = FALSE
+  DEFINE   CRYPTO_DRIVER_SUPPORT  = TRUE
   DEFINE SD_MMC_TIMEOUT   = 100
   DEFINE USE_CBMEM_FOR_CONSOLE= FALSE
   DEFINE BOOTSPLASH_IMAGE = FALSE
@@ -860,11 +861,13 @@
   # Misc
   #
 !if $(CRYPTO_PROTOCOL_SUPPORT) == TRUE
+!if $(CRYPTO_DRIVER_SUPPORT) == TRUE
   CryptoPkg/Driver/CryptoDxe.inf {
 
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
   }
+!endif
 !endif
 
   #--
diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf 
b/UefiPayloadPkg/UefiPayloadPkg.fdf
index 7d04a8cffd..8cb7e5ac50 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -154,8 +154,10 @@ INF 
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRou
 INF 
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
 
 !if $(CRYPTO_PROTOCOL_SUPPORT) == TRUE
+!if $(CRYPTO_DRIVER_SUPPORT) == TRUE
 INF CryptoPkg/Driver/CryptoDxe.inf
 !endif
+!endif
 !if $(SECURITY_STUB_ENABLE) == TRUE
 INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 !endif
-- 
2.39.2.windows.1



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

Re: [edk2-devel] [PATCH RESEND v2 0/2] AMD CPU extended topology

[Abdul Lateef Attar via groups.io]

Gentle reminder, please review the patch series.

On 18-01-2024 09:24, Abdul Lateef Attar via groups.io wrote:

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


From: Abdul Lateef Attar 

Resending the patch with updated Cc list.

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

V2: delta changes
  - Added additional check apart from supported CPUID extneded number.
  - removed EFIAPI

Implements AMD extended toplogy.
Adds CPUID macro
update APIC library to use new exteded cpuid.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
Cc: Abdul Lateef Attar 

Abdul Lateef Attar (2):
   MdePkg: Adds AMD Extended CPU topology CPUID
   UefiCpuPkg/BaseXApic[X2]ApicLib: Implements AMD extended cpu topology

  MdePkg/Include/Register/Amd/Cpuid.h   |  23 +++-
  .../Library/BaseXApicLib/BaseXApicLib.c   | 126 +-
  .../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c   | 126 +-
  3 files changed, 272 insertions(+), 3 deletions(-)

--
2.34.1









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

[edk2-devel] [PATCH v2] UefiPayloadPkg/Crypto: Support external Crypto drivers.

[Guo, Gua]

From: Gua Guo 

Crypto in serveral case will use old version or latest version,
Platform may choose to only update Crypto drivers without updating
whole UPL, in this case the Crypto driver will provide by platform
payload outside the common UPL binary.

Cc: Chasel Chiu 
Cc: Guo Dong 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Gua Guo 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 10 +-
 UefiPayloadPkg/UefiPayloadPkg.fdf |  2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 4f195c1e52..2c4013bd9d 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -37,12 +37,18 @@
   DEFINE ATA_ENABLE   = TRUE
   DEFINE SD_ENABLE= TRUE
   DEFINE PS2_MOUSE_ENABLE = TRUE
-  DEFINE CRYPTO_PROTOCOL_SUPPORT  = FALSE
   DEFINE SD_MMC_TIMEOUT   = 100
   DEFINE USE_CBMEM_FOR_CONSOLE= FALSE
   DEFINE BOOTSPLASH_IMAGE = FALSE
   DEFINE NVME_ENABLE  = TRUE
   DEFINE CAPSULE_SUPPORT  = FALSE
+
+  #
+  # Crypto Support
+  #
+  DEFINE CRYPTO_PROTOCOL_SUPPORT= FALSE
+  DEFINE CRYPTO_DRIVER_EXTERNAL_SUPPORT = FALSE
+
   #
   # Setup Universal Payload
   #
@@ -860,11 +866,13 @@
   # Misc
   #
 !if $(CRYPTO_PROTOCOL_SUPPORT) == TRUE
+!if $(CRYPTO_DRIVER_EXTERNAL_SUPPORT) == FALSE
   CryptoPkg/Driver/CryptoDxe.inf {
 
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
   }
+!endif
 !endif

   #--
diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf 
b/UefiPayloadPkg/UefiPayloadPkg.fdf
index 7d04a8cffd..c1b1e35f32 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.fdf
+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
@@ -154,8 +154,10 @@ INF 
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRou
 INF 
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf

 !if $(CRYPTO_PROTOCOL_SUPPORT) == TRUE
+!if $(CRYPTO_DRIVER_EXTERNAL_SUPPORT) == FALSE
 INF CryptoPkg/Driver/CryptoDxe.inf
 !endif
+!endif
 !if $(SECURITY_STUB_ENABLE) == TRUE
 INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 !endif
--
2.39.2.windows.1



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

Re: [edk2-devel] [PATCH v2] UefiPayloadPkg/Crypto: Support external Crypto drivers.

[Lu, James]

Reviewed-by: James Lu 


Thanks, 
James


-Original Message-
From: Guo, Gua  
Sent: Thursday, January 25, 2024 1:09 PM
To: devel@edk2.groups.io
Cc: Guo, Gua ; Chiu, Chasel ; Dong, 
Guo ; Rhodes, Sean ; Lu, James 

Subject: [PATCH v2] UefiPayloadPkg/Crypto: Support external Crypto drivers.

From: Gua Guo 


Crypto in serveral case will use old version or latest version,

Platform may choose to only update Crypto drivers without updating

whole UPL, in this case the Crypto driver will provide by platform

payload outside the common UPL binary.



Cc: Chasel Chiu 

Cc: Guo Dong 

Cc: Sean Rhodes 

Cc: James Lu 

Cc: Gua Guo 

Signed-off-by: Gua Guo 

---

 UefiPayloadPkg/UefiPayloadPkg.dsc | 10 +-

 UefiPayloadPkg/UefiPayloadPkg.fdf |  2 ++

 2 files changed, 11 insertions(+), 1 deletion(-)



diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc

index 4f195c1e52..2c4013bd9d 100644

--- a/UefiPayloadPkg/UefiPayloadPkg.dsc

+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc

@@ -37,12 +37,18 @@

   DEFINE ATA_ENABLE   = TRUE

   DEFINE SD_ENABLE= TRUE

   DEFINE PS2_MOUSE_ENABLE = TRUE

-  DEFINE CRYPTO_PROTOCOL_SUPPORT  = FALSE

   DEFINE SD_MMC_TIMEOUT   = 100

   DEFINE USE_CBMEM_FOR_CONSOLE= FALSE

   DEFINE BOOTSPLASH_IMAGE = FALSE

   DEFINE NVME_ENABLE  = TRUE

   DEFINE CAPSULE_SUPPORT  = FALSE

+

+  #

+  # Crypto Support

+  #

+  DEFINE CRYPTO_PROTOCOL_SUPPORT= FALSE

+  DEFINE CRYPTO_DRIVER_EXTERNAL_SUPPORT = FALSE

+

   #

   # Setup Universal Payload

   #

@@ -860,11 +866,13 @@

   # Misc

   #

 !if $(CRYPTO_PROTOCOL_SUPPORT) == TRUE

+!if $(CRYPTO_DRIVER_EXTERNAL_SUPPORT) == FALSE

   CryptoPkg/Driver/CryptoDxe.inf {

 

   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf

   TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf

   }

+!endif

 !endif



   #--

diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf 
b/UefiPayloadPkg/UefiPayloadPkg.fdf

index 7d04a8cffd..c1b1e35f32 100644

--- a/UefiPayloadPkg/UefiPayloadPkg.fdf

+++ b/UefiPayloadPkg/UefiPayloadPkg.fdf

@@ -154,8 +154,10 @@ INF 
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRou

 INF 
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf



 !if $(CRYPTO_PROTOCOL_SUPPORT) == TRUE

+!if $(CRYPTO_DRIVER_EXTERNAL_SUPPORT) == FALSE

 INF CryptoPkg/Driver/CryptoDxe.inf

 !endif

+!endif

 !if $(SECURITY_STUB_ENABLE) == TRUE

 INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf

 !endif

--

2.39.2.windows.1





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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/Sec: Setup MTRR early in the boot process.

[Gerd Hoffmann]

On Wed, Jan 24, 2024 at 05:14:10PM +0100, Laszlo Ersek wrote:
> On 1/24/24 16:15, Gerd Hoffmann wrote:
> > Specifically before running lzma uncompress of the main firmware volume.
> > This is needed to make sure caching is enabled, otherwise the uncompress
> > can be extremely slow.
> > 
> > Adapt the ASSERTs in PlatformInitLib to the changes.
> > 
> > Background:  In some virtual machine configurations with assigned
> > devices kvm uses EPT memory types to apply guest MTRR settings.
> > In case MTRRs are disabled kvm will use the uncachable memory type
> > for all mappings.
> 
> I suggest mentioning mdev and noncoherent DMA here (the linux code you
> quoted elsewhere would be welcome too).

Ok, I guess it makes sense to quote it completely in the
commit message then ...

static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
{
/* We wanted to honor guest CD/MTRR/PAT, but doing so could result in
 * memory aliases with conflicting memory types and sometimes MCEs.
 * We have to be careful as to what are honored and when.
 *
 * For MMIO, guest CD/MTRR are ignored.  The EPT memory type is set to
 * UC.  The effective memory type is UC or WC depending on guest PAT.
 * This was historically the source of MCEs and we want to be
 * conservative.
 *
 * When there is no need to deal with noncoherent DMA (e.g., no VT-d
 * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.  The
 * EPT memory type is set to WB.  The effective memory type is forced
 * WB.
 *
 * Otherwise, we trust guest.  Guest CD/MTRR/PAT are all honored.  The
 * EPT memory type is used to emulate guest CD/MTRR.
 */

if (is_mmio)
return MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT;

if (!kvm_arch_has_noncoherent_dma(vcpu->kvm))
return (MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | 
VMX_EPT_IPAT_BIT;

if (kvm_read_cr0_bits(vcpu, X86_CR0_CD)) {
if (kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
return MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT;
else
return (MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT) |
VMX_EPT_IPAT_BIT;
}

return kvm_mtrr_get_guest_memory_type(vcpu, gfn) << 
VMX_EPT_MT_EPTE_SHIFT;
}

> The original report 
> claims that commit e8aa4c6546ad ("UefiCpuPkg/ResetVector: Cache Disable
> should not be set by default in CR0", 2023-08-30) triggered the symptom.

> I don't understand how *clearing* CD in CR0, could make guest memory
> *less* cacheable. I understand the point about MTRR, but exactly the
> MTRR's currently upstream state should have masked any changes to CD.

... because it also explains that question:  I think with CD set we
take the KVM_X86_QUIRK_CD_NW_CLEARED code path and run with memory in
write-back mode.

> (2) We already assume (minimally since 2015) that MTRRs are supported by
> the processor.

No.  The whole MTRR setup is gated by "if (IsMtrrSupported ())".

Also note that qemu allows to turn off MTRRs (-cpu host,mtrr=off),
which btw can be used as workaround for this bug.  With MTRR support
disabled kvm takes yet another code path ...

> >InitializeApicTimer (0, MAX_UINT32, TRUE, 5);
> >DisableApicTimerInterrupt ();
> >  
> > +  //
> > +  // Initialize MTRR
> > +  //
> > +  SecMtrrSetup ();

> (7) If you have a particular reason for doing it here, please capture
> that in the comment.

Placing it near other hardware init (timers) looked somewhat logical to
me.  Any other place in that function should work equally well though.

> (8) Just for symmetry -- I'm noticing there are two
> SecCoreStartupWithStack() functions; the other being in
> "OvmfPkg/IntelTdx/Sec/SecMain.c".
> 
> Also, Min's original QEMU command line included TDVF references.
> 
> Does that mean this patch should be reflected to the TDX platform's modules?

Probably, I'll have a look.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/ResetVector: send post codes to qemu debug console

[Gerd Hoffmann]

On Wed, Jan 24, 2024 at 05:43:29PM -0800, Erdem Aktas wrote:
> Same for TDX, I did not run it but it should cause failure
> as debugShowPostCode is called OvmfPkg/ResetVector/Ia32/IntelTdx.asm before
> actually the #VE handlers are installed.
> 
> > Had a meeting get canceled and so got a chance to test this. As I thought,
> > this causes SEV-ES/SEV-SNP guest failures.

Hmm, I guess that pretty much kills the idea.  The first post code is
sent before probing for TDX/SEV happens ...

take care,
  Gerd



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