Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

We need the use case on our platforms, it says we don’t have plan at the 
moment. However we are welcome anyone from community to implement it. 

Abner

From: Yoshinoya 
Sent: Wednesday, November 1, 2023 1:20 PM
To: devel@edk2.groups.io; Chang, Abner 
Cc: Konstantin Aladyshev ; Attar, AbdulLateef (Abdul 
Lateef) ; nick...@nvidia.com
Subject: Re:Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS 
support

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

Hi, Abner:
Got it, Thanks.

Is there any plan to implement MTCP-over-smbus or MTCP-over-PCIE ?



Thanks







At 2023-10-31 15:00:03, "Chang, Abner via groups.io" 
mailto:abner.chang=amd@groups.io>> wrote:
MCTP over KCS defines two types of KCS-like access, one is compatible with IPMI 
KCS, another is memory map I/O access. It doesn’t require any special HW, just 
require the I/O cycle or memory cycle can be delivered to the management 
controller.
Yes, we can consider MCTP is a software layer protocol and the that protocol is 
HW (transport interface) agnostic.

Abner

From: Yoshinoya mailto:yoshinoyat...@163.com>>
Sent: Tuesday, October 31, 2023 2:38 PM
To: devel@edk2.groups.io; Chang, Abner 
mailto:abner.ch...@amd.com>>
Cc: Konstantin Aladyshev mailto:aladyshe...@gmail.com>>; 
Attar, AbdulLateef (Abdul Lateef) 
mailto:abdullateef.at...@amd.com>>; 
nick...@nvidia.com
Subject: Re:Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS 
support

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

Hi, Abner:
I ask you a favor.

KCS actually layer on LPC interface.
KCS is a usual BMC-to-CPU communication channel.

Does MCTP-over-KCS feature require some special LPC interface hardware changes?
Or, MCTP is just a software stack and it uses current LPC interface, not any 
special hardward design change requirement.



Thanks







At 2023-10-26 13:03:02, "Chang, Abner via groups.io" 
mailto:abner.chang=amd@groups.io>> wrote:

>[AMD Official Use Only - General]

>

>Merged.   I will send another patch for Uncrustify updates if any.

>

>Abner

>

>> -Original Message-

>> From: Chang, Abner

>> Sent: Tuesday, October 24, 2023 10:44 AM

>> To: Konstantin Aladyshev 
>> mailto:aladyshe...@gmail.com>>; 
>> devel@edk2.groups.io

>> Cc: Attar, AbdulLateef (Abdul Lateef) 
>> mailto:abdullateef.at...@amd.com>>;

>> nick...@nvidia.com

>> Subject: RE: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

>>

>> For entire V3 and the additional patch 16/16,

>> Reviewed-by: Abner Chang mailto:abner.ch...@amd.com>>

>>

>> I will do the Uncrustify check and merge this patch set once the 
>> corresponding

>> edk2 changes are merged.

>> Thanks

>> Abner

>>

>> > -Original Message-

>> > From: Konstantin Aladyshev 
>> > mailto:aladyshe...@gmail.com>>

>> > Sent: Monday, October 23, 2023 9:05 PM

>> > To: devel@edk2.groups.io

>> > Cc: Chang, Abner mailto:abner.ch...@amd.com>>; Attar, 
>> > AbdulLateef (Abdul

>> > Lateef) mailto:abdullateef.at...@amd.com>>; 
>> > nick...@nvidia.com; Konstantin

>> > Aladyshev mailto:aladyshe...@gmail.com>>

>> > Subject: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

>> >

>> > Caution: This message originated from an External Source. Use proper

>> caution

>> > when opening attachments, clicking links, or responding.

>> >

>> >

>> > The Manageability KCS transport library needs to support requests both

>> > from MCTP and IPMI transports. Currently the code only handles IPMI

>> > case correctly.

>> > In the MCTP case the communication should be based on the MCTP-over-

>> KCS

>> > specification (DSP0254). This specification defines a special KCS

>> > binding header and trailer structures that need to be present in every

>> > MCTP message.

>> > The header structure contains a length field, therefore response packet

>> > size is not needed to be known beforehand.

>> > The trailer structure contains a PEC checksum that can be used to check

>> > itegrity of the response message.

>> > Modify Manageability KCS transport library code to check which message

>> > is processed (IPMI or MCTP) and handle each case correctly based on its

>> > own specification.

>> > This patch is a result of a joint effort from the Konstantin Aladyshev

>> > mailto:aladyshe...@gmail.com>> and Abner Chang 
>> > mailto:abner.ch...@amd.com>>.

>> >

>> > Tested:

>> > PLDM communication between the HOST and BMC was tested with both

>> > components implemented via open-source software:

>> > - The HOST (UEFI firmware) part was based one the edk2 [1] and

>> > edk2-platforms [2] code,

>> > - The BMC part was based on the openbmc [3] 

Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

[Yoshinoya]

Hi, Abner:
Got it, Thanks.


Is there any plan to implement MTCP-over-smbus or MTCP-over-PCIE ?




Thanks










At 2023-10-31 15:00:03, "Chang, Abner via groups.io" 
 wrote:

MCTP over KCS defines two types of KCS-like access, one is compatible with IPMI 
KCS, another is memory map I/O access. It doesn’t require any special HW, just 
require the I/O cycle or memory cycle can be delivered to the management 
controller.

Yes, we can consider MCTP is a software layer protocol and the that protocol is 
HW (transport interface) agnostic.

 

Abner

 

From: Yoshinoya 
Sent: Tuesday, October 31, 2023 2:38 PM
To: devel@edk2.groups.io; Chang, Abner 
Cc: Konstantin Aladyshev ; Attar, AbdulLateef (Abdul 
Lateef) ; nick...@nvidia.com
Subject: Re:Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS 
support

 

| |

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

|

 

Hi, Abner:

I ask you a favor.

 

KCS actually layer on LPC interface.

KCS is a usual BMC-to-CPU communication channel.

 

Does MCTP-over-KCS feature require some special LPC interface hardware changes?

Or, MCTP is just a software stack and it uses current LPC interface, not any 
special hardward design change requirement.

 

Thanks

 

 

 


At 2023-10-26 13:03:02, "Chang, Abner via groups.io" 
 wrote:
>[AMD Official Use Only - General]
> 
>Merged.   I will send another patch for Uncrustify updates if any.
> 
>Abner
> 
>> -Original Message-
>> From: Chang, Abner
>> Sent: Tuesday, October 24, 2023 10:44 AM
>> To: Konstantin Aladyshev ; devel@edk2.groups.io
>> Cc: Attar, AbdulLateef (Abdul Lateef) ;
>> nick...@nvidia.com
>> Subject: RE: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support
>> 
>> For entire V3 and the additional patch 16/16,
>> Reviewed-by: Abner Chang 
>> 
>> I will do the Uncrustify check and merge this patch set once the 
>> corresponding
>> edk2 changes are merged.
>> Thanks
>> Abner
>> 
>> > -Original Message-
>> > From: Konstantin Aladyshev 
>> > Sent: Monday, October 23, 2023 9:05 PM
>> > To: devel@edk2.groups.io
>> > Cc: Chang, Abner ; Attar, AbdulLateef (Abdul
>> > Lateef) ; nick...@nvidia.com; Konstantin
>> > Aladyshev 
>> > Subject: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support
>> >
>> > Caution: This message originated from an External Source. Use proper
>> caution
>> > when opening attachments, clicking links, or responding.
>> >
>> >
>> > The Manageability KCS transport library needs to support requests both
>> > from MCTP and IPMI transports. Currently the code only handles IPMI
>> > case correctly.
>> > In the MCTP case the communication should be based on the MCTP-over-
>> KCS
>> > specification (DSP0254). This specification defines a special KCS
>> > binding header and trailer structures that need to be present in every
>> > MCTP message.
>> > The header structure contains a length field, therefore response packet
>> > size is not needed to be known beforehand.
>> > The trailer structure contains a PEC checksum that can be used to check
>> > itegrity of the response message.
>> > Modify Manageability KCS transport library code to check which message
>> > is processed (IPMI or MCTP) and handle each case correctly based on its
>> > own specification.
>> > This patch is a result of a joint effort from the Konstantin Aladyshev
>> >  and Abner Chang .
>> >
>> > Tested:
>> > PLDM communication between the HOST and BMC was tested with both
>> > components implemented via open-source software:
>> > - The HOST (UEFI firmware) part was based one the edk2 [1] and
>> > edk2-platforms [2] code,
>> > - The BMC part was based on the openbmc [3] distribution.
>> >
>> > The testing process and all the necessary utilities are described in
>> > the [4] repository.
>> >
>> > The provided changes keep IPMI over KCS stack working as reported by
>> > Abner Chang.
>> >
>> > [1]: https://github.com/tianocore/edk2
>> > [2]: https://github.com/tianocore/edk2-platforms
>> > [3]: https://github.com/openbmc/openbmc
>> > [4]: https://github.com/Kostr/PLDM
>> >
>> > Changes v2 -> v3:
>> >  - Add new patch that adds PLDM completion code check
>> >
>> > Changes v1 -> v2:
>> >  - Add new patches with corrections for the PLDM protocol. The
>> >   resulting communication via EDKII_PLDM_PROTOCOL was successfully
>> >   tested.
>> >
>> > Abner Chang (4):
>> >   ManageabilityPkg: Add PLDM terminus PCDs
>> >   PldmProtocolDxe: Correct TID argument usage
>> >   ManageabilityPkg/PldmProtocol: Remove PLDM command table
>> >   PldmSmbiosTransferDxe: Implement Set PLDM terminus ID API
>> >
>> > Konstantin Aladyshev (12):
>> >   ManageabilityPkg: Add definition for the MCTP KCS TRAILER structure
>> >   ManageabilityPkg: Check MCTP EIDs for reserved values
>> >   ManageabilityPkg: Support both MCTP and IPMI in KCS tranport library
>> >   ManageabilityPkg: Check header fields in the MCTP response
>> >   ManageabilityPkg: Correct typo in 

Re: [edk2-devel] [edk2-redfish-client][PATCH] RedfishClientPkg/RedfishLib: align with edk2 RedfishLib

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Nickle Wang 
> Sent: Thursday, October 26, 2023 4:35 PM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Igor Kulchytskyy
> ; Nick Ramirez 
> Subject: [edk2-redfish-client][PATCH] RedfishClientPkg/RedfishLib: align with
> edk2 RedfishLib
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Update RedfishLib to align with RedfishLib in edk2 repository.
> RedfishLib commits on edk2:
> cf68ff61 RedfishPkg/RedfishLib: introduce new interfaces.
> 1cbdd6e9 RedfishPkg/libredfish: introduce new interfaces.
> 8765f3eb RedfishPkg/RedfishLib: return HTTP headers to caller.
>
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> Cc: Nick Ramirez 
> ---
>  .../PrivateLibrary/RedfishLib/RedfishLib.inf  |   1 +
>  .../edk2libredfish/include/redfishPayload.h   |  32 +-
>  .../edk2libredfish/include/redfishService.h   |  21 +
>  .../PrivateLibrary/RedfishLib/RedfishLib.c| 345 +++-
>  .../PrivateLibrary/RedfishLib/RedfishMisc.c   |  13 +-
>  .../RedfishLib/edk2libredfish/src/payload.c   | 124 +---
>  .../RedfishLib/edk2libredfish/src/service.c   | 531 ++
>  7 files changed, 527 insertions(+), 540 deletions(-)
>
> diff --git a/RedfishClientPkg/PrivateLibrary/RedfishLib/RedfishLib.inf
> b/RedfishClientPkg/PrivateLibrary/RedfishLib/RedfishLib.inf
> index a54e397d..79d8792f 100644
> --- a/RedfishClientPkg/PrivateLibrary/RedfishLib/RedfishLib.inf
> +++ b/RedfishClientPkg/PrivateLibrary/RedfishLib/RedfishLib.inf
> @@ -3,6 +3,7 @@
>  #
>  #  Copyright (c) 2019, Intel Corporation. All rights reserved.
>  #  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
> +#  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> diff --git
> a/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishP
> ayload.h
> b/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishP
> ayload.h
> index 8403d693..f7917603 100644
> ---
> a/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishP
> ayload.h
> +++
> b/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishP
> ayload.h
> @@ -10,6 +10,7 @@
>
>Copyright (c) 2019, Intel Corporation. All rights reserved.
>(C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
> +  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -19,7 +20,7 @@
>  #define LIBREDFISH_REDFISH_PAYLOAD_H_
>
>  #include 
> -
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -65,15 +66,6 @@ patchPayload (
>EFI_HTTP_STATUS_CODE  **StatusCode
>);
>
> -redfishPayload *
> -patchPayloadEx (
> -  redfishPayload*target,
> -  redfishPayload*payload,
> -  EFI_HTTP_HEADER   **Headers,
> -  UINTN *HeaderCount,
> -  EFI_HTTP_STATUS_CODE  **StatusCode
> -  );
> -
>  redfishPayload *
>  postContentToPayload (
>redfishPayload*target,
> @@ -83,17 +75,6 @@ postContentToPayload (
>EFI_HTTP_STATUS_CODE  **StatusCode
>);
>
> -redfishPayload *
> -postContentToPayloadEx (
> -  redfishPayload*target,
> -  const char*data,
> -  size_tdataSize,
> -  const char*contentType,
> -  EFI_HTTP_HEADER   **Headers,
> -  UINTN *HeaderCount,
> -  EFI_HTTP_STATUS_CODE  **StatusCode
> -  );
> -
>  redfishPayload *
>  postPayload (
>redfishPayload*target,
> @@ -101,15 +82,6 @@ postPayload (
>EFI_HTTP_STATUS_CODE  **StatusCode
>);
>
> -redfishPayload *
> -postPayloadEx (
> -  redfishPayload*target,
> -  redfishPayload*payload,
> -  EFI_HTTP_HEADER   **Headers,
> -  UINTN *HeaderCount,
> -  EFI_HTTP_STATUS_CODE  **StatusCode
> -  );
> -
>  void
>  cleanupPayload (
>redfishPayload  *payload
> diff --git
> a/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishS
> ervice.h
> b/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishS
> ervice.h
> index c41c0d14..c2e0fd32 100644
> ---
> a/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishS
> ervice.h
> +++
> b/RedfishClientPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishS
> ervice.h
> @@ -10,6 +10,7 @@
>
>Copyright (c) 2019, Intel Corporation. All rights reserved.
>(C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
> +  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights
> reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -153,6 +154,18 @@ postUriFromServiceEx (
>EFI_HTTP_STATUS_CODE  **StatusCode
>);
>
> +json_t *
> +putUriFromServiceEx (
> +  redfishService*service,
> +  const char

Re: [edk2-devel] [PATCH] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after RestEx

[Igor Kulchytskyy via groups.io]

Hi Mike,
Thank you for review.
Please see my answers below the text.

-Original Message-
From: Mike Maslenkin 
Sent: Tuesday, October 31, 2023 9:00 PM
To: devel@edk2.groups.io; Igor Kulchytskyy 
Cc: Abner Chang ; Nickle Wang 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH] RedfishPkg: RedfishDiscoverDxe: 
Fix issue if IPv4 installed after RestEx


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

Hi Igor

please find my comments below.

On Tue, Oct 31, 2023 at 8:56 PM Igor Kulchytskyy via groups.io
 wrote:
>
> Supported function of the driver changed to wait for all newtwork
> interface to be installed.
> Filer out the network interfaces which are not supported by
> Redfish Host Interface.
>
> Cc: Abner Chang 
> Cc: Nickle Wang 
> Cc: Igor Kulchytskyy 
> Signed-off-by: Igor Kulchytskyy 
> ---
>  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 96 ++--
>  1 file changed, 89 insertions(+), 7 deletions(-)
>
> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
> b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> index 23da3b968f..a88ad55938 100644
> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> @@ -322,9 +322,15 @@ GetTargetNetworkInterfaceInternal (
>  {
>EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;
>
> +  if (IsListEmpty()) {
> +return NULL;
> +  }
> +
>ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
> *)GetFirstNode ();
>while (TRUE) {
> -if (CompareMem ((VOID *)>MacAddress, 
> >MacAddress, ThisNetworkInterface->HwAddressSize) == 
> 0) {
> +if (CompareMem ((VOID *)>MacAddress, 
> >MacAddress, ThisNetworkInterface->HwAddressSize) == 
> 0 &&
> +((TargetNetworkInterface->IsIpv6 && 
> ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp6) ||
> +(!TargetNetworkInterface->IsIpv6 && 
> ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp4))) {
>return ThisNetworkInterface;
>  }
>
> @@ -354,6 +360,10 @@ GetTargetNetworkInterfaceInternalByController (
>  {
>EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;
>
> +  if (IsListEmpty()) {
> +return NULL;
> +  }
> +

I also have these two hunks in my pending list.
But I suggest to add ASSERT to GetTargetNetworkInterfaceInternal, just
because currently it is really impossible situation,
and mEfiRedfishDiscoverNetworkInterface was checked before in scope of
 ValidateTargetNetworkInterface().

Igor: Agree.
I also just noticed that even if GetTargetNetworkInterfaceInternal function may 
return NULL, the return value is not verified on NULL in 
RedfishServiceAcquireService function.
I think we should add this verification.


Also I wonder why check patch doesn't complain about missed spaces in
"IsListEmpty ()" call for example.

>ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
> *)GetFirstNode ();
>while (TRUE) {
>  if (ThisNetworkInterface->OpenDriverControllerHandle == 
> ControllerHandle) {
> @@ -476,6 +486,38 @@ CheckIsIpVersion6 (
>return FALSE;
>  }
>
> +/**
> +  This function returns the  IP type supported by the Host Interface
> +
> +  @retval IP Type
> +  //  Unknown=00h,
> +  //  Ipv4=01h,
> +  //  Ipv6=02h,
> +
> +**/
> +UINT8

STATIC ?
Igor: WHY?

> +GetHiIpProtocolType()
> +{
> +  EFI_STATUS Status;
> +  REDFISH_OVER_IP_PROTOCOL_DATA  *Data;
> +  REDFISH_INTERFACE_DATA *DeviceDescriptor;
> +
> +  Data = NULL;
> +  DeviceDescriptor = NULL;
> +  if (mSmbios == NULL) {
> +Status = gBS->LocateProtocol (, NULL, (VOID 
> **));
> +if (EFI_ERROR (Status)) {
> +  return 0;

In this driver REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP{4,6}
used and accessible.
so, 0 means  REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN
And these values actually checked in scope of BuildupNetworkInterface() below.
Igor: Thank you. Missed that macro.

> +}
> +  }
> +  Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
> ); // Search for SMBIOS type 42h
> +  if (!EFI_ERROR (Status) && (Data != NULL) &&
> +  (Data->HostIpAssignmentType == RedfishHostIpAssignmentStatic)) {
> +  return Data->HostIpAddressFormat;
> +  }
> +  return 0;

Same here, 0 is a magic value for
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN

> +}
> +
>  /**
>This function discover Redfish service through SMBIOS host interface.
>
> @@ -512,6 +554,15 @@ DiscoverRedfishHostInterface (
>
>Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
> ); // Search for SMBIOS type 42h
>if (!EFI_ERROR (Status) && (Data != NULL) && (DeviceDescriptor != NULL)) {
> +
> +if (Instance->NetworkInterface->NetworkProtocolType == ProtocolTypeTcp4 
> && Data->HostIpAddressFormat != 
> REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4) { 

Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks

[Wu, Hao A]

Acked-by: Hao A Wu 

Best Regards,
Hao Wu

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Henz,
> Patrick
> Sent: Wednesday, November 1, 2023 12:51 AM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Ni, Ray ; Henz,
> Patrick 
> Subject: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop
> values in XhcGetElapsedTicks
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4578
> 
> The implementation of XhcGetElapsedTicks did not account for
> non-zero start and stop values for the performance counter
> timer, potentially resulting in an incorrect elapsed tick
> count getting returned to the caller. Account for non-zero
> start and stop values when calculating the elapsed tick
> count.
> 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Signed-off-by: Patrick Henz 
> Reviewed-by:
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> index 7a2e32a9dd..6cb97b7452 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> @@ -2389,7 +2389,7 @@ XhcGetElapsedTicks (
>  // Counter counts upwards, check for an overflow condition
> 
>  //
> 
>  if (*PreviousTick > CurrentTick) {
> 
> -  Delta = (mPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
> 
> +  Delta = (CurrentTick - mPerformanceCounterStartValue) +
> (mPerformanceCounterEndValue - *PreviousTick);
> 
>  } else {
> 
>Delta = CurrentTick - *PreviousTick;
> 
>  }
> 
> @@ -2398,7 +2398,7 @@ XhcGetElapsedTicks (
>  // Counter counts downwards, check for an underflow condition
> 
>  //
> 
>  if (*PreviousTick < CurrentTick) {
> 
> -  Delta = (mPerformanceCounterStartValue - CurrentTick) + *PreviousTick;
> 
> +  Delta = (mPerformanceCounterStartValue - CurrentTick) + (*PreviousTick
> - mPerformanceCounterEndValue);
> 
>  } else {
> 
>Delta = *PreviousTick - CurrentTick;
> 
>  }
> 
> --
> 2.34.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#110434):
> https://edk2.groups.io/g/devel/message/110434
> Mute This Topic: https://groups.io/mt/102301510/1768737
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [hao.a...@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations

[Pedro Falcato]

+CC ARM maintainers

On Wed, Nov 1, 2023 at 12:40 AM Joe L  wrote:
>
> Hello,
>
> During experimentation on an AARCH64 platform with a PCIe endpoint that 
> supports option ROM, it was found that the ordering of transactions between 
> ECAM (Cfg-Write) and MMIO (Mem-Read) is not preserved by the CHI HN-I node. 
> The observed sequence is as follows:
> 1. EFI issues a Cfg-Write to endpoint Memory Space Enable bit to enable 
> memory access
> 2. EFI issues a Mem-Read to the endpoint Option ROM memory space and receives 
> back 0x (unsupported request)
> If the memory ordering between the two accesses is explicitly preserved via 
> memory barrier (DMB instruction), 2. will return back valid data instead of 
> UR. Analyzing the transactions with a protocol analyzer, we found that the 
> Mem-Read was being issued before the completion for the Cfg-Write is received.
>
> On this system, the HN-I node is configured to separate the ECAM and MMIO 
> into different SAM regions. Both regions are assigned Decice-nGnRnE 
> attributes. According to this snippet from Arm "DEN0114 PCIe AMBA Integration 
> Guide", the ordering of even Device-nGnRnE memory regions cannot be 
> guaranteed if they belong to separate PCIe address spaces
>
> 4.8.2
>
> Multiple PCIe address spaces mapped as Device-nGnRnE or Device-nGnRE Arm 
> memory model does not give any ordering guarantees between accesses to 
> different Device-nGnRnE or Device-nGnRE peripherals. Additionally, there is 
> no restriction on mapping various PCIe address spaces of the same PCIe 
> function as different Device-nGnRnE or Device-nGnRE peripherals. 
> Consequently, software cannot assume that program order will be maintained 
> between accesses to two different PCIe address spaces, even though both 
> spaces are mapped as Device-nGnRnE or Device-nGnRE. Therefore, for maximum 
> software portability, ordering requirements between accesses to different 
> PCIe address spaces must be handled explicitly in software using appropriate 
> ordering instructions."
>
> We requested a comment from an Arm representative and received a similar 
> response, confirming that a memory barrier is needed to ensure ordering 
> between accesses to ECAM and MMIO regions (or between any two ranges that are 
> assigned to a separate SAM address region)
>
> When they are to two different order regions, the read will not wait for the 
> write to complete, and can return data before the write does anything. The 
> HN-I only preserves ordering between reads and writes to the same Order 
> Region (which implies the same Address Region). Likewise, the HN-I will only 
> preserve ordering between multiple reads and between multiple writes within 
> the same Order Region, and it accomplishes this by issuing the reads with the 
> same ARID and the writes with the same AWID (i.e. it relies on the downstream 
> device to follow AXI ordering rules). Issuing a CHI request with 
> REQ.Order=EndpointOrder only guarantees ordering to the same “endpoint 
> address range,” which the HN-I defines as an Order Region (within an Address 
> Region).
>
> Our CMN TRM showcases an example where ECAM and MMIO are two different 
> regions in the HN-I SAM. The implication is that we would expect a DSB 
> between the ECAM write and MMIO read. I'm asking our Open Source Software 
> group to confirm that standard PCIe software is generally expected to be 
> aware of the need for a DSB--but my impression from talking to some of our 
> hardware engineers is that that is indeed the expectation.
>
>
> I am requesting that EDK2 consumes or produces a change to the current 
> PciExpressLib that will ensure ordering on Arm architectures after Cfg-Writes 
> which may or may not have side effects. For example, in 
> MdePkg/Library/BasePciExpressLib/PciExpressLib.c,
>
> UINT8
> EFIAPI
> PciExpressWrite8 (
>   IN  UINTN  Address,
>   IN  UINT8  Value
>   )
> {
>   ASSERT_INVALID_PCI_ADDRESS (Address);
>   if (Address >= PcdPciExpressBaseSize ()) {
> return (UINT8)-1;
>   }
>
>   return MmioWrite8 ((UINTN)GetPciExpressBaseAddress () + Address, Value);
> }
>
> should become
>
>
>
> UINT8
> EFIAPI
> PciExpressWrite8 (
>   IN  UINTN  Address,
>   IN  UINT8  Value
>   )
> {
>   ASSERT_INVALID_PCI_ADDRESS (Address);
>   if (Address >= PcdPciExpressBaseSize ()) {
> return (UINT8)-1;
>   }
>
>   UINT8 ReturnValue = MmioWrite8 ((UINTN)GetPciExpressBaseAddress () + 
> Address, Value);
>   #if defined (MDE_CPU_AARCH64)
>  MemoryFence (); // DMB sy or DSB
>   #endif
>
>   return ReturnValue;
> }
>
> Please let me know your thoughts and if this is the correct implementation 
> change needed to enforce memory ordering between separate address regions. I 
> would also like to know the preferred memory barrier instruction in this case 
> (DMB or DSB).

Hrmmm, I think the current implementation of MmioRead/Write only
offers TSO instead of "full serialization". For instance:

//
//  Reads an 8-bit MMIO register.
//

Re: [edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple definitions.

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Sure, thanks for this change.

Reviewed-by: Abner Chang mailto:abner.ch...@amd.com>>

From: Nickle Wang 
Sent: Wednesday, November 1, 2023 8:53 AM
To: Mike Maslenkin ; devel@edk2.groups.io; Chang, 
Abner 
Cc: Igor Kulchytskyy ; Nick Ramirez 
Subject: RE: [edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple 
definitions.

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


> Ack.

> Looks good to me.



Thanks for your review, Mike!  @Abner Chang, could 
you please provide reviewed-by to version 3 if this looks good to you?



Regards,

Nickle



> -Original Message-

> From: Mike Maslenkin 
> mailto:mike.maslen...@gmail.com>>

> Sent: Tuesday, October 31, 2023 11:14 PM

> To: devel@edk2.groups.io; Nickle Wang 
> mailto:nick...@nvidia.com>>

> Cc: Abner Chang mailto:abner.ch...@amd.com>>; Igor 
> Kulchytskyy mailto:ig...@ami.com>>;

> Nick Ramirez mailto:nrami...@nvidia.com>>

> Subject: Re: [edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple

> definitions.

>

> External email: Use caution opening links or attachments

>

>

> On Tue, Oct 31, 2023 at 3:56 PM Nickle Wang via groups.io

> mailto:nicklew=nvidia@groups.io>> wrote:

> >

> > There are two definitions for below functions in RedfishCrtLib.h.

> > Create this change to remote duplicated functions.

> > Function list: strcmp(), strncmp(), strncpy(), strcpy(), strcat(),

> > strlen(), strchr(), strcasecmp(), strstr(), memcmp(), memset(),

> > memcpy(), memchr(), memcmp() and memmove().

> >

> > Signed-off-by: Nickle Wang mailto:nick...@nvidia.com>>

> > Cc: Abner Chang mailto:abner.ch...@amd.com>>

> > Cc: Igor Kulchytskyy mailto:ig...@ami.com>>

> > Cc: Nick Ramirez mailto:nrami...@nvidia.com>>

> > Cc: Mike Maslenkin 
> > mailto:mike.maslen...@gmail.com>>

> > Reviewed-by: Abner Chang mailto:abner.ch...@amd.com>>

> > ---

> >  RedfishPkg/Include/Library/RedfishCrtLib.h | 105

> > -

> >  1 file changed, 105 deletions(-)

> >

> > diff --git a/RedfishPkg/Include/Library/RedfishCrtLib.h

> > b/RedfishPkg/Include/Library/RedfishCrtLib.h

> > index 23c6acfca33e..ac6c5162ad6a 100644

> > --- a/RedfishPkg/Include/Library/RedfishCrtLib.h

> > +++ b/RedfishPkg/Include/Library/RedfishCrtLib.h

> > @@ -172,20 +172,6 @@ free(

> >void *

> >);

> >

> > -void   *

> > -memset (

> > -  void *,

> > -  int,

> > -  size_t

> > -  );

> > -

> > -int

> > -memcmp  (

> > -  const void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> >  int

> >  isdigit (

> >int

> > @@ -216,47 +202,6 @@ isalnum (

> >int

> >);

> >

> > -void   *

> > -memcpy (

> > -  void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> > -void   *

> > -memset (

> > -  void *,

> > -  int,

> > -  size_t

> > -  );

> > -

> > -void   *

> > -memchr (

> > -  const void *,

> > -  int,

> > -  size_t

> > -  );

> > -

> > -int

> > -memcmp  (

> > -  const void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> > -void   *

> > -memmove(

> > -  void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> > -int

> > -strcmp  (

> > -  const char *,

> > -  const char *

> > -  );

> > -

> >  int

> >  strncmp (

> >const char *,

> > @@ -264,35 +209,6 @@ strncmp (

> >size_t

> >);

> >

> > -char   *

> > -strcpy (

> > -  char *,

> > -  const char *

> > -  );

> > -

> > -size_t

> > -strlen  (

> > -  const char *

> > -  );

> > -

> > -char   *

> > -strcat (

> > -  char *,

> > -  const char *

> > -  );

> > -

> > -char   *

> > -strchr (

> > -  const char *,

> > -  int

> > -  );

> > -

> > -int

> > -strcasecmp  (

> > -  const char *,

> > -  const char *

> > -  );

> > -

> >  int

> >  strncasecmp (

> >const char *,

> > @@ -300,21 +216,6 @@ strncasecmp (

> >size_t

> >);

> >

> > -char   *

> > -strncpy(

> > -  char *,

> > -  size_t,

> > -  const char *,

> > -  size_t

> > -  );

> > -

> > -int

> > -strncmp (

> > -  const char *,

> > -  const char *,

> > -  size_t

> > -  );

> > -

> >  char   *

> >  strrchr(

> >const char *,

> > @@ -328,12 +229,6 @@ strtoul (

> >int

> >);

> >

> > -char *

> > -strstr  (

> > -  const char  *s1,

> > -  const char  *s2

> > -  );

> > -

> >  long

> >  strtol  (

> >const char *,

> > --

> > 2.17.1

>

> Ack.

> Looks good to me.


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

Re: [edk2-devel] [PATCH v3 0/5] StarFive/VisionFive2: Add VisionFive 2 platform

[John Chew]

Hi Sunil,

Okay, I will update the "Maintainers.txt" file in patch v4.

By the way, I wonder if you also review this series?

[PATCH v2 0/5] Designware MMCDXE changes and enhancement

Thanks,

John


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110460): https://edk2.groups.io/g/devel/message/110460
Mute This Topic: https://groups.io/mt/102214516/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/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks

[Mike Maslenkin]

On Tue, Oct 31, 2023 at 7:52 PM Henz, Patrick  wrote:
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4578
>
> The implementation of XhcGetElapsedTicks did not account for
> non-zero start and stop values for the performance counter
> timer, potentially resulting in an incorrect elapsed tick
> count getting returned to the caller. Account for non-zero
> start and stop values when calculating the elapsed tick
> count.
>
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Signed-off-by: Patrick Henz 
> Reviewed-by:
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
> b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> index 7a2e32a9dd..6cb97b7452 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> @@ -2389,7 +2389,7 @@ XhcGetElapsedTicks (
>  // Counter counts upwards, check for an overflow condition
>  //
>  if (*PreviousTick > CurrentTick) {
> -  Delta = (mPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
> +  Delta = (CurrentTick - mPerformanceCounterStartValue) + 
> (mPerformanceCounterEndValue - *PreviousTick);
>  } else {
>Delta = CurrentTick - *PreviousTick;
>  }
> @@ -2398,7 +2398,7 @@ XhcGetElapsedTicks (
>  // Counter counts downwards, check for an underflow condition
>  //
>  if (*PreviousTick < CurrentTick) {
> -  Delta = (mPerformanceCounterStartValue - CurrentTick) + *PreviousTick;
> +  Delta = (mPerformanceCounterStartValue - CurrentTick) + (*PreviousTick 
> - mPerformanceCounterEndValue);
>  } else {
>Delta = *PreviousTick - CurrentTick;
>  }
> --
> 2.34.1
>
>
>
> 
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#110434): https://edk2.groups.io/g/devel/message/110434
> Mute This Topic: https://groups.io/mt/102301510/1770412
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [mike.maslen...@gmail.com]
> 
>
>
Hello, All

Just curious why this patch was broken by google groups.

Some patches to edk2 and edk2-redfish-client have unintended line
breaks marked with "=",  additional "0D" and additional "3D" to "="
Web shows https://edk2.groups.io/g/devel/message/110434 exactly as it
saved by mailer.
What do sender should setup to avoid this?

Regards,
Mike.


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

Re: [edk2-devel] [PATCH] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after RestEx

[Mike Maslenkin]

Hi Igor

please find my comments below.

On Tue, Oct 31, 2023 at 8:56 PM Igor Kulchytskyy via groups.io
 wrote:
>
> Supported function of the driver changed to wait for all newtwork
> interface to be installed.
> Filer out the network interfaces which are not supported by
> Redfish Host Interface.
>
> Cc: Abner Chang 
> Cc: Nickle Wang 
> Cc: Igor Kulchytskyy 
> Signed-off-by: Igor Kulchytskyy 
> ---
>  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 96 ++--
>  1 file changed, 89 insertions(+), 7 deletions(-)
>
> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
> b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> index 23da3b968f..a88ad55938 100644
> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> @@ -322,9 +322,15 @@ GetTargetNetworkInterfaceInternal (
>  {
>EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;
>
> +  if (IsListEmpty()) {
> +return NULL;
> +  }
> +
>ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
> *)GetFirstNode ();
>while (TRUE) {
> -if (CompareMem ((VOID *)>MacAddress, 
> >MacAddress, ThisNetworkInterface->HwAddressSize) == 
> 0) {
> +if (CompareMem ((VOID *)>MacAddress, 
> >MacAddress, ThisNetworkInterface->HwAddressSize) == 
> 0 &&
> +((TargetNetworkInterface->IsIpv6 && 
> ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp6) ||
> +(!TargetNetworkInterface->IsIpv6 && 
> ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp4))) {
>return ThisNetworkInterface;
>  }
>
> @@ -354,6 +360,10 @@ GetTargetNetworkInterfaceInternalByController (
>  {
>EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;
>
> +  if (IsListEmpty()) {
> +return NULL;
> +  }
> +

I also have these two hunks in my pending list.
But I suggest to add ASSERT to GetTargetNetworkInterfaceInternal, just
because currently it is really impossible situation,
and mEfiRedfishDiscoverNetworkInterface was checked before in scope of
 ValidateTargetNetworkInterface().
Also I wonder why check patch doesn't complain about missed spaces in
"IsListEmpty ()" call for example.

>ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
> *)GetFirstNode ();
>while (TRUE) {
>  if (ThisNetworkInterface->OpenDriverControllerHandle == 
> ControllerHandle) {
> @@ -476,6 +486,38 @@ CheckIsIpVersion6 (
>return FALSE;
>  }
>
> +/**
> +  This function returns the  IP type supported by the Host Interface
> +
> +  @retval IP Type
> +  //  Unknown=00h,
> +  //  Ipv4=01h,
> +  //  Ipv6=02h,
> +
> +**/
> +UINT8

STATIC ?

> +GetHiIpProtocolType()
> +{
> +  EFI_STATUS Status;
> +  REDFISH_OVER_IP_PROTOCOL_DATA  *Data;
> +  REDFISH_INTERFACE_DATA *DeviceDescriptor;
> +
> +  Data = NULL;
> +  DeviceDescriptor = NULL;
> +  if (mSmbios == NULL) {
> +Status = gBS->LocateProtocol (, NULL, (VOID 
> **));
> +if (EFI_ERROR (Status)) {
> +  return 0;

In this driver REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP{4,6}
used and accessible.
so, 0 means  REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN
And these values actually checked in scope of BuildupNetworkInterface() below.

> +}
> +  }
> +  Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
> ); // Search for SMBIOS type 42h
> +  if (!EFI_ERROR (Status) && (Data != NULL) &&
> +  (Data->HostIpAssignmentType == RedfishHostIpAssignmentStatic)) {
> +  return Data->HostIpAddressFormat;
> +  }
> +  return 0;

Same here, 0 is a magic value for
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN

> +}
> +
>  /**
>This function discover Redfish service through SMBIOS host interface.
>
> @@ -512,6 +554,15 @@ DiscoverRedfishHostInterface (
>
>Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
> ); // Search for SMBIOS type 42h
>if (!EFI_ERROR (Status) && (Data != NULL) && (DeviceDescriptor != NULL)) {
> +
> +if (Instance->NetworkInterface->NetworkProtocolType == ProtocolTypeTcp4 
> && Data->HostIpAddressFormat != 
> REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4) { // IPv4 case
> +  DEBUG((DEBUG_ERROR, "%a: Network Interface is IPv4, but Host Interface 
> requires Ipv6\n"));

Missed argument for %a format
Missed space "DEBUG (("

> +  return EFI_UNSUPPORTED;
> +}
> +else if (Instance->NetworkInterface->NetworkProtocolType == 
> ProtocolTypeTcp6 && Data->HostIpAddressFormat != 
> REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6) { // IPv6 case
> +  DEBUG((DEBUG_ERROR, "%a: Network Interface is IPv6, but Host Interface 
> requires IPv4\n"));

Missed argument for %a format
Missed space "DEBUG (("


> +  return EFI_UNSUPPORTED;
> +}
>  //
>  // Check if we can reach out Redfish service using this network 
> interface.
>  // Check with MAC address using Device Descriptor Data Device Type 04 
> and Type 

Re: [edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple definitions.

[Nickle Wang via groups.io]

> Ack.

> Looks good to me.



Thanks for your review, Mike!  @Abner Chang, could 
you please provide reviewed-by to version 3 if this looks good to you?



Regards,

Nickle



> -Original Message-

> From: Mike Maslenkin 

> Sent: Tuesday, October 31, 2023 11:14 PM

> To: devel@edk2.groups.io; Nickle Wang 

> Cc: Abner Chang ; Igor Kulchytskyy ;

> Nick Ramirez 

> Subject: Re: [edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple

> definitions.

>

> External email: Use caution opening links or attachments

>

>

> On Tue, Oct 31, 2023 at 3:56 PM Nickle Wang via groups.io

> mailto:nicklew=nvidia@groups.io>> wrote:

> >

> > There are two definitions for below functions in RedfishCrtLib.h.

> > Create this change to remote duplicated functions.

> > Function list: strcmp(), strncmp(), strncpy(), strcpy(), strcat(),

> > strlen(), strchr(), strcasecmp(), strstr(), memcmp(), memset(),

> > memcpy(), memchr(), memcmp() and memmove().

> >

> > Signed-off-by: Nickle Wang mailto:nick...@nvidia.com>>

> > Cc: Abner Chang mailto:abner.ch...@amd.com>>

> > Cc: Igor Kulchytskyy mailto:ig...@ami.com>>

> > Cc: Nick Ramirez mailto:nrami...@nvidia.com>>

> > Cc: Mike Maslenkin 
> > mailto:mike.maslen...@gmail.com>>

> > Reviewed-by: Abner Chang mailto:abner.ch...@amd.com>>

> > ---

> >  RedfishPkg/Include/Library/RedfishCrtLib.h | 105

> > -

> >  1 file changed, 105 deletions(-)

> >

> > diff --git a/RedfishPkg/Include/Library/RedfishCrtLib.h

> > b/RedfishPkg/Include/Library/RedfishCrtLib.h

> > index 23c6acfca33e..ac6c5162ad6a 100644

> > --- a/RedfishPkg/Include/Library/RedfishCrtLib.h

> > +++ b/RedfishPkg/Include/Library/RedfishCrtLib.h

> > @@ -172,20 +172,6 @@ free(

> >void *

> >);

> >

> > -void   *

> > -memset (

> > -  void *,

> > -  int,

> > -  size_t

> > -  );

> > -

> > -int

> > -memcmp  (

> > -  const void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> >  int

> >  isdigit (

> >int

> > @@ -216,47 +202,6 @@ isalnum (

> >int

> >);

> >

> > -void   *

> > -memcpy (

> > -  void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> > -void   *

> > -memset (

> > -  void *,

> > -  int,

> > -  size_t

> > -  );

> > -

> > -void   *

> > -memchr (

> > -  const void *,

> > -  int,

> > -  size_t

> > -  );

> > -

> > -int

> > -memcmp  (

> > -  const void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> > -void   *

> > -memmove(

> > -  void *,

> > -  const void *,

> > -  size_t

> > -  );

> > -

> > -int

> > -strcmp  (

> > -  const char *,

> > -  const char *

> > -  );

> > -

> >  int

> >  strncmp (

> >const char *,

> > @@ -264,35 +209,6 @@ strncmp (

> >size_t

> >);

> >

> > -char   *

> > -strcpy (

> > -  char *,

> > -  const char *

> > -  );

> > -

> > -size_t

> > -strlen  (

> > -  const char *

> > -  );

> > -

> > -char   *

> > -strcat (

> > -  char *,

> > -  const char *

> > -  );

> > -

> > -char   *

> > -strchr (

> > -  const char *,

> > -  int

> > -  );

> > -

> > -int

> > -strcasecmp  (

> > -  const char *,

> > -  const char *

> > -  );

> > -

> >  int

> >  strncasecmp (

> >const char *,

> > @@ -300,21 +216,6 @@ strncasecmp (

> >size_t

> >);

> >

> > -char   *

> > -strncpy(

> > -  char *,

> > -  size_t,

> > -  const char *,

> > -  size_t

> > -  );

> > -

> > -int

> > -strncmp (

> > -  const char *,

> > -  const char *,

> > -  size_t

> > -  );

> > -

> >  char   *

> >  strrchr(

> >const char *,

> > @@ -328,12 +229,6 @@ strtoul (

> >int

> >);

> >

> > -char *

> > -strstr  (

> > -  const char  *s1,

> > -  const char  *s2

> > -  );

> > -

> >  long

> >  strtol  (

> >const char *,

> > --

> > 2.17.1

>

> Ack.

> Looks good to me.


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

[edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations

[Joe L]

Hello,

During experimentation on an AARCH64 platform with a PCIe endpoint that 
supports option ROM, it was found that the ordering of transactions between 
ECAM (Cfg-Write) and MMIO (Mem-Read) is not preserved by the CHI HN-I node. The 
observed sequence is as follows:
1. EFI issues a Cfg-Write to endpoint Memory Space Enable bit to enable memory 
access
2. EFI issues a Mem-Read to the endpoint Option ROM memory space and receives 
back 0x (unsupported request)
If the memory ordering between the two accesses is explicitly preserved via 
memory barrier (DMB instruction), 2. will return back valid data instead of UR. 
Analyzing the transactions with a protocol analyzer, we found that the Mem-Read 
was being issued before the completion for the Cfg-Write is received.

On this system, the HN-I node is configured to separate the ECAM and MMIO into 
different SAM regions. Both regions are assigned Decice-nGnRnE attributes. 
According to this snippet from Arm "DEN0114 PCIe AMBA Integration Guide", the 
ordering of even Device-nGnRnE memory regions cannot be guaranteed if they 
belong to separate PCIe address spaces

> 
> 
> 
> *4.8.2*
> 
> Multiple PCIe address spaces mapped as Device-nGnRnE or Device-nGnRE Arm
> memory model does not give any ordering guarantees between accesses to
> different Device-nGnRnE or Device-nGnRE peripherals. Additionally, there
> is no restriction on mapping various PCIe address spaces of the same PCIe
> function as different Device-nGnRnE or Device-nGnRE peripherals.
> Consequently, software cannot assume that program order will be maintained
> between accesses to two different PCIe address spaces, even though both
> spaces are mapped as Device-nGnRnE or Device-nGnRE. Therefore, for maximum
> software portability, ordering requirements between accesses to different
> PCIe address spaces must be handled explicitly in software using
> appropriate ordering instructions."

We requested a comment from an Arm representative and received a similar 
response, confirming that a memory barrier is needed to ensure ordering between 
accesses to ECAM and MMIO regions (or between any two ranges that are assigned 
to a separate SAM address region)

> 
> 
> 
> When they are to two different order regions, the read will not wait for
> the write to complete, and can return data before the write does anything.
> The HN-I only preserves ordering between reads and writes to the same
> Order Region (which implies the same Address Region). Likewise, the HN-I
> will only preserve ordering between multiple reads and between multiple
> writes within the same Order Region, and it accomplishes this by issuing
> the reads with the same ARID and the writes with the same AWID (i.e. it
> relies on the downstream device to follow AXI ordering rules). Issuing a
> CHI request with REQ.Order=EndpointOrder only guarantees ordering to the
> same “endpoint address range,” which the HN-I defines as an Order Region
> (within an Address Region).
> 
> Our CMN TRM showcases an example where ECAM and MMIO are two different
> regions in the HN-I SAM. The implication is that we would expect a DSB
> between the ECAM write and MMIO read. I'm asking our Open Source Software
> group to confirm that standard PCIe software is generally expected to be
> aware of the need for a DSB--but my impression from talking to some of our
> hardware engineers is that that is indeed the expectation.
> 
> 
> 

I am requesting that EDK2 consumes or produces a change to the current 
PciExpressLib that will ensure ordering on Arm architectures after Cfg-Writes 
which may or may not have side effects. For example, in 
MdePkg/Library/BasePciExpressLib/PciExpressLib.c,

UINT8
EFIAPI
PciExpressWrite8 (
 IN  UINTN  Address,
 IN  UINT8  Value
 )
{
 ASSERT_INVALID_PCI_ADDRESS (Address);
 if (Address >= PcdPciExpressBaseSize ()) {
   return (UINT8)-1;
 }

 return MmioWrite8 ((UINTN)GetPciExpressBaseAddress () + Address, Value);
}

should become

UINT8
EFIAPI
PciExpressWrite8 (
 IN  UINTN  Address,
 IN  UINT8  Value
 )
{
 ASSERT_INVALID_PCI_ADDRESS (Address);
 if (Address >= PcdPciExpressBaseSize ()) {
   return (UINT8)-1;
 }
 
 UINT8 ReturnValue = MmioWrite8 ((UINTN)GetPciExpressBaseAddress () + Address, 
Value);
 #if defined (MDE_CPU_AARCH64)
MemoryFence (); // DMB sy or DSB
 #endif

 return ReturnValue;
}

Please let me know your thoughts and if this is the correct implementation 
change needed to enforce memory ordering between separate address regions. I 
would also like to know the preferred memory barrier instruction in this case 
(DMB or DSB).

Thanks,

Joe


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

Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

[Laszlo Ersek]

On 10/31/23 18:06, Laszlo Ersek wrote:

> (3) During all this discussion here, I have been *distinctly*
> recalling that I've experienced an *actual performance regression*
> sometime, after we had unwittingly switched from the REP variant to
> the non-REP variant.
>
> And now I have actually found it. I'm going to quote the commit
> message in full:
>
>> commit fb8b54694c53e73e1b6a098686e908f54f9bb7a9
>> Author: Laszlo Ersek 
>> Date:   Thu Apr 7 22:28:38 2016 +0200
>>
>> UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes of IO ports
>>
>> * Short description:
>>
>>   The CpuIoServiceRead() and CpuIoServiceWrite() functions transfer data
>>   between memory and IO ports with individual Io(Read|Write)(8|16|32)
>>   function calls, each in an appropriately set up loop.
>>
>>   On the Ia32 and X64 platforms however, FIFO reads and writes can be
>>   optimized, by coding them in assembly, and delegating the loop to the
>>   CPU, with the REP prefix.
>>
>>   On KVM virtualization hosts, this difference has a huge performance
>>   impact: if the loop is open-coded, then the virtual machine traps to 
>> the
>>   hypervisor on every single UINT8 / UINT16 / UINT32 transfer, whereas
>>   with the REP prefix, KVM can transfer up to a page of data per VM trap.
>>   This is especially noticeable with IDE PIO transfers, where all the 
>> data
>>   are squeezed through IO ports.
>>
>> * Long description:
>>
>>   The RootBridgeIoIoRW() function in
>>
>> PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
>>
>>   used to have the exact same IO port acces optimization, dating back
>>   verbatim to commit 1fd376d9792:
>>
>> PcAtChipsetPkg/PciHostBridgeDxe: Improve KVM FIFO I/O read/write
>>   performance
>>
>>   OvmfPkg cloned the "PcAtChipsetPkg/PciHostBridgeDxe" driver (for
>>   unrelated reasons), and inherited the optimization from PcAtChipsetPkg.
>>
>>   The "PcAtChipsetPkg/PciHostBridgeDxe" driver was ultimately removed in
>>   commit 111d79db47:
>>
>> PcAtChipsetPkg/PciHostBridge: Remove PciHostBridge driver
>>
>>   and OvmfPkg too was rebased to the new core Pci Host Bridge Driver, in
>>   commit 4014885ffd:
>>
>> OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe
>>
>>   This caused the optimization to go lost. Namely, the
>>   RootBridgeIoIoRead() and RootBridgeIoIoWrite() functions in the new 
>> core
>>   Pci Host Bridge Driver delegate IO port accesses to
>>   EFI_CPU_IO2_PROTOCOL. And, in OvmfPkg (and likely most other Ia32 / X64
>>   edk2 platforms), this protocol is provided by "UefiCpuPkg/CpuIo2Dxe",
>>   which lacks the optimization.
>>
>>   Therefore, this patch ports the C source code logic from commit
>>   1fd376d9792 (see above) to "UefiCpuPkg/CpuIo2Dxe", plus it ports the
>>   NASM-converted assembly helper functions from OvmfPkg commits
>>   6026bf460037 and ace1d0517b65:
>>
>> OvmfPkg PciHostBridgeDxe: Convert Ia32/IoFifo.asm to NASM
>>
>> OvmfPkg PciHostBridgeDxe: Convert X64/IoFifo.asm to NASM
>>
>>   In order to support the MSFT and INTEL toolchains as well, the *.asm
>>   files are ported from OvmfPkg as well, immediately from before the 
>> above
>>   conversion (that is, at 6026bf460037^).
>>
>> * Notes about the port:
>>
>>   - The write and read branches from commit 1fd376d9792 are split to the
>> separate functions CpuIoServiceWrite() and CpuIoServiceRead().
>>
>>   - The EfiPciWidthUintXX constants are replaced with 
>> EfiCpuIoWidthUintXX.
>>
>>   - The cast expression "(UINTN) Address" is replaced with
>> "(UINTN)Address" (i.e., no space), because that's how the receiving
>> functions spell it as well.
>>
>>   - The labels in the switch statements are unindented by one level, to
>> match the edk2 coding style (and the rest of UefiCpuPkg) better.
>>
>> * The first signoff belongs to Jordan, because he authored all of
>>   1fd376d9792, 6026bf460037 and ace1d0517b65.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Jordan Justen 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> Ref: https://www.redhat.com/archives/vfio-users/2016-April/msg00029.html
>> Reported-by: Mark 
>> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/10424/focus=10432
>> Reported-by: Jordan Justen 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>> Cc: Jeff Fan 
>> Cc: Mark 
>> Tested-by: Mark 
>> Reviewed-by: Jeff Fan 
>
> This is "hard evidence". Per bullet (2), Jordan had added the FIFO /
> REP variants to EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL, for some
> (non-specific) performance boost. and when that optimization was later
> lost, due to a mistake, we saw IDE PIO performance *tank* on QEMU/KVM.
>
> Therefore, I am now being 

Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Jeremy Linton]

On 10/31/23 12:37, Neal Gompa via groups.io wrote:

From: Neal Gompa 

Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, the introduction of Platform Recovery in UEFI 2.5 makes it
necessary to signal ReadyToBoot when a Platform Recovery boot loader
runs because otherwise it may lead to the execution of a boot loader
that has similar requirements to a regular one that is not launched
as a Boot Manager option.

This is especially critical to ensuring that the graphical console
is actually usable during platform recovery, as some platforms do
rely on the ConsolePrefDxe driver, which only performs console
initialization after ReadyToBoot is triggered.

This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
in EfiBootManagerProcessLoadOption () when invoking platform recovery,
which is the function that sets up the platform recovery boot process.

The expected behavior has been clarified in the UEFI 2.10 specification
to explicitly indicate this behavior is required for correct operation.

This is a rebased version of the patch originally written by Pete Batard.


Took me a bit to swap in that whole conversation again, and recheck the 
spec's and code paths, but this all looks fine to me and should allow 
the PFTF build to drop the similar patch from Pete that has been carried 
downstream for the past couple years.


As for testing the previous patch has been in the field for a couple 
years now and i'm not aware of it causing any issues. The additional 
restriction of limiting it to platform recovery logically makes sense, 
and as far as I can see shouldn't cause any problems.


So,

Reviewed-by: Jeremy Linton 


As a PS: I also went to check the ready to boot behavior for OsRecovery 
and realized that apparently none of that support was ever merged? That 
seems a bit of an oversight since its been in the spec for a few years now.





Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831

Cc: Pete Batard 
Cc: Daniel P. Berrangé 
Cc: Gerd Hoffmann 
Cc: Samer El-Haj-Mahmoud 
Cc: Laszlo Ersek 

Co-authored-by: Pete Batard 
Signed-off-by: Neal Gompa 
---
  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 2087f0b91d..83a2f893e4 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1416,6 +1416,17 @@ EfiBootManagerProcessLoadOption (
  return EFI_SUCCESS;
}
  
+  if (LoadOption->OptionType == LoadOptionTypePlatformRecovery) {

+//
+// Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+//
+EfiSignalEventReadyToBoot ();
+//
+// Report Status Code to indicate ReadyToBoot was signaled
+//
+REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+  }
+
//
// Load and start the load option.
//




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

[edk2-devel] [PATCH v1 1/1] ReadMe.rst: Add Apache License 2.0 and update submodule list

[Michael Kubacki]

From: Michael Kubacki 

- Adds Apache License 2.0 as an acceptable source license per
  discussion in https://edk2.groups.io/g/devel/message/110226
- Updates the URL for existing licenses to match the current path
  used by opensource.org.
- The submodule list in this file is stale and is very prone to
  being forgotten. The list of submodules in the submodules setion
  is replaced with a link to .gitmodules which has an active list
  of submodules at any given time.

Cc: Andrew Fish 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Pedro Falcato 
Cc: Sean Brogan 
Signed-off-by: Michael Kubacki 
---
 ReadMe.rst | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/ReadMe.rst b/ReadMe.rst
index ed1d4822459b..6b3eddc33af5 100644
--- a/ReadMe.rst
+++ b/ReadMe.rst
@@ -134,11 +134,12 @@ To make a contribution to a TianoCore project, follow 
these steps.
 copyright license as the base project. When that is not possible,
 then contributions using the following licenses can be accepted:
 
--  BSD (2-clause): http://opensource.org/licenses/BSD-2-Clause
--  BSD (3-clause): http://opensource.org/licenses/BSD-3-Clause
--  MIT: http://opensource.org/licenses/MIT
--  Python-2.0: http://opensource.org/licenses/Python-2.0
--  Zlib: http://opensource.org/licenses/Zlib
+-  Apache License, Version 2.0: https://opensource.org/license/apache-2-0/
+-  BSD (2-clause): http://opensource.org/license/BSD-2-Clause
+-  BSD (3-clause): http://opensource.org/license/BSD-3-Clause
+-  MIT: http://opensource.org/license/MIT
+-  Python-2.0: http://opensource.org/license/Python-2.0
+-  Zlib: http://opensource.org/license/Zlib
 
 For documentation:
 
@@ -245,12 +246,7 @@ Submodules
 
 Submodule in EDK II is allowed but submodule chain should be avoided
 as possible as we can. Currently EDK II contains the following submodules
-
--  CryptoPkg/Library/OpensslLib/openssl
--  ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
--  MdeModulePkg/Universal/RegularExpressionDxe/oniguruma
--  MdeModulePkg/Library/BrotliCustomDecompressLib/brotli
--  BaseTools/Source/C/BrotliCompress/brotli
+`.gitmodules <.gitmodules>`__.
 
 ArmSoftFloatLib is actually required by OpensslLib. It's inevitable
 in openssl-1.1.1 (since stable201905) for floating point parameter
-- 
2.42.0.windows.2



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Correct file description for MpHandOff header file

[Laszlo Ersek]

On 10/31/23 21:33, Laszlo Ersek wrote:
> On 10/7/23 08:32, Yuanhao Xie wrote:
>> Cc: Eric Dong 
>> Cc: Rahul Kumar 
>> Cc: Tom Lendacky 
>> Signed-off-by: Yuanhao Xie 
>> ---
>>  UefiCpuPkg/Library/MpInitLib/MpHandOff.h | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> Queued in .

Commit ccbe2e938386.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110451): https://edk2.groups.io/g/devel/message/110451
Mute This Topic: https://groups.io/mt/101813022/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/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks

[Laszlo Ersek]

On 10/31/23 17:51, Henz, Patrick wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4578
> 
> The implementation of XhcGetElapsedTicks did not account for
> non-zero start and stop values for the performance counter
> timer, potentially resulting in an incorrect elapsed tick
> count getting returned to the caller. Account for non-zero
> start and stop values when calculating the elapsed tick
> count.
> 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Signed-off-by: Patrick Henz 
> Reviewed-by:
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
> b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> index 7a2e32a9dd..6cb97b7452 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> @@ -2389,7 +2389,7 @@ XhcGetElapsedTicks (
>  // Counter counts upwards, check for an overflow condition
>  //
>  if (*PreviousTick > CurrentTick) {
> -  Delta = (mPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
> +  Delta = (CurrentTick - mPerformanceCounterStartValue) + 
> (mPerformanceCounterEndValue - *PreviousTick);
>  } else {
>Delta = CurrentTick - *PreviousTick;
>  }
> @@ -2398,7 +2398,7 @@ XhcGetElapsedTicks (
>  // Counter counts downwards, check for an underflow condition
>  //
>  if (*PreviousTick < CurrentTick) {
> -  Delta = (mPerformanceCounterStartValue - CurrentTick) + *PreviousTick;
> +  Delta = (mPerformanceCounterStartValue - CurrentTick) + (*PreviousTick 
> - mPerformanceCounterEndValue);
>  } else {
>Delta = *PreviousTick - CurrentTick;
>  }

Reviewed-by: Laszlo Ersek 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110450): https://edk2.groups.io/g/devel/message/110450
Mute This Topic: https://groups.io/mt/102301510/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] UefiCpuPkg: Correct file description for MpHandOff header file

[Laszlo Ersek]

On 10/7/23 08:32, Yuanhao Xie wrote:
> Cc: Eric Dong 
> Cc: Rahul Kumar 
> Cc: Tom Lendacky 
> Signed-off-by: Yuanhao Xie 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpHandOff.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Queued in .



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110449): https://edk2.groups.io/g/devel/message/110449
Mute This Topic: https://groups.io/mt/101813022/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 v1 1/1] BaseTools: Resolve invalid escape sequence

[Joey Vagedes via groups.io]

Resolves an invalid escape sequence in a regex string that occurs
because the string was not marked as a raw string, so backslash
characters create unexpected escape sequences.

This was brought to light due to Python 3.12 now detecting invalid
escape sequences and generates a warning. It is best practice to
always use raw strings for regex strings.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Signed-off-by: Joey Vagedes 
---
 BaseTools/Scripts/BinToPcd.py | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Scripts/BinToPcd.py b/BaseTools/Scripts/BinToPcd.py
index 460c08b7f7cd..43fc458b0426 100644
--- a/BaseTools/Scripts/BinToPcd.py
+++ b/BaseTools/Scripts/BinToPcd.py
@@ -10,13 +10,12 @@ BinToPcd
 '''
 from __future__ import print_function
 
-import sys
 import argparse
-import re
-import xdrlib
 import io
-import struct
 import math
+import re
+import struct
+import sys
 
 #
 # Globals for help information
@@ -38,13 +37,13 @@ if __name__ == '__main__':
 return Value
 
 def ValidatePcdName (Argument):
-if re.split ('[a-zA-Z\_][a-zA-Z0-9\_]*\.[a-zA-Z\_][a-zA-Z0-9\_]*', 
Argument) != ['', '']:
+if re.split (r'[a-zA-Z\_][a-zA-Z0-9\_]*\.[a-zA-Z\_][a-zA-Z0-9\_]*', 
Argument) != ['', '']:
 Message = '{Argument} is not in the form 
.'.format (Argument = Argument)
 raise argparse.ArgumentTypeError (Message)
 return Argument
 
 def ValidateGuidName (Argument):
-if re.split ('[a-zA-Z\_][a-zA-Z0-9\_]*', Argument) != ['', '']:
+if re.split (r'[a-zA-Z\_][a-zA-Z0-9\_]*', Argument) != ['', '']:
 Message = '{Argument} is not a valid GUID C name'.format (Argument 
= Argument)
 raise argparse.ArgumentTypeError (Message)
 return Argument
-- 
2.34.1



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

Re: [edk2-devel] CodeQL and Apache Licensed Files

[Pedro Falcato]

On Tue, Oct 31, 2023 at 7:43 PM Kinney, Michael D
 wrote:
>
> Hi Pedro,
>
> SPDX is only for licenses, not copyrights.

IANAL, but several FOSS projects (including Linux) have generally
replaced the "Copyright (c) ..." verbiage with SPDX.
I assume there has to be some legal basis for this, although I don't
know if it depends on the license, etc
(IIRC I /think/ one could state that copyright holders are stored in
git information, but, again, I'm not a lawyer)

-- 
Pedro


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

Re: [edk2-devel] CodeQL and Apache Licensed Files

[Michael D Kinney]

Hi Michael,

I agree that SPDX is preferred in file headers over license text
in TianoCore projects.

I just do not know what the rules are when you copy a file from
An external project if you can replace without permission from the
owning project since many of the licenses state that the license
and copyrights need to be preserved.

Mike

> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, October 31, 2023 12:34 PM
> To: Kinney, Michael D ; Laszlo Ersek
> ; devel@edk2.groups.io; 'Leif Lindholm'
> ; 'Andrew Fish' 
> Cc: 'Sean Brogan' ; Gerd Hoffmann
> ; Oliver Steffen 
> Subject: Re: [edk2-devel] CodeQL and Apache Licensed Files
> 
> On 10/31/2023 3:19 PM, Kinney, Michael D wrote:
> > Michael,
> >
> > I noticed some of the files had Apache 2.0 license and then
> > you added content under BSD-2-Clause-Patent.  Why wouldn't
> > you continue with the original Apache 2.0 license?
> >
> I will continue with the original license.
> 
> > Also, I am not sure if you can replace the license text with
> > the SPDX identifier if the original file had the text.  I know
> > TianoCore did a license change, but we had to get approval from
> > all contributors.
> >
> I interpreted the earlier question (3) to mean appending an SPDX
> identifier to the existing header.
> 
> I still think there's some value in that for machine readability and
> consistency with the ID being present in most other source files in
> the
> repo. Do we care to have that?
> 
> Note: "Copyright notices" in
> https://spdx.dev/learn/handling-license-info/ instructs not remove or
> modify existing notices.
> 
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: Laszlo Ersek 
> >> Sent: Tuesday, October 31, 2023 10:22 AM
> >> To: Michael Kubacki ;
> >> devel@edk2.groups.io; Kinney, Michael D
> ;
> >> 'Leif Lindholm' ; 'Andrew Fish'
> >> 
> >> Cc: 'Sean Brogan' ; Gerd Hoffmann
> >> ; Oliver Steffen 
> >> Subject: Re: [edk2-devel] CodeQL and Apache Licensed Files
> >>
> >> On 10/31/23 17:07, Michael Kubacki wrote:
> >>> On 10/28/2023 7:51 AM, Laszlo Ersek wrote:
>  On 10/27/23 23:11, Michael Kubacki wrote:
> > I'd like to bring attention to Apache License 2.0 code in the
> >> CodeQL
> > series I sent to the mailing list for steward review.
> >
> > In particular, the files in the BaseTools/Plugin/CodeQL/analyze
> > directory of this patch:
> >
> > https://edk2.groups.io/g/devel/message/109696
> >
> > Please let me know if any next steps are needed.
> 
>  (1) I don't know if edk2 accepts contributions under Apache
> License
> >> 2.0;
>  just want to point out that this license is acceptable in Fedora
> >> (and so
>  RHEL too), per
>  .
> >> Assuming
>  we're talking about "Apache Software License 2.0".
> 
> >>> A few submodules are using the Apache License 2.0.
> >>>
> >>> For example, OpenSSL v3:
> >>>
> >>> - https://www.openssl.org/source/license.html
> >>> -
> >>
> https://git.openssl.org/?p=openssl.git;a=blob_plain;f=LICENSE.txt;hb=H
> >> EAD
> >>>
> >>> And cmoocka:
> >>>
> >>> - https://gitlab.com/cmocka/cmocka/-/blob/master/COPYING
> >>
> >> Thanks for identifying those!
> >>
> >>>
> >>> I'm unaware if there was precedent specific to submodules, but I'd
> >>> expect terms like redistribution clauses to already apply
> regardless
> >> of
> >>> tooling used to acquire the source code into the project.
> >>
> >> I believe the same.
> >>
> >>>
>  (2) Should we extend "License Details" and "Code Contributions"
> in
>  "ReadMe.rst"?
> 
> >>> My initial thought was to add the path
> >> (BaseTools\Plugin\CodeQL\analyze)
> >>> to "License Details".
> >>>
> >>> Was that all that you had in mind or to elaborate further in that
> >>> section on the licenses used/allowed?
> >>
> >> - Under "License Details", simply list
> BaseTools/Plugin/CodeQL/analyze
> >> as one of the "components" (i.e., first list) that use a
> "additional
> >> licenses".
> >>
> >> - Under "Code Contributions", we should list "Apache Software
> License
> >> 2.0" as acceptable -- both for this new feature, and for the
> *already*
> >> upstream stuff that you found above.
> >>
> >>>
>  (3) Should the new files (under Apache License 2.0) use an SPDX
>  identifier tag, for easy greppability?
> 
> >>> I'd be happy to add that.
> >>
> >> That's a relief, I didn't know whether you could touch up the
> license
> >> blocks!
> >>
> >> Thanks!
> >> Laszlo
> >>
> >>>
>  (4) With the addition, downstream packages (such as RPMs in
> Fedora
> >> and
>  RHEL) might want to spell out the short SPDX identifier of the
> new
>  license too in their License: tags.
> 
>  Laszlo
> 
> 
> 
>  
> 
> >>>
> >


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

Re: [edk2-devel] CodeQL and Apache Licensed Files

[Michael D Kinney]

Hi Pedro,

SPDX is only for licenses, not copyrights.

There used to be a requirement for Intel copyright end year to be updated.
That is no longer a requirement, and should reduce the churn on the file
headers.

Mike


> -Original Message-
> From: Pedro Falcato 
> Sent: Tuesday, October 31, 2023 12:23 PM
> To: devel@edk2.groups.io; ler...@redhat.com
> Cc: mikub...@linux.microsoft.com; Kinney, Michael D
> ; Leif Lindholm
> ; Andrew Fish ; Sean
> Brogan ; Gerd Hoffmann ;
> Oliver Steffen 
> Subject: Re: [edk2-devel] CodeQL and Apache Licensed Files
> 
> On Sat, Oct 28, 2023 at 12:51 PM Laszlo Ersek 
> wrote:
> >
> > On 10/27/23 23:11, Michael Kubacki wrote:
> > > I'd like to bring attention to Apache License 2.0 code in the
> CodeQL
> > > series I sent to the mailing list for steward review.
> > >
> > > In particular, the files in the BaseTools/Plugin/CodeQL/analyze
> > > directory of this patch:
> > >
> > > https://edk2.groups.io/g/devel/message/109696
> > >
> > > Please let me know if any next steps are needed.
> >
> > (1) I don't know if edk2 accepts contributions under Apache License
> 2.0;
> > just want to point out that this license is acceptable in Fedora
> (and so
> > RHEL too), per
> > .
> Assuming
> > we're talking about "Apache Software License 2.0".
> >
> > (2) Should we extend "License Details" and "Code Contributions" in
> > "ReadMe.rst"?
> >
> > (3) Should the new files (under Apache License 2.0) use an SPDX
> > identifier tag, for easy greppability?
> 
> I would welcome replacing *all* copyright notices with SPDX tags.
> Would also end the "Copyright (c) Corp Corporation" churn that
> regularly happens in EDK2!
> 
> --
> Pedro


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

[Pedro Falcato]

On Sat, Oct 28, 2023 at 12:51 PM Laszlo Ersek  wrote:
>
> On 10/27/23 23:11, Michael Kubacki wrote:
> > I'd like to bring attention to Apache License 2.0 code in the CodeQL
> > series I sent to the mailing list for steward review.
> >
> > In particular, the files in the BaseTools/Plugin/CodeQL/analyze
> > directory of this patch:
> >
> > https://edk2.groups.io/g/devel/message/109696
> >
> > Please let me know if any next steps are needed.
>
> (1) I don't know if edk2 accepts contributions under Apache License 2.0;
> just want to point out that this license is acceptable in Fedora (and so
> RHEL too), per
> . Assuming
> we're talking about "Apache Software License 2.0".
>
> (2) Should we extend "License Details" and "Code Contributions" in
> "ReadMe.rst"?
>
> (3) Should the new files (under Apache License 2.0) use an SPDX
> identifier tag, for easy greppability?

I would welcome replacing *all* copyright notices with SPDX tags.
Would also end the "Copyright (c) Corp Corporation" churn that
regularly happens in EDK2!

-- 
Pedro


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

Re: [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Pedro Falcato]

On Tue, Oct 31, 2023 at 9:55 AM Dhaval Sharma  wrote:
>
> I am posting an update on behalf of Jingyu as he had trouble with posting. 
> CC'ing him here:
> In summary what we have verified so far:
>
> I have verified that instructions/op codes are okay. I have also verified on 
> Qemu that functionally it seems to be calling correct instructions. Ensured 
> with negative test cases that any other op codes do cause exceptions as 
> expected.
> Jingyu was able to verify the CpuFlushCpuDataCache function with this 
> framework (he had to use custom op code based on his soc implementation) on 
> SG2042. There is one issue that he is debugging now which is related to other 
> cache instructions and he will get back with more data. P.S. SG2042 does not 
> implement the exact same CMO opcodes but equivalent ones. So this experiment 
> is just an additional data point that helps verify the framework and not CMO 
> itself.
> In general it sounds like framework flows are alright and as long as 
> instructions do their job as claimed in the spec, it is lower risk.
>
> Guess this is what we have so far. If it makes sense to everyone, we could go 
> ahead with merging with this *feature disabled by default* after Jingyu 
> provides clarity reg failures on SG2042 platform. Otherwise we can wait until 
> newer Si is available where these exact instructions can be tested and then 
> upstreamed.

Thanks!

To be clear, I wasn't NAKing it, I even gave you my Rb. I just think
we should be extra careful sending arch-related changes that haven't
been tested on real HW, because hardware tends to be tricky :)

-- 
Pedro


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

Re: [edk2-devel] CodeQL and Apache Licensed Files

[Michael D Kinney]

Michael,

I noticed some of the files had Apache 2.0 license and then
you added content under BSD-2-Clause-Patent.  Why wouldn't 
you continue with the original Apache 2.0 license?

Also, I am not sure if you can replace the license text with
the SPDX identifier if the original file had the text.  I know
TianoCore did a license change, but we had to get approval from
all contributors.

Thanks,

Mike

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, October 31, 2023 10:22 AM
> To: Michael Kubacki ;
> devel@edk2.groups.io; Kinney, Michael D ;
> 'Leif Lindholm' ; 'Andrew Fish'
> 
> Cc: 'Sean Brogan' ; Gerd Hoffmann
> ; Oliver Steffen 
> Subject: Re: [edk2-devel] CodeQL and Apache Licensed Files
> 
> On 10/31/23 17:07, Michael Kubacki wrote:
> > On 10/28/2023 7:51 AM, Laszlo Ersek wrote:
> >> On 10/27/23 23:11, Michael Kubacki wrote:
> >>> I'd like to bring attention to Apache License 2.0 code in the
> CodeQL
> >>> series I sent to the mailing list for steward review.
> >>>
> >>> In particular, the files in the BaseTools/Plugin/CodeQL/analyze
> >>> directory of this patch:
> >>>
> >>> https://edk2.groups.io/g/devel/message/109696
> >>>
> >>> Please let me know if any next steps are needed.
> >>
> >> (1) I don't know if edk2 accepts contributions under Apache License
> 2.0;
> >> just want to point out that this license is acceptable in Fedora
> (and so
> >> RHEL too), per
> >> .
> Assuming
> >> we're talking about "Apache Software License 2.0".
> >>
> > A few submodules are using the Apache License 2.0.
> >
> > For example, OpenSSL v3:
> >
> > - https://www.openssl.org/source/license.html
> > -
> https://git.openssl.org/?p=openssl.git;a=blob_plain;f=LICENSE.txt;hb=H
> EAD
> >
> > And cmoocka:
> >
> > - https://gitlab.com/cmocka/cmocka/-/blob/master/COPYING
> 
> Thanks for identifying those!
> 
> >
> > I'm unaware if there was precedent specific to submodules, but I'd
> > expect terms like redistribution clauses to already apply regardless
> of
> > tooling used to acquire the source code into the project.
> 
> I believe the same.
> 
> >
> >> (2) Should we extend "License Details" and "Code Contributions" in
> >> "ReadMe.rst"?
> >>
> > My initial thought was to add the path
> (BaseTools\Plugin\CodeQL\analyze)
> > to "License Details".
> >
> > Was that all that you had in mind or to elaborate further in that
> > section on the licenses used/allowed?
> 
> - Under "License Details", simply list BaseTools/Plugin/CodeQL/analyze
> as one of the "components" (i.e., first list) that use a "additional
> licenses".
> 
> - Under "Code Contributions", we should list "Apache Software License
> 2.0" as acceptable -- both for this new feature, and for the *already*
> upstream stuff that you found above.
> 
> >
> >> (3) Should the new files (under Apache License 2.0) use an SPDX
> >> identifier tag, for easy greppability?
> >>
> > I'd be happy to add that.
> 
> That's a relief, I didn't know whether you could touch up the license
> blocks!
> 
> Thanks!
> Laszlo
> 
> >
> >> (4) With the addition, downstream packages (such as RPMs in Fedora
> and
> >> RHEL) might want to spell out the short SPDX identifier of the new
> >> license too in their License: tags.
> >>
> >> Laszlo
> >>
> >>
> >>
> >> 
> >>
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110441): https://edk2.groups.io/g/devel/message/110441
Mute This Topic: https://groups.io/mt/102230244/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] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after RestEx

[Igor Kulchytskyy via groups.io]

Supported function of the driver changed to wait for all newtwork
interface to be installed.
Filer out the network interfaces which are not supported by
Redfish Host Interface.

Cc: Abner Chang 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Signed-off-by: Igor Kulchytskyy 
---
 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 96 ++--
 1 file changed, 89 insertions(+), 7 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 23da3b968f..a88ad55938 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
@@ -322,9 +322,15 @@ GetTargetNetworkInterfaceInternal (
 {
   EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;

+  if (IsListEmpty()) {
+return NULL;
+  }
+
   ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
*)GetFirstNode ();
   while (TRUE) {
-if (CompareMem ((VOID *)>MacAddress, 
>MacAddress, ThisNetworkInterface->HwAddressSize) == 0) 
{
+if (CompareMem ((VOID *)>MacAddress, 
>MacAddress, ThisNetworkInterface->HwAddressSize) == 0 
&&
+((TargetNetworkInterface->IsIpv6 && 
ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp6) ||
+(!TargetNetworkInterface->IsIpv6 && 
ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp4))) {
   return ThisNetworkInterface;
 }

@@ -354,6 +360,10 @@ GetTargetNetworkInterfaceInternalByController (
 {
   EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;

+  if (IsListEmpty()) {
+return NULL;
+  }
+
   ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
*)GetFirstNode ();
   while (TRUE) {
 if (ThisNetworkInterface->OpenDriverControllerHandle == ControllerHandle) {
@@ -476,6 +486,38 @@ CheckIsIpVersion6 (
   return FALSE;
 }

+/**
+  This function returns the  IP type supported by the Host Interface
+
+  @retval IP Type
+  //  Unknown=00h,
+  //  Ipv4=01h,
+  //  Ipv6=02h,
+
+**/
+UINT8
+GetHiIpProtocolType()
+{
+  EFI_STATUS Status;
+  REDFISH_OVER_IP_PROTOCOL_DATA  *Data;
+  REDFISH_INTERFACE_DATA *DeviceDescriptor;
+
+  Data = NULL;
+  DeviceDescriptor = NULL;
+  if (mSmbios == NULL) {
+Status = gBS->LocateProtocol (, NULL, (VOID 
**));
+if (EFI_ERROR (Status)) {
+  return 0;
+}
+  }
+  Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
); // Search for SMBIOS type 42h
+  if (!EFI_ERROR (Status) && (Data != NULL) &&
+  (Data->HostIpAssignmentType == RedfishHostIpAssignmentStatic)) {
+  return Data->HostIpAddressFormat;
+  }
+  return 0;
+}
+
 /**
   This function discover Redfish service through SMBIOS host interface.

@@ -512,6 +554,15 @@ DiscoverRedfishHostInterface (

   Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
); // Search for SMBIOS type 42h
   if (!EFI_ERROR (Status) && (Data != NULL) && (DeviceDescriptor != NULL)) {
+
+if (Instance->NetworkInterface->NetworkProtocolType == ProtocolTypeTcp4 && 
Data->HostIpAddressFormat != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4) 
{ // IPv4 case
+  DEBUG((DEBUG_ERROR, "%a: Network Interface is IPv4, but Host Interface 
requires Ipv6\n"));
+  return EFI_UNSUPPORTED;
+}
+else if (Instance->NetworkInterface->NetworkProtocolType == 
ProtocolTypeTcp6 && Data->HostIpAddressFormat != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6) { // IPv6 case
+  DEBUG((DEBUG_ERROR, "%a: Network Interface is IPv6, but Host Interface 
requires IPv4\n"));
+  return EFI_UNSUPPORTED;
+}
 //
 // Check if we can reach out Redfish service using this network interface.
 // Check with MAC address using Device Descriptor Data Device Type 04 and 
Type 05.
@@ -1102,6 +1153,7 @@ RedfishServiceGetNetworkInterface (
   OUT EFI_REDFISH_DISCOVER_NETWORK_INTERFACE  **NetworkIntfInstances
   )
 {
+  EFI_STATUS   Status;
   EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterfaceIntn;
   EFI_REDFISH_DISCOVER_NETWORK_INTERFACE   *ThisNetworkInterface;
   EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL   *RestExInstance;
@@ -1141,6 +1193,16 @@ RedfishServiceGetNetworkInterface (

   ThisNetworkInterfaceIntn = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
*)GetFirstNode ();
   while (TRUE) {
+// If Get Subnet Info skip this interface
+Status = NetworkInterfaceGetSubnetInfo (ThisNetworkInterfaceIntn, 
ImageHandle); // Get subnet info
+if (EFI_ERROR(Status)) {
+  if (IsNodeAtEnd (, 
>Entry)) {
+break;
+  }
+  ThisNetworkInterfaceIntn = 
(EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL *)GetNextNode 
(, >Entry);
+  continue;
+}
+
 ThisNetworkInterface->IsIpv6 = FALSE;
 if (CheckIsIpVersion6 (ThisNetworkInterfaceIntn)) {
   ThisNetworkInterface->IsIpv6 = TRUE;
@@ -1260,7 +1322,12 @@ RedfishServiceAcquireService (
   

Re: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Neal Gompa]

On Thu, Oct 26, 2023 at 12:39 PM Laszlo Ersek  wrote:
>
> On 10/26/23 18:19, Laszlo Ersek wrote:
> > On 10/26/23 15:53, Neal Gompa wrote:
> >> From: Neal Gompa 
> >>
> >> Currently, the ReadyToBoot event is only signaled when a formal Boot
> >> Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> >>
> >> However, the introduction of Platform Recovery in UEFI 2.5 makes it
> >> necessary to signal ReadyToBoot when a Platform Recovery boot loader
> >> runs because otherwise it may lead to the execution of a boot loader
> >> that has similar requirements to a regular one that is not launched
> >> as a Boot Manager option.
> >>
> >> This is especially critical to ensuring that the graphical console
> >> is actually usable during platform recovery, as some platforms do
> >> rely on the ConsolePrefDxe driver, which only performs console
> >> initialization after ReadyToBoot is triggered.
> >>
> >> This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
> >> in EfiBootManagerProcessLoadOption (), which is the function that sets
> >> up the platform recovery boot process.
> >>
> >> The expected behavior has been clarified in the UEFI 2.10 specification
> >> to explicitly indicate this behavior is required for correct operation.
> >>
> >> This is a rebased version of the patch originally written by Pete Batard.
> >>
> >> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831
> >>
> >> Cc: Pete Batard 
> >> Cc: Daniel P. Berrangé 
> >> Cc: Gerd Hoffmann 
> >> Cc: Samer El-Haj-Mahmoud 
> >>
> >> Co-authored-by: Pete Batard 
> >> Signed-off-by: Neal Gompa 
> >> ---
> >>  MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
> >>  1 file changed, 9 insertions(+)
> >>
> >> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
> >> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >> index 2087f0b91d..31ed608817 100644
> >> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >> @@ -1416,6 +1416,15 @@ EfiBootManagerProcessLoadOption (
> >>  return EFI_SUCCESS;
> >>}
> >>
> >> +  //
> >> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load 
> >> and execute the boot option.
> >> +  //
> >> +  EfiSignalEventReadyToBoot ();
> >> +  //
> >> +  // Report Status Code to indicate ReadyToBoot was signalled
> >> +  //
> >> +  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
> >> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> >> +
> >>//
> >>// Load and start the load option.
> >>//
> >
> > While the patch does the right thing for the latest UEFI spec language,
> > it does a bit too much.
> >
> > The spec says (v2.10), under 7.1.2 "EFI_BOOT_SERVICES.CreateEventEx()":
> >
> > ---
> > EFI_EVENT_GROUP_READY_TO_BOOT
> >
> > This event group is notified by the system right before notifying
> > EFI_EVENT_GROUP_AFTER_READY_TO_BOOT event group when the Boot Manager is
> > about to load and execute a boot option or a platform or OS recovery
> > option. The event group presents the last chance to modify device or
> > system configuration prior to passing control to a boot option.
> > ---
> >
> > NB "boot option", or "platform or OS recovery option".
> >
> > However, EfiBootManagerProcessLoadOption() is also used for launching
> > Driver and SysPrep options.
> >
> > EfiBootManagerProcessLoadOption() has two call sites:
> >
> > (1) in ProcessLoadOptions() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
> >
> > (2) near the end of BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]
> >
> > Call site (2) bears the comment "When platform recovery is not enabled,
> > still boot to platform default file path", so I figure signaling
> > ready-to-boot at that point is fine.
> >
> > Call site (1) requires further investigation. Namely,
> > ProcessLoadOptions() itself is called from three locations, all inside
> > BdsEntry() [MdeModulePkg/Universal/BdsDxe/BdsEntry.c]:
> >
> > (1.1) under comment "Execute Driver Options", for "LoadOptionTypeDriver"
> > type load options
> >
> > (1.2) under comment "Execute SysPrep", for "LoadOptionTypeSysPrep"
> > type load options
> >
> > (1.3) for "LoadOptionTypePlatformRecovery" type load options.
> >
> > I figure the intended extension is for case (1.3), but the patch, as
> > proposed, will also affect (1.1) and (1.2); that is, when Driver and
> > SysPrep options are processes. That's beyond what the spec says, in
> > my opinion.
> >
> > Now, EfiBootManagerProcessLoadOption() takes a pointer to an
> > EFI_BOOT_MANAGER_LOAD_OPTION structure. This structure has a field
> > called OptionType (of type EFI_BOOT_MANAGER_LOAD_OPTION_TYPE). You might
> > want to restrict the signaling and the status code reporting to when
> > LoadOption->OptionType is either LoadOptionTypeBoot or
> > LoadOptionTypePlatformRecovery (i.e., exclude LoadOptionTypeDriver and
> > LoadOptionTypeSysPrep).
>
> In 

[edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Neal Gompa]

From: Neal Gompa 

Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, the introduction of Platform Recovery in UEFI 2.5 makes it
necessary to signal ReadyToBoot when a Platform Recovery boot loader
runs because otherwise it may lead to the execution of a boot loader
that has similar requirements to a regular one that is not launched
as a Boot Manager option.

This is especially critical to ensuring that the graphical console
is actually usable during platform recovery, as some platforms do
rely on the ConsolePrefDxe driver, which only performs console
initialization after ReadyToBoot is triggered.

This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
in EfiBootManagerProcessLoadOption () when invoking platform recovery,
which is the function that sets up the platform recovery boot process.

The expected behavior has been clarified in the UEFI 2.10 specification
to explicitly indicate this behavior is required for correct operation.

This is a rebased version of the patch originally written by Pete Batard.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831

Cc: Pete Batard 
Cc: Daniel P. Berrangé 
Cc: Gerd Hoffmann 
Cc: Samer El-Haj-Mahmoud 
Cc: Laszlo Ersek 

Co-authored-by: Pete Batard 
Signed-off-by: Neal Gompa 
---
 .../Library/UefiBootManagerLib/BmLoadOption.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 2087f0b91d..83a2f893e4 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1416,6 +1416,17 @@ EfiBootManagerProcessLoadOption (
 return EFI_SUCCESS;
   }
 
+  if (LoadOption->OptionType == LoadOptionTypePlatformRecovery) {
+//
+// Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+//
+EfiSignalEventReadyToBoot ();
+//
+// Report Status Code to indicate ReadyToBoot was signaled
+//
+REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+  }
+
   //
   // Load and start the load option.
   //
-- 
2.41.0



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

Re: [edk2-devel] CodeQL and Apache Licensed Files

[Laszlo Ersek]

On 10/31/23 17:07, Michael Kubacki wrote:
> On 10/28/2023 7:51 AM, Laszlo Ersek wrote:
>> On 10/27/23 23:11, Michael Kubacki wrote:
>>> I'd like to bring attention to Apache License 2.0 code in the CodeQL
>>> series I sent to the mailing list for steward review.
>>>
>>> In particular, the files in the BaseTools/Plugin/CodeQL/analyze
>>> directory of this patch:
>>>
>>> https://edk2.groups.io/g/devel/message/109696
>>>
>>> Please let me know if any next steps are needed.
>>
>> (1) I don't know if edk2 accepts contributions under Apache License 2.0;
>> just want to point out that this license is acceptable in Fedora (and so
>> RHEL too), per
>> . Assuming
>> we're talking about "Apache Software License 2.0".
>>
> A few submodules are using the Apache License 2.0.
> 
> For example, OpenSSL v3:
> 
> - https://www.openssl.org/source/license.html
> - https://git.openssl.org/?p=openssl.git;a=blob_plain;f=LICENSE.txt;hb=HEAD
> 
> And cmoocka:
> 
> - https://gitlab.com/cmocka/cmocka/-/blob/master/COPYING

Thanks for identifying those!

> 
> I'm unaware if there was precedent specific to submodules, but I'd
> expect terms like redistribution clauses to already apply regardless of
> tooling used to acquire the source code into the project.

I believe the same.

> 
>> (2) Should we extend "License Details" and "Code Contributions" in
>> "ReadMe.rst"?
>>
> My initial thought was to add the path (BaseTools\Plugin\CodeQL\analyze)
> to "License Details".
> 
> Was that all that you had in mind or to elaborate further in that
> section on the licenses used/allowed?

- Under "License Details", simply list BaseTools/Plugin/CodeQL/analyze
as one of the "components" (i.e., first list) that use a "additional
licenses".

- Under "Code Contributions", we should list "Apache Software License
2.0" as acceptable -- both for this new feature, and for the *already*
upstream stuff that you found above.

> 
>> (3) Should the new files (under Apache License 2.0) use an SPDX
>> identifier tag, for easy greppability?
>>
> I'd be happy to add that.

That's a relief, I didn't know whether you could touch up the license
blocks!

Thanks!
Laszlo

> 
>> (4) With the addition, downstream packages (such as RPMs in Fedora and
>> RHEL) might want to spell out the short SPDX identifier of the new
>> license too in their License: tags.
>>
>> Laszlo
>>
>>
>>
>> 
>>
> 



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

Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

[Laszlo Ersek]

On 10/31/23 10:56, duntan wrote:
> Hi Tom,
> Thanks for your testing and comments. I'll modify the patch commit
> message and code according to your comments.
> Yes the patch changes the behavior for IoReadFifo/ IoWriteFifo API for
> non-Tdx and non-SEV case. Looking forward to more comments from the
> community.
>
> Hi Laszlo,
> May I know the actually performance gap data in the case that you
> mentioned?

Good call to have me measure this.

I cannot reproduce the performance hit *at all* with the isa-debugcon
device (that is, through the OVMF debug log).

I built OVMF X64 with PcdDebugPrintErrorLevel set to 0x8040004F, at
commit a671a14e63fd. That was the baseline. I built both NOOPT and
DEBUG.

Then I repeated the same, with your patches applied.

I cannot show any human-perceptible boot time difference.

Note that the NOOPT comparison excludes LTO (i.e., compiler advances) as
the potential factor that might mask the impact of your patches. I also
disassembled some binaries producing debug output, and indeed, without
your patches, we have rep outsb in them, and with your patches, we
don't. Yet, there is no performance difference.

This is striking news.

I want to understand why we have thought thus far that individual IO
Port traps are extremely expensive. I've now found evidence going back
as far as 2012 -- the year when I joined edk2!

Here are some facts:


(1) in commit f1ec65ba24e1 ("OvmfPkg: Add QemuFwCfgLib library class and
implementation", 2012-05-30) -- note the date! --, Jordan added the
initial implementation of QemuFwCfgLib. That version already used an
open-coded IoReadFifo8 function.

There was no particular explanation captured in the commit message.

I also happen to have the entire 2012 edk2-devel mailing list traffic
saved locally (well, the messages posted after I joined), and the
discussions around the various versions of the patch in question don't
seem to specifically justify the REP variant. So, we cannot conclude
much from this piece of evidence.


(2) Then I decided to search that entire year's traffic (i.e., 2012's)
for the word "fifo". I found relevant hits:

- In commit 1fd376d97922 ("PcAtChipsetPkg/PciHostBridgeDxe: Improve KVM
  FIFO I/O read/write performance", 2012-06-01) -- note the year again!
  --, Jordan brought the FIFO variants to the
  EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation in edk2. The code was
  duplicated.

  Note that Jordan clearly stated in the commit message:

> KVM can substantially boost the speed of the rep insb/insw/insl
> and rep outsb/outsw/outsl instructions by transferring up to
> a page of data per VM trap.

- On the same day when Jordan posted the patch that would become
  above-noted commit 1fd376d97922, Jordan also asked on the list
  (subject "IoLib I/O FIFO read/write routines"):

> Regarding the routines now defined in 
> PcAtChipsetPkg/PciHostBridgeDxe/IoFifo.h.
> IoReadFifo8, IoReadFifo16, IoReadFifo32,
> IoWriteFifo8, IoWriteFifo16, and IoWriteFifo32
>
> Would it make sense to consider adding these to 
> MdePkg/Include/Library/IoLib.h?

  Again, this was still in 2012.

So here we can conclude that Jordan saw some specific perf boost due to
employing the FIFO variants in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL, but the
use case was not documented.


(3) During all this discussion here, I have been *distinctly* recalling
that I've experienced an *actual performance regression* sometime, after
we had unwittingly switched from the REP variant to the non-REP variant.

And now I have actually found it. I'm going to quote the commit message
in full:

> commit fb8b54694c53e73e1b6a098686e908f54f9bb7a9
> Author: Laszlo Ersek 
> Date:   Thu Apr 7 22:28:38 2016 +0200
>
> UefiCpuPkg: CpuIo2Dxe: optimize FIFO reads and writes of IO ports
>
> * Short description:
>
>   The CpuIoServiceRead() and CpuIoServiceWrite() functions transfer data
>   between memory and IO ports with individual Io(Read|Write)(8|16|32)
>   function calls, each in an appropriately set up loop.
>
>   On the Ia32 and X64 platforms however, FIFO reads and writes can be
>   optimized, by coding them in assembly, and delegating the loop to the
>   CPU, with the REP prefix.
>
>   On KVM virtualization hosts, this difference has a huge performance
>   impact: if the loop is open-coded, then the virtual machine traps to the
>   hypervisor on every single UINT8 / UINT16 / UINT32 transfer, whereas
>   with the REP prefix, KVM can transfer up to a page of data per VM trap.
>   This is especially noticeable with IDE PIO transfers, where all the data
>   are squeezed through IO ports.
>
> * Long description:
>
>   The RootBridgeIoIoRW() function in
>
> PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c
>
>   used to have the exact same IO port acces optimization, dating back
>   verbatim to commit 1fd376d9792:
>
> PcAtChipsetPkg/PciHostBridgeDxe: Improve KVM FIFO I/O read/write
>   performance
>
> 

Re: [edk2-devel] [PATCH v7 5/5] OvmfPkg/RiscVVirt: Override for RV CPU Features

[Andrei Warkentin]

I think I misunderstood the intent. Reviewing the full patchset, it seems this 
is necessary to avoid using the new CMO path in the Virt platform (since the 
default value is all FFs). Shouldn’t the default Pcd value here be all 0’s – 
i.e. CMO or any other feature use becomes “opt in” instead of “opt out”?

It also seems that encoding the meaning inside the bit positions is a bit… 
obscure. Have you considered storing a pointer to a struct with bitfields 
instead? You could then change the logic to be something like “If PcdPtrValue 
!= NULL && ((struct cast *) PcdPtrValue)->LegibleFieldName”. I think this would 
do wonders for code maintainability. The cost of course is in having to 
initialize the Pcd now at runtime, and the additional dereference, but that 
seems like a low cost all things considered.

From: Dhaval Sharma 
Sent: Tuesday, October 31, 2023 1:13 AM
To: Warkentin, Andrei ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v7 5/5] OvmfPkg/RiscVVirt: Override for RV CPU 
Features

Thanks. This PCD is for Virt platform only. Or maybe I am missing the point.


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

[edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Non-zero start/stop values in XhcGetElapsedTicks

[Henz, Patrick]

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

The implementation of XhcGetElapsedTicks did not account for
non-zero start and stop values for the performance counter
timer, potentially resulting in an incorrect elapsed tick
count getting returned to the caller. Account for non-zero
start and stop values when calculating the elapsed tick
count.

Cc: Hao A Wu 
Cc: Ray Ni 
Signed-off-by: Patrick Henz 
Reviewed-by:
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 7a2e32a9dd..6cb97b7452 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -2389,7 +2389,7 @@ XhcGetElapsedTicks (
 // Counter counts upwards, check for an overflow condition
 //
 if (*PreviousTick > CurrentTick) {
-  Delta = (mPerformanceCounterEndValue - *PreviousTick) + CurrentTick;
+  Delta = (CurrentTick - mPerformanceCounterStartValue) + 
(mPerformanceCounterEndValue - *PreviousTick);
 } else {
   Delta = CurrentTick - *PreviousTick;
 }
@@ -2398,7 +2398,7 @@ XhcGetElapsedTicks (
 // Counter counts downwards, check for an underflow condition
 //
 if (*PreviousTick < CurrentTick) {
-  Delta = (mPerformanceCounterStartValue - CurrentTick) + *PreviousTick;
+  Delta = (mPerformanceCounterStartValue - CurrentTick) + (*PreviousTick - 
mPerformanceCounterEndValue);
 } else {
   Delta = *PreviousTick - CurrentTick;
 }
-- 
2.34.1



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

Re: [edk2-devel] CodeQL and Apache Licensed Files

[Michael Kubacki]

On 10/28/2023 7:51 AM, Laszlo Ersek wrote:

On 10/27/23 23:11, Michael Kubacki wrote:

I'd like to bring attention to Apache License 2.0 code in the CodeQL
series I sent to the mailing list for steward review.

In particular, the files in the BaseTools/Plugin/CodeQL/analyze
directory of this patch:

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

Please let me know if any next steps are needed.


(1) I don't know if edk2 accepts contributions under Apache License 2.0;
just want to point out that this license is acceptable in Fedora (and so
RHEL too), per
. Assuming
we're talking about "Apache Software License 2.0".


A few submodules are using the Apache License 2.0.

For example, OpenSSL v3:

- https://www.openssl.org/source/license.html
- https://git.openssl.org/?p=openssl.git;a=blob_plain;f=LICENSE.txt;hb=HEAD

And cmoocka:

- https://gitlab.com/cmocka/cmocka/-/blob/master/COPYING

I'm unaware if there was precedent specific to submodules, but I'd 
expect terms like redistribution clauses to already apply regardless of 
tooling used to acquire the source code into the project.



(2) Should we extend "License Details" and "Code Contributions" in
"ReadMe.rst"?

My initial thought was to add the path (BaseTools\Plugin\CodeQL\analyze) 
to "License Details".


Was that all that you had in mind or to elaborate further in that 
section on the licenses used/allowed?



(3) Should the new files (under Apache License 2.0) use an SPDX
identifier tag, for easy greppability?


I'd be happy to add that.


(4) With the addition, downstream packages (such as RPMs in Fedora and
RHEL) might want to spell out the short SPDX identifier of the new
license too in their License: tags.

Laszlo








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

Re: [edk2-devel] [PATCH] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in AMD MmSaveStateLib

[Laszlo Ersek]

On 10/31/23 11:43, Attar, AbdulLateef (Abdul Lateef) via groups.io wrote:
> [Public]
> 
> Hi Laszlo and @Lin, Jacque
> Please find my response inline.
> Thanks
> AbduL
> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, October 30, 2023 7:34 PM
> To: devel@edk2.groups.io; Lin, Jacque 
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Chang, 
> Abner ; Gerd Hoffmann ; Paolo Bonzini 
> 
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/MmSaveStateLib: Remove checking 
> Smm Rev ID in AMD MmSaveStateLib

> Are you saying that the
> 
>   SmmRevId < AMD_SMM_MIN_REV_ID_X64
> 
> check will always evaluate to FALSE, and so the "return EFI_NOT_FOUND"
> branch is dead code?
> [Attar, AbdulLateef (Abdul Lateef)] that's right it always evaluate to FALSE
> If that's the case, then the patch seems right, but *why* is SmmRevId always 
> greater than or equal to AMD_SMM_MIN_REV_ID_X64?
> [Attar, AbdulLateef (Abdul Lateef)] as per AMD64 Programmer's manual 10.2.4 
> SMM-Revision Identifier.
> First 16bit contains the version, which 0x64 for 64bit architecture.
> Bit 16 and bit 17 always set 1.
> Hence SmmRevId is always equal to AMD_SMM_MIN_REV_ID_X64.

That may apply to physical hardware platforms, but does not apply to
QEMU/KVM, and this library instance is also used in OVMF (on QEMU/KVM),
since commit commit f2188fe5d155 ("OvmfPkg: Uses MmSaveStateLib
library", 2023-07-03).

Therefore, whatever you do in this library instance, must consider the
impact on OVMF on QEMU/KVM.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110432): https://edk2.groups.io/g/devel/message/110432
Mute This Topic: https://groups.io/mt/102269908/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 v7 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Laszlo Ersek]

On 10/31/23 10:55, Dhaval Sharma wrote:
> I am posting an update on behalf of Jingyu as he had trouble with
> posting.

... that should be rectified now



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110431): https://edk2.groups.io/g/devel/message/110431
Mute This Topic: https://groups.io/mt/102256466/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 v7 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Jingyu Li via groups.io]

> 
> Implement Cache Management Operations (CMO) defined by
> RISC-V spec https://github.com/riscv/riscv-CMOs.
> 
> Notes:
> 1. CMO only supports block based Operations. Meaning cache
> flush/invd/clean Operations are not available for the entire
> range. In that case we fallback on fence.i instructions.
> 2. Operations are implemented using Opcodes to make them compiler
> independent. binutils 2.39+ compilers support CMO instructions.
> 
> Test:
> 1. Ensured correct instructions are refelecting in asm
> 2. Not able to verify actual instruction in HW as Qemu ignores
> any actual cache operations.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Cc: Laszlo Ersek 
> 
> Signed-off-by: Dhaval Sharma 
> Reviewed-by: Laszlo Ersek 
> ---
> 

I verified this CMO framework on an actual HW platform.

SW:
edk2: https://github.com/rivosinc/edk2/tree/dev-rv-cmo-v7 branch: dev-rv-cmo-v7
edk2-platforms: https://github.com/sophgo/edk2-platforms branch: sg2042-dev

HW:
Milk-V Pioneer Box, a developer motherboard based on SG2042 with 64-Core T-HEAD 
C920.

Attention:
The T-HEAD C920 implemented its own CMO Extension and is different from the 
standard CMO Extension.

Test steps:
1. Modified the opcodes in RiscVasm.inc to accommodate the C920 CMO feature.
diff --git a/MdePkg/Include/RiscV64/RiscVasm.inc 
b/MdePkg/Include/RiscV64/RiscVasm.inc
index 29de735885..5df85fdb31 100644
--- a/MdePkg/Include/RiscV64/RiscVasm.inc
+++ b/MdePkg/Include/RiscV64/RiscVasm.inc
@@ -7,13 +7,13 @@
*/

.macro RISCVCMOFLUSH
-    .word 0x25200f
+    .long 0x0275000b^M
.endm

.macro RISCVCMOINVALIDATE
-    .word 0x05200f
+    .long 0x0265000b^M
.endm

.macro RISCVCMOCLEAN
-    .word 0x15200f
+    .long 0x0275000b^M
.endm

2. We enable the CMO during the PCIe devices with DMA access to the memory, 
just focus on the implementation of CpuFlushCpuDataCache based on the 
EFI_CPU_ARCH_PROTOCOL. Except for PCIe, in other words, except for the 
cpu->FlushDataCache, we do not use CMO. And the PCIe inbound only relates to 
datacache.clean and datacache.invalidate.
diff --git a/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c 
b/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
index 2af3b62234..cf50bc5f92 100644
--- a/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
@@ -9,6 +9,8 @@
**/

#include "CpuDxe.h"
+#include ^M
+#include ^M

//
// Global Variables
@@ -59,7 +61,7 @@ EFI_CPU_ARCH_PROTOCOL  gCpu = {
CpuGetTimerValue,
CpuSetMemoryAttributes,
1,                          // NumberOfTimers
-  4                           // DmaBufferAlignment
+  64                           // DmaBufferAlignment^M
};

//
@@ -90,6 +92,21 @@ CpuFlushCpuDataCache (
IN EFI_CPU_FLUSH_TYPE     FlushType
)
{
+  PatchPcdSet64 (PcdRiscVFeatureOverride, 0x1);^M
+  switch (FlushType) {^M
+    case EfiCpuFlushTypeWriteBack:^M
+      WriteBackDataCacheRange ((VOID *)(UINTN)Start, (UINTN)Length);^M
+      break;^M
+    case EfiCpuFlushTypeInvalidate:^M
+      InvalidateInstructionCacheRange ((VOID *)(UINTN)Start, (UINTN)Length);^M
+      break;^M
+    case EfiCpuFlushTypeWriteBackInvalidate:^M
+      WriteBackInvalidateDataCacheRange ((VOID *)(UINTN)Start, 
(UINTN)Length);^M
+      break;^M
+    default:^M
+      return EFI_INVALID_PARAMETER;^M
+  }^M
+^M
return EFI_SUCCESS;
}

diff --git a/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc 
b/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
index 51ff89678c..e2e44ad619 100644
--- a/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
+++ b/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
@@ -389,6 +389,7 @@

[PcdsPatchableInModule]
gSophgoSG2042PlatformPkgTokenSpaceGuid.PcdSG2042PhyAddrToVirAddr|0
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0


#
@@ -500,7 +501,7 @@
# RISC-V Core module
#
UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
-  Silicon/Sophgo/SG2042Pkg/Override/UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf
+  UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf

MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

diff --git a/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf 
b/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
index 844fc3eac0..9cbb1d3f65 100644
--- a/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
+++ b/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
@@ -77,7 +77,7 @@ INF  Silicon/Sophgo/SG2042Pkg/Drivers/SdHostDxe/SdHostDxe.inf

# RISC-V Core Drivers
INF  UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
-INF  
Silicon/Sophgo/SG2042Pkg/Override/UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf
+INF  UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf

INF  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
INF  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf

3. Now the PCIe devices are in work order on PioneerBox. The CMO instructions 
are executed as expected.
Reviewed-by: Jingyu Li 

Thanks,
Jingyu

Re: [edk2-devel] [PATCH] UefiCpuPkg: Correct file description for MpHandOff header file

[rahul . r . kumar]

Reviewed-by: Rahul R Kumar 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110427): https://edk2.groups.io/g/devel/message/110427
Mute This Topic: https://groups.io/mt/101813022/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] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in AMD MmSaveStateLib

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

[Public]

+Laszlo, +Gerd, +Paolo
PR:  https://github.com/tianocore/edk2/pull/4982

-Original Message-
From: Lin, Jacque 
Sent: Tuesday, October 31, 2023 11:07 AM
To: devel@edk2.groups.io
Cc: Lin, Jacque ; Attar, AbdulLateef (Abdul Lateef) 
; Chang, Abner 
Subject: [PATCH v2] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in 
AMD MmSaveStateLib

Remove checking SMM Rev ID in AMD Save State lib when reading Save State 
Register EFI_MM_SAVE_STATE_REGISTER_IO.
For AMD, it is not necessary to check SmmRevId when reading Save State Register 
EFI_MM_SAVE_STATE_REGISTER_IO.

Cc: Abdul Lateef Attar 
Cc: Abner Chang 
Signed-off-by: Jacque Lin 
---
 UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c 
b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
index 3315a6cc44..c4bf6ad4bb 100644
--- a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
+++ b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
@@ -102,7 +102,6 @@ MmSaveStateReadRegister (
   OUT VOID*Buffer   ) {-  UINT32 
SmmRevId;   EFI_MM_SAVE_STATE_IO_INFO  *IoInfo;   AMD_SMRAM_SAVE_STATE_MAP   
*CpuSaveState;   UINT8  DataWidth;@@ -124,18 +123,6 @@ 
MmSaveStateReadRegister (
// Check for special EFI_MM_SAVE_STATE_REGISTER_IO   if (Register == 
EFI_MM_SAVE_STATE_REGISTER_IO) {-//-// Get SMM Revision ID-//-
MmSaveStateReadRegisterByIndex (CpuIndex, 
AMD_MM_SAVE_STATE_REGISTER_SMMREVID_INDEX, sizeof (SmmRevId), );--
//-// See if the CPU supports the IOMisc register in the save state-//- 
   if (SmmRevId < AMD_SMM_MIN_REV_ID_X64) {-  return EFI_NOT_FOUND;-}-  
   // Check if IO Restart Dword [IO Trap] is valid or not using bit 1. if 
(!(CpuSaveState->x64.IO_DWord & 0x02u)) {   return EFI_NOT_FOUND;--
2.36.1.windows.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in AMD MmSaveStateLib

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

[Public]

Hi Laszlo and @Lin, Jacque
Please find my response inline.
Thanks
AbduL
-Original Message-
From: Laszlo Ersek 
Sent: Monday, October 30, 2023 7:34 PM
To: devel@edk2.groups.io; Lin, Jacque 
Cc: Attar, AbdulLateef (Abdul Lateef) ; Chang, Abner 
; Gerd Hoffmann ; Paolo Bonzini 

Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/MmSaveStateLib: Remove checking 
Smm Rev ID in AMD MmSaveStateLib

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


+Gerd, +Paolo

On 10/30/23 07:12, Jacque Lin via groups.io wrote:
> Remove checking SMM Rev ID in AMD Save State lib when reading Save
> State Register EFI_MM_SAVE_STATE_REGISTER_IO.
> For AMD, it is not necessary to check SmmRevId when reading Save State
> Register EFI_MM_SAVE_STATE_REGISTER_IO.
>
> Cc: Abdul Lateef Attar 
> Cc: Abner Chang 
> Signed-off-by: Jacque Lin 
> ---
>  UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c | 13 -
>  1 file changed, 13 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> index 3315a6cc44..c4bf6ad4bb 100644
> --- a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> +++ b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> @@ -102,7 +102,6 @@ MmSaveStateReadRegister (
>OUT VOID*Buffer
>
>)
>
>  {
>
> -  UINT32 SmmRevId;
>
>EFI_MM_SAVE_STATE_IO_INFO  *IoInfo;
>
>AMD_SMRAM_SAVE_STATE_MAP   *CpuSaveState;
>
>UINT8  DataWidth;
>
> @@ -124,18 +123,6 @@ MmSaveStateReadRegister (
>
>
>// Check for special EFI_MM_SAVE_STATE_REGISTER_IO
>
>if (Register == EFI_MM_SAVE_STATE_REGISTER_IO) {
>
> -//
>
> -// Get SMM Revision ID
>
> -//
>
> -MmSaveStateReadRegisterByIndex (CpuIndex, 
> AMD_MM_SAVE_STATE_REGISTER_SMMREVID_INDEX, sizeof (SmmRevId), );
>
> -
>
> -//
>
> -// See if the CPU supports the IOMisc register in the save state
>
> -//
>
> -if (SmmRevId < AMD_SMM_MIN_REV_ID_X64) {
>
> -  return EFI_NOT_FOUND;
>
> -}
>
> -
>
>  // Check if IO Restart Dword [IO Trap] is valid or not using bit 1.
>
>  if (!(CpuSaveState->x64.IO_DWord & 0x02u)) {
>
>return EFI_NOT_FOUND;
>

I still don't understand.

Are you saying that the

  SmmRevId < AMD_SMM_MIN_REV_ID_X64

check will always evaluate to FALSE, and so the "return EFI_NOT_FOUND"
branch is dead code?
[Attar, AbdulLateef (Abdul Lateef)] that's right it always evaluate to FALSE
If that's the case, then the patch seems right, but *why* is SmmRevId always 
greater than or equal to AMD_SMM_MIN_REV_ID_X64?
[Attar, AbdulLateef (Abdul Lateef)] as per AMD64 Programmer's manual 10.2.4 
SMM-Revision Identifier.
First 16bit contains the version, which 0x64 for 64bit architecture.
Bit 16 and bit 17 always set 1.
Hence SmmRevId is always equal to AMD_SMM_MIN_REV_ID_X64.

SmmRevId is used to tell apart x86 from x64 (i.e., to distinguish the two 
formats of the save state map). Is the intent of this patch to remove 32-bit 
(x86) support?
[Attar, AbdulLateef (Abdul Lateef)]  Nope, we are not removing the x86(32bit) 
support.
@Lin, Jacque can you modify the logic like below, so that we will honor 
x86(32bit).

if (MmSaveStateGetRegisterLma () == EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT) {
//
// Get SMM Revision ID
//
MmSaveStateReadRegisterByIndex (CpuIndex, 
AMD_MM_SAVE_STATE_REGISTER_SMMREVID_INDEX, sizeof (SmmRevId), );
if (SmmRevId < AMD_SMM_MIN_REV_ID_X64) {
  return EFI_NOT_FOUND;
}
}
That makes me uncomfortable, because it could break SMM support in
*IA32* OVMF. Note that commit f2188fe5d155 ("OvmfPkg: Uses MmSaveStateLib 
library", 2023-07-03) also updated "OvmfPkg/OvmfPkgIa32.dsc".

In fact, I'm worried that the conversion of OVMF to MmSaveStateLib may have 
been incorrect. Note that commit f2188fe5d155 removed the following comment 
from "OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c":

> //
> // No support for I/O restart
> //

Furthermore, commit f2188fe5d155 removed the following functions:
GetRegisterIndex(), ReadSaveStateRegisterByIndex(), 
SmmCpuFeaturesReadSaveStateRegister(),
SmmCpuFeaturesWriteSaveStateRegister().

In particular, the latter two functions contained comments and code
like:

>   //
>   // Check for special EFI_SMM_SAVE_STATE_REGISTER_IO
>   //
>   if (Register == EFI_SMM_SAVE_STATE_REGISTER_IO) {
> return EFI_NOT_FOUND;
>   }

and

>   //
>   // Writes to EFI_SMM_SAVE_STATE_REGISTER_IO are not supported
>   //
>   if (Register == EFI_SMM_SAVE_STATE_REGISTER_IO) {
> return EFI_NOT_FOUND;
>   }

All of these came from Paolo's original commit 4036b4e57cce ("OvmfPkg:
SmmCpuFeaturesLib: implement SMRAM state save map access", 2015-11-30).

Consider the following commits from Paolo (including 4036b4e57cce):

> commit 86d71589c1fdb099c04a0f9e548fe868a2fef266
> Author: Paolo Bonzini 
> Date:   Mon Nov 

Re: [edk2-devel] [PATCH] MdeModulePkg/DxeCore: Allow relocation of images with large address

[Laszlo Ersek]

On 10/31/23 14:42, Laszlo Ersek wrote:
> On 10/30/23 18:27, Jeff Brasen via groups.io wrote:
>> Anything else needed to get this merged would as the November stable release 
>> is coming up.
> 
> Queued via .

Commit aa8431822b7631659586247b1e50d21126f3cfcc.




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110426): https://edk2.groups.io/g/devel/message/110426
Mute This Topic: https://groups.io/mt/102280269/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] ArmVirtPkg/PlatformCI/ReadMe.md: Update contents

[Laszlo Ersek]

On 10/31/23 14:43, Laszlo Ersek wrote:
> On 10/31/23 13:23, Laszlo Ersek wrote:
>> On 10/31/23 00:09, Michael Kubacki wrote:
>>> From: Michael Kubacki 
>>>
>>> Since the code is most regularly tested in CI, distro/versioning
>>> details are updated to match the latest CI configuration.
>>>
>>> CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
>>> file's creation, but the code is actually built in a Fedora container
>>> so Fedora is mentioned as the primary build/test environment.
>>>
>>> Updates the following information:
>>>
>>> - Build OS: Fedora 37 Linux
>>> - Supported Configuration: Additional DSCs added
>>> - Python: 3.12.x
>>> - Packaging Tool: dnf instead of apt
>>> - Container Details: Added
>>> - Primary Build Example: QemuBuild.py instead of PlatformBuild.py
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Gerd Hoffmann 
>>> Cc: Julien Grall 
>>> Cc: Leif Lindholm 
>>> Cc: Sami Mujawar 
>>> Signed-off-by: Michael Kubacki 
>>> ---
>>>
>>> Notes:
>>> I don't use ArmVirtPkg that often. I was reviewing the
>>> file for the latest build instructions and realized it
>>> was quite out of date, leading to this patch.
>>> 
>>> The project is using Python 3.11.x right now, but a
>>> patch is going in the next day or so that has shown
>>> Python 3.12 will work:
>>> https://edk2.groups.io/g/devel/message/110323
>>> 
>>> So I went ahead and made the Python version in this
>>> patch mention 3.12.x.
>>>
>>>  ArmVirtPkg/PlatformCI/ReadMe.md | 53 +---
>>>  1 file changed, 34 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/ArmVirtPkg/PlatformCI/ReadMe.md 
>>> b/ArmVirtPkg/PlatformCI/ReadMe.md
>>> index ee8d8cd61e73..c0f2b2a43b3c 100644
>>> --- a/ArmVirtPkg/PlatformCI/ReadMe.md
>>> +++ b/ArmVirtPkg/PlatformCI/ReadMe.md
>>> @@ -5,28 +5,43 @@ to use the same Pytools based build infrastructure 
>>> locally.
>>>  
>>>  ## Supported Configuration Details
>>>  
>>> -This solution for building and running ArmVirtPkg has only been validated 
>>> with Ubuntu
>>> -18.04 and the GCC5 toolchain. Two different firmware builds are supported 
>>> and are
>>> -described below.
>>> +This solution for building and running ArmVirtPkg has been validated with 
>>> Fedora
>>> +37 Linux and the GCC5 toolchain. Two different firmware builds are 
>>> supported
>>> +and are described below.
>>
>> "Two different firmware builds" is now stale; we're listing 10.
>>
>> I'd suggest "The following different firmware builds".
>>
>> No need to repost just for that; I'm fine if it gets updated upon merge.
>>
>> Reviewed-by: Laszlo Ersek 
> 
> With the proposed update included:
> 
> Queued via .

Commit a6871b53599e2bf23bfa16adae638cc9a6f0755f.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110425): https://edk2.groups.io/g/devel/message/110425
Mute This Topic: https://groups.io/mt/102287336/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/4] ArmVirtPkg: Add varpolicy shell command

[Laszlo Ersek]

On 10/31/23 14:43, Laszlo Ersek wrote:
> On 10/30/23 23:36, Ard Biesheuvel wrote:
>> On Mon, 30 Oct 2023 at 21:31,  wrote:
>>>
>>> From: Michael Kubacki 
>>>
>>> Adds the varpolicy EFI shell command to all DSC files that
>>> currently include other dynamic shell commands from ShellPkg.
>>>
>>> This command allows variable policies to be dumped in the EFI
>>> shell for convenient auditing and debug.
>>>
>>> Use the command in the EFI shell as follows:
>>>
>>> - `"varpolicy"` dumps platform variables
>>> - `"varpolicy -?"` shows help text
>>> - `"varpolicy -b"` pages output as expected
>>> - `"varpolicy -s"` shows accurate variable statistic information
>>> - `"varpolicy -p"` shows accurate UEFI variable policy information
>>> - `"varpolicy-v -b"` dumps all information including variable data hex dump
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Gerd Hoffmann 
>>> Cc: Julien Grall 
>>> Cc: Laszlo Ersek 
>>> Cc: Leif Lindholm 
>>> Cc: Sami Mujawar 
>>> Signed-off-by: Michael Kubacki 
>>
>> Reviewed-by: Ard Biesheuvel 
> 
> Queued via .

merged as commit range
2e128302e608fbe2c03d1967dd7328bbdf07bab3~4..2e128302e608fbe2c03d1967dd7328bbdf07bab3



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

[Laszlo Ersek]

On 10/31/23 14:43, Laszlo Ersek wrote:
> On 10/30/23 20:07, Michael Kubacki wrote:
>> Reviewed-by: Michael Kubacki 
> 
> Queued via .

Commit 8e7462907050350f8a9ed54437a4441082180a9c.



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

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

[Laszlo Ersek]

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

Merged as commit 36812d6c3e0c4402ea90e20566ac80de634d210b.

Laszlo



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

Re: [edk2-devel] [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address Structure

[Laszlo Ersek]

On 10/31/23 14:42, Laszlo Ersek wrote:
> On 10/31/23 10:19, Jinlong Xu wrote:
>> Hi, Liming
>>
>> Could you please help merge the patch? This is a portion of PRM ACPI  6.5 
>> support feature.
> 
> Queued via .

Merged as commit 2426a356258f0f759eb0661e1f8c0196aac48123 via
.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110421): https://edk2.groups.io/g/devel/message/110421
Mute This Topic: https://groups.io/mt/102173814/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] ArmVirtPkg/PlatformCI/ReadMe.md: Update contents

[Michael Kubacki]

On 10/31/2023 8:23 AM, Laszlo Ersek wrote:

On 10/31/23 00:09, Michael Kubacki wrote:

From: Michael Kubacki 

Since the code is most regularly tested in CI, distro/versioning
details are updated to match the latest CI configuration.

CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
file's creation, but the code is actually built in a Fedora container
so Fedora is mentioned as the primary build/test environment.

Updates the following information:

- Build OS: Fedora 37 Linux
- Supported Configuration: Additional DSCs added
- Python: 3.12.x
- Packaging Tool: dnf instead of apt
- Container Details: Added
- Primary Build Example: QemuBuild.py instead of PlatformBuild.py

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Signed-off-by: Michael Kubacki 
---

Notes:
 I don't use ArmVirtPkg that often. I was reviewing the
 file for the latest build instructions and realized it
 was quite out of date, leading to this patch.
 
 The project is using Python 3.11.x right now, but a

 patch is going in the next day or so that has shown
 Python 3.12 will work:
 https://edk2.groups.io/g/devel/message/110323
 
 So I went ahead and made the Python version in this

 patch mention 3.12.x.

  ArmVirtPkg/PlatformCI/ReadMe.md | 53 +---
  1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/ArmVirtPkg/PlatformCI/ReadMe.md b/ArmVirtPkg/PlatformCI/ReadMe.md
index ee8d8cd61e73..c0f2b2a43b3c 100644
--- a/ArmVirtPkg/PlatformCI/ReadMe.md
+++ b/ArmVirtPkg/PlatformCI/ReadMe.md
@@ -5,28 +5,43 @@ to use the same Pytools based build infrastructure locally.
  
  ## Supported Configuration Details
  
-This solution for building and running ArmVirtPkg has only been validated with Ubuntu

-18.04 and the GCC5 toolchain. Two different firmware builds are supported and 
are
-described below.
+This solution for building and running ArmVirtPkg has been validated with 
Fedora
+37 Linux and the GCC5 toolchain. Two different firmware builds are supported
+and are described below.


"Two different firmware builds" is now stale; we're listing 10.

I'd suggest "The following different firmware builds".

No need to repost just for that; I'm fine if it gets updated upon merge.


Thanks for catching that and getting those changes merged.


Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

  
-| Configuration name  | Architecture   | DSC File |Additional Flags |

-| :-- | :- | :-   | :  
 |
-| AARCH64 | AARCH64| ArmVirtQemu.dsc  | None   
 |
-| ARM | ARM| ArmVirtQemu.dsc  | None   
 |
+| Configuration name  | Architecture   | DSC File   | 
Additional Flags |
+| :-- | :- | :- | 
:|
+| AARCH64 - KVM Cloud HV  | AARCH64| ArmVirtCloudHv.dsc | None 
|
+| ARM - KVM Cloud HV  | ARM| ArmVirtCloudHv.dsc | None 
|
+| AARCH64 - kvmtool   | AARCH64| ArmVirtKvmTool.dsc | None 
|
+| ARM - kvmtool   | ARM| ArmVirtKvmTool.dsc | None 
|
+| AARCH64 - QEMU  | AARCH64| ArmVirtQemu.dsc| None 
|
+| ARM - QEMU  | ARM| ArmVirtQemu.dsc| None 
|
+| AARCH64 - QEMU Kernel   | AARCH64| ArmVirtQemuKernel.dsc  | None 
|
+| ARM - QEMU Kernel   | ARM| ArmVirtQemuKernel.dsc  | None 
|
+| AARCH64 - Xen HV| AARCH64| ArmVirtXen.dsc | None 
|
+| ARM - Xen HV| ARM| ArmVirtXen.dsc | None 
|
  
  ## EDK2 Developer environment
  
-- [Python 3.8.x - Download & Install](https://www.python.org/downloads/)

+- [Python 3.12.x - Download & Install](https://www.python.org/downloads/)
  - [GIT - Download & Install](https://git-scm.com/download/)
  - [QEMU - Download, Install, and add to your 
path](https://www.qemu.org/download/)
  - [Edk2 Source](https://github.com/tianocore/edk2)
-- Additional packages found necessary for Ubuntu 18.04
-  - apt-get install gcc g++ make uuid-dev
+- Additional packages found necessary for Fedora Linux 37
+  - dnf install gcc g++ make libuuid-devel
  
  Note: edksetup, Submodule initialization and manual installation of NASM, iASL, or

  the required cross-compiler toolchains are **not** required, this is handled 
by the
  Pytools build system.
  
+The code is built in CI using a container. The latest Fedora Linux 37 container is

+available in this GitHub container registry feed
+[fedora-37-test](https://github.com/tianocore/containers/pkgs/container/containers%2Ffedora-37-test).
+
+The exact container version tested in CI is maintained in 

Re: [edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple definitions.

[Mike Maslenkin]

On Tue, Oct 31, 2023 at 3:56 PM Nickle Wang via groups.io
 wrote:
>
> There are two definitions for below functions in RedfishCrtLib.h. Create
> this change to remote duplicated functions.
> Function list: strcmp(), strncmp(), strncpy(), strcpy(), strcat(),
> strlen(), strchr(), strcasecmp(), strstr(), memcmp(), memset(),
> memcpy(), memchr(), memcmp() and memmove().
>
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> Cc: Nick Ramirez 
> Cc: Mike Maslenkin 
> Reviewed-by: Abner Chang 
> ---
>  RedfishPkg/Include/Library/RedfishCrtLib.h | 105 -
>  1 file changed, 105 deletions(-)
>
> diff --git a/RedfishPkg/Include/Library/RedfishCrtLib.h 
> b/RedfishPkg/Include/Library/RedfishCrtLib.h
> index 23c6acfca33e..ac6c5162ad6a 100644
> --- a/RedfishPkg/Include/Library/RedfishCrtLib.h
> +++ b/RedfishPkg/Include/Library/RedfishCrtLib.h
> @@ -172,20 +172,6 @@ free(
>void *
>);
>
> -void   *
> -memset (
> -  void *,
> -  int,
> -  size_t
> -  );
> -
> -int
> -memcmp  (
> -  const void *,
> -  const void *,
> -  size_t
> -  );
> -
>  int
>  isdigit (
>int
> @@ -216,47 +202,6 @@ isalnum (
>int
>);
>
> -void   *
> -memcpy (
> -  void *,
> -  const void *,
> -  size_t
> -  );
> -
> -void   *
> -memset (
> -  void *,
> -  int,
> -  size_t
> -  );
> -
> -void   *
> -memchr (
> -  const void *,
> -  int,
> -  size_t
> -  );
> -
> -int
> -memcmp  (
> -  const void *,
> -  const void *,
> -  size_t
> -  );
> -
> -void   *
> -memmove(
> -  void *,
> -  const void *,
> -  size_t
> -  );
> -
> -int
> -strcmp  (
> -  const char *,
> -  const char *
> -  );
> -
>  int
>  strncmp (
>const char *,
> @@ -264,35 +209,6 @@ strncmp (
>size_t
>);
>
> -char   *
> -strcpy (
> -  char *,
> -  const char *
> -  );
> -
> -size_t
> -strlen  (
> -  const char *
> -  );
> -
> -char   *
> -strcat (
> -  char *,
> -  const char *
> -  );
> -
> -char   *
> -strchr (
> -  const char *,
> -  int
> -  );
> -
> -int
> -strcasecmp  (
> -  const char *,
> -  const char *
> -  );
> -
>  int
>  strncasecmp (
>const char *,
> @@ -300,21 +216,6 @@ strncasecmp (
>size_t
>);
>
> -char   *
> -strncpy(
> -  char *,
> -  size_t,
> -  const char *,
> -  size_t
> -  );
> -
> -int
> -strncmp (
> -  const char *,
> -  const char *,
> -  size_t
> -  );
> -
>  char   *
>  strrchr(
>const char *,
> @@ -328,12 +229,6 @@ strtoul (
>int
>);
>
> -char *
> -strstr  (
> -  const char  *s1,
> -  const char  *s2
> -  );
> -
>  long
>  strtol  (
>const char *,
> --
> 2.17.1

Ack.
Looks good to me.


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

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

[Michael D Kinney]

Right. But if you break in with debugger, you can still skip over the jmp 
instruction and continue.

I agree XIP does not allow variable value to be updated, but we would never 
want to do that or all future dead loops in non XIP code would not loop.

Mike

From: Ni, Ray 
Sent: Tuesday, October 31, 2023 1:31 AM
To: Kinney, Michael D ; Andrew (EFI) Fish 
; edk2-devel-groups-io ; Rebecca Cran 
; Hernandez Miramontes, Jose Miguel 

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

Mike,
This is not friendly for XIP code. With XIP code, the global variable is not 
able to be updated as it sits in read-only SPI flash.

Thanks,
Ray

From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Tuesday, October 31, 2023 11:37 AM
To: Ni, Ray mailto:ray...@intel.com>>; Andrew (EFI) Fish 
mailto:af...@apple.com>>; edk2-devel-groups-io 
mailto:devel@edk2.groups.io>>; Rebecca Cran 
mailto:rebe...@bsdio.com>>; Hernandez Miramontes, Jose 
Miguel 
mailto:jose.miguel.hernandez.miramon...@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [edk2-devel] CpuDeadLoop() is optimized by compiler


Does using a static volatile global instead of a volatile local work?



Mike



From: Ni, Ray mailto:ray...@intel.com>>
Sent: Monday, October 30, 2023 7:52 PM
To: Andrew (EFI) Fish mailto:af...@apple.com>>; 
edk2-devel-groups-io mailto:devel@edk2.groups.io>>; 
Rebecca Cran mailto:rebe...@bsdio.com>>; Hernandez 
Miramontes, Jose Miguel 
mailto:jose.miguel.hernandez.miramon...@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler



It's been a while.



Is there any better solution? Can we go with assembly solution?



Thanks,

Ray



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



I don't think the atomic is going to help. The compiler honored the volatile by 
doing a read, but assumed it would never change due to scoping. As you can see 
in my example if the compiler thinks DeadLoopCount can be changed it will put 
the check back in and assume the function can return. So an assembly function 
that does nothing called IncreaseScope()

 would fix this issue too.





void IncreaseScope(int *ptr);





void CpuDeadLoopFix(void) {



volatile

int DeadLoopCount = 0;



while(DeadLoopCount ==

0) {



IncreaseScope();



}



}





void CpuDeadLoop(void) {



volatile

int DeadLoopCount = 0;



while(DeadLoopCount ==

0);



}





Gives us:





voltbl

SEGMENT



voltbl

ENDS



voltbl

SEGMENT



voltbl

ENDS





DeadLoopCount$ =

48



CpuDeadLoopFix PROC

; COMDAT



$LN12:



sub

rsp, 40

; 0028H



mov

DWORD PTR

DeadLoopCount$[rsp],

0



jmp

SHORT $LN10@CpuDeadLoo



$LL2@CpuDeadLoo:



lea

rcx, QWORD

PTR DeadLoopCount$[rsp]



call

IncreaseScope



$LN10@CpuDeadLoo:



mov

eax, DWORD

PTR DeadLoopCount$[rsp]



test

eax, eax



je

SHORT $LL2@CpuDeadLoo



add

rsp, 40

; 0028H



ret

0



CpuDeadLoopFix ENDP





DeadLoopCount$ =

8



CpuDeadLoop PROC

; COMDAT



mov

DWORD PTR

DeadLoopCount$[rsp],

0



$LL2@CpuDeadLoo:



mov

eax, DWORD

PTR DeadLoopCount$[rsp]



jmp

SHORT $LL2@CpuDeadLoo



CpuDeadLoop ENDP







Compiler 
Explorer

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

[Laszlo Ersek]

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

Queued via .



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

Re: [edk2-devel] [PATCH v1 1/1] ArmVirtPkg/PlatformCI/ReadMe.md: Update contents

[Laszlo Ersek]

On 10/31/23 13:23, Laszlo Ersek wrote:
> On 10/31/23 00:09, Michael Kubacki wrote:
>> From: Michael Kubacki 
>>
>> Since the code is most regularly tested in CI, distro/versioning
>> details are updated to match the latest CI configuration.
>>
>> CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
>> file's creation, but the code is actually built in a Fedora container
>> so Fedora is mentioned as the primary build/test environment.
>>
>> Updates the following information:
>>
>> - Build OS: Fedora 37 Linux
>> - Supported Configuration: Additional DSCs added
>> - Python: 3.12.x
>> - Packaging Tool: dnf instead of apt
>> - Container Details: Added
>> - Primary Build Example: QemuBuild.py instead of PlatformBuild.py
>>
>> Cc: Ard Biesheuvel 
>> Cc: Gerd Hoffmann 
>> Cc: Julien Grall 
>> Cc: Leif Lindholm 
>> Cc: Sami Mujawar 
>> Signed-off-by: Michael Kubacki 
>> ---
>>
>> Notes:
>> I don't use ArmVirtPkg that often. I was reviewing the
>> file for the latest build instructions and realized it
>> was quite out of date, leading to this patch.
>> 
>> The project is using Python 3.11.x right now, but a
>> patch is going in the next day or so that has shown
>> Python 3.12 will work:
>> https://edk2.groups.io/g/devel/message/110323
>> 
>> So I went ahead and made the Python version in this
>> patch mention 3.12.x.
>>
>>  ArmVirtPkg/PlatformCI/ReadMe.md | 53 +---
>>  1 file changed, 34 insertions(+), 19 deletions(-)
>>
>> diff --git a/ArmVirtPkg/PlatformCI/ReadMe.md 
>> b/ArmVirtPkg/PlatformCI/ReadMe.md
>> index ee8d8cd61e73..c0f2b2a43b3c 100644
>> --- a/ArmVirtPkg/PlatformCI/ReadMe.md
>> +++ b/ArmVirtPkg/PlatformCI/ReadMe.md
>> @@ -5,28 +5,43 @@ to use the same Pytools based build infrastructure locally.
>>  
>>  ## Supported Configuration Details
>>  
>> -This solution for building and running ArmVirtPkg has only been validated 
>> with Ubuntu
>> -18.04 and the GCC5 toolchain. Two different firmware builds are supported 
>> and are
>> -described below.
>> +This solution for building and running ArmVirtPkg has been validated with 
>> Fedora
>> +37 Linux and the GCC5 toolchain. Two different firmware builds are supported
>> +and are described below.
> 
> "Two different firmware builds" is now stale; we're listing 10.
> 
> I'd suggest "The following different firmware builds".
> 
> No need to repost just for that; I'm fine if it gets updated upon merge.
> 
> Reviewed-by: Laszlo Ersek 

With the proposed update included:

Queued via .



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110416): https://edk2.groups.io/g/devel/message/110416
Mute This Topic: https://groups.io/mt/102287336/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/4] ArmVirtPkg: Add varpolicy shell command

[Laszlo Ersek]

On 10/30/23 23:36, Ard Biesheuvel wrote:
> On Mon, 30 Oct 2023 at 21:31,  wrote:
>>
>> From: Michael Kubacki 
>>
>> Adds the varpolicy EFI shell command to all DSC files that
>> currently include other dynamic shell commands from ShellPkg.
>>
>> This command allows variable policies to be dumped in the EFI
>> shell for convenient auditing and debug.
>>
>> Use the command in the EFI shell as follows:
>>
>> - `"varpolicy"` dumps platform variables
>> - `"varpolicy -?"` shows help text
>> - `"varpolicy -b"` pages output as expected
>> - `"varpolicy -s"` shows accurate variable statistic information
>> - `"varpolicy -p"` shows accurate UEFI variable policy information
>> - `"varpolicy-v -b"` dumps all information including variable data hex dump
>>
>> Cc: Ard Biesheuvel 
>> Cc: Gerd Hoffmann 
>> Cc: Julien Grall 
>> Cc: Laszlo Ersek 
>> Cc: Leif Lindholm 
>> Cc: Sami Mujawar 
>> Signed-off-by: Michael Kubacki 
> 
> Reviewed-by: Ard Biesheuvel 

Queued via .



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

[Laszlo Ersek]

On 10/30/23 20:07, Michael Kubacki wrote:
> Reviewed-by: Michael Kubacki 

Queued via .



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

Re: [edk2-devel] [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address Structure

[Laszlo Ersek]

On 10/31/23 10:19, Jinlong Xu wrote:
> Hi, Liming
> 
> Could you please help merge the patch? This is a portion of PRM ACPI  6.5 
> support feature.

Queued via .



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110413): https://edk2.groups.io/g/devel/message/110413
Mute This Topic: https://groups.io/mt/102173814/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/DxeCore: Allow relocation of images with large address

[Laszlo Ersek]

On 10/30/23 18:27, Jeff Brasen via groups.io wrote:
> Anything else needed to get this merged would as the November stable release 
> is coming up.

Queued via .



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110412): https://edk2.groups.io/g/devel/message/110412
Mute This Topic: https://groups.io/mt/102280269/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/XhciDxe: Use Performance Timer for XHCI Timeouts

[Henz, Patrick]

That’s a great catch, thank you for bringing this to my attention Laszlo. Work 
is in progress.

Patrick Henz

-Original Message-
From: Laszlo Ersek  
Sent: Tuesday, October 31, 2023 7:16 AM
To: devel@edk2.groups.io; hao.a...@intel.com; Henz, Patrick 
; Michael Brown 
Cc: Kinney, Michael D ; Gao, Liming 

Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance Timer 
for XHCI Timeouts

On 10/31/23 02:41, Wu, Hao A wrote:
> (Add MdePkg maintainers for their feedbacks)
> 
> Sorry that I do not have strong opinion on this one.
> 
> Some of my thoughts are:
> * If you find the to-be-added APIs can be used in serveral places to reduce
>   repetative codes, then it will be worthwhile to add new library APIs.
> 
> * TimerLib has many instance implementations, my take is that many post-mem
>   instances use library level global variable to store information like timer
>   frequency to avoid calculating it every time.
>   For pre-mem instances, such caching is not feasible. I think it will be the
>   API consumer's responsibility to limit the usage of these APIs for 
> performance
>   consideration.
> 
> Best Regards,
> Hao Wu

Patrick, while at it: I've recently filed the bug

  potentially invalid elapsed tick count calculation from commit 43dcf453fc15 

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

and assigned it to you (given that that commit is yours). I proposed the 
solution in the bugzilla too; please check it out if you can find the time.

Thanks
Laszlo

> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Henz, 
>> Patrick
>> Sent: Tuesday, October 31, 2023 4:36 AM
>> To: Wu, Hao A ; devel@edk2.groups.io; Michael 
>> Brown 
>> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use 
>> Performance Timer for XHCI Timeouts
>>
>> My changes have been in for a little over a month now, I've been 
>> looking into updating the TimerLib API but I'm questioning if it 
>> still makes sense to go down that path.  The functions I had 
>> implemented, XhcGetElapsedTicks () and XhcConvertTimeToTicks (), now 
>> rely heavily on the use of global variables for caching return values 
>> from GetPerformanceCounterProperties. As-is these functions won't 
>> work for all instances of TimerLib, specifically if the instance is 
>> used before memory (RAM) is available. I could implement the 
>> functions as they originally were, but I wouldn't be able to replace 
>> the Xhc functions without adding additional parameters to said 
>> TimerLib functions (e.g. adding Frequency, StartValue, StopValue to 
>> ConvertTimeToTicks), which feels clunky to me. Would a new library 
>> make sense here? Something that sits between the driver and the TimerLib 
>> library? Or do we just leave things as they currently are?
>>
>> Thanks,
>> Patrick Henz
>>
>> -Original Message-
>> From: Wu, Hao A 
>> Sent: Thursday, August 10, 2023 8:43 PM
>> To: Henz, Patrick ; devel@edk2.groups.io; 
>> Michael Brown 
>> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use 
>> Performance Timer for XHCI Timeouts
>>
>> My personal preference is to do this as two steps.
>> Address the issue in XhciDxe first. Then add new TimerLib API to 
>> replace all driver/library internal implementations.
>>
>> Best Regards,
>> Hao Wu
>>
>>> -Original Message-
>>> From: Henz, Patrick 
>>> Sent: Friday, August 11, 2023 6:45 AM
>>> To: devel@edk2.groups.io; Wu, Hao A ; Michael 
>>> Brown 
>>> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use 
>>> Performance Timer for XHCI Timeouts
>>>
>>> I can certainly make that change.
>>>
>>> For what it's worth I have been working on adding the new function, 
>>> GetElapsedTicks, to the various implementations of TimerLib. I've 
>>> finished up testing, I would just need to clean up the commits for a 
>>> patch. Should I move forward with that, or would we rather I just 
>>> add XhcGetElapsedTime to XhciDxe for the time being?
>>>
>>> Thanks,
>>> Patrick Henz
>>>
>>> -Original Message-
>>> From: devel@edk2.groups.io  On Behalf Of Wu,
>> Hao
>>> A
>>> Sent: Sunday, July 30, 2023 9:57 PM
>>> To: devel@edk2.groups.io; Henz, Patrick ; 
>>> Michael Brown 
>>> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use 
>>> Performance Timer for XHCI Timeouts
>>>
>>> For the 2 occurrences of in XhcWaitOpRegBit & XhcExecTransfer:
>>>   TimeoutTime = XHC_MICROSECOND_TO_NANOSECOND (Timeout * 
>>> XHC_1_MILLISECOND); How about changing them to:
>>>   TimeoutTime = XHC_MICROSECOND_TO_NANOSECOND ((UINT64)
>> Timeout
>>> * XHC_1_MILLISECOND); to address possible overflow during "Timeout * 
>>> XHC_1_MILLISECOND"?
>>>
>>> For extending XhcGetElapsedTime as a TimerLib API, I am fine to put 
>>> it in XhciDxe at this moment.
>>> If package maintainers suggest to make it as a public library API, 
>>> my take is that this should be done in a separate commit.
>>>
>>> Best Regards,
>>> Hao Wu
>>>
 -Original Message-
 From: 

Re: [edk2-devel] [PATCH 6/7] OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files

[Ard Biesheuvel]

On Tue, 31 Oct 2023 at 13:30, Laszlo Ersek  wrote:
>
> On 10/30/23 15:36, Ard Biesheuvel wrote:
> > On Fri, 27 Oct 2023 at 07:43, duntan  wrote:
> >>
> >> Use BaseIoLibIntrinsic.inf in dsc files. The
> >> BaseIoLibIntrinsic supports Tdx and sev now.
> >> The BaseIoLibIntrinsicSev will be removed in
> >> the following patches.
> >>
> >> Signed-off-by: Dun Tan 
> >> Cc: Ard Biesheuvel 
> >> Cc: Jiewen Yao 
> >> Cc: Jordan Justen 
> >> Cc: Gerd Hoffmann 
> >> Cc: Ray Ni 
> >
> > Reviewed-by: Ard Biesheuvel 
>
> While I agree that this patch *in itself* is (quite obviously) formally
> correct, semantically it is wrong for OVMF; which is why I have NACKed
> the whole series; see .
>
> (Just highlighting it here too, lest it get lost in the review thread.)
>

Apologies, I missed that.


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

Re: [edk2-devel] [PATCH] RedfishPkg/RedfishCrtLib: remove multiple definitions.

[Nickle Wang via groups.io]

Thanks Mike! By following the logic, strlen() can be removed too. Version 3 
patch is here: https://edk2.groups.io/g/devel/message/110408 I removed memcmp, 
memmove, and strlen.

Regards,
Nickle

> -Original Message-
> From: Mike Maslenkin 
> Sent: Sunday, October 29, 2023 9:58 PM
> To: Nickle Wang 
> Cc: devel@edk2.groups.io; Abner Chang ; Igor
> Kulchytskyy ; Nick Ramirez 
> Subject: Re: [edk2-devel] [PATCH] RedfishPkg/RedfishCrtLib: remove multiple
> definitions.
> 
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Oct 25, 2023 at 3:40 PM Nickle Wang  wrote:
> >
> > > double declaration of 'strcpy' is still there.
> >
> > Thanks for catching this, Mike. Version 2 patch file was sent.
> >
> > Regards,
> > Nickle
> 
> Hello, Nickle
> 
> v2 is good enough, but it can be improved a bit.
> 
> Since the definitions in this header file have become clearer and simpler, It 
> now
> appears that memcmp and memmove declarations can also be removed.
> 
> The logic is that we don't need to declare function prototypes for those that 
> are
> overridden at the bottom of this header file.
> If there were such functions in the code, the linking process would fail, but 
> there
> should not be such functions, since their names are replaced by the 
> preprocessor
> according to the definitions.
> 
> Regards,
> Mike.


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

[edk2-devel] [PATCH v3] RedfishPkg/RedfishCrtLib: remove multiple definitions.

[Nickle Wang via groups.io]

There are two definitions for below functions in RedfishCrtLib.h. Create
this change to remote duplicated functions.
Function list: strcmp(), strncmp(), strncpy(), strcpy(), strcat(),
strlen(), strchr(), strcasecmp(), strstr(), memcmp(), memset(),
memcpy(), memchr(), memcmp() and memmove().

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
Cc: Mike Maslenkin 
Reviewed-by: Abner Chang 
---
 RedfishPkg/Include/Library/RedfishCrtLib.h | 105 -
 1 file changed, 105 deletions(-)

diff --git a/RedfishPkg/Include/Library/RedfishCrtLib.h 
b/RedfishPkg/Include/Library/RedfishCrtLib.h
index 23c6acfca33e..ac6c5162ad6a 100644
--- a/RedfishPkg/Include/Library/RedfishCrtLib.h
+++ b/RedfishPkg/Include/Library/RedfishCrtLib.h
@@ -172,20 +172,6 @@ free(
   void *
   );
 
-void   *
-memset (
-  void *,
-  int,
-  size_t
-  );
-
-int
-memcmp  (
-  const void *,
-  const void *,
-  size_t
-  );
-
 int
 isdigit (
   int
@@ -216,47 +202,6 @@ isalnum (
   int
   );
 
-void   *
-memcpy (
-  void *,
-  const void *,
-  size_t
-  );
-
-void   *
-memset (
-  void *,
-  int,
-  size_t
-  );
-
-void   *
-memchr (
-  const void *,
-  int,
-  size_t
-  );
-
-int
-memcmp  (
-  const void *,
-  const void *,
-  size_t
-  );
-
-void   *
-memmove(
-  void *,
-  const void *,
-  size_t
-  );
-
-int
-strcmp  (
-  const char *,
-  const char *
-  );
-
 int
 strncmp (
   const char *,
@@ -264,35 +209,6 @@ strncmp (
   size_t
   );
 
-char   *
-strcpy (
-  char *,
-  const char *
-  );
-
-size_t
-strlen  (
-  const char *
-  );
-
-char   *
-strcat (
-  char *,
-  const char *
-  );
-
-char   *
-strchr (
-  const char *,
-  int
-  );
-
-int
-strcasecmp  (
-  const char *,
-  const char *
-  );
-
 int
 strncasecmp (
   const char *,
@@ -300,21 +216,6 @@ strncasecmp (
   size_t
   );
 
-char   *
-strncpy(
-  char *,
-  size_t,
-  const char *,
-  size_t
-  );
-
-int
-strncmp (
-  const char *,
-  const char *,
-  size_t
-  );
-
 char   *
 strrchr(
   const char *,
@@ -328,12 +229,6 @@ strtoul (
   int
   );
 
-char *
-strstr  (
-  const char  *s1,
-  const char  *s2
-  );
-
 long
 strtol  (
   const char *,
-- 
2.17.1



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

Re: [edk2-devel] [PATCH 6/7] OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files

[Laszlo Ersek]

On 10/30/23 15:36, Ard Biesheuvel wrote:
> On Fri, 27 Oct 2023 at 07:43, duntan  wrote:
>>
>> Use BaseIoLibIntrinsic.inf in dsc files. The
>> BaseIoLibIntrinsic supports Tdx and sev now.
>> The BaseIoLibIntrinsicSev will be removed in
>> the following patches.
>>
>> Signed-off-by: Dun Tan 
>> Cc: Ard Biesheuvel 
>> Cc: Jiewen Yao 
>> Cc: Jordan Justen 
>> Cc: Gerd Hoffmann 
>> Cc: Ray Ni 
> 
> Reviewed-by: Ard Biesheuvel 

While I agree that this patch *in itself* is (quite obviously) formally
correct, semantically it is wrong for OVMF; which is why I have NACKed
the whole series; see .

(Just highlighting it here too, lest it get lost in the review thread.)

Thanks,
Laszlo

>> ---
>>  OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
>>  OvmfPkg/Bhyve/BhyveX64.dsc   | 2 +-
>>  OvmfPkg/CloudHv/CloudHvX64.dsc   | 2 +-
>>  OvmfPkg/IntelTdx/IntelTdxX64.dsc | 2 +-
>>  OvmfPkg/Microvm/MicrovmX64.dsc   | 2 +-
>>  OvmfPkg/OvmfPkgIa32.dsc  | 2 +-
>>  OvmfPkg/OvmfPkgIa32X64.dsc   | 2 +-
>>  OvmfPkg/OvmfPkgX64.dsc   | 2 +-
>>  OvmfPkg/OvmfXen.dsc  | 2 +-
>>  9 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
>> index 302c90e7c2..06086e0cc5 100644
>> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
>> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
>> @@ -142,7 +142,7 @@
>>
>> PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
>>PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
>>CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
>> -  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>> +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
>>
>> OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
>>SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
>>MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
>> diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
>> index 6693342c5f..1376dd7468 100644
>> --- a/OvmfPkg/Bhyve/BhyveX64.dsc
>> +++ b/OvmfPkg/Bhyve/BhyveX64.dsc
>> @@ -149,7 +149,7 @@
>>
>> PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
>>PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
>>CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
>> -  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>> +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
>>
>> OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
>>SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
>>MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
>> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
>> index 35942e02df..1d2a13dd92 100644
>> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
>> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
>> @@ -159,7 +159,7 @@
>>
>> PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
>>PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
>>CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
>> -  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>> +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
>>
>> OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
>>SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
>>MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
>> diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc 
>> b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
>> index 182ec3705d..6623196c8b 100644
>> --- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
>> +++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
>> @@ -146,7 +146,7 @@
>>
>> PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
>>PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
>>CcProbeLib|OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.inf
>> -  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
>> +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
>>
>> OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
>>SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
>>MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
>> diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
>> index 0f26f2a9a9..c76a135f9e 100644
>> --- a/OvmfPkg/Microvm/MicrovmX64.dsc
>> +++ b/OvmfPkg/Microvm/MicrovmX64.dsc
>> @@ -157,7 +157,7 @@
>>
>> PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
>>PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
>>CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
>> -  

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

[Leif Lindholm]

On Sat, Oct 28, 2023 at 12:23:30 -0700, Michael D Kinney wrote:
> Over the past few months, all the of the Maintainers and
> Reviewers listed in Maintainers.txt have been contacted to make
> sure Maintainers.txt accurately represents the TianoCore
> community members that are actively participating in their
> roles.  Based on specific feedback, bounced emails, and no
> responses, updates have been made.
> 
> * RISCV64: Daniel Schaefer replaced with Andrei Warkentin
> * ArmVirtPkg Xen has no remaining reviewers and review
>   responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
> * ACPI modules related to S3 has no remaining reviewers and
>   review responsibility defaults to MdeModulePkg Maintainers/
>   Reviewers.
> * OVMF CSM modules has no remaining reviewers and review
>   responsibility defaults to OvmfPkg Maintainers/Reviewers.
> * Bounce: Chan Laura 
> * Many smaller updates removing individuals that are no
>   longer involved or have replacement coverage.
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Andrei Warkentin 
> Cc: Catharine West 
> Cc: Dandan Bi 
> Cc: Daniel Schaefer 
> Cc: David Woodhouse 
> Cc: Debkumar De 
> Cc: Eric Dong 
> Cc: Guomin Jiang 
> Cc: Hao A Wu 
> Cc: James Bottomley 
> Cc: Jian J Wang 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Peter Grehan 
> Cc: Qi Zhang 
> Cc: Ray Han Lim Ng 
> Cc: Stefan Berger 
> Cc: Wenxing Hou 
> Cc: Xiaoyu Lu 
> Signed-off-by: Michael D Kinney 

Reviewed-by: Leif Lindholm 

(I have some comments for later in the thread, but they do not affect
this patch.)

/
Leif

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

Re: [edk2-devel] [PATCH v1 1/1] ArmVirtPkg/PlatformCI/ReadMe.md: Update contents

[Laszlo Ersek]

On 10/31/23 00:09, Michael Kubacki wrote:
> From: Michael Kubacki 
> 
> Since the code is most regularly tested in CI, distro/versioning
> details are updated to match the latest CI configuration.
> 
> CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
> file's creation, but the code is actually built in a Fedora container
> so Fedora is mentioned as the primary build/test environment.
> 
> Updates the following information:
> 
> - Build OS: Fedora 37 Linux
> - Supported Configuration: Additional DSCs added
> - Python: 3.12.x
> - Packaging Tool: dnf instead of apt
> - Container Details: Added
> - Primary Build Example: QemuBuild.py instead of PlatformBuild.py
> 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Julien Grall 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> I don't use ArmVirtPkg that often. I was reviewing the
> file for the latest build instructions and realized it
> was quite out of date, leading to this patch.
> 
> The project is using Python 3.11.x right now, but a
> patch is going in the next day or so that has shown
> Python 3.12 will work:
> https://edk2.groups.io/g/devel/message/110323
> 
> So I went ahead and made the Python version in this
> patch mention 3.12.x.
> 
>  ArmVirtPkg/PlatformCI/ReadMe.md | 53 +---
>  1 file changed, 34 insertions(+), 19 deletions(-)
> 
> diff --git a/ArmVirtPkg/PlatformCI/ReadMe.md b/ArmVirtPkg/PlatformCI/ReadMe.md
> index ee8d8cd61e73..c0f2b2a43b3c 100644
> --- a/ArmVirtPkg/PlatformCI/ReadMe.md
> +++ b/ArmVirtPkg/PlatformCI/ReadMe.md
> @@ -5,28 +5,43 @@ to use the same Pytools based build infrastructure locally.
>  
>  ## Supported Configuration Details
>  
> -This solution for building and running ArmVirtPkg has only been validated 
> with Ubuntu
> -18.04 and the GCC5 toolchain. Two different firmware builds are supported 
> and are
> -described below.
> +This solution for building and running ArmVirtPkg has been validated with 
> Fedora
> +37 Linux and the GCC5 toolchain. Two different firmware builds are supported
> +and are described below.

"Two different firmware builds" is now stale; we're listing 10.

I'd suggest "The following different firmware builds".

No need to repost just for that; I'm fine if it gets updated upon merge.

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

>  
> -| Configuration name  | Architecture   | DSC File 
> |Additional Flags |
> -| :-- | :- | :-   | :
>|
> -| AARCH64 | AARCH64| ArmVirtQemu.dsc  | None 
>|
> -| ARM | ARM| ArmVirtQemu.dsc  | None 
>|
> +| Configuration name  | Architecture   | DSC File   | 
> Additional Flags |
> +| :-- | :- | :- | 
> :|
> +| AARCH64 - KVM Cloud HV  | AARCH64| ArmVirtCloudHv.dsc | 
> None |
> +| ARM - KVM Cloud HV  | ARM| ArmVirtCloudHv.dsc | 
> None |
> +| AARCH64 - kvmtool   | AARCH64| ArmVirtKvmTool.dsc | 
> None |
> +| ARM - kvmtool   | ARM| ArmVirtKvmTool.dsc | 
> None |
> +| AARCH64 - QEMU  | AARCH64| ArmVirtQemu.dsc| 
> None |
> +| ARM - QEMU  | ARM| ArmVirtQemu.dsc| 
> None |
> +| AARCH64 - QEMU Kernel   | AARCH64| ArmVirtQemuKernel.dsc  | 
> None |
> +| ARM - QEMU Kernel   | ARM| ArmVirtQemuKernel.dsc  | 
> None |
> +| AARCH64 - Xen HV| AARCH64| ArmVirtXen.dsc | 
> None |
> +| ARM - Xen HV| ARM| ArmVirtXen.dsc | 
> None |
>  
>  ## EDK2 Developer environment
>  
> -- [Python 3.8.x - Download & Install](https://www.python.org/downloads/)
> +- [Python 3.12.x - Download & Install](https://www.python.org/downloads/)
>  - [GIT - Download & Install](https://git-scm.com/download/)
>  - [QEMU - Download, Install, and add to your 
> path](https://www.qemu.org/download/)
>  - [Edk2 Source](https://github.com/tianocore/edk2)
> -- Additional packages found necessary for Ubuntu 18.04
> -  - apt-get install gcc g++ make uuid-dev
> +- Additional packages found necessary for Fedora Linux 37
> +  - dnf install gcc g++ make libuuid-devel
>  
>  Note: edksetup, Submodule initialization and manual installation of NASM, 
> iASL, or
>  the required cross-compiler toolchains are **not** required, this is handled 
> by the
>  Pytools build system.
>  
> +The code is built in CI using a container. The latest Fedora Linux 37 
> container is
> +available in this GitHub container registry feed
> 

Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance Timer for XHCI Timeouts

[Laszlo Ersek]

On 10/31/23 02:41, Wu, Hao A wrote:
> (Add MdePkg maintainers for their feedbacks)
> 
> Sorry that I do not have strong opinion on this one.
> 
> Some of my thoughts are:
> * If you find the to-be-added APIs can be used in serveral places to reduce
>   repetative codes, then it will be worthwhile to add new library APIs.
> 
> * TimerLib has many instance implementations, my take is that many post-mem
>   instances use library level global variable to store information like timer
>   frequency to avoid calculating it every time.
>   For pre-mem instances, such caching is not feasible. I think it will be the
>   API consumer's responsibility to limit the usage of these APIs for 
> performance
>   consideration.
> 
> Best Regards,
> Hao Wu

Patrick, while at it: I've recently filed the bug

  potentially invalid elapsed tick count calculation from commit 43dcf453fc15 

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

and assigned it to you (given that that commit is yours). I proposed the 
solution in the bugzilla too; please check it out if you can find the time.

Thanks
Laszlo

> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Henz,
>> Patrick
>> Sent: Tuesday, October 31, 2023 4:36 AM
>> To: Wu, Hao A ; devel@edk2.groups.io; Michael Brown
>> 
>> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance
>> Timer for XHCI Timeouts
>>
>> My changes have been in for a little over a month now, I've been looking into
>> updating the TimerLib API but I'm questioning if it still makes sense to go 
>> down
>> that path.  The functions I had implemented, XhcGetElapsedTicks () and
>> XhcConvertTimeToTicks (), now rely heavily on the use of global variables for
>> caching return values from GetPerformanceCounterProperties. As-is these
>> functions won't work for all instances of TimerLib, specifically if the 
>> instance is
>> used before memory (RAM) is available. I could implement the functions as
>> they originally were, but I wouldn't be able to replace the Xhc functions
>> without adding additional parameters to said TimerLib functions (e.g. adding
>> Frequency, StartValue, StopValue to ConvertTimeToTicks), which feels clunky
>> to me. Would a new library make sense here? Something that sits between
>> the driver and the TimerLib library? Or do we just leave things as they
>> currently are?
>>
>> Thanks,
>> Patrick Henz
>>
>> -Original Message-
>> From: Wu, Hao A 
>> Sent: Thursday, August 10, 2023 8:43 PM
>> To: Henz, Patrick ; devel@edk2.groups.io; Michael
>> Brown 
>> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance
>> Timer for XHCI Timeouts
>>
>> My personal preference is to do this as two steps.
>> Address the issue in XhciDxe first. Then add new TimerLib API to replace all
>> driver/library internal implementations.
>>
>> Best Regards,
>> Hao Wu
>>
>>> -Original Message-
>>> From: Henz, Patrick 
>>> Sent: Friday, August 11, 2023 6:45 AM
>>> To: devel@edk2.groups.io; Wu, Hao A ; Michael
>>> Brown 
>>> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use
>>> Performance Timer for XHCI Timeouts
>>>
>>> I can certainly make that change.
>>>
>>> For what it's worth I have been working on adding the new function,
>>> GetElapsedTicks, to the various implementations of TimerLib. I've
>>> finished up testing, I would just need to clean up the commits for a
>>> patch. Should I move forward with that, or would we rather I just add
>>> XhcGetElapsedTime to XhciDxe for the time being?
>>>
>>> Thanks,
>>> Patrick Henz
>>>
>>> -Original Message-
>>> From: devel@edk2.groups.io  On Behalf Of Wu,
>> Hao
>>> A
>>> Sent: Sunday, July 30, 2023 9:57 PM
>>> To: devel@edk2.groups.io; Henz, Patrick ;
>>> Michael Brown 
>>> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use
>>> Performance Timer for XHCI Timeouts
>>>
>>> For the 2 occurrences of in XhcWaitOpRegBit & XhcExecTransfer:
>>>   TimeoutTime = XHC_MICROSECOND_TO_NANOSECOND (Timeout *
>>> XHC_1_MILLISECOND); How about changing them to:
>>>   TimeoutTime = XHC_MICROSECOND_TO_NANOSECOND ((UINT64)
>> Timeout
>>> * XHC_1_MILLISECOND); to address possible overflow during "Timeout *
>>> XHC_1_MILLISECOND"?
>>>
>>> For extending XhcGetElapsedTime as a TimerLib API, I am fine to put it
>>> in XhciDxe at this moment.
>>> If package maintainers suggest to make it as a public library API, my
>>> take is that this should be done in a separate commit.
>>>
>>> Best Regards,
>>> Hao Wu
>>>
 -Original Message-
 From: devel@edk2.groups.io  On Behalf Of Henz,
 Patrick
 Sent: Thursday, July 6, 2023 4:16 AM
 To: devel@edk2.groups.io
 Cc: Henz, Patrick 
 Subject: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance
 Timer for XHCI Timeouts

 REF:INVALID URI REMOVED
 bu
 g.cgi?id=2948__;!!NpxR!kyFQM5IkKYAG9CRBO4xphwBnzi_jhb2oU-
>>> NKbMjOV-lctg5
 _B3K1Lcta452Gx-1twRt8At3cueAYDq_n$

 XhciDxe uses the timer 

Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance Timer for XHCI Timeouts

[Laszlo Ersek]

On 10/31/23 02:41, Wu, Hao A wrote:
> (Add MdePkg maintainers for their feedbacks)
> 
> Sorry that I do not have strong opinion on this one.
> 
> Some of my thoughts are:
> * If you find the to-be-added APIs can be used in serveral places to reduce
>   repetative codes, then it will be worthwhile to add new library APIs.
> 
> * TimerLib has many instance implementations, my take is that many post-mem
>   instances use library level global variable to store information like timer
>   frequency to avoid calculating it every time.
>   For pre-mem instances, such caching is not feasible. I think it will be the
>   API consumer's responsibility to limit the usage of these APIs for 
> performance
>   consideration.

I wouldn't recommend extending the TimerLib class. TimerLib has a huge
amount of instances (implementations), and adding the (effectively) same
calculation to each is a waste of developer effort, reviewer effort, and
long-term maintenance (lots of duplications).

Introducing a separate TimerTickDiffLib class is what I proposed in
2017. It can be small and simple; do one thing and do it well. It would
be widely used (*many* sites need tick differences). Yet keeping it
separate from TimerLib is absolutely justified, as TimerTickDiffLib
would be independent of both timer hardware specifics *and* of firmware
phase too (RAM or no RAM).

The functions -- or more likely, the single function -- in
TimerTickDiffLib can easily take the performance counter characteristics
as parameters. Then callers in RAM-based modules may pass those args
from global variables in which they cache the perf counter
characteristics themselves. No need to move the caching into a
particular (RAM-bound) TimerTickDiffLib instance. And callers that XIP
from flash can fill in those args from repeated / separate
GetPerformanceCounterProperties() calls, or -- in the luckier case --
cache the output of GetPerformanceCounterProperties() for each *call
site*, in local variables.

A futher API optimization may be to introduce a new (small) structure
type in TimerTickDiffLib, for collecting the outputs of
GetPerformanceCounterProperties(). Then the sole function in
TimerTickDiffLib would take a pointer to a *constant* structure of this
type.

Thanks
Laszlo

> 
> Best Regards,
> Hao Wu
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Henz,
>> Patrick
>> Sent: Tuesday, October 31, 2023 4:36 AM
>> To: Wu, Hao A ; devel@edk2.groups.io; Michael Brown
>> 
>> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance
>> Timer for XHCI Timeouts
>>
>> My changes have been in for a little over a month now, I've been looking into
>> updating the TimerLib API but I'm questioning if it still makes sense to go 
>> down
>> that path.  The functions I had implemented, XhcGetElapsedTicks () and
>> XhcConvertTimeToTicks (), now rely heavily on the use of global variables for
>> caching return values from GetPerformanceCounterProperties. As-is these
>> functions won't work for all instances of TimerLib, specifically if the 
>> instance is
>> used before memory (RAM) is available. I could implement the functions as
>> they originally were, but I wouldn't be able to replace the Xhc functions
>> without adding additional parameters to said TimerLib functions (e.g. adding
>> Frequency, StartValue, StopValue to ConvertTimeToTicks), which feels clunky
>> to me. Would a new library make sense here? Something that sits between
>> the driver and the TimerLib library? Or do we just leave things as they
>> currently are?
>>
>> Thanks,
>> Patrick Henz
>>
>> -Original Message-
>> From: Wu, Hao A 
>> Sent: Thursday, August 10, 2023 8:43 PM
>> To: Henz, Patrick ; devel@edk2.groups.io; Michael
>> Brown 
>> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use Performance
>> Timer for XHCI Timeouts
>>
>> My personal preference is to do this as two steps.
>> Address the issue in XhciDxe first. Then add new TimerLib API to replace all
>> driver/library internal implementations.
>>
>> Best Regards,
>> Hao Wu
>>
>>> -Original Message-
>>> From: Henz, Patrick 
>>> Sent: Friday, August 11, 2023 6:45 AM
>>> To: devel@edk2.groups.io; Wu, Hao A ; Michael
>>> Brown 
>>> Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Use
>>> Performance Timer for XHCI Timeouts
>>>
>>> I can certainly make that change.
>>>
>>> For what it's worth I have been working on adding the new function,
>>> GetElapsedTicks, to the various implementations of TimerLib. I've
>>> finished up testing, I would just need to clean up the commits for a
>>> patch. Should I move forward with that, or would we rather I just add
>>> XhcGetElapsedTime to XhciDxe for the time being?
>>>
>>> Thanks,
>>> Patrick Henz
>>>
>>> -Original Message-
>>> From: devel@edk2.groups.io  On Behalf Of Wu,
>> Hao
>>> A
>>> Sent: Sunday, July 30, 2023 9:57 PM
>>> To: devel@edk2.groups.io; Henz, Patrick ;
>>> Michael Brown 
>>> Subject: Re: [edk2-devel] [PATCH] 

Re: [edk2-devel] [PATCH v2] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in AMD MmSaveStateLib

[Paolo Bonzini]

On Tue, Oct 31, 2023 at 10:16 AM Attar, AbdulLateef (Abdul Lateef)
 wrote:
>
> [Public]
>
> +Laszlo, +Gerd, +Paolo
> PR:  https://github.com/tianocore/edk2/pull/4982

I left a comment in the PR.

The patch is only correct if this code is only ever used on 64-bit
processors. Note that KVM uses the legacy 32-bit format of the SMRAM
state save area, if the virtual machine is configured to clear the LM
bit of CPUID.

Second, the commit message does not explain why you are doing this.
Without such an explanation, it is impossible to provide more
constructive feedback.

Paolo

> -Original Message-
> From: Lin, Jacque 
> Sent: Tuesday, October 31, 2023 11:07 AM
> To: devel@edk2.groups.io
> Cc: Lin, Jacque ; Attar, AbdulLateef (Abdul Lateef) 
> ; Chang, Abner 
> Subject: [PATCH v2] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in 
> AMD MmSaveStateLib
>
> Remove checking SMM Rev ID in AMD Save State lib when reading Save State 
> Register EFI_MM_SAVE_STATE_REGISTER_IO.
> For AMD, it is not necessary to check SmmRevId when reading Save State 
> Register EFI_MM_SAVE_STATE_REGISTER_IO.
>
> Cc: Abdul Lateef Attar 
> Cc: Abner Chang 
> Signed-off-by: Jacque Lin 
> ---
>  UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c | 13 -
>  1 file changed, 13 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c 
> b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> index 3315a6cc44..c4bf6ad4bb 100644
> --- a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> +++ b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> @@ -102,7 +102,6 @@ MmSaveStateReadRegister (
>OUT VOID*Buffer   ) {-  UINT32 
> SmmRevId;   EFI_MM_SAVE_STATE_IO_INFO  *IoInfo;   AMD_SMRAM_SAVE_STATE_MAP   
> *CpuSaveState;   UINT8  DataWidth;@@ -124,18 +123,6 @@ 
> MmSaveStateReadRegister (
> // Check for special EFI_MM_SAVE_STATE_REGISTER_IO   if (Register == 
> EFI_MM_SAVE_STATE_REGISTER_IO) {-//-// Get SMM Revision ID-//-
> MmSaveStateReadRegisterByIndex (CpuIndex, 
> AMD_MM_SAVE_STATE_REGISTER_SMMREVID_INDEX, sizeof (SmmRevId), );--   
>  //-// See if the CPU supports the IOMisc register in the save state-
> //-if (SmmRevId < AMD_SMM_MIN_REV_ID_X64) {-  return EFI_NOT_FOUND;-  
>   }- // Check if IO Restart Dword [IO Trap] is valid or not using bit 1.  
>if (!(CpuSaveState->x64.IO_DWord & 0x02u)) {   return EFI_NOT_FOUND;--
> 2.36.1.windows.1
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110402): https://edk2.groups.io/g/devel/message/110402
Mute This Topic: https://groups.io/mt/102292190/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] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in AMD MmSaveStateLib

[Laszlo Ersek]

Hi,

On 10/31/23 10:15, Attar, AbdulLateef (Abdul Lateef) wrote:
> [Public]
> 
> +Laszlo, +Gerd, +Paolo
> PR:  https://github.com/tianocore/edk2/pull/4982

... My opinion, stated elsewhere in this thread in detail, is that this
patch is wrong, and should not be merged.

Laszlo

> 
> -Original Message-
> From: Lin, Jacque 
> Sent: Tuesday, October 31, 2023 11:07 AM
> To: devel@edk2.groups.io
> Cc: Lin, Jacque ; Attar, AbdulLateef (Abdul Lateef) 
> ; Chang, Abner 
> Subject: [PATCH v2] UefiCpuPkg/MmSaveStateLib: Remove checking Smm Rev ID in 
> AMD MmSaveStateLib
> 
> Remove checking SMM Rev ID in AMD Save State lib when reading Save State 
> Register EFI_MM_SAVE_STATE_REGISTER_IO.
> For AMD, it is not necessary to check SmmRevId when reading Save State 
> Register EFI_MM_SAVE_STATE_REGISTER_IO.
> 
> Cc: Abdul Lateef Attar 
> Cc: Abner Chang 
> Signed-off-by: Jacque Lin 
> ---
>  UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c 
> b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> index 3315a6cc44..c4bf6ad4bb 100644
> --- a/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> +++ b/UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveState.c
> @@ -102,7 +102,6 @@ MmSaveStateReadRegister (
>OUT VOID*Buffer   ) {-  UINT32 
> SmmRevId;   EFI_MM_SAVE_STATE_IO_INFO  *IoInfo;   AMD_SMRAM_SAVE_STATE_MAP   
> *CpuSaveState;   UINT8  DataWidth;@@ -124,18 +123,6 @@ 
> MmSaveStateReadRegister (
> // Check for special EFI_MM_SAVE_STATE_REGISTER_IO   if (Register == 
> EFI_MM_SAVE_STATE_REGISTER_IO) {-//-// Get SMM Revision ID-//-
> MmSaveStateReadRegisterByIndex (CpuIndex, 
> AMD_MM_SAVE_STATE_REGISTER_SMMREVID_INDEX, sizeof (SmmRevId), );--   
>  //-// See if the CPU supports the IOMisc register in the save state-
> //-if (SmmRevId < AMD_SMM_MIN_REV_ID_X64) {-  return EFI_NOT_FOUND;-  
>   }- // Check if IO Restart Dword [IO Trap] is valid or not using bit 1.  
>if (!(CpuSaveState->x64.IO_DWord & 0x02u)) {   return EFI_NOT_FOUND;--
> 2.36.1.windows.1
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110401): https://edk2.groups.io/g/devel/message/110401
Mute This Topic: https://groups.io/mt/102292190/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/Core: Fix potential memory leak issue

[Laszlo Ersek]

comment below

On 10/31/23 09:37, Xu, Wei6 wrote:
> Delete one my wrong comments.
>
> -Original Message-
> From: Xu, Wei6
> Sent: Tuesday, October 31, 2023 2:40 PM
> To: Laszlo Ersek ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Sami Mujawar 
> ; Ni, Ray 
> Subject: RE: [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential memory leak 
> issue
>
> Thanks a lot for reviewing the patch.
> I have different opinions with (2), could you please check that?
> Thanks a lot.
> If you agree (2) is not an issue, I will prepare a new patch version
> to only address (1) and (3)
>
> BR,
> Wei
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Monday, October 30, 2023 8:25 PM
>> To: Xu, Wei6 ; devel@edk2.groups.io
>> Cc: Ard Biesheuvel ; Sami Mujawar
>> ; Ni, Ray 
>> Subject: Re: [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential
>> memory leak issue
>>
>> On 10/30/23 08:49, Wei6 Xu wrote:
>>> In MmCoreFfsFindMmDriver(), ScratchBuffer is not freed in the error
>>> return path that DstBuffer page allocation fails. Free ScratchBuffer
>>> before return with error.
>>>
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Cc: Sami Mujawar 
>>> Cc: Ray Ni 
>>> Signed-off-by: Wei6 Xu 
>>> ---
>>>  StandaloneMmPkg/Core/FwVol.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/StandaloneMmPkg/Core/FwVol.c
>>> b/StandaloneMmPkg/Core/FwVol.c index e1e20ffd14ac..9d0ce66ef839
>> 100644
>>> --- a/StandaloneMmPkg/Core/FwVol.c
>>> +++ b/StandaloneMmPkg/Core/FwVol.c
>>> @@ -150,6 +150,7 @@ MmCoreFfsFindMmDriver (
>>>  //
>>>  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
>> (DstBufferSize));
>>>  if (DstBuffer == NULL) {
>>> +  FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES
>>> + (ScratchBufferSize));
>>>return EFI_OUT_OF_RESOURCES;
>>>  }
>>>
>>
>> This patch is good, with regard to ScratchBuffer:
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> However, upon further staring at the code, I think that we have a
>> DstBuffer life-cycle problem as well, independently of ScratchBuffer:
>>
>> (1) ExtractGuidedSectionDecode() does not necessarily use the caller-
>> allocated buffer. The library class header file
>> "MdePkg/Include/Library/ExtractGuidedSectionLib.h" says that, "If the
>> decoded buffer is identical to the data in InputSection, then
>> OutputBuffer is set to point at the data in InputSection.  Otherwise,
>> the decoded data will be placed in caller allocated buffer specified
>> by OutputBuffer."
>>
>> This means that the ExtractGuidedSectionDecode() call may change the
>> value of DstBuffer (rather than changing the contents of the buffer
>> that DstBuffer points at) -- in which case freeing DstBuffer is
>> wrong.
>>
>> This means we need a second variable. One variable needs to preserve
>> the allocation address, and the address of the other variable must be
>> passed to ExtractGuidedSectionDecode(). After the call, we need to
>> free the *original* variable (the one that
>> ExtractGuidedSectionDecode() could not have overwritten).
>>
>
> Will prepare a new patch version to address this.
>
>> (2) As far as I can tell, we leak our original DstBuffer allocation
>> in two cases:
>>
>> - Upon every iteration of the loop after the first iteration, we
>> overwrite the DstBuffer variable with the new allocation address. The
>> old one is lost (leaked).
>>
>> My understanding is that, after the recursive MmCoreFfsFindMmDriver()
>> call returns, we no longer need the decompressed DstBuffer,
>> therefore, we should free the *original* DstBuffer allocation (per
>> (1)) right there.
>>
>> - The last (potentially: only one) iteration of the loop allocates
>> DstBuffer, and that allocation is never freed. We don't overwrite the
>> address with a new allocation's address, but still we never free the
>> original allocation. The FreeDstBuffer label is apparently never
>> reached.
>>
>
> In the success case, DstBuffer should NOT be freed, because the buffer
> holds the MM drivers, which will be used in the driver dispatch
> process later.

Ouch, good point! MmAddToDriverList() only links the driver image into a
list ("mDiscoveredList").

Okay, but then we can still improve the code:

* if ExtractGuidedSectionDecode() reports that it did not use DstBuffer
  (i.e., it outputs a pointer pointing back into the input blob), then
  there is no reason to preserve the original allocation. Especially
  because the allocation is in MM RAM, which is a scarce resources.

* this is more like a question than a suggestion. Do you know if the
  drivers linked into "mDiscoveredList" execute "in place" (from the
  DstBuffer allocation(s)), or if they are never again needed when after
  the Standalone MM dispatches has actually loaded and launched them?
  Because in the latter case, it would be nice to release the original
  DstBuffer allocations; otherwise they just waste MM RAM. (Either way,
  I agree this is probably out of scope for now.)

* Consider the following comment, and global variable definition, 

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[Laszlo Ersek]

On 10/31/23 07:10, jacopo.r0...@gmail.com wrote:
> Hi Laszlo,
>
> If I generate the certificate like
>
> /openssl req -new -nodes -x509 -days 365 -keyout server.key -out
> server.crt -config config /
>
> it works perfectly fine (with the original configuration).
>
> The problem stands with the *chain* of certificates, meaning that I
> have a root certificate (let's call it A) and sign another one for an
> IP (let's call it B). Then in the image server with such IP I set the
> certificate B, and in the VM I trust the certificate A. Unless I
> missed something, this scenario is not covered in
> https://listman.redhat.com/archives/edk2-devel-archive/2019-October/009601.html
> 
> .
>
> Could you confirm this is supposed to work?

Absolutely.

The expectation is not to enroll the server certificate directly in
OVMF, but to enroll the CA certificate.

In the message you link above, the certificate generation script is
embedded. There is a section that generates the CA certificate:

> openssl req -x509 -nodes \
>   -subj   /CN="$CA_NAME" \
>   -out"$CA_NAME".crt \
>   -keyout "$TMP_CA_KEY"

and then there is a function that generates a CA-issued certificate:

> # Create a CA-issued certificate.
> # Parameters:
> # $1: Common Name
> # $2: IPv4 or IPv6 address literal, to be used in SAN; or empty string
> gencrt()
> {
>   local CN="$1"
>   local SANIP="$2"
>   local STEM
>   local EXT
>
>   if test -z "$SANIP"; then
> # File name stem consists of Common Name only. No certificate extensions.
> STEM=svr_$CN
> EXT=
>   else
> # File name stem includes Common Name and IP address literal.
> STEM=svr_${CN}_${SANIP}
>
> # SAN IP extension in the certificate. Rewrite the ad-hoc extensions file
> # with the current SAN IP.
> echo "subjectAltName=IP:$SANIP" >| "$TMP_EXT"
> EXT="-extfile $TMP_EXT"
>   fi
>   STEM=${STEM//[:.]/_}
>
>   # Generate CSR.
>   openssl req -new -nodes \
> -subj   /CN="$CN" \
> -out"$TMP_CSR" \
> -keyout "$STEM".key
>
>   # Sign the certificate request, potentially adding the SAN IP.
>   openssl x509 -req -CAcreateserial $EXT \
> -in   "$TMP_CSR" \
> -out  "$STEM".crt \
> -CA   "$CA_NAME".crt \
> -CAkey"$TMP_CA_KEY" \
> -CAserial "$TMP_CA_SRL"
> }

As you see, this function does generate a Certificate Signing Request,
and then signs it with the CA certificate.

Importantly, it's the CA certificate from the first step that is
supposed to be enrolled in OVMF, then.

... However, this actually makes me notice a difference, between your
commands and mine!

(1) In your setup, you add the Subject Alt Name IP Address when
generating the CSR (note "-config config"):

  openssl req \
-new \
-key myip.key \
-out myip.csr \
-config config<-- this here

and then sign the CSR

  openssl x509 \
-req \
-in myip.csr \
-CA rootCA.crt \
-CAkey rootCA.key \
-CAcreateserial \
-out myip.crt \
-days 500 \
-sha256

(2) Whereas in my setup, the Subject Alt Name IP Address is NOT added
when generating the CSR (note the lack of any "-config" option):

  openssl req \
-new \
-nodes \
-subj /CN="$CN" \
-out "$TMP_CSR" \
-keyout "$STEM".key

Instead it is added when the CA signs the CSR (see "-extfile $TMP_EXT"):

  openssl x509 \
-req \
-CAcreateserial \
-extfile $TMP_EXT \<- this here
-in "$TMP_CSR" \
-out "$STEM".crt \
-CA "$CA_NAME".crt \
-CAkey "$TMP_CA_KEY" \
-CAserial "$TMP_CA_SRL"


... Yes, I think that is exactly the problem on your end. Namely, I have
now done two things:

(a) I've re-run my script from the above link. From the output files,
I've picked the *server* certificate called
"svr_192_168_124_2_192_168_124_2.crt". This is the server certificate
that has the IP address in *both* the Common Name field, *and* in the
"Subject Alt Name IP Address" field. I've dumped this certificate to
text form:

$ openssl x509 -in svr_192_168_124_2_192_168_124_2.crt -text -noout

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1f:1a:ac:bf:ff:56:be:04:ff:fe:49:ff:e7:8b:9d:e6:0c:8d:63:dd
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TianoCore_BZ_960_CA
Validity
Not Before: Oct 31 10:57:30 2023 GMT
Not After : Nov 30 10:57:30 2023 GMT
Subject: CN = 192.168.124.2
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
[...]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
IP Address:192.168.124.2
X509v3 Subject Key Identifier:
2C:98:BC:EF:85:61:7F:05:42:8E:75:47:0B:66:80:4C:AD:3F:50:30

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Laszlo Ersek]

On 10/30/23 12:22, Sunil V L wrote:
> On Mon, Oct 30, 2023 at 04:48:18PM +0530, Sunil V L wrote:
>> On Sun, Oct 29, 2023 at 08:16:12PM +0530, Dhaval Sharma wrote:
>>> Use newly defined cache management operations for RISC-V where possible
>>> It builds up on the support added for RISC-V cache management
>>> instructions in BaseLib.
>>> Cc: Michael D Kinney 
>>> Cc: Liming Gao 
>>> Cc: Zhiguang Liu 
>>> Cc: Laszlo Ersek 
>>>
>>> Signed-off-by: Dhaval Sharma 
>>> Acked-by: Laszlo Ersek 
>>> ---
>>>
>>> Notes:
>>> V7:
>>> - Added PcdLib
>>> - Restructure DEBUG message based on feedback on V6
>>> - Make naming consistent to CMO, remove all CBO references
>>> - Add ASSERT for not supported functions instead of plain debug message
>>> - Added RB tag
>>> V6:
>>> - Utilize cache management instructions if HW supports it
>>>   This patch is part of restructuring on top of v5
>>>
>>>  MdePkg/MdePkg.dec  |   8 +
>>>  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
>>>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 168 
>>> +---
>>>  MdePkg/MdePkg.uni  |   4 +
>>>  4 files changed, 165 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>>> index ac54338089e8..fa92673ff633 100644
>>> --- a/MdePkg/MdePkg.dec
>>> +++ b/MdePkg/MdePkg.dec
>>> @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
>>> PcdsPatchableInModule.AARCH64]
>>># @Prompt CPU Rng algorithm's GUID.
>>>
>>> gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
>>>  
>>> +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
>>> +  #
>>> +  # Configurability to override RISC-V CPU Features
>>> +  # BIT 0 = Cache Management Operations. This bit is relevant only if
>>> +  # previous stage has feature enabled and user wants to disable it.
>> NIT: I am wondering whether PcdRiscVCpuFeatureDisable is better so that
>> it is explicit.
>>
>>> +  #
>>> +  
>>> gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
>>> +
>> Instead of this, can default value match only those features which are
>> enabled by default for qemu virt machine? That way, I think we can avoid
>> having this PCD defined again in RiscVVirt.
>>
> Sorry, I take back. This is common for all platforms. So, we can't take
> qemu as reference.

yes, and sorry that I'm only seeing your addition now!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110398): https://edk2.groups.io/g/devel/message/110398
Mute This Topic: https://groups.io/mt/102256468/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 v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Laszlo Ersek]

On 10/30/23 12:18, Sunil V L wrote:
> On Sun, Oct 29, 2023 at 08:16:12PM +0530, Dhaval Sharma wrote:
>> Use newly defined cache management operations for RISC-V where possible
>> It builds up on the support added for RISC-V cache management
>> instructions in BaseLib.
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Cc: Zhiguang Liu 
>> Cc: Laszlo Ersek 
>>
>> Signed-off-by: Dhaval Sharma 
>> Acked-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> V7:
>> - Added PcdLib
>> - Restructure DEBUG message based on feedback on V6
>> - Make naming consistent to CMO, remove all CBO references
>> - Add ASSERT for not supported functions instead of plain debug message
>> - Added RB tag
>> V6:
>> - Utilize cache management instructions if HW supports it
>>   This patch is part of restructuring on top of v5
>>
>>  MdePkg/MdePkg.dec  |   8 +
>>  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
>>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 168 
>> +---
>>  MdePkg/MdePkg.uni  |   4 +
>>  4 files changed, 165 insertions(+), 20 deletions(-)
>>
>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
>> index ac54338089e8..fa92673ff633 100644
>> --- a/MdePkg/MdePkg.dec
>> +++ b/MdePkg/MdePkg.dec
>> @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
>> PcdsPatchableInModule.AARCH64]
>># @Prompt CPU Rng algorithm's GUID.
>>
>> gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
>>  
>> +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
>> +  #
>> +  # Configurability to override RISC-V CPU Features
>> +  # BIT 0 = Cache Management Operations. This bit is relevant only if
>> +  # previous stage has feature enabled and user wants to disable it.
> NIT: I am wondering whether PcdRiscVCpuFeatureDisable is better so that
> it is explicit.
> 
>> +  #
>> +  
>> gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
>> +
> Instead of this, can default value match only those features which are
> enabled by default for qemu virt machine? That way, I think we can avoid
> having this PCD defined again in RiscVVirt.

I proposed the all-bits-one value.

First, PcdRiscVFeatureOverride is in MdePkg, which is much more general
than QEMU.

Second, the all-bits-one pattern means that the MdePkg.dec default does
not try to disable any features enabled by earlier components in the
boot process, *even such features* that it does not know about
specifically (i.e., those for which edk2 does not define a specific
feature bit).

IMO, for any "feature negotiation" bitmask, there are two choices:

- clear all bits except those that we know about (and know how to use),

- use all-bits-one.

The first option is good if unknown (future) features are expected to
*break* us.

The second option is good if we are unaffected by extra (future)
features, and we want to keep everything enabled for the runtime OS that
comes after us.

I understood that we had case #2 here.

If we have case#1 instead, then we should indeed limit the bitmask to
those features that *core edk2* knows about. But even in that case, I
think MdePkg.dec should be as permissive as possible, and any
QEMU-specific limitation should go into the OVMF DSC file.

> 
>>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>>## This value is used to set the base address of PCI express hierarchy.
>># @Prompt PCI Express Base Address.
>> diff --git 
>> a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf 
>> b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
>> index 6fd9cbe5f6c9..601a38d6c109 100644
>> --- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
>> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
>> @@ -56,3 +56,8 @@ [LibraryClasses]
>>BaseLib
>>DebugLib
>>  
>> +[LibraryClasses.RISCV64]
>> +  PcdLib
>> +
>> +[Pcd.RISCV64]
>> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
>> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
>> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
>> index 4eb18edb9aa7..5b3104afb67e 100644
>> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
>> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
>> @@ -2,6 +2,7 @@
>>RISC-V specific functionality for cache.
>>  
>>Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
>> reserved.
>> +  Copyright (c) 2023, Rivos Inc. All rights reserved.
>>  
>>SPDX-License-Identifier: BSD-2-Clause-Patent
>>  **/
>> @@ -9,10 +10,115 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +
>> +//
>> +// TODO: Grab cache block size and make Cache Management Operation
>> +// enabling decision based on RISC-V CPU 

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

[Laszlo Ersek]

On 10/31/23 02:41, mikub...@linux.microsoft.com wrote:
> From: Michael Kubacki 
> 
> Adds a GitHub workflow that uses the actions/stale GitHub action to
> automatically leave notifications on and close PRs that have had no
> activity for a long time.
> 
> Note: Modifications to a PR reset the staleness counter. This
>   includes pushing to the PR, adding a label to the PR,
>   commenting on the PR, etc.
> 
>   If a PR has been marked "stale", simply leaving a comment will
>   reset the counter.
> 
> Configuration choices:
> 
> 1. Do not attempt to close edk2 GitHub issues.
> 2. Mark edk2 PRs as stale if no activity in the last 60 days. Close
>PRs marked stale if no further activity in 7 days.
> 3. Do not exempt PRs with a "push" label.
> 4. Run the check once daily. Allow manual runs from those that have
>permission to run GitHub workflows.
> 5. Add the label "stale" to the PR when it enters the stale state.
> 
> Rationale:
> 
> 1. We do not use issues often enough. The limited usage of GitHub
>issues in Tianocore org GitHub projects are in another repo not
>impacted by this workflow and expected to track long term tasks.

I tend to disagree on this one; I generally consider the separate
Bugzilla installation superior to the github issue tracker, so I'd
prefer to disable the issue tracker altogether. :)

But I realize the project is moving in the opposite direction, so I
agree this choice is consistent with future goals.

> 2. This is the default value. In non-edk2 projects, I've seen these
>times work fairly well to identify PRs that have fallen stale.
> 3. Adding a "push" label resets the stale timer. If a PR has had a
>"push" label for 60+ days and has not been fixed for submission,
>then it is has very likely been abandoned.
> 4. This is sufficient to update PRs on the day granularity the
>configuration settings are applied against.
> 5. The label makes it easy to filter stale PRs in the PR list and
>write automation around PRs that are stale. It's also an obvious
>visual identifier that a PR needs attention in the PR list.
> 
> Cc: Sean Brogan 
> Cc: Michael Kubacki 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> I tested this workflow on my edk2 fork:
> 
> https://github.com/makubacki/edk2/actions/runs/6700887619
> 
> Here's an example of a PR it did not mark stale there:
> 
> https://github.com/makubacki/edk2/pull/136
> 
> Here's an example of a PR it did mark stale there:
> 
> https://github.com/makubacki/edk2/pull/4
> 
>  .github/workflows/stale.yml | 44 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
> new file mode 100644
> index ..b9160b548ab3
> --- /dev/null
> +++ b/.github/workflows/stale.yml
> @@ -0,0 +1,44 @@
> +# This workflow warns and then closes issues and PRs that have had no 
> activity
> +# for a specified amount of time.
> +#
> +# For more information, see:
> +# https://github.com/actions/stale
> +#
> +# Copyright (c) Microsoft Corporation.
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +
> +name: Stale Check
> +
> +on:
> +  schedule:
> +# At 23:35 on every day-of-week from Sunday through Saturday
> +# https://crontab.guru/#35_23_*_*_0-6
> +- cron: '35 23 * * 0-6'

What timezone? :)

(Not an objection, just pure curiosity.)

Thank you very much for handling this!

Acked-by: Laszlo Ersek 

Laszlo

> +  workflow_dispatch:
> +
> +jobs:
> +  stale:
> +name: Stale
> +runs-on: ubuntu-latest
> +permissions:
> +  issues: write
> +  pull-requests: write
> +
> +steps:
> +- name: Check for Stale Items
> +  uses: actions/stale@v8
> +  with:
> +days-before-issue-close: -1
> +days-before-issue-stale: -1
> +days-before-pr-stale: 60
> +days-before-pr-close: 7
> +stale-pr-message: >
> +  This PR has been automatically marked as stale because it has not 
> had
> +  activity in 60 days. It will be closed if no further activity 
> occurs within
> +  7 days. Thank you for your contributions.
> +close-pr-message: >
> +  This pull request has been automatically been closed because it 
> did not have any
> +  activity in 60 days and no follow up within 7 days after being 
> marked stale.
> +  Thank you for your contributions.
> +stale-pr-label: stale



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

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

[Laszlo Ersek]

On 10/28/23 21:23, Michael D Kinney wrote:
> Over the past few months, all the of the Maintainers and
> Reviewers listed in Maintainers.txt have been contacted to make
> sure Maintainers.txt accurately represents the TianoCore
> community members that are actively participating in their
> roles.  Based on specific feedback, bounced emails, and no
> responses, updates have been made.
> 
> * RISCV64: Daniel Schaefer replaced with Andrei Warkentin
> * ArmVirtPkg Xen has no remaining reviewers and review
>   responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
> * ACPI modules related to S3 has no remaining reviewers and
>   review responsibility defaults to MdeModulePkg Maintainers/
>   Reviewers.
> * OVMF CSM modules has no remaining reviewers and review
>   responsibility defaults to OvmfPkg Maintainers/Reviewers.
> * Bounce: Chan Laura 
> * Many smaller updates removing individuals that are no
>   longer involved or have replacement coverage.
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Andrei Warkentin 
> Cc: Catharine West 
> Cc: Dandan Bi 
> Cc: Daniel Schaefer 
> Cc: David Woodhouse 
> Cc: Debkumar De 
> Cc: Eric Dong 
> Cc: Guomin Jiang 
> Cc: Hao A Wu 
> Cc: James Bottomley 
> Cc: Jian J Wang 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Peter Grehan 
> Cc: Qi Zhang 
> Cc: Ray Han Lim Ng 
> Cc: Stefan Berger 
> Cc: Wenxing Hou 
> Cc: Xiaoyu Lu 
> Signed-off-by: Michael D Kinney 
> ---
>  Maintainers.txt | 53 ++---
>  1 file changed, 2 insertions(+), 51 deletions(-)

FWIW:

Reviewed-by: Laszlo Ersek 

Additionally, based on Mike's explanation down-thread, I'm proposing:

- a follow-up patch to Maintainers.txt where we remove the "Orphan"
status from the generic description,

- filing three separate BZs, for the removal of OvmfPkg/Csm/,
SignedCapsulePkg, and SourceLevelDebugPkg, respectively (where the
latter two could be moved to edk2-platforms),

- I'm happy to take on the OvmfPkg/Csm/ removal BZ.

Laszlo



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

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

[Laszlo Ersek]

On 10/30/23 23:18, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> I do not support orphaned categories and that option should be
> removed from Maintainer.txt. One of the motivations to get 
> Maintainers.txt updated is to work on the set of tasks related to 
> using GitHub PRs for code review.

I see. I didn't know. So, the mailing list based review process is going
away.

> If a component is orphaned,
> then nobody would be assigned to a PR in that area and the PR
> would be stuck and would eventually be deleted for no activity.
> A terrible experience for a submitter.

I agree, although just because a PR is auto-assigned to reviewers, tehre
is no guarantee that those reviewers will provide timely feedback.

(The current, long response times on the list may have two reasons; one,
reviewers missing patches (in spite of the direct CC's); two, reviewers
not acting on the patches they are aware of. Reviewing PRs on GitHub may
help with the former, but I'm doubtful it will help with the latter.
Anyway, I'm not trying to object to the workflow change.)

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

OK!

> If there is a future need for the feature and there are those that
> are willing to support it, it can always be resurrected from the
> history.
> 
> If it is a critical feature that will break the entire project 
> if it is removed, then we must find community members that are 
> willing to own it.
> 
> The immediate backup for this scenario is the EDK II Stewards, but
> They may not have the background on the specific feature to maintain
> it well.  For example, I am currently helping with the NetworkPkg
> because there are no maintainers and I have been recruiting without
> success.

It's unfortunate that NetworkPkg has no dedicated maintainer; UEFI
network boot (for example in OVMF guests) is certainly used in the industry.

I'll try to help out with patch reviews for NetworkPkg as well.

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

... or else SignedCapulsePkg could be moved to edk2-platforms.

(While I prefer to keep everything in one big tree, I agree that moving
SignedCapulsePkg to edk2-platforms would be consistent with past
subsystem movements.)

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

I'd even welcome that, as I see SOURCE_DEBUG_ENABLE an unnecessary (not
functional) complication in the OVMF DSC files.

OK, let us review the patch again from scratch, with these points in mind.

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

[duntan]

Hi Tom,
Thanks for your testing and comments. I'll modify the patch commit message and 
code according to your comments. 
Yes the patch changes the behavior for IoReadFifo/ IoWriteFifo API for non-Tdx 
and non-SEV case. Looking forward to more comments from the community.

Hi Laszlo,
May I know the actually performance gap data in the case that you mentioned? 
Also, if a DEBUG binary is used, I think the boot time impact might be 
acceptable?

Thanks,
Dun

-Original Message-
From: Laszlo Ersek  
Sent: Saturday, October 28, 2023 7:40 PM
To: devel@edk2.groups.io; thomas.lenda...@amd.com; Tan, Dun 
; leo.du...@amd.com; brijesh.si...@amd.com; Chang, Abner 
; michael.r...@amd.com; Attar, AbdulLateef (Abdul Lateef) 

Cc: Ni, Ray ; Yao, Jiewen 
Subject: Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic 
and remove BaseIoLibIntrinsicSev

On 10/27/23 23:31, Lendacky, Thomas via groups.io wrote:
> On 10/27/23 03:05, Tan, Dun wrote:
>> Hi all,
>>
>> Could you please help to review this patch set? In this patch set, 
>> the IoLib instance BaseIoLibIntrinsic is modified to support AMD SEV 
>> feature and the BaseIoLibIntrinsicSev is removed.
>> Also could you help to do a test on AMD processor to make sure that 
>> the SEV feature still works good with this patch set?
> 
> I was able to test SEV, SEV-ES and SEV-SNP guests successfully at each 
> step of the patchset.
> 
> However, you are unrolling the string I/O for everyone, now, not just 
> SEV guests. Is that acceptable to the community?

Thank you for making this comment, Tom, because this is exactly what I meant to 
raise immediately, upon reading the cover letter.

No, it is not acceptable.

The FIFO variants exist for a reason. When the guest performs multiple 
individual IO Port accesses, those translate to individual traps to the 
hypervisor, with significant performance impact. When IO Port string operations 
are used instead, with the REP prefix, then there is just
*one* trap, and the hypervisor can perform the whole "string" transfer in one 
go (up to a page size, anyways, IIRC). This has very visible impact on OVMF 
debug output (via the isa-debugcon QEMU device), and/or in case fw_cfg is used 
without DMA support.

(If you search OvmfPkg for IoReadFifo8 and IoWriteFifo8, you'll find the 
QemuFwCfgLib and PlatformDebugLibIoPort libraries using them.)

In fact, during initial SEV enablement, the SEV enlightenment was introduced 
because SEV does not handle the REP prefix with these instructions, and so a 
fallback had to be added.

See commits b6d11d7c4678 ("MdePkg: BaseIoLibIntrinsic (IoLib class) library", 
2017-04-13) and 97353a9c914d ("OvmfPkg: Update dsc to use IoLib from 
BaseIoLibIntrinsicSev.inf", 2017-07-10).

Accordingly, there's a *huge* performance (boot time) impact when you boot OVMF 
in a SEV guest with DEBUG_VERBOSE messages enabled (and captured; i.e., when 
the isa-debugcon device is active).

> I think there need to
> be comments in IoLibFifo.c around the new code about why the access is 
> unrolled/looping so that someone down the road doesn't come along and 
> try to use string I/O again.

String IO must be preserved for such guests that don't run in Confidential 
Virtual Machines ("CVM"s).

In particular patches #6 and #7 would damage OVMF.

Nacked-by: Laszlo Ersek 

Laszlo

> 
> From a commit message standpoint, you have up to 74 characters per 
> line to use and I see most of your messages do not make use of that. 
> Also, you use sev when it should be SEV. Using SEV will make grep'ing 
> commit messages simpler.
> 
> Thanks,
> Tom
> 
>>
>> Thanks,
>> Dun
>>
>> -Original Message-
>> From: Tan, Dun
>> Sent: Friday, October 27, 2023 3:35 PM
>> To: Yao, Jiewen ; devel@edk2.groups.io
>> Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in 
>> BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev
>>
>> Thanks for the suggestion.
>> I'll update the test result once I finished the test. Also the 
>> abstract message in this patch has been modified to mention that this 
>> patch should not be merged now.
>>
>> Thanks,
>> Dun
>>
>> -Original Message-
>> From: Yao, Jiewen 
>> Sent: Friday, October 27, 2023 3:07 PM
>> To: Tan, Dun ; devel@edk2.groups.io
>> Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in 
>> BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev
>>
>> Here is my suggestion:
>>
>> 1) Please perform the test to ensure the functional part is correct.
>>
>> Without that, how can people know you are doing things right?
>>
>> 2) If you do not run any test, before you send out patch, please call 
>> out that clearly.
>> That is important to reminder the maintainer: Don't merge, even if it 
>> pass review.
>>
>> Otherwise, once the review passed, the maintainer may merge it.
>> I don't think that is the intention.
>>
>>
>>
>> Thank you
>> Yao, Jiewen
>>  
>>> -Original Message-
>>> From: Tan, Dun 
>>> Sent: Friday, October 27, 2023 2:32 PM
>>> To: Yao, Jiewen ; 

Re: [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Dhaval Sharma]

I am posting an update on behalf of Jingyu as he had trouble with posting.
CC'ing him here:
In summary what we have verified so far:

   1. I have verified that instructions/op codes are okay. I have also
   verified on Qemu that functionally it seems to be calling correct
   instructions. Ensured with negative test cases that any other op codes do
   cause exceptions as expected.
   2. Jingyu was able to verify the CpuFlushCpuDataCache function with this
   framework (he had to use custom op code based on his soc implementation) on
   SG2042. There is one issue that he is debugging now which is related to
   other cache instructions and he will get back with more data. P.S. SG2042
   does not implement the exact same CMO opcodes but equivalent ones. So this
   experiment is just an additional data point that helps verify the framework
   and not CMO itself.
   3. In general it sounds like framework flows are alright and as long as
   instructions do their job as claimed in the spec, it is lower risk.

Guess this is what we have so far. If it makes sense to everyone, we could
go ahead with merging with this *feature disabled by default* after Jingyu
provides clarity reg failures on SG2042 platform. Otherwise we can wait
until newer Si is available where these exact instructions can be tested
and then upstreamed.

[From Jingyu]
I verified this CMO framework on an actual HW platform.

SW:
edk2: https://github.com/rivosinc/edk2/tree/dev-rv-cmo-v7 branch:
dev-rv-cmo-v7
edk2-platforms: https://github.com/sophgo/edk2-platforms  branch: sg2042-dev

HW:
Milk-V Pioneer Box, a developer motherboard based on SG2042 with 64-Core
T-HEAD C920.

Attention:
The T-HEAD C920 implemented its own CMO Extension and is different from the
standard CMO Extension.

Test steps:
1. Modified the opcodes in RiscVasm.inc to accommodate the C920 CMO feature.
diff --git a/MdePkg/Include/RiscV64/RiscVasm.inc
b/MdePkg/Include/RiscV64/RiscVasm.inc
index 29de735885..5df85fdb31 100644
--- a/MdePkg/Include/RiscV64/RiscVasm.inc
+++ b/MdePkg/Include/RiscV64/RiscVasm.inc
@@ -7,13 +7,13 @@
  */

 .macro RISCVCMOFLUSH
-.word 0x25200f
+.long 0x0275000b^M
 .endm

 .macro RISCVCMOINVALIDATE
-.word 0x05200f
+.long 0x0265000b^M
 .endm

 .macro RISCVCMOCLEAN
-.word 0x15200f
+.long 0x0275000b^M
 .endm

2. We enable the CMO during the PCIe devices with DMA access to the memory,
just focus on the implementation of CpuFlushCpuDataCache based on the
EFI_CPU_ARCH_PROTOCOL. Except for PCIe, in other words, except for the
cpu->FlushDataCache, we do not use CMO. And the PCIe inbound only relates
to datacache.clean and datacache.invalidate.
diff --git a/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
b/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
index 2af3b62234..cf50bc5f92 100644
--- a/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c
@@ -9,6 +9,8 @@
 **/

 #include "CpuDxe.h"
+#include ^M
+#include ^M

 //
 // Global Variables
@@ -59,7 +61,7 @@ EFI_CPU_ARCH_PROTOCOL  gCpu = {
   CpuGetTimerValue,
   CpuSetMemoryAttributes,
   1,  // NumberOfTimers
-  4   // DmaBufferAlignment
+  64   // DmaBufferAlignment^M
 };

 //
@@ -90,6 +92,21 @@ CpuFlushCpuDataCache (
   IN EFI_CPU_FLUSH_TYPE FlushType
   )
 {
+  PatchPcdSet64 (PcdRiscVFeatureOverride, 0x1);^M
+  switch (FlushType) {^M
+case EfiCpuFlushTypeWriteBack:^M
+  WriteBackDataCacheRange ((VOID *)(UINTN)Start, (UINTN)Length);^M
+  break;^M
+case EfiCpuFlushTypeInvalidate:^M
+  InvalidateInstructionCacheRange ((VOID *)(UINTN)Start,
(UINTN)Length);^M
+  break;^M
+case EfiCpuFlushTypeWriteBackInvalidate:^M
+  WriteBackInvalidateDataCacheRange ((VOID *)(UINTN)Start,
(UINTN)Length);^M
+  break;^M
+default:^M
+  return EFI_INVALID_PARAMETER;^M
+  }^M
+^M
   return EFI_SUCCESS;
 }

diff --git a/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
b/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
index 51ff89678c..e2e44ad619 100644
--- a/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
+++ b/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
@@ -389,6 +389,7 @@

 [PcdsPatchableInModule]
   gSophgoSG2042PlatformPkgTokenSpaceGuid.PcdSG2042PhyAddrToVirAddr|0
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0

 

 #
@@ -500,7 +501,7 @@
   # RISC-V Core module
   #
   UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
-
Silicon/Sophgo/SG2042Pkg/Override/UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf
+  UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf
   MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf

   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

diff --git a/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
b/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
index 844fc3eac0..9cbb1d3f65 100644
--- a/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
+++ b/Platform/Sophgo/SG2042_EVB_Board/SG2042.fdf
@@ 

Re: [edk2-devel] [PATCH v3 0/5] StarFive/VisionFive2: Add VisionFive 2 platform

[Sunil V L]

Hi John,

I forgot to mention that you need one more patch to add the maintainer
entry for the platform.

Otherwise, for the series,
Acked-by: Sunil V L 

Thanks,
Sunil
On Fri, Oct 27, 2023 at 11:19:01AM +0800, John Chew wrote:
> v3:
>   - Combine "Add VisionFive 2 platform" patch series with
> "Patches for JH7110 SoC platform" patch series [Sunil]
>   - Change commit message for [1/5], [4/5], [5/5] in this patch series
> [Sunil]
> 
> v2:
>   - Change PlatformBootManagerLib to:
>   Platform/RISC-V/PlatformPkg/.../PlatformBootManagerLib.inf
> [Sunil]
>   - Added PCIE PCDs
> PcdPciBusMin, PcdPciBusMax, PcdPciIoBase, PcdPciIoSize
> PcdPciIoOffset, PcdPci0Mmio32Base, PcdPci0Mmio32Size
> PcdPci0Mmio64Base, PcdPci0Mmio64Size, PcdPci1Mmio32Base
> PcdPci1Mmio32Size, PcdPci1Mmio64Base, PcdPci1Mmio64Size
> [John Chew]
>   - Include all maintainer in all patches in this series [Sunil]
>   - Added missing commit message to patches 1/6, 2/6, 6/6 [Sunil]
>   - Remove commented code in JH7110.h [Sunil]
>   - Remove BootServicesDxe/BootServicesDxe.inf, as it is not required 
> anymore because memory allocation is handle by MMC driver [Sunil]
>   - Remove PlatformBootManagerLib.inf and change PlatformBootManagerLib to
> "Platform/RISC-V/PlatformPkg/.../PlatformBootManagerLib.inf" [Sunil] 
>   - Added PCDs for PCIE (Please refer to patch 0001 for details) [John Chew]
> 
> v1:
>   - Added new platform support for VisionFive2 SBC.
>   - Boot flow in VF2 using EDK2 as bootloader:
> BootROM -> U-Boot SPL -> OpenSBI -> EDK2 -> Linux -> OS
>   - Supported boot source for Linux from EDK2:
>   - SD Card
>   - eMMC
>   - NVMe
>   - USB
>   - In this patches it include all the platform specific drivers/protocol
> that is being use for JH7110 SoC platform. All the drivers includes:
>   1. PCIE driver for NVME and USB (GT710 graphic in progress)
>   2. QSPI Flash driver for efi variable
>   3. FVB driver for efi variable
>   4. Boot service memory allocation driver
>   5. Platform boot manager for graphical console display
> 
> Cc: Sunil V L 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Li Yong 
> Cc: mindachen1987 
> 
> John Chew (2):
>   StarFive/JH7110Pkg: Add SPI protocol and driver support
>   StarFive/JH7110Pkg: Add firmware volume block protocol
> 
> mindachen1987 (3):
>   StarFive/JH7110Pkg: Add Pci controller driver
>   StarFive/JH7110Pkg: Add JH7110 Silicon Package
>   StarFive/VisionFive2: Add VisionFive 2 platform
> 
>  Platform/StarFive/VisionFive2/DeviceTree/Gpio.h  
>  |   42 +
>  Platform/StarFive/VisionFive2/DeviceTree/Irq.h   
>  |   20 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkGen.h  
>  |  398 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkIsp.h  
>  |   57 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkVout.h 
>  |   68 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110PinCtrl.h 
>  | 1573 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110Power.h   
>  |   22 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110Rst.h 
>  |  228 +++
>  Platform/StarFive/VisionFive2/DeviceTree/Led.h   
>  |   90 +
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveClk.dtsi
>  |  130 ++
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveHdmi.dtsi   
>  |   28 +
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveJH7110.dtsi 
>  | 1812 
>  Platform/StarFive/VisionFive2/DeviceTree/StarFivePwmDac.dtsi 
>  |   26 +
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dts 
>  |  211 +++
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dtsi
>  |  838 +
>  Platform/StarFive/VisionFive2/DeviceTree/Thermal.h   
>  |   16 +
>  Platform/StarFive/VisionFive2/DeviceTree/VisionFive2DeviceTree.inf   
>  |   36 +
>  Platform/StarFive/VisionFive2/VarStore.fdf.inc   
>  |   77 +
>  Platform/StarFive/VisionFive2/VisionFive2.dsc
>  |  596 +++
>  Platform/StarFive/VisionFive2/VisionFive2.fdf
>  |  284 +++
>  Platform/StarFive/VisionFive2/VisionFive2.fdf.inc
>  |   48 +
>  Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c  
>  |  909 ++
>  Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.h  
>  |  138 ++
>  Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.inf
>  |   70 +
>  

Re: [edk2-devel] [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address Structure

[Jinlong Xu]

Hi, Liming

Could you please help merge the patch? This is a portion of PRM ACPI  6.5 
support feature.

Thanks
Jinlong

-Original Message-
From: Xu, Jinlong 
Sent: Wednesday, October 25, 2023 3:29 PM
To: gaoliming ; devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: RE: [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address 
Structure

Just one patch, in patch v1, the commit message check failed, sorry for I never 
use PatchCheck.py to check the commit message in patch v1 

Thanks
Jinlong

-Original Message-
From: gaoliming 
Sent: Wednesday, October 25, 2023 3:24 PM
To: Xu, Jinlong ; devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: 回复: [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address 
Structure

Jinlong:
  I want to confirm whether there is only one patch. If yes, why patch shows 
2/5? Seemly, this is the second one of the patch serial. 

  For this change, Reviewed-by: Liming Gao

Thanks
Liming
> -邮件原件-
> 发件人: Jinlong Xu 
> 发送时间: 2023年10月20日 19:14
> 收件人: devel@edk2.groups.io
> 抄送: Michael D Kinney ; Liming Gao 
> 
> 主题: [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address 
> Structure
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4567
> 
> ACPI_Spec_6_5_Aug29 Table 5.1, add 0x0B/Platform Runtime Mechanism
> (PRM)
> in Address Space ID of Generic Address Structure (GAS)
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Signed-off-by: Jinlong Xu 
> ---
>  MdePkg/Include/IndustryStandard/Acpi65.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h
> b/MdePkg/Include/IndustryStandard/Acpi65.h
> index 6caadf240498..86754a0e123a 100644
> --- a/MdePkg/Include/IndustryStandard/Acpi65.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi65.h
> @@ -43,6 +43,7 @@ typedef struct {
>  #define EFI_ACPI_6_5_GENERAL_PURPOSE_IO  0x08
> 
>  #define EFI_ACPI_6_5_GENERIC_SERIAL_BUS  0x09
> 
>  #define EFI_ACPI_6_5_PLATFORM_COMMUNICATION_CHANNEL  0x0A
> 
> +#define EFI_ACPI_6_5_PLATFORM_RUNTIME_MECHANISM  0x0B
> 
>  #define EFI_ACPI_6_5_FUNCTIONAL_FIXED_HARDWARE   0x7F
> 
> 
> 
>  //
> 
> --
> 2.39.2.windows.1





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

Re: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when calling C function in 64bit

[Ashraf Ali S]

Reviewed-by: mailto:ashraf.al...@intel.com>>;

Thanks.,
S, Ashraf Ali

From: Kuo, Ted 
Sent: Tuesday, October 31, 2023 2:06 PM
To: Ni, Ray ; devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Duggapu, Chinni B 
; Ng, Ray Han Lim ; Zeng, 
Star ; S, Ashraf Ali ; Mohapatra, 
Susovan 
Subject: RE: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when 
calling C function in 64bit


Reviewed-by: Ted Kuo mailto:ted@intel.com>>

From: Ni, Ray mailto:ray...@intel.com>>
Sent: Tuesday, October 31, 2023 4:26 PM
To: devel@edk2.groups.io; Ni, Ray 
mailto:ray...@intel.com>>
Cc: Chiu, Chasel mailto:chasel.c...@intel.com>>; 
Desimone, Nathaniel L 
mailto:nathaniel.l.desim...@intel.com>>; 
Duggapu, Chinni B 
mailto:chinni.b.dugg...@intel.com>>; Ng, Ray Han 
Lim mailto:ray.han.lim...@intel.com>>; Zeng, Star 
mailto:star.z...@intel.com>>; Kuo, Ted 
mailto:ted@intel.com>>; S, Ashraf Ali 
mailto:ashraf.al...@intel.com>>; Mohapatra, Susovan 
mailto:susovan.mohapa...@intel.com>>
Subject: Re: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when 
calling C function in 64bit

Sorry, I copied the maintainers from Maintainers.txt but forgot to change all 
M/R to "Cc". That caused not all the maintainers/reviewers are CCed.
I will fix the commit message before merging.

Thanks,
Ray

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> on behalf of Ni, Ray 
mailto:ray...@intel.com>>
Sent: Tuesday, October 31, 2023 4:22 PM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Chiu, Chasel mailto:chasel.c...@intel.com>>
Subject: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when 
calling C function in 64bit

When FSP runs in API mode, it saves the IDTR in its own stack then
switches to bootloader's stack before it returns from FspMemoryInit.
Next time when the bootloader calls TempRamExit, FSP switches to
its own stack and restores IDTR from its stack saved earlier.

However, due to a bug in BaseFspSwitchStackLib, the IDTR saved on
FSP's stack might be corrupted that results the following TempRamExit
call fails inside FSP due to PeiServices pointer cannot be retrieved
from IDT.base - 8.

The bug is the assembly code doesn't reserve 32 bytes before calling
the C routine in 64bit. According to the x86-64 calling convention,
caller is responsible for allocating 32 bytes of "shadow space" on the
stack right before calling the function (regardless of the actual
number of parameters used).

When FSP is built in optimization-off mode, the C routine makes use
of the 32-byte "shadow space" which is not reserved by the assembly
caller. That causes the IDTR saved on the stack is corrupted by the
C routine.
The patch fixes so by reserving the 32 bytes before calling C routine.

Signed-off-by: Ray Ni mailto:ray...@intel.com>>
Cc: Chasel Chiu mailto:chasel.c...@intel.com>>
M: Nate DeSimone 
mailto:nathaniel.l.desim...@intel.com>>
M: Duggapu Chinni B 
mailto:chinni.b.dugg...@intel.com>>
M: Ray Han Lim Ng mailto:ray.han.lim...@intel.com>>
R: Star Zeng mailto:star.z...@intel.com>>
R: Ted Kuo mailto:ted@intel.com>>
R: Ashraf Ali S mailto:ashraf.al...@intel.com>>
R: Susovan Mohapatra 
mailto:susovan.mohapa...@intel.com>>
---
 IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm 
b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
index 1ea1220608..e3a7cf002f 100644
--- a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
+++ b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
@@ -1,6 +1,6 @@
 ;--

 ;

-; Copyright (c) 2022, Intel Corporation. All rights reserved.

+; Copyright (c) 2022 - 2023, Intel Corporation. All rights reserved.

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

 ;

 ; Abstract:

@@ -60,7 +60,9 @@ ASM_PFX(FspSwitchStack):


 ; Load new stack

 mov rcx, rsp

+sub rsp, 0x20

 callASM_PFX(SwapStack)

+add rsp, 0x20

 mov rsp, rax



 ; Restore previous contexts

--
2.39.1.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110384): https://edk2.groups.io/g/devel/message/110384
Mute This Topic: https://groups.io/mt/102293342/1712937
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/3759105/1712937/893644498/xyzzy 
[ray...@intel.com]
-=-=-=-=-=-=


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

Re: [edk2-devel] [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential memory leak issue

[Xu, Wei6]

Delete one my wrong comments.

-Original Message-
From: Xu, Wei6 
Sent: Tuesday, October 31, 2023 2:40 PM
To: Laszlo Ersek ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; Sami Mujawar 
; Ni, Ray 
Subject: RE: [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential memory leak 
issue

Thanks a lot for reviewing the patch.
I have different opinions with (2), could you please check that? Thanks a lot.
If you agree (2) is not an issue, I will prepare a new patch version to only 
address (1) and (3)

BR,
Wei
>-Original Message-
>From: Laszlo Ersek 
>Sent: Monday, October 30, 2023 8:25 PM
>To: Xu, Wei6 ; devel@edk2.groups.io
>Cc: Ard Biesheuvel ; Sami Mujawar 
>; Ni, Ray 
>Subject: Re: [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential memory 
>leak issue
>
>On 10/30/23 08:49, Wei6 Xu wrote:
>> In MmCoreFfsFindMmDriver(), ScratchBuffer is not freed in the error 
>> return path that DstBuffer page allocation fails. Free ScratchBuffer 
>> before return with error.
>>
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Sami Mujawar 
>> Cc: Ray Ni 
>> Signed-off-by: Wei6 Xu 
>> ---
>>  StandaloneMmPkg/Core/FwVol.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/StandaloneMmPkg/Core/FwVol.c 
>> b/StandaloneMmPkg/Core/FwVol.c index e1e20ffd14ac..9d0ce66ef839
>100644
>> --- a/StandaloneMmPkg/Core/FwVol.c
>> +++ b/StandaloneMmPkg/Core/FwVol.c
>> @@ -150,6 +150,7 @@ MmCoreFfsFindMmDriver (
>>  //
>>  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
>(DstBufferSize));
>>  if (DstBuffer == NULL) {
>> +  FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES 
>> + (ScratchBufferSize));
>>return EFI_OUT_OF_RESOURCES;
>>  }
>>
>
>This patch is good, with regard to ScratchBuffer:
>
>Reviewed-by: Laszlo Ersek 
>
>However, upon further staring at the code, I think that we have a 
>DstBuffer life-cycle problem as well, independently of ScratchBuffer:
>
>(1) ExtractGuidedSectionDecode() does not necessarily use the caller- 
>allocated buffer. The library class header file 
>"MdePkg/Include/Library/ExtractGuidedSectionLib.h" says that, "If the 
>decoded buffer is identical to the data in InputSection, then 
>OutputBuffer is set to point at the data in InputSection.  Otherwise, 
>the decoded data will be placed in caller allocated buffer specified by 
>OutputBuffer."
>
>This means that the ExtractGuidedSectionDecode() call may change the 
>value of DstBuffer (rather than changing the contents of the buffer 
>that DstBuffer points at) -- in which case freeing DstBuffer is wrong.
>
>This means we need a second variable. One variable needs to preserve 
>the allocation address, and the address of the other variable must be 
>passed to ExtractGuidedSectionDecode(). After the call, we need to free 
>the
>*original* variable (the one that ExtractGuidedSectionDecode() could 
>not have overwritten).
>

Will prepare a new patch version to address this.

>(2) As far as I can tell, we leak our original DstBuffer allocation in two 
>cases:
>
>- Upon every iteration of the loop after the first iteration, we 
>overwrite the DstBuffer variable with the new allocation address. The old one 
>is lost (leaked).
>
>My understanding is that, after the recursive MmCoreFfsFindMmDriver() 
>call returns, we no longer need the decompressed DstBuffer, therefore, 
>we should free the *original* DstBuffer allocation (per (1)) right there.
>
>- The last (potentially: only one) iteration of the loop allocates 
>DstBuffer, and that allocation is never freed. We don't overwrite the 
>address with a new allocation's address, but still we never free the 
>original allocation. The FreeDstBuffer label is apparently never reached.
>

In the success case, DstBuffer should NOT be freed, because the buffer holds 
the MM drivers, which will be used in the driver dispatch process later.

>(3) And finally, a logic bug (or at least questionable behavior):
>
>The loop at the *top* of the function scans the firmware volume for 
>embedded firmware volumes (recursing into them if any are found), while 
>the loop at the *bottom* of the function scans the *same* firmware 
>volume for MM driver binaries (adding them to the "MM driver list"), 
>starting anew from the beginning of the firmware volume.
>
>Now, there are many exit points in the function-top loop. Those can be 
>classified in two groups: "break", and "return/goto". The former class 
>makes sense. The latter class does not seem to make sense to me.
>
>Consider: just because we fail to scan the firmware volume for embedded 
>firmware volumes, for any reason really, should we really abandon 
>scanning the same firmware volume for MM driver binaries? What I don't 
>understand here in particular is the *inconsistency* between the exit 
>points, in the function-top loop:
>
>- if we realize there are no (more) embedded FVs, we break out; good
>
>- if we realize the next embedded FV is not "GUID defined", we break 
>out; good (well, questionable -- perhaps we should continue scanning?

Re: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when calling C function in 64bit

[Kuo, Ted]

Reviewed-by: Ted Kuo mailto:ted@intel.com>>

From: Ni, Ray 
Sent: Tuesday, October 31, 2023 4:26 PM
To: devel@edk2.groups.io; Ni, Ray 
Cc: Chiu, Chasel ; Desimone, Nathaniel L 
; Duggapu, Chinni B 
; Ng, Ray Han Lim ; Zeng, 
Star ; Kuo, Ted ; S, Ashraf Ali 
; Mohapatra, Susovan 
Subject: Re: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when 
calling C function in 64bit

Sorry, I copied the maintainers from Maintainers.txt but forgot to change all 
M/R to "Cc". That caused not all the maintainers/reviewers are CCed.
I will fix the commit message before merging.

Thanks,
Ray

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> on behalf of Ni, Ray 
mailto:ray...@intel.com>>
Sent: Tuesday, October 31, 2023 4:22 PM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Chiu, Chasel mailto:chasel.c...@intel.com>>
Subject: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when 
calling C function in 64bit

When FSP runs in API mode, it saves the IDTR in its own stack then
switches to bootloader's stack before it returns from FspMemoryInit.
Next time when the bootloader calls TempRamExit, FSP switches to
its own stack and restores IDTR from its stack saved earlier.

However, due to a bug in BaseFspSwitchStackLib, the IDTR saved on
FSP's stack might be corrupted that results the following TempRamExit
call fails inside FSP due to PeiServices pointer cannot be retrieved
from IDT.base - 8.

The bug is the assembly code doesn't reserve 32 bytes before calling
the C routine in 64bit. According to the x86-64 calling convention,
caller is responsible for allocating 32 bytes of "shadow space" on the
stack right before calling the function (regardless of the actual
number of parameters used).

When FSP is built in optimization-off mode, the C routine makes use
of the 32-byte "shadow space" which is not reserved by the assembly
caller. That causes the IDTR saved on the stack is corrupted by the
C routine.
The patch fixes so by reserving the 32 bytes before calling C routine.

Signed-off-by: Ray Ni mailto:ray...@intel.com>>
Cc: Chasel Chiu mailto:chasel.c...@intel.com>>
M: Nate DeSimone 
mailto:nathaniel.l.desim...@intel.com>>
M: Duggapu Chinni B 
mailto:chinni.b.dugg...@intel.com>>
M: Ray Han Lim Ng mailto:ray.han.lim...@intel.com>>
R: Star Zeng mailto:star.z...@intel.com>>
R: Ted Kuo mailto:ted@intel.com>>
R: Ashraf Ali S mailto:ashraf.al...@intel.com>>
R: Susovan Mohapatra 
mailto:susovan.mohapa...@intel.com>>
---
 IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm 
b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
index 1ea1220608..e3a7cf002f 100644
--- a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
+++ b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
@@ -1,6 +1,6 @@
 ;--

 ;

-; Copyright (c) 2022, Intel Corporation. All rights reserved.

+; Copyright (c) 2022 - 2023, Intel Corporation. All rights reserved.

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

 ;

 ; Abstract:

@@ -60,7 +60,9 @@ ASM_PFX(FspSwitchStack):


 ; Load new stack

 mov rcx, rsp

+sub rsp, 0x20

 callASM_PFX(SwapStack)

+add rsp, 0x20

 mov rsp, rax



 ; Restore previous contexts

--
2.39.1.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110384): https://edk2.groups.io/g/devel/message/110384
Mute This Topic: https://groups.io/mt/102293342/1712937
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/3759105/1712937/893644498/xyzzy 
[ray...@intel.com]
-=-=-=-=-=-=



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

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

[Ni, Ray]

Mike,
This is not friendly for XIP code. With XIP code, the global variable is not 
able to be updated as it sits in read-only SPI flash.

Thanks,
Ray

From: Kinney, Michael D 
Sent: Tuesday, October 31, 2023 11:37 AM
To: Ni, Ray ; Andrew (EFI) Fish ; 
edk2-devel-groups-io ; Rebecca Cran ; 
Hernandez Miramontes, Jose Miguel 
Cc: Kinney, Michael D 
Subject: RE: [edk2-devel] CpuDeadLoop() is optimized by compiler


Does using a static volatile global instead of a volatile local work?



Mike



From: Ni, Ray 
Sent: Monday, October 30, 2023 7:52 PM
To: Andrew (EFI) Fish ; edk2-devel-groups-io 
; Rebecca Cran ; Hernandez Miramontes, 
Jose Miguel 
Cc: Kinney, Michael D 
Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler



It's been a while.



Is there any better solution? Can we go with assembly solution?



Thanks,

Ray



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



I don’t think the atomic is going to help. The compiler honored the volatile by 
doing a read, but assumed it would never change due to scoping. As you can see 
in my example if the compiler thinks DeadLoopCount can be changed it will put 
the check back in and assume the function can return. So an assembly function 
that does nothing called IncreaseScope()

 would fix this issue too.





void IncreaseScope(int *ptr);





void CpuDeadLoopFix(void) {



volatile

int DeadLoopCount = 0;



while(DeadLoopCount ==

0) {



IncreaseScope();



}



}





void CpuDeadLoop(void) {



volatile

int DeadLoopCount = 0;



while(DeadLoopCount ==

0);



}





Gives us:





voltbl

SEGMENT



voltbl

ENDS



voltbl

SEGMENT



voltbl

ENDS





DeadLoopCount$ =

48



CpuDeadLoopFix PROC

; COMDAT



$LN12:



sub

rsp, 40

; 0028H



mov

DWORD PTR

DeadLoopCount$[rsp],

0



jmp

SHORT $LN10@CpuDeadLoo



$LL2@CpuDeadLoo:



lea

rcx, QWORD

PTR DeadLoopCount$[rsp]



call

IncreaseScope



$LN10@CpuDeadLoo:



mov

eax, DWORD

PTR DeadLoopCount$[rsp]



test

eax, eax



je

SHORT $LL2@CpuDeadLoo



add

rsp, 40

; 0028H



ret

0



CpuDeadLoopFix ENDP





DeadLoopCount$ =

8



CpuDeadLoop PROC

; COMDAT



mov

DWORD PTR

DeadLoopCount$[rsp],

0



$LL2@CpuDeadLoo:



mov

eax, DWORD

PTR DeadLoopCount$[rsp]



jmp

SHORT $LL2@CpuDeadLoo



CpuDeadLoop ENDP







Compiler 
Explorer

Re: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when calling C function in 64bit

[Ni, Ray]

Sorry, I copied the maintainers from Maintainers.txt but forgot to change all 
M/R to "Cc". That caused not all the maintainers/reviewers are CCed.
I will fix the commit message before merging.

Thanks,
Ray

From: devel@edk2.groups.io  on behalf of Ni, Ray 

Sent: Tuesday, October 31, 2023 4:22 PM
To: devel@edk2.groups.io 
Cc: Chiu, Chasel 
Subject: [edk2-devel] [PATCH] IntelFsp2Pkg/SwitchStack: Reserve 32B when 
calling C function in 64bit

When FSP runs in API mode, it saves the IDTR in its own stack then
switches to bootloader's stack before it returns from FspMemoryInit.
Next time when the bootloader calls TempRamExit, FSP switches to
its own stack and restores IDTR from its stack saved earlier.

However, due to a bug in BaseFspSwitchStackLib, the IDTR saved on
FSP's stack might be corrupted that results the following TempRamExit
call fails inside FSP due to PeiServices pointer cannot be retrieved
from IDT.base - 8.

The bug is the assembly code doesn't reserve 32 bytes before calling
the C routine in 64bit. According to the x86-64 calling convention,
caller is responsible for allocating 32 bytes of "shadow space" on the
stack right before calling the function (regardless of the actual
number of parameters used).

When FSP is built in optimization-off mode, the C routine makes use
of the 32-byte "shadow space" which is not reserved by the assembly
caller. That causes the IDTR saved on the stack is corrupted by the
C routine.
The patch fixes so by reserving the 32 bytes before calling C routine.

Signed-off-by: Ray Ni 
Cc: Chasel Chiu 
M: Nate DeSimone 
M: Duggapu Chinni B 
M: Ray Han Lim Ng 
R: Star Zeng 
R: Ted Kuo 
R: Ashraf Ali S 
R: Susovan Mohapatra 
---
 IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm 
b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
index 1ea1220608..e3a7cf002f 100644
--- a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
+++ b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
@@ -1,6 +1,6 @@
 ;--

 ;

-; Copyright (c) 2022, Intel Corporation. All rights reserved.

+; Copyright (c) 2022 - 2023, Intel Corporation. All rights reserved.

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

 ;

 ; Abstract:

@@ -60,7 +60,9 @@ ASM_PFX(FspSwitchStack):


 ; Load new stack

 mov rcx, rsp

+sub rsp, 0x20

 callASM_PFX(SwapStack)

+add rsp, 0x20

 mov rsp, rax



 ; Restore previous contexts

--
2.39.1.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110384): https://edk2.groups.io/g/devel/message/110384
Mute This Topic: https://groups.io/mt/102293342/1712937
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/3759105/1712937/893644498/xyzzy 
[ray...@intel.com]
-=-=-=-=-=-=




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110385): https://edk2.groups.io/g/devel/message/110385
Mute This Topic: https://groups.io/mt/102293342/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] IntelFsp2Pkg/SwitchStack: Reserve 32B when calling C function in 64bit

[Ni, Ray]

When FSP runs in API mode, it saves the IDTR in its own stack then
switches to bootloader's stack before it returns from FspMemoryInit.
Next time when the bootloader calls TempRamExit, FSP switches to
its own stack and restores IDTR from its stack saved earlier.

However, due to a bug in BaseFspSwitchStackLib, the IDTR saved on
FSP's stack might be corrupted that results the following TempRamExit
call fails inside FSP due to PeiServices pointer cannot be retrieved
from IDT.base - 8.

The bug is the assembly code doesn't reserve 32 bytes before calling
the C routine in 64bit. According to the x86-64 calling convention,
caller is responsible for allocating 32 bytes of "shadow space" on the
stack right before calling the function (regardless of the actual
number of parameters used).

When FSP is built in optimization-off mode, the C routine makes use
of the 32-byte "shadow space" which is not reserved by the assembly
caller. That causes the IDTR saved on the stack is corrupted by the
C routine.
The patch fixes so by reserving the 32 bytes before calling C routine.

Signed-off-by: Ray Ni 
Cc: Chasel Chiu 
M: Nate DeSimone 
M: Duggapu Chinni B 
M: Ray Han Lim Ng 
R: Star Zeng 
R: Ted Kuo 
R: Ashraf Ali S 
R: Susovan Mohapatra 
---
 IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm 
b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
index 1ea1220608..e3a7cf002f 100644
--- a/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
+++ b/IntelFsp2Pkg/Library/BaseFspSwitchStackLib/X64/Stack.nasm
@@ -1,6 +1,6 @@
 ;--
 ;
-; Copyright (c) 2022, Intel Corporation. All rights reserved.
+; Copyright (c) 2022 - 2023, Intel Corporation. All rights reserved.
 ; SPDX-License-Identifier: BSD-2-Clause-Patent
 ;
 ; Abstract:
@@ -60,7 +60,9 @@ ASM_PFX(FspSwitchStack):
 
 ; Load new stack
 mov rcx, rsp
+sub rsp, 0x20
 callASM_PFX(SwapStack)
+add rsp, 0x20
 mov rsp, rax
 
 ; Restore previous contexts
-- 
2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110384): https://edk2.groups.io/g/devel/message/110384
Mute This Topic: https://groups.io/mt/102293342/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 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

On Tuesday, October 31, 2023 8:45 AM, Erdem Aktas wrote:

> On Sun, Oct 29, 2023 at 11:42 PM Sun, CepingX 
> mailto:cepingx@intel.com>>

> wrote:

> >

> > On Saturday, October 28, 2023 12:45 AM, Erdem Aktas wrote:

> > This should be the [PATCH V1 2/2] I assume?

> > Yes, the name is same with [PATCH v1 0/2] , may be confusion, I would

> update in next version to avoid the same title name.

> >

> >

> > On Thu, Oct 26, 2023 at 5:58 PM sunceping 
> > mailto:cepingx@intel.com>> wrote:

> >  [Sources]

> >VirtualMemory.h

> >MemoryEncryption.c

> > +  X64/TdVmCallMapGPA.nasm

> > I do not think we need another TdVmCallMapGPA definition, do we?

> > Currently,  the TdVmCall always clears the R11 if the return code is not

> successful,  which means we need to change TdVmCall if we don't add

> TdVmCallMapGPA.

> > Refer the GHCI Spec , if the returns code is not successful, the R11

> > value is not valid for the sub-functions except MapGPA,  which means

> TdVmCall should clear the value on unsuccessful returns and only save the

> value if MapGPA returns unsuccessfully.  If an update is required, the logic 
> in

> TdVmCall could be complex.

>

> It seems like TdVmCallMapGPA function is actually duplicating most of the

> code that the TdVmCall function is already doing.

> According to the spec, R11 has meaningful data when mapgpa has RETRY,

> GPA_IN_USE or ALIGN_ERROR.

> I do not think the TdVmCall change logic would be complex (or not more

> than what TdVmCallMapGPA is already doing).

> I would like to see what others are saying on this.

>

Yes, we can wait for other's comments.  @Gerd 
Hoffmann ,  Could you help add a comment?



> > -  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0,

> > 0, NULL);

> > +  while (RetryCount < MAX_RETRIES_PER_PAGE) {

> > +TdStatus = TdVmCallMapGPA (PhysicalAddress, Length,

> > + );

> > Why not this?

> >  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,

> > ); The TdVmCall always clears the R11 value when

> unsuccessful returns as above comments, therefor add the

> TdVmCallMapGPA to handle it.

> right, the tdvmcall does not handle the R11 correctly for mapGPA. I think it

> should be an easy fix in that function instead of creating a whole copy of 
> that

> function.

> Is there a reason why we think it is complicated?



If an update is required,  the TdVmCall has to add a flag or value to indicate 
the

 MapGPA and always compares the return code before clearing. This indicates

that additional code must be developed specifically to handle the results and 
solely

 for MapGPA at this time,  it would make the code seems complex and not easy 
extend

 in the future.

Based on the above considerations, we extract the code for MapGPA as an 
individual function,

 that' s easy to understand and extend for other results in the future.



Thanks

Ceping


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

[edk2-devel] [edk2-redfish-client][PATCH 3/3] RedfishClientPkg/RedfishFeatureUtilityLib: fix issues and enhancement

[Nickle Wang via groups.io]

-Add RedfishDebugLib to print Redfish request and response
details when PATCH and POST request return error.
-Use "%a:" in debug print to align with the style in EDK2.
-Enhance GetConfigureLang() to handle pending resource URI.
Pending resource share ths same schema as its active resource.
So we can simply remove "/Settings" from URI and search again.
-Enhancement to GetPropertyVagueValue(). This function stops
to handle remaining property while error happens. We like to
process as much as properties as we can and skip the problematic
property.
-Enhancement to MatchPropertyWithJsonContext(). For string type
of BIOS attribute, it is possible that the attribute value is
empty by default. This does not means that the resource is not
provisioned yet.
-Fix typo.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   1 +
 .../RedfishFeatureUtilityLib.inf  |   1 +
 .../RedfishFeatureUtilityInternal.h   |   2 +
 .../RedfishFeatureUtilityLib.c| 272 ++
 4 files changed, 154 insertions(+), 122 deletions(-)

diff --git a/RedfishClientPkg/RedfishClientLibs.dsc.inc 
b/RedfishClientPkg/RedfishClientLibs.dsc.inc
index 5ea38015..5eae6711 100644
--- a/RedfishClientPkg/RedfishClientLibs.dsc.inc
+++ b/RedfishClientPkg/RedfishClientLibs.dsc.inc
@@ -39,3 +39,4 @@
   RedfishEventLib|RedfishClientPkg/Library/RedfishEventLib/RedfishEventLib.inf
   
RedfishVersionLib|RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
   
RedfishAddendumLib|RedfishClientPkg/Library/RedfishAddendumLib/RedfishAddendumLib.inf
+  RedfishDebugLib|RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
index 66d5dce6..fd66b8ac 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
@@ -45,6 +45,7 @@
   UefiRuntimeServicesTableLib
   PrintLib
   HttpLib
+  RedfishDebugLib
 
 [Protocols]
   gEdkIIRedfishETagProtocolGuid   ## CONSUMED ##
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
index d2bd6507..5d39984c 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
@@ -2,6 +2,7 @@
   Common header file for RedfishFeatureUtilityLib driver.
 
   (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
+  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -28,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index e1899878..13e29902 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -133,7 +133,7 @@ SetEtagWithUri (
 
   Status = RedfishLocateProtocol ((VOID **), 
);
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a, fail to locate gEdkIIRedfishETagProtocolGuid: 
%r\n", __func__, Status));
+DEBUG ((DEBUG_ERROR, "%a: fail to locate gEdkIIRedfishETagProtocolGuid: 
%r\n", __func__, Status));
 return Status;
   }
 
@@ -175,7 +175,7 @@ GetEtagWithUri (
 
   Status = RedfishLocateProtocol ((VOID **), 
);
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a, fail to locate gEdkIIRedfishETagProtocolGuid: 
%r\n", __func__, Status));
+DEBUG ((DEBUG_ERROR, "%a: fail to locate gEdkIIRedfishETagProtocolGuid: 
%r\n", __func__, Status));
 return NULL;
   }
 
@@ -306,10 +306,10 @@ ApplyFeatureSettingsStringType (
   //
   Status = RedfishPlatformConfigGetValue (Schema, Version, ConfigureLang, 
);
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a, %a.%a %s failed: %r\n", __func__, Schema, 
Version, ConfigureLang, Status));
+DEBUG ((DEBUG_ERROR, "%a: %a.%a %s failed: %r\n", __func__, Schema, 
Version, ConfigureLang, Status));
   } else {
 if (RedfishValue.Type != RedfishValueTypeString) {
-  DEBUG ((DEBUG_ERROR, "%a, %a.%a %s value is not string type\n", 
__func__, Schema, Version, ConfigureLang));
+  DEBUG ((DEBUG_ERROR, "%a: %a.%a %s value is not string type\n", 
__func__, Schema, Version, ConfigureLang));
   return EFI_DEVICE_ERROR;
 }
 
@@ -317,7 +317,7 @@ ApplyFeatureSettingsStringType (
   //
   // Apply settings from redfish
   //
-  DEBUG ((DEBUG_MANAGEABILITY, "%a, %a.%a apply %s from %a 

[edk2-devel] [edk2-redfish-client][PATCH 2/3] RedfishClientPkg/RedfishConfigLangMapDxe: uninitialized variable issue

[Nickle Wang via groups.io]

-RedfishConfigLangMapDxe relies on variable arch protocol.
-Status variable is not initialized.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 .../RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf   | 4 ++--
 .../RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.c | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git 
a/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf 
b/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
index 821f0552..42d9daf2 100644
--- a/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
+++ b/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #
 #  (C) Copyright 2022 Hewlett Packard Enterprise Development LP
-#  Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+#  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -45,4 +45,4 @@
   gEfiRedfishClientVariableGuid  ## CONSUMED ##
 
 [Depex]
-  TRUE
+  gEfiVariableArchProtocolGuid
diff --git a/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.c 
b/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.c
index 6a72afed..97f29549 100644
--- a/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.c
+++ b/RedfishClientPkg/RedfishConfigLangMapDxe/RedfishConfigLangMapDxe.c
@@ -1,7 +1,7 @@
 /** @file
 
   (C) Copyright 2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -756,6 +756,7 @@ RedfishConfigLangMapDriverEntryPoint (
   InitializeListHead 
(>ConfigLangList.Listheader);
   mRedfishConfigLangMapPrivate->VariableName = AllocateCopyPool (StrSize 
(CONFIG_LANG_MAP_VARIABLE_NAME), CONFIG_LANG_MAP_VARIABLE_NAME);
   if (mRedfishConfigLangMapPrivate->VariableName == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
 goto ON_ERROR;
   }
 
-- 
2.17.1



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

[edk2-devel] [edk2-redfish-client][PATCH 1/3] RedfishClientPkg/RedfishETagDxe: fix uninitialized variable issue

[Nickle Wang via groups.io]

Status variable is not initialized.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
---
 RedfishClientPkg/RedfishETagDxe/RedfishETagDxe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/RedfishClientPkg/RedfishETagDxe/RedfishETagDxe.c 
b/RedfishClientPkg/RedfishETagDxe/RedfishETagDxe.c
index a892ced9..f731d39d 100644
--- a/RedfishClientPkg/RedfishETagDxe/RedfishETagDxe.c
+++ b/RedfishClientPkg/RedfishETagDxe/RedfishETagDxe.c
@@ -1,7 +1,7 @@
 /** @file
 
   (C) Copyright 2021-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -728,6 +728,7 @@ RedfishETagDriverEntryPoint (
   InitializeListHead (>ETagList.Listheader);
   mRedfishETagPrivate->VariableName = AllocateCopyPool (StrSize 
(ETAG_VARIABLE_NAME), ETAG_VARIABLE_NAME);
   if (mRedfishETagPrivate->VariableName == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
 goto ON_ERROR;
   }
 
-- 
2.17.1



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

[edk2-devel] [edk2-redfish-client][PATCH 0/3] Fix various issues and enhancement.

[Nickle Wang via groups.io]

Fix various issues and add enhancement to RedfishClientPkg. 
PR is opened here: https://github.com/tianocore/edk2-redfish-client/pull/55

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 

Nickle Wang (3):
  RedfishClientPkg/RedfishETagDxe: fix uninitialized variable issue
  RedfishClientPkg/RedfishConfigLangMapDxe: uninitialized variable issue
  RedfishClientPkg/RedfishFeatureUtilityLib: fix issues and enhancement

 RedfishClientPkg/RedfishClientLibs.dsc.inc|   1 +
 .../RedfishFeatureUtilityLib.inf  |   1 +
 .../RedfishConfigLangMapDxe.inf   |   4 +-
 .../RedfishFeatureUtilityInternal.h   |   2 +
 .../RedfishFeatureUtilityLib.c| 272 ++
 .../RedfishConfigLangMapDxe.c |   3 +-
 .../RedfishETagDxe/RedfishETagDxe.c   |   3 +-
 7 files changed, 160 insertions(+), 126 deletions(-)

-- 
2.17.1



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

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Mon, Oct 30, 2023 at 11:24:15PM -0700, Dhaval Sharma wrote:
> Can we define these bits in the header file so that the definitions can
> be used by multiple modules?
> [Dhaval] I could put it un Baselib.h (MDE_CPU_RISCV64) but sounds like right 
> now BaseLib.h is free of such #defines. If you think it is still better would 
> do it. I do not have any preference.
Right, fine then.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110378): https://edk2.groups.io/g/devel/message/110378
Mute This Topic: https://groups.io/mt/102256468/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 v3 00/16] MTCP-over-KCS support

[Chang, Abner via groups.io]

MCTP over KCS defines two types of KCS-like access, one is compatible with IPMI 
KCS, another is memory map I/O access. It doesn't require any special HW, just 
require the I/O cycle or memory cycle can be delivered to the management 
controller.
Yes, we can consider MCTP is a software layer protocol and the that protocol is 
HW (transport interface) agnostic.

Abner

From: Yoshinoya 
Sent: Tuesday, October 31, 2023 2:38 PM
To: devel@edk2.groups.io; Chang, Abner 
Cc: Konstantin Aladyshev ; Attar, AbdulLateef (Abdul 
Lateef) ; nick...@nvidia.com
Subject: Re:Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS 
support

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

Hi, Abner:
I ask you a favor.

KCS actually layer on LPC interface.
KCS is a usual BMC-to-CPU communication channel.

Does MCTP-over-KCS feature require some special LPC interface hardware changes?
Or, MCTP is just a software stack and it uses current LPC interface, not any 
special hardward design change requirement.



Thanks







At 2023-10-26 13:03:02, "Chang, Abner via groups.io" 
mailto:abner.chang=amd@groups.io>> wrote:

>[AMD Official Use Only - General]

>

>Merged.   I will send another patch for Uncrustify updates if any.

>

>Abner

>

>> -Original Message-

>> From: Chang, Abner

>> Sent: Tuesday, October 24, 2023 10:44 AM

>> To: Konstantin Aladyshev 
>> mailto:aladyshe...@gmail.com>>; 
>> devel@edk2.groups.io

>> Cc: Attar, AbdulLateef (Abdul Lateef) 
>> mailto:abdullateef.at...@amd.com>>;

>> nick...@nvidia.com

>> Subject: RE: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

>>

>> For entire V3 and the additional patch 16/16,

>> Reviewed-by: Abner Chang mailto:abner.ch...@amd.com>>

>>

>> I will do the Uncrustify check and merge this patch set once the 
>> corresponding

>> edk2 changes are merged.

>> Thanks

>> Abner

>>

>> > -Original Message-

>> > From: Konstantin Aladyshev 
>> > mailto:aladyshe...@gmail.com>>

>> > Sent: Monday, October 23, 2023 9:05 PM

>> > To: devel@edk2.groups.io

>> > Cc: Chang, Abner mailto:abner.ch...@amd.com>>; Attar, 
>> > AbdulLateef (Abdul

>> > Lateef) mailto:abdullateef.at...@amd.com>>; 
>> > nick...@nvidia.com; Konstantin

>> > Aladyshev mailto:aladyshe...@gmail.com>>

>> > Subject: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

>> >

>> > Caution: This message originated from an External Source. Use proper

>> caution

>> > when opening attachments, clicking links, or responding.

>> >

>> >

>> > The Manageability KCS transport library needs to support requests both

>> > from MCTP and IPMI transports. Currently the code only handles IPMI

>> > case correctly.

>> > In the MCTP case the communication should be based on the MCTP-over-

>> KCS

>> > specification (DSP0254). This specification defines a special KCS

>> > binding header and trailer structures that need to be present in every

>> > MCTP message.

>> > The header structure contains a length field, therefore response packet

>> > size is not needed to be known beforehand.

>> > The trailer structure contains a PEC checksum that can be used to check

>> > itegrity of the response message.

>> > Modify Manageability KCS transport library code to check which message

>> > is processed (IPMI or MCTP) and handle each case correctly based on its

>> > own specification.

>> > This patch is a result of a joint effort from the Konstantin Aladyshev

>> > mailto:aladyshe...@gmail.com>> and Abner Chang 
>> > mailto:abner.ch...@amd.com>>.

>> >

>> > Tested:

>> > PLDM communication between the HOST and BMC was tested with both

>> > components implemented via open-source software:

>> > - The HOST (UEFI firmware) part was based one the edk2 [1] and

>> > edk2-platforms [2] code,

>> > - The BMC part was based on the openbmc [3] distribution.

>> >

>> > The testing process and all the necessary utilities are described in

>> > the [4] repository.

>> >

>> > The provided changes keep IPMI over KCS stack working as reported by

>> > Abner Chang.

>> >

>> > [1]: https://github.com/tianocore/edk2

>> > [2]: https://github.com/tianocore/edk2-platforms

>> > [3]: https://github.com/openbmc/openbmc

>> > [4]: https://github.com/Kostr/PLDM

>> >

>> > Changes v2 -> v3:

>> >  - Add new patch that adds PLDM completion code check

>> >

>> > Changes v1 -> v2:

>> >  - Add new patches with corrections for the PLDM protocol. The

>> >   resulting communication via EDKII_PLDM_PROTOCOL was successfully

>> >   tested.

>> >

>> > Abner Chang (4):

>> >   ManageabilityPkg: Add PLDM terminus PCDs

>> >   PldmProtocolDxe: Correct TID argument usage

>> >   ManageabilityPkg/PldmProtocol: Remove PLDM command table

>> >   PldmSmbiosTransferDxe: Implement Set PLDM terminus ID API

>> >

>> > Konstantin Aladyshev 

Re: [edk2-devel] [PATCH v4 1/1] IpmiFeaturePkg/GenericIpmi: Support Standalone MM

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

I can help to merge this change if maintainer or review have no problem with 
it, as I am not any of those.
Abner

> -Original Message-
> From: Lixia Huang 
> Sent: Tuesday, October 31, 2023 2:24 PM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Nate DeSimone
> 
> Subject: [PATCH v4 1/1] IpmiFeaturePkg/GenericIpmi: Support Standalone
> MM
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Add Standalone Mm Generic Impi driver. And add type 'PcdsFixedAtBuild'
> for PcdIpmiSmmIoBaseAddress to access in StandaloneMm driver
>
> Cc: Abner Chang 
> Cc: Nate DeSimone 
> Signed-off-by: Lixia Huang 
> ---
>
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Standa
> loneMm/StandaloneMmGenericIpmi.c   | 146 
>
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Standa
> loneMm/StandaloneMmGenericIpmi.inf |  51 +++
>
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec
> |   2 +
>  3 files changed, 199 insertions(+)
>
> diff --git
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
> daloneMm/StandaloneMmGenericIpmi.c
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
> daloneMm/StandaloneMmGenericIpmi.c
> new file mode 100644
> index ..d808e2517c99
> --- /dev/null
> +++
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
> daloneMm/StandaloneMmGenericIpmi.c
> @@ -0,0 +1,146 @@
> +/** @file
> +  Generic StandaloneMm IPMI stack driver
> +
> +  Copyright 2023 Intel Corporation. 
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +//
> +// Statements that include other files
> +//
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "IpmiHooks.h"
> +#include "IpmiBmcCommon.h"
> +#include "IpmiBmc.h"
> +
> +IPMI_BMC_INSTANCE_DATA *mIpmiInstance;
> +EFI_HANDLE mHandle;
> +
> +/**
> +Routine Description:
> +  Setup and initialize the BMC for the SMM phase.  In order to verify the BMC
> is functioning
> +  as expected, the BMC Selftest is performed.  The results are then checked
> and any errors are
> +  reported to the error manager.  Errors are collected throughout this 
> routine
> and reported
> +  just prior to installing the driver.  If there are more errors than
> MAX_SOFT_COUNT, then they
> +  will be ignored.
> +
> +Arguments:
> +  ImageHandle - Handle of this driver image
> +  SystemTable - Table containing standard EFI services
> +
> +Returns:
> +  EFI_SUCCESS - Successful driver initialization
> +
> +**/
> +EFI_STATUS
> +SmmInitializeIpmiKcsPhysicalLayer (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +
> +  DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer entry \n"));
> +
> +  Status = gMmst->MmAllocatePool (
> +EfiRuntimeServicesData,
> +sizeof (IPMI_BMC_INSTANCE_DATA),
> +(VOID **));
> +
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "mIpmiInstance mem alloc failed - 0x%x\n",
> Status));
> +return Status;
> +  } else {
> +
> +//
> +// Initialize the KCS transaction timeout. Assume delay unit is 1000 us.
> +//
> +mIpmiInstance->KcsTimeoutPeriod = (BMC_KCS_TIMEOUT * 1000*1000) /
> KCS_DELAY_UNIT;
> +
> +//
> +// Initialize IPMI IO Base, we still use SMS IO base to get device ID and
> Seltest result since SMM IF may have different cmds supported
> +//
> +mIpmiInstance->IpmiIoBase   = FixedPcdGet16
> (PcdIpmiSmmIoBaseAddress);
> +mIpmiInstance->Signature= SM_IPMI_BMC_SIGNATURE;
> +mIpmiInstance->SlaveAddress = BMC_SLAVE_ADDRESS;
> +mIpmiInstance->BmcStatus= BMC_NOTREADY;
> +mIpmiInstance->IpmiTransport.IpmiSubmitCommand  =
> IpmiSendCommand;
> +mIpmiInstance->IpmiTransport.GetBmcStatus   = IpmiGetBmcStatus;
> +
> +mHandle = NULL;
> +Status = gMmst->MmInstallProtocolInterface (
> +  ,
> +  ,
> +  EFI_NATIVE_INTERFACE,
> +  >IpmiTransport
> +  );
> +ASSERT_EFI_ERROR (Status);
> +
> +DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer exit \n"));
> +
> +return EFI_SUCCESS;
> +  }
> +}
> +
> +/**
> +  The module Entry Point of driver.
> +
> +  @param[in]  ImageHandleThe firmware allocated handle for the EFI
> image.
> +  @param[in]  SystemTableA pointer to the MM System Table.
> +
> +  @retval EFI_SUCCESSThe entry point is executed successfully.
> +  @retval Other  Some error occurs when executing this entry point.
> +
> +**/
> +EFI_STATUS
> +InitializeGenericIpmiStandaloneMm 

Re: [edk2-devel] [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential memory leak issue

[Xu, Wei6]

Thanks a lot for reviewing the patch.
I have different opinions with (2), could you please check that? Thanks a lot.
If you agree (2) is not an issue, I will prepare a new patch version to only 
address (1) and (3)

BR,
Wei
>-Original Message-
>From: Laszlo Ersek 
>Sent: Monday, October 30, 2023 8:25 PM
>To: Xu, Wei6 ; devel@edk2.groups.io
>Cc: Ard Biesheuvel ; Sami Mujawar
>; Ni, Ray 
>Subject: Re: [PATCH v3 2/4] StandaloneMmPkg/Core: Fix potential memory
>leak issue
>
>On 10/30/23 08:49, Wei6 Xu wrote:
>> In MmCoreFfsFindMmDriver(), ScratchBuffer is not freed in the error
>> return path that DstBuffer page allocation fails. Free ScratchBuffer
>> before return with error.
>>
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Sami Mujawar 
>> Cc: Ray Ni 
>> Signed-off-by: Wei6 Xu 
>> ---
>>  StandaloneMmPkg/Core/FwVol.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/StandaloneMmPkg/Core/FwVol.c
>> b/StandaloneMmPkg/Core/FwVol.c index e1e20ffd14ac..9d0ce66ef839
>100644
>> --- a/StandaloneMmPkg/Core/FwVol.c
>> +++ b/StandaloneMmPkg/Core/FwVol.c
>> @@ -150,6 +150,7 @@ MmCoreFfsFindMmDriver (
>>  //
>>  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
>(DstBufferSize));
>>  if (DstBuffer == NULL) {
>> +  FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES
>> + (ScratchBufferSize));
>>return EFI_OUT_OF_RESOURCES;
>>  }
>>
>
>This patch is good, with regard to ScratchBuffer:
>
>Reviewed-by: Laszlo Ersek 
>
>However, upon further staring at the code, I think that we have a DstBuffer
>life-cycle problem as well, independently of ScratchBuffer:
>
>(1) ExtractGuidedSectionDecode() does not necessarily use the caller-
>allocated buffer. The library class header file
>"MdePkg/Include/Library/ExtractGuidedSectionLib.h" says that, "If the
>decoded buffer is identical to the data in InputSection, then OutputBuffer is
>set to point at the data in InputSection.  Otherwise, the decoded data will be
>placed in caller allocated buffer specified by OutputBuffer."
>
>This means that the ExtractGuidedSectionDecode() call may change the value
>of DstBuffer (rather than changing the contents of the buffer that DstBuffer
>points at) -- in which case freeing DstBuffer is wrong.
>
>This means we need a second variable. One variable needs to preserve the
>allocation address, and the address of the other variable must be passed to
>ExtractGuidedSectionDecode(). After the call, we need to free the
>*original* variable (the one that ExtractGuidedSectionDecode() could not
>have overwritten).
>

Will prepare a new patch version to address this.

>(2) As far as I can tell, we leak our original DstBuffer allocation in two 
>cases:
>
>- Upon every iteration of the loop after the first iteration, we overwrite the
>DstBuffer variable with the new allocation address. The old one is lost 
>(leaked).
>
>My understanding is that, after the recursive MmCoreFfsFindMmDriver() call
>returns, we no longer need the decompressed DstBuffer, therefore, we
>should free the *original* DstBuffer allocation (per (1)) right there.
>
>- The last (potentially: only one) iteration of the loop allocates DstBuffer, 
>and
>that allocation is never freed. We don't overwrite the address with a new
>allocation's address, but still we never free the original allocation. The
>FreeDstBuffer label is apparently never reached.
>

In the success case, DstBuffer should NOT be freed, because the buffer holds 
the MM drivers, which will be used in the driver dispatch process later.

>(3) And finally, a logic bug (or at least questionable behavior):
>
>The loop at the *top* of the function scans the firmware volume for
>embedded firmware volumes (recursing into them if any are found), while
>the loop at the *bottom* of the function scans the *same* firmware volume
>for MM driver binaries (adding them to the "MM driver list"), starting anew
>from the beginning of the firmware volume.
>
>Now, there are many exit points in the function-top loop. Those can be
>classified in two groups: "break", and "return/goto". The former class makes
>sense. The latter class does not seem to make sense to me.
>
>Consider: just because we fail to scan the firmware volume for embedded
>firmware volumes, for any reason really, should we really abandon scanning
>the same firmware volume for MM driver binaries? What I don't understand
>here in particular is the *inconsistency* between the exit points, in the
>function-top loop:
>
>- if we realize there are no (more) embedded FVs, we break out; good
>
>- if we realize the next embedded FV is not "GUID defined", we break out;
>good (well, questionable -- perhaps we should continue scanning?
>the next embedded FV could be GUID defined after all!)
>

If the FfsFindSectionData with EFI_SECTION_GUID_DEFINED fails, it means there 
is no GUID defined embedded FV at all in current FwVol. No need to continue 
scanning.

>- if ExtractGuidedSectionGetInfo() fails, we break out again; good (or, well, 
>we
>could 

Re: [edk2-devel] [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support

[Yoshinoya]

Hi, Abner:
I ask you a favor.


KCS actually layer on LPC interface.
KCS is a usual BMC-to-CPU communication channel.


Does MCTP-over-KCS feature require some special LPC interface hardware changes?
Or, MCTP is just a software stack and it uses current LPC interface, not any 
special hardward design change requirement.




Thanks











At 2023-10-26 13:03:02, "Chang, Abner via groups.io" 
 wrote:
>[AMD Official Use Only - General]
>
>Merged.   I will send another patch for Uncrustify updates if any.
>
>Abner
>
>> -Original Message-
>> From: Chang, Abner
>> Sent: Tuesday, October 24, 2023 10:44 AM
>> To: Konstantin Aladyshev ; devel@edk2.groups.io
>> Cc: Attar, AbdulLateef (Abdul Lateef) ;
>> nick...@nvidia.com
>> Subject: RE: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support
>>
>> For entire V3 and the additional patch 16/16,
>> Reviewed-by: Abner Chang 
>>
>> I will do the Uncrustify check and merge this patch set once the 
>> corresponding
>> edk2 changes are merged.
>> Thanks
>> Abner
>>
>> > -Original Message-
>> > From: Konstantin Aladyshev 
>> > Sent: Monday, October 23, 2023 9:05 PM
>> > To: devel@edk2.groups.io
>> > Cc: Chang, Abner ; Attar, AbdulLateef (Abdul
>> > Lateef) ; nick...@nvidia.com; Konstantin
>> > Aladyshev 
>> > Subject: [PATCH edk2-platforms v3 00/16] MTCP-over-KCS support
>> >
>> > Caution: This message originated from an External Source. Use proper
>> caution
>> > when opening attachments, clicking links, or responding.
>> >
>> >
>> > The Manageability KCS transport library needs to support requests both
>> > from MCTP and IPMI transports. Currently the code only handles IPMI
>> > case correctly.
>> > In the MCTP case the communication should be based on the MCTP-over-
>> KCS
>> > specification (DSP0254). This specification defines a special KCS
>> > binding header and trailer structures that need to be present in every
>> > MCTP message.
>> > The header structure contains a length field, therefore response packet
>> > size is not needed to be known beforehand.
>> > The trailer structure contains a PEC checksum that can be used to check
>> > itegrity of the response message.
>> > Modify Manageability KCS transport library code to check which message
>> > is processed (IPMI or MCTP) and handle each case correctly based on its
>> > own specification.
>> > This patch is a result of a joint effort from the Konstantin Aladyshev
>> >  and Abner Chang .
>> >
>> > Tested:
>> > PLDM communication between the HOST and BMC was tested with both
>> > components implemented via open-source software:
>> > - The HOST (UEFI firmware) part was based one the edk2 [1] and
>> > edk2-platforms [2] code,
>> > - The BMC part was based on the openbmc [3] distribution.
>> >
>> > The testing process and all the necessary utilities are described in
>> > the [4] repository.
>> >
>> > The provided changes keep IPMI over KCS stack working as reported by
>> > Abner Chang.
>> >
>> > [1]: https://github.com/tianocore/edk2
>> > [2]: https://github.com/tianocore/edk2-platforms
>> > [3]: https://github.com/openbmc/openbmc
>> > [4]: https://github.com/Kostr/PLDM
>> >
>> > Changes v2 -> v3:
>> >  - Add new patch that adds PLDM completion code check
>> >
>> > Changes v1 -> v2:
>> >  - Add new patches with corrections for the PLDM protocol. The
>> >   resulting communication via EDKII_PLDM_PROTOCOL was successfully
>> >   tested.
>> >
>> > Abner Chang (4):
>> >   ManageabilityPkg: Add PLDM terminus PCDs
>> >   PldmProtocolDxe: Correct TID argument usage
>> >   ManageabilityPkg/PldmProtocol: Remove PLDM command table
>> >   PldmSmbiosTransferDxe: Implement Set PLDM terminus ID API
>> >
>> > Konstantin Aladyshev (12):
>> >   ManageabilityPkg: Add definition for the MCTP KCS TRAILER structure
>> >   ManageabilityPkg: Check MCTP EIDs for reserved values
>> >   ManageabilityPkg: Support both MCTP and IPMI in KCS tranport library
>> >   ManageabilityPkg: Check header fields in the MCTP response
>> >   ManageabilityPkg: Correct typo in MCTP destination EID field
>> >   ManageabilityPkg: Update the algorithm of using MCTP endpoint ID PCD
>> >   ManageabilityPkg: Correct value for the MCTP TAG_OWNER response bit
>> >   ManageabilityPkg: Don't check MCTP header fields if transfer has
>> > failed
>> >   ManageabilityPkg: Use correct constants for PLDM header checks
>> >   ManageabilityPkg: Return error on multiple-packet MCTP responses
>> >   ManageabilityPkg: Return error on PLDM header check fails
>> >   ManageabilityPkg: Check PLDM completion code
>> >
>> >  .../Include/Library/BasePldmProtocolLib.h |  16 +
>> >  .../Library/ManageabilityTransportMctpLib.h   |   9 +-
>> >  .../Include/Protocol/MctpProtocol.h   |  12 +-
>> >  .../Include/Protocol/PldmProtocol.h   |  18 +-
>> >  .../Protocol/PldmSmbiosTransferProtocol.h |  26 ++
>> >  .../Common/KcsCommon.c| 284 +++---
>> >  .../Dxe/ManageabilityTransportMctp.c  |   4 +-
>> >  

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

[Jordan Justen]

On 2023-10-28 12:23:30, Michael D Kinney wrote:
> @@ -497,7 +463,6 @@ F: OvmfPkg/
>  W: http://www.tianocore.org/ovmf/
>  M: Ard Biesheuvel  [ardbiesheuvel]
>  M: Jiewen Yao  [jyao1]
> -R: Jordan Justen  [jljusten]
>  R: Gerd Hoffmann  [kraxel]
>  S: Maintained

Acked-by: Jordan Justen 


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

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Dhaval Sharma]

Can we define these bits in the header file so that the definitions can
be used by multiple modules?
[Dhaval] I could put it un Baselib.h (MDE_CPU_RISCV64) but sounds like right 
now BaseLib.h is free of such #defines. If you think it is still better would 
do it. I do not have any preference.


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

[edk2-devel] [PATCH v4 1/1] IpmiFeaturePkg/GenericIpmi: Support Standalone MM

[Huang, Li-Xia]

Add Standalone Mm Generic Impi driver. And add type 'PcdsFixedAtBuild'
for PcdIpmiSmmIoBaseAddress to access in StandaloneMm driver

Cc: Abner Chang 
Cc: Nate DeSimone 
Signed-off-by: Lixia Huang 
---
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
   | 146 
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.inf
 |  51 +++
 Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec   
|   2 +
 3 files changed, 199 insertions(+)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
new file mode 100644
index ..d808e2517c99
--- /dev/null
+++ 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
@@ -0,0 +1,146 @@
+/** @file
+  Generic StandaloneMm IPMI stack driver
+
+  Copyright 2023 Intel Corporation. 
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+//
+// Statements that include other files
+//
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "IpmiHooks.h"
+#include "IpmiBmcCommon.h"
+#include "IpmiBmc.h"
+
+IPMI_BMC_INSTANCE_DATA *mIpmiInstance;
+EFI_HANDLE mHandle;
+
+/**
+Routine Description:
+  Setup and initialize the BMC for the SMM phase.  In order to verify the BMC 
is functioning
+  as expected, the BMC Selftest is performed.  The results are then checked 
and any errors are
+  reported to the error manager.  Errors are collected throughout this routine 
and reported
+  just prior to installing the driver.  If there are more errors than 
MAX_SOFT_COUNT, then they
+  will be ignored.
+
+Arguments:
+  ImageHandle - Handle of this driver image
+  SystemTable - Table containing standard EFI services
+
+Returns:
+  EFI_SUCCESS - Successful driver initialization
+
+**/
+EFI_STATUS
+SmmInitializeIpmiKcsPhysicalLayer (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+
+  DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer entry \n"));
+
+  Status = gMmst->MmAllocatePool (
+EfiRuntimeServicesData,
+sizeof (IPMI_BMC_INSTANCE_DATA),
+(VOID **));
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "mIpmiInstance mem alloc failed - 0x%x\n", Status));
+return Status;
+  } else {
+
+//
+// Initialize the KCS transaction timeout. Assume delay unit is 1000 us.
+//
+mIpmiInstance->KcsTimeoutPeriod = (BMC_KCS_TIMEOUT * 1000*1000) / 
KCS_DELAY_UNIT;
+
+//
+// Initialize IPMI IO Base, we still use SMS IO base to get device ID and 
Seltest result since SMM IF may have different cmds supported
+//
+mIpmiInstance->IpmiIoBase   = FixedPcdGet16 
(PcdIpmiSmmIoBaseAddress);
+mIpmiInstance->Signature= SM_IPMI_BMC_SIGNATURE;
+mIpmiInstance->SlaveAddress = BMC_SLAVE_ADDRESS;
+mIpmiInstance->BmcStatus= BMC_NOTREADY;
+mIpmiInstance->IpmiTransport.IpmiSubmitCommand  = IpmiSendCommand;
+mIpmiInstance->IpmiTransport.GetBmcStatus   = IpmiGetBmcStatus;
+
+mHandle = NULL;
+Status = gMmst->MmInstallProtocolInterface (
+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  >IpmiTransport
+  );
+ASSERT_EFI_ERROR (Status);
+
+DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer exit \n"));
+
+return EFI_SUCCESS;
+  }
+}
+
+/**
+  The module Entry Point of driver.
+
+  @param[in]  ImageHandleThe firmware allocated handle for the EFI image.
+  @param[in]  SystemTableA pointer to the MM System Table.
+
+  @retval EFI_SUCCESSThe entry point is executed successfully.
+  @retval Other  Some error occurs when executing this entry point.
+
+**/
+EFI_STATUS
+InitializeGenericIpmiStandaloneMm (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE*SystemTable
+  )
+{
+  SmmInitializeIpmiKcsPhysicalLayer ();
+  return EFI_SUCCESS;
+}
+
+/**
+  Unloads an image.
+
+  @param[in] ImageHandleHandle that identifies the image to be 
unloaded.
+
+  @retval EFI_SUCCESS   The image has been unloaded.
+  @retval EFI_INVALID_PARAMETER ImageHandle is not a valid image handle.
+
+**/
+EFI_STATUS
+EFIAPI
+GenericIpmiStandaloneMmUnload (
+  IN EFI_HANDLE ImageHandle
+  )
+{
+  EFI_STATUSStatus;
+
+  Status = EFI_SUCCESS;
+  if (mIpmiInstance != NULL) {
+if (mHandle != NULL) {
+  Status = gMmst->MmUninstallProtocolInterface (
+mHandle,
+,
+>IpmiTransport

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Dhaval Sharma]

NIT: I am wondering whether PcdRiscVCpuFeatureDisable is better so that
it is explicit.
[Dhaval] Well setting it to 1 would mean feature is enabled. Do it would be 
confusing to see PcdRiscVCpuFeatureDisable == 1 means feature is enabled.


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

Re: [edk2-devel] [PATCH v7 5/5] OvmfPkg/RiscVVirt: Override for RV CPU Features

[Dhaval Sharma]

Thanks. This PCD is for Virt platform only. Or maybe I am missing the point.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110369): https://edk2.groups.io/g/devel/message/110369
Mute This Topic: https://groups.io/mt/102256471/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 1/1] IpmiFeaturePkg/GenericIpmi: Support Standalone MM

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

> -Original Message-
> From: Lixia Huang 
> Sent: Tuesday, October 31, 2023 2:00 PM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Nate DeSimone
> 
> Subject: [PATCH v3 1/1] IpmiFeaturePkg/GenericIpmi: Support Standalone
> MM
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Add Standalone Mm Generic Impi driver. And add type 'PcdsFixedAtBuild'
> for PcdIpmiSmmIoBaseAddress to access in StandaloneMm driver
>
> Cc: Abner Chang 
> Cc: Nate DeSimone 
> Signed-off-by: Lixia Huang 
> ---
>
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Standa
> loneMm/StandaloneMmGenericIpmi.c   | 148 
>
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Standa
> loneMm/StandaloneMmGenericIpmi.inf |  51 +++
>
> Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec
> |   2 +
>  3 files changed, 201 insertions(+)
>
> diff --git
> a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
> daloneMm/StandaloneMmGenericIpmi.c
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
> daloneMm/StandaloneMmGenericIpmi.c
> new file mode 100644
> index ..8c07845917be
> --- /dev/null
> +++
> b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
> daloneMm/StandaloneMmGenericIpmi.c
> @@ -0,0 +1,148 @@
> +/** @file
> +  Generic StandaloneMm IPMI stack driver
> +
> +  Copyright 2023 Intel Corporation. 
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +//
> +// Statements that include other files
> +//
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "IpmiHooks.h"
> +#include "IpmiBmcCommon.h"
> +#include "IpmiBmc.h"
> +
> +IPMI_BMC_INSTANCE_DATA *mIpmiInstance;
> +EFI_HANDLE mHandle;
> +
> +/*++
> +
> +Routine Description:
> +  Setup and initialize the BMC for the SMM phase.  In order to verify the BMC
> is functioning
> +  as expected, the BMC Selftest is performed.  The results are then checked
> and any errors are
> +  reported to the error manager.  Errors are collected throughout this 
> routine
> and reported
> +  just prior to installing the driver.  If there are more errors than
> MAX_SOFT_COUNT, then they
> +  will be ignored.
> +
> +Arguments:
> +  ImageHandle - Handle of this driver image
> +  SystemTable - Table containing standard EFI services
> +
> +Returns:
> +  EFI_SUCCESS - Successful driver initialization
> +
> +--*/
Your function comment blocks are not in a consistent format across the file. 
You can unify them with the format "/**  **/ ".

Abner


> +EFI_STATUS
> +SmmInitializeIpmiKcsPhysicalLayer (
> +  VOID
> +  )
> +
> +{
> +  EFI_STATUS   Status;
> +
> +  DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer entry \n"));
> +
> +  Status = gMmst->MmAllocatePool (
> +EfiRuntimeServicesData,
> +sizeof (IPMI_BMC_INSTANCE_DATA),
> +(VOID **));
> +
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "mIpmiInstance mem alloc failed - 0x%x\n",
> Status));
> +return Status;
> +  } else {
> +
> +//
> +// Initialize the KCS transaction timeout. Assume delay unit is 1000 us.
> +//
> +mIpmiInstance->KcsTimeoutPeriod = (BMC_KCS_TIMEOUT * 1000*1000) /
> KCS_DELAY_UNIT;
> +
> +//
> +// Initialize IPMI IO Base, we still use SMS IO base to get device ID and
> Seltest result since SMM IF may have different cmds supported
> +//
> +mIpmiInstance->IpmiIoBase   = FixedPcdGet16
> (PcdIpmiSmmIoBaseAddress);
> +mIpmiInstance->Signature= SM_IPMI_BMC_SIGNATURE;
> +mIpmiInstance->SlaveAddress = BMC_SLAVE_ADDRESS;
> +mIpmiInstance->BmcStatus= BMC_NOTREADY;
> +mIpmiInstance->IpmiTransport.IpmiSubmitCommand  =
> IpmiSendCommand;
> +mIpmiInstance->IpmiTransport.GetBmcStatus   = IpmiGetBmcStatus;
> +
> +mHandle = NULL;
> +Status = gMmst->MmInstallProtocolInterface (
> +  ,
> +  ,
> +  EFI_NATIVE_INTERFACE,
> +  >IpmiTransport
> +  );
> +ASSERT_EFI_ERROR (Status);
> +
> +DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer exit \n"));
> +
> +return EFI_SUCCESS;
> +  }
> +}
> +
> +/**
> +  The module Entry Point of driver.
> +
> +  @param[in]  ImageHandleThe firmware allocated handle for the EFI
> image.
> +  @param[in]  SystemTableA pointer to the MM System Table.
> +
> +  @retval EFI_SUCCESSThe entry point is executed successfully.
> +  @retval Other  Some error occurs when executing this entry point.
> +
> +**/
> +EFI_STATUS
> 

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo . r00ta]

Hi Laszlo,

If I generate the certificate like

openssl req -new -nodes -x509 -days 365 -keyout server.key -out server.crt 
-config config

it works perfectly fine (with the original configuration).

The problem stands with the *chain* of certificates, meaning that I have a root 
certificate (let's call it A) and sign another one for an IP (let's call it B). 
Then in the image server with such IP I set the certificate B, and in the VM I 
trust the certificate A. Unless I missed something, this scenario is not 
covered in 
https://listman.redhat.com/archives/edk2-devel-archive/2019-October/009601.html.

Could you confirm this is supposed to work?

Thank you very much for your time on this, I appreciate it!

Jacopo


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

[edk2-devel] [PATCH v3 1/1] IpmiFeaturePkg/GenericIpmi: Support Standalone MM

[Huang, Li-Xia]

Add Standalone Mm Generic Impi driver. And add type 'PcdsFixedAtBuild'
for PcdIpmiSmmIoBaseAddress to access in StandaloneMm driver

Cc: Abner Chang 
Cc: Nate DeSimone 
Signed-off-by: Lixia Huang 
---
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
   | 148 
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.inf
 |  51 +++
 Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec   
|   2 +
 3 files changed, 201 insertions(+)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
new file mode 100644
index ..8c07845917be
--- /dev/null
+++ 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
@@ -0,0 +1,148 @@
+/** @file
+  Generic StandaloneMm IPMI stack driver
+
+  Copyright 2023 Intel Corporation. 
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+//
+// Statements that include other files
+//
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "IpmiHooks.h"
+#include "IpmiBmcCommon.h"
+#include "IpmiBmc.h"
+
+IPMI_BMC_INSTANCE_DATA *mIpmiInstance;
+EFI_HANDLE mHandle;
+
+/*++
+
+Routine Description:
+  Setup and initialize the BMC for the SMM phase.  In order to verify the BMC 
is functioning
+  as expected, the BMC Selftest is performed.  The results are then checked 
and any errors are
+  reported to the error manager.  Errors are collected throughout this routine 
and reported
+  just prior to installing the driver.  If there are more errors than 
MAX_SOFT_COUNT, then they
+  will be ignored.
+
+Arguments:
+  ImageHandle - Handle of this driver image
+  SystemTable - Table containing standard EFI services
+
+Returns:
+  EFI_SUCCESS - Successful driver initialization
+
+--*/
+EFI_STATUS
+SmmInitializeIpmiKcsPhysicalLayer (
+  VOID
+  )
+
+{
+  EFI_STATUS   Status;
+
+  DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer entry \n"));
+
+  Status = gMmst->MmAllocatePool (
+EfiRuntimeServicesData,
+sizeof (IPMI_BMC_INSTANCE_DATA),
+(VOID **));
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "mIpmiInstance mem alloc failed - 0x%x\n", Status));
+return Status;
+  } else {
+
+//
+// Initialize the KCS transaction timeout. Assume delay unit is 1000 us.
+//
+mIpmiInstance->KcsTimeoutPeriod = (BMC_KCS_TIMEOUT * 1000*1000) / 
KCS_DELAY_UNIT;
+
+//
+// Initialize IPMI IO Base, we still use SMS IO base to get device ID and 
Seltest result since SMM IF may have different cmds supported
+//
+mIpmiInstance->IpmiIoBase   = FixedPcdGet16 
(PcdIpmiSmmIoBaseAddress);
+mIpmiInstance->Signature= SM_IPMI_BMC_SIGNATURE;
+mIpmiInstance->SlaveAddress = BMC_SLAVE_ADDRESS;
+mIpmiInstance->BmcStatus= BMC_NOTREADY;
+mIpmiInstance->IpmiTransport.IpmiSubmitCommand  = IpmiSendCommand;
+mIpmiInstance->IpmiTransport.GetBmcStatus   = IpmiGetBmcStatus;
+
+mHandle = NULL;
+Status = gMmst->MmInstallProtocolInterface (
+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  >IpmiTransport
+  );
+ASSERT_EFI_ERROR (Status);
+
+DEBUG ((DEBUG_INFO,"SmmInitializeIpmiKcsPhysicalLayer exit \n"));
+
+return EFI_SUCCESS;
+  }
+}
+
+/**
+  The module Entry Point of driver.
+
+  @param[in]  ImageHandleThe firmware allocated handle for the EFI image.
+  @param[in]  SystemTableA pointer to the MM System Table.
+
+  @retval EFI_SUCCESSThe entry point is executed successfully.
+  @retval Other  Some error occurs when executing this entry point.
+
+**/
+EFI_STATUS
+InitializeGenericIpmiStandaloneMm (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE*SystemTable
+  )
+{
+  SmmInitializeIpmiKcsPhysicalLayer ();
+  return EFI_SUCCESS;
+}
+
+/**
+  Unloads an image.
+
+  @param[in] ImageHandleHandle that identifies the image to be 
unloaded.
+
+  @retval EFI_SUCCESS   The image has been unloaded.
+  @retval EFI_INVALID_PARAMETER ImageHandle is not a valid image handle.
+
+**/
+EFI_STATUS
+EFIAPI
+GenericIpmiStandaloneMmUnload (
+  IN EFI_HANDLE ImageHandle
+  )
+{
+  EFI_STATUSStatus;
+
+  Status = EFI_SUCCESS;
+  if (mIpmiInstance != NULL) {
+if (mHandle != NULL) {
+  Status = gMmst->MmUninstallProtocolInterface (
+mHandle,
+,
+