date:20210325

[edk2-devel] [PATCH] RedfishPkg/RedfishDiscoverDxe: EFI Redfish Discover Protocol

2021-03-25 Thread Abner Chang

EDK2 EFI Redfish Discover Protocol implementation. Refer to UEFI spec 2.9
section 31.1.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Fan Wang 
Cc: Jiewen Yao 
---
 RedfishPkg/RedfishComponents.dsc.inc  |3 +-
 RedfishPkg/Redfish.fdf.inc|3 +-
 .../RedfishDiscoverDxe/RedfishDiscoverDxe.inf |   55 +
 .../RedfishDiscoverInternal.h |  234 ++
 RedfishPkg/RedfishDiscoverDxe/ComponentName.c |  218 ++
 .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 1910 +
 .../RedfishSmbiosHostInterface.c  |  118 +
 7 files changed, 2539 insertions(+), 2 deletions(-)
 create mode 100644 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
 create mode 100644 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
 create mode 100644 RedfishPkg/RedfishDiscoverDxe/ComponentName.c
 create mode 100644 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
 create mode 100644 RedfishPkg/RedfishDiscoverDxe/RedfishSmbiosHostInterface.c

diff --git a/RedfishPkg/RedfishComponents.dsc.inc 
b/RedfishPkg/RedfishComponents.dsc.inc
index 08f1d3bc32..6f3b055aba 100644
--- a/RedfishPkg/RedfishComponents.dsc.inc
+++ b/RedfishPkg/RedfishComponents.dsc.inc
@@ -6,7 +6,7 @@
 # of EDKII Redfish drivers according to the value of flags described in
 # "RedfishDefines.dsc.inc".
 #
-# (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -17,4 +17,5 @@
   RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.inf
   RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
   RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.inf
+  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
 !endif
diff --git a/RedfishPkg/Redfish.fdf.inc b/RedfishPkg/Redfish.fdf.inc
index a64fd119a9..205c3101c0 100644
--- a/RedfishPkg/Redfish.fdf.inc
+++ b/RedfishPkg/Redfish.fdf.inc
@@ -5,7 +5,7 @@
 # by using "!include RedfishPkg/RedfisLibs.fdf.inc" to specify the module 
instances
 # to be built in the firmware volume.
 #
-# (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -15,4 +15,5 @@
   INF RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.inf
   INF RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
   INF RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.inf
+  INF RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
 !endif
diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
new file mode 100644
index 00..345bacf44d
--- /dev/null
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
@@ -0,0 +1,55 @@
+## @file
+#  Implementation of EFI_REDFISH_DISCOVER_PROTOCOL interfaces.
+#
+#  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION   = 0x0001001b
+  BASE_NAME = RedfishDiscoverDxe
+  FILE_GUID = 28A76FE5-43D7-48A3-9714-C1B7BDD6DFB6
+  MODULE_TYPE   = UEFI_DRIVER
+  VERSION_STRING= 1.0
+  ENTRY_POINT   = RedfishDiscoverEntryPoint
+  UNLOAD_IMAGE  = RedfishDiscoverUnload
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  NetworkPkg/NetworkPkg.dec
+  RedfishPkg/RedfishPkg.dec
+
+[Sources]
+  ComponentName.c
+  RedfishDiscoverDxe.c
+  RedfishSmbiosHostInterface.c
+  RedfishDiscoverInternal.h
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  MemoryAllocationLib
+  PrintLib
+  RestExLib
+  UefiLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Protocols]
+  gEfiRestExServiceBindingProtocolGuid## Consuming
+  gEfiRestExProtocolGuid  ## Consuming
+  gEfiTcp4ServiceBindingProtocolGuid  ## Consuming
+  gEfiTcp4ProtocolGuid## Consuming
+  gEfiTcp6ServiceBindingProtocolGuid  ## Consuming
+  gEfiTcp6ProtocolGuid## Consuming
+  gEfiRedfishDiscoverProtocolGuid ## Prodcuing
+  gEfiSmbiosProtocolGuid  ## Consuming
+  gEfiDriverBindingProtocolGuid   ## Consuming
+
+[Pcd]
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand ## CONSUMES
+
diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
new file mode 100644
index 00..cf69d9231a
--- /dev/null
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
@@ -0,0 +1,234 @@
+/** @file
+  This file defines the EFI Redfish Discover Protocol interface.
+
+  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef

Re: [edk2-devel] [edk2-test][Patch 1/1] ImageIndex need be corrected to range 1 ~ DescriptorCount.

2021-03-25 Thread Gao Jie

Reviewed-by: Barton Gao >


On 2021/3/22 14:12, Eric Jin wrote:

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

The goal of the Support Routine: CheckForSupportGetImage is to detect the
current FMP instance's capability for supporting GetImage().

In current code, "ImageIndex = 0" is the input parameter, but it is
inconsistent with spec -"A unique number identifying the firmware image(s)
within the device. The number is between 1 and DescriptorCount."

It is a bug and need the fix.
The similar errors exist in CheckForSupportSetImage/CheckForSupportCheckImage.

Cc: G Edhaya Chandran 
Cc: Barton Gao 
Cc: Samer El-Haj-Mahmoud 
Cc: Arvin Chen 
Signed-off-by: Eric Jin 
---
  .../BlackBoxTest/FirmwareManagementBBTestConformance.c | 7 ---
  .../BlackBoxTest/FirmwareManagementBBTestConformance.c | 7 ---
  2 files changed, 8 insertions(+), 6 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
index 257f2756dbcb..44d01d27a8f2 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
@@ -2,6 +2,7 @@
  
Copyright 2006 - 2016 Unified EFI, Inc.

Copyright (c) 2010 - 2016, Dell Inc. All rights reserved.
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
  
This program and the accompanying materials

are licensed and made available under the terms and conditions of the BSD 
License
@@ -208,7 +209,7 @@ CheckForSupportGetImage (
TestGuid = gFirmwareManagementBBTestConformanceSupportGuid001;
ResultMessageLabel = L"GetImage, function support check";
  
-  ImageIndex = 0;

+  ImageIndex = 1;
Image = NULL;
ImageSize = 0;
  
@@ -283,7 +284,7 @@ CheckForSupportSetImage (

TestGuid = gFirmwareManagementBBTestConformanceSupportGuid002;
ResultMessageLabel = L"SetImage, function support check";
  
-  ImageIndex = 0;

+  ImageIndex = 1;
Image = NULL;
ImageSize = 0;
AbortReason = NULL;
@@ -362,7 +363,7 @@ CheckForSupportCheckImage (
TestGuid = gFirmwareManagementBBTestConformanceSupportGuid003;
ResultMessageLabel = L"CheckImage, function support check";
  
-  ImageIndex = 0;

+  ImageIndex = 1;
Image = NULL;
ImageSize = 0;
  
diff --git a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c

index 797229adc8f6..65715f6c33e6 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/FirmwareManagement/BlackBoxTest/FirmwareManagementBBTestConformance.c
@@ -3,6 +3,7 @@
Copyright 2006 - 2016 Unified EFI, Inc.
Copyright (c) 2010 - 2016, Dell Inc. All rights reserved.
Copyright (c) 2019,Microchip Technology Inc.
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
  
This program and the accompanying materials

are licensed and made available under the terms and conditions of the BSD 
License
@@ -209,7 +210,7 @@ CheckForSupportGetImage (
TestGuid = gFirmwareManagementBBTestConformanceSupportGuid001;
ResultMessageLabel = L"GetImage, function support check";
  
-  ImageIndex = 0;

+  ImageIndex = 1;
Image = NULL;
ImageSize = 0;
  
@@ -284,7 +285,7 @@ CheckForSupportSetImage (

TestGuid = gFirmwareManagementBBTestConformanceSupportGuid002;
ResultMessageLabel = L"SetImage, function support check";
  
-  ImageIndex = 0;

+  ImageIndex = 1;
Image = NULL;
ImageSize = 0;
AbortReason = NULL;
@@ -363,7 +364,7 @@ CheckForSupportCheckImage (
TestGuid = gFirmwareManagementBBTestConformanceSupportGuid003;
ResultMessageLabel = L"CheckImage, function support check";
  
-  ImageIndex = 0;

+  ImageIndex = 1;
Image = NULL;
ImageSize = 0;
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73307): https://edk2.groups.io/g/devel/message/73307
Mute This Topic: https://groups.io/mt/81518326/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 02/29] MdePkg: Add MdeLibs.dsc.inc file to MdePkg

2021-03-25 Thread Dandan Bi

Thanks Mike.
I will submit a new version to address that.


Thanks,
Dandan
> -Original Message-
> From: Kinney, Michael D 
> Sent: Friday, March 26, 2021 8:49 AM
> To: Bi, Dandan ; devel@edk2.groups.io; Kinney,
> Michael D 
> Cc: Liming Gao ; Liu, Zhiguang
> ; Laszlo Ersek 
> Subject: RE: [patch V2 02/29] MdePkg: Add MdeLibs.dsc.inc file to MdePkg
> 
> Dandan,
> 
> I have a concern about the context of the dsc.inc file.
> 
> You assume that the MdeLibs.dsc.inc file will be included from the common
> [LibraryClasses] section.
> 
> This means that this dsc.inc file can not be extended to support CPU arch
> specific lib mappings.
> 
> I recommend this dsc.inc file contain the [LibraryClasses] line and that the
> MdeLibs.dsc.inc file be included just before the [LibraryClasses] line in the
> consuming DSC files.
> 
> For example, there are some required library class mappings for ARM and
> AARCH64 that are the same in every DSC file.
> I want to have the option to add CPU or module specific lib mappings to
> MdeLibs.dsc.inc.
> 
> [LibraryClasses.ARM, LibraryClasses.AARCH64]
>   #
>   # It is not possible to prevent ARM compiler calls to generic intrinsic
> functions.
>   # This library provides the instrinsic functions generated by a given 
> compiler.
>   # [LibraryClasses.ARM] and NULL mean link this library into all ARM images.
>   #
>   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> 
>   #
>   # Since software stack checking may be heuristically enabled by the
> compiler
>   # include BaseStackCheckLib unconditionally.
>   #
>   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> 
> 
> Mike
> 
> > -Original Message-
> > From: Bi, Dandan 
> > Sent: Monday, March 22, 2021 1:09 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Liming Gao
> > ; Liu, Zhiguang ;
> > Laszlo Ersek 
> > Subject: [patch V2 02/29] MdePkg: Add MdeLibs.dsc.inc file to MdePkg
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
> >
> > MdeLibs.dsc.inc is added for some default libraries provided by MdePkg.
> > Platform can include MdeLibs.dsc.inc file to avoid some potential
> > incompatible changes to platform dsc file in future.
> >
> > Only add RegisterFilterLib into it as the first version of MdeLibs.dsc.inc.
> > Can update and maintain MdeLibs.dsc.inc gradually later.
> >
> > "MdeLibs.dsc.inc" for the [LibraryClasses*] section(s)
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Laszlo Ersek 
> > Signed-off-by: Dandan Bi 
> > ---
> >  MdePkg/MdeLibs.dsc.inc | 14 ++
> >  1 file changed, 14 insertions(+)
> >  create mode 100644 MdePkg/MdeLibs.dsc.inc
> >
> > diff --git a/MdePkg/MdeLibs.dsc.inc b/MdePkg/MdeLibs.dsc.inc new file
> > mode 100644 index 00..75e516c21a
> > --- /dev/null
> > +++ b/MdePkg/MdeLibs.dsc.inc
> > @@ -0,0 +1,14 @@
> > +## @file
> > +# Mde DSC include file for [LibraryClasses*] section of all Architectures.
> > +#
> > +# This file can be included to the [LibraryClasses*] section(s) of a
> > +platform DSC file # by using "!include MdePkg/MdeLibs.dsc.inc" to
> > +specify the library instances # of some EDKII basic/common library classes.
> > +#
> > +# Copyright (c) 2021, Intel Corporation. All rights reserved. #
> > +#SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +
> > + RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilte
> > + rLibNull.inf
> > --
> > 2.18.0.windows.1



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

回复: [edk2-devel] [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

2021-03-25 Thread gaoliming

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Gao, Zhichao
> 发送时间: 2021年3月26日 8:50
> 收件人: Chang, Abner (HPS SW/FW Technologist) ;
> devel@edk2.groups.io
> 抄送: Ni, Ray ; Wang, Nickle (HPS SW)
> ; O'Hanley, Peter (EXL) ;
> Liming Gao 
> 主题: Re: [edk2-devel] [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib:
> Support EFI Redfish protocols
> 
> You can push with the correction and add my R-B. No need to send V5 if
there
> is no more comment for your patch set.
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Chang, Abner (HPS SW/FW Technologist) 
> > Sent: Thursday, March 25, 2021 7:36 PM
> > To: Gao, Zhichao ; devel@edk2.groups.io
> > Cc: Ni, Ray ; Wang, Nickle (HPS SW)
> > ; O'Hanley, Peter (EXL) ;
> > Liming Gao 
> > Subject: RE: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> > Redfish protocols
> >
> > Hi Zhichao,
> > I resend v4 patch, in which your R-B to the previous patch is removed
and
> > Liming is added to CC list. No others changes were made in this patches.
> > I will send v5 with the correction on copyright. Or can I just push to
master
> > with the correction and your R-B?
> >
> > Thanks
> > Abner
> >
> > > -Original Message-
> > > From: Gao, Zhichao [mailto:zhichao@intel.com]
> > > Sent: Thursday, March 25, 2021 5:09 PM
> > > To: Chang, Abner (HPS SW/FW Technologist) ;
> > > devel@edk2.groups.io
> > > Cc: Ni, Ray ; Wang, Nickle (HPS SW)
> > > ; O'Hanley, Peter (EXL)
> > ;
> > > Liming Gao 
> > > Subject: RE: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> > > Redfish protocols
> > >
> > > First, thanks Liming's catch.
> > >
> > > Abner,
> > >
> > > The patch has been updated, you should remove my R-B for the V4
> version.
> > > Otherwise the reviewers/maintainers may treated it as reviewed one.
> > > And please add the one who already gave the comment for your patch to
> > > the Cc list. They care about the about the change and this would help
> > > them to know the update and have a chance to view your patch in an
> early
> > time.
> > >
> > > For this patch, the copyright should be updated to 2021. With this
> > > updated,
> > > Reviewed-by: Zhichao Gao 
> > >
> > > Thanks,
> > > Zhichao
> > >
> > > > -Original Message-
> > > > From: Abner Chang 
> > > > Sent: Thursday, March 25, 2021 12:53 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Ni, Ray ; Gao, Zhichao
> > > > ; Nickle Wang ; Peter
> > > > O'Hanley 
> > > > Subject: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> > > Redfish
> > > > protocols
> > > >
> > > > Add handle parsing for EFI Redfish Discover protocol.
> > > > Add handle parsing for EFI RestEx protocol.
> > > >
> > > > Signed-off-by: Abner Chang 
> > > > Cc: Ray Ni 
> > > > Cc: Zhichao Gao 
> > > > Cc: Nickle Wang 
> > > > Cc: Peter O'Hanley 
> > > > Reviewed-by: Zhichao Gao 
> > > > ---
> > > >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++-
> > > >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.c   | 8
> +++-
> > > >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 4 +++-
> > > >  3 files changed, 13 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> > > > a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > > index 93b69cd8e9..446cd8d609 100644
> > > > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > > +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > > @@ -2,7 +2,7 @@
> > > >  #  Provides interface to advanced shell functionality for parsing
> > > > both
> > > handle
> > > > and protocol database.
> > > >  #  Copyright (c) 2010 - 2018, Intel Corporation. All rights
> > > > reserved.   #
> > > (C)
> > > > Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
> -
> > #
> > > > (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> > > > +#  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> > > > +LP
> > > >  #
> > > >  #  SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -269,6
> +269,8
> > @@
> > > >gEfiHttpProtocolGuid
> ## UNDEFINED
> > > >gEfiHttpUtilitiesProtocolGuid   ##
> UNDEFINED
> > > >gEfiRestProtocolGuid##
> UNDEFINED
> > > > +  gEfiRestExProtocolGuid  ##
> UNDEFINED
> > > > +  gEfiRedfishDiscoverProtocolGuid ##
> UNDEFINED
> > > >gEfiMmEndOfDxeProtocolGuid
> ## UNDEFINED
> > > >gEfiMmIoTrapDispatchProtocolGuid##
> UNDEFINED
> > > >gEfiMmPowerButtonDispatchProtocolGuid
> ## UNDEFINED
> > > > diff --git
> > > > a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > > index 500a95a89a..e34cefd7b4 100644
> > > > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > > +++

Re: [edk2-devel] [PATCH v1 1/1] SecurityPkg/Tcg2Smm: Initialize local Status variable

2021-03-25 Thread Yao, Jiewen

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> Kubacki
> Sent: Friday, March 26, 2021 8:42 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ;
> Zhang, Qi1 ; Kumar, Rahul1 ;
> Kun Qin 
> Subject: [edk2-devel] [PATCH v1 1/1] SecurityPkg/Tcg2Smm: Initialize local
> Status variable
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3277
> 
> Initializes the Status variable in TcgMmReadyToLock().
> 
> Fixes a Clang build failure:
> Tcg2Smm.c - SecurityPkg\Tcg\Tcg2Smm\Tcg2Smm.c:254:7: error:
> variable 'Status' is used uninitialized whenever 'if'
> condition is false [-Werror,-Wsometimes-uninitialized]
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
> Cc: Kun Qin 
> Signed-off-by: Michael Kubacki 
> ---
>  SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> index 589c08794bcf..f49eccb0bdf4 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
> @@ -253,6 +253,8 @@ TcgMmReadyToLock (
>  {
>EFI_STATUS Status;
> 
> +  Status = EFI_SUCCESS;
> +
>if (mReadyToLockHandle != NULL) {
>  Status = gMmst->MmiHandlerUnRegister (mReadyToLockHandle);
>  mReadyToLockHandle = NULL;
> --
> 2.28.0.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#73301): https://edk2.groups.io/g/devel/message/73301
> Mute This Topic: https://groups.io/mt/81617668/1772286
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [jiewen@intel.com]
> -=-=-=-=-=-=
> 



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

Re: [edk2-devel] [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

2021-03-25 Thread Gao, Zhichao

You can push with the correction and add my R-B. No need to send V5 if there is 
no more comment for your patch set.

Thanks,
Zhichao

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist) 
> Sent: Thursday, March 25, 2021 7:36 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Ni, Ray ; Wang, Nickle (HPS SW)
> ; O'Hanley, Peter (EXL) ;
> Liming Gao 
> Subject: RE: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> Redfish protocols
> 
> Hi Zhichao,
> I resend v4 patch, in which your R-B to the previous patch is removed and
> Liming is added to CC list. No others changes were made in this patches.
> I will send v5 with the correction on copyright. Or can I just push to master
> with the correction and your R-B?
> 
> Thanks
> Abner
> 
> > -Original Message-
> > From: Gao, Zhichao [mailto:zhichao@intel.com]
> > Sent: Thursday, March 25, 2021 5:09 PM
> > To: Chang, Abner (HPS SW/FW Technologist) ;
> > devel@edk2.groups.io
> > Cc: Ni, Ray ; Wang, Nickle (HPS SW)
> > ; O'Hanley, Peter (EXL)
> ;
> > Liming Gao 
> > Subject: RE: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> > Redfish protocols
> >
> > First, thanks Liming's catch.
> >
> > Abner,
> >
> > The patch has been updated, you should remove my R-B for the V4 version.
> > Otherwise the reviewers/maintainers may treated it as reviewed one.
> > And please add the one who already gave the comment for your patch to
> > the Cc list. They care about the about the change and this would help
> > them to know the update and have a chance to view your patch in an early
> time.
> >
> > For this patch, the copyright should be updated to 2021. With this
> > updated,
> > Reviewed-by: Zhichao Gao 
> >
> > Thanks,
> > Zhichao
> >
> > > -Original Message-
> > > From: Abner Chang 
> > > Sent: Thursday, March 25, 2021 12:53 PM
> > > To: devel@edk2.groups.io
> > > Cc: Ni, Ray ; Gao, Zhichao
> > > ; Nickle Wang ; Peter
> > > O'Hanley 
> > > Subject: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> > Redfish
> > > protocols
> > >
> > > Add handle parsing for EFI Redfish Discover protocol.
> > > Add handle parsing for EFI RestEx protocol.
> > >
> > > Signed-off-by: Abner Chang 
> > > Cc: Ray Ni 
> > > Cc: Zhichao Gao 
> > > Cc: Nickle Wang 
> > > Cc: Peter O'Hanley 
> > > Reviewed-by: Zhichao Gao 
> > > ---
> > >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++-
> > >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.c   | 8 +++-
> > >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 4 +++-
> > >  3 files changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git
> > > a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > index 93b69cd8e9..446cd8d609 100644
> > > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > > @@ -2,7 +2,7 @@
> > >  #  Provides interface to advanced shell functionality for parsing
> > > both
> > handle
> > > and protocol database.
> > >  #  Copyright (c) 2010 - 2018, Intel Corporation. All rights
> > > reserved.   #
> > (C)
> > > Copyright 2013-2015 Hewlett-Packard Development Company, L.P. -
> #
> > > (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> > > +#  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> > > +LP
> > >  #
> > >  #  SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -269,6 +269,8
> @@
> > >gEfiHttpProtocolGuid## UNDEFINED
> > >gEfiHttpUtilitiesProtocolGuid   ## UNDEFINED
> > >gEfiRestProtocolGuid## UNDEFINED
> > > +  gEfiRestExProtocolGuid  ## UNDEFINED
> > > +  gEfiRedfishDiscoverProtocolGuid ## UNDEFINED
> > >gEfiMmEndOfDxeProtocolGuid  ## UNDEFINED
> > >gEfiMmIoTrapDispatchProtocolGuid## UNDEFINED
> > >gEfiMmPowerButtonDispatchProtocolGuid   ## UNDEFINED
> > > diff --git
> > > a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > index 500a95a89a..e34cefd7b4 100644
> > > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > > @@ -3,7 +3,7 @@
> > >
> > >Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
> > >(C) Copyright 2013-2015 Hewlett-Packard Development Company,
> > L.P.
> > > -  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development
> > LP
> > > +  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> > LP
> > >SPDX-License-Identifier: BSD-2-Clause-Patent
> > >
> > >  **/
> > > @@ -2250,6 +2250,12 @@ STATIC CONST GUID_INFO_BLOCK
> > >

Re: [edk2-devel] [patch V2 02/29] MdePkg: Add MdeLibs.dsc.inc file to MdePkg

2021-03-25 Thread Michael D Kinney

Dandan,

I have a concern about the context of the dsc.inc file.

You assume that the MdeLibs.dsc.inc file will be included from
the common [LibraryClasses] section.

This means that this dsc.inc file can not be extended to support
CPU arch specific lib mappings.

I recommend this dsc.inc file contain the [LibraryClasses] 
line and that the MdeLibs.dsc.inc file be included just before
the [LibraryClasses] line in the consuming DSC files.

For example, there are some required library class mappings
for ARM and AARCH64 that are the same in every DSC file.
I want to have the option to add CPU or module specific 
lib mappings to MdeLibs.dsc.inc.

[LibraryClasses.ARM, LibraryClasses.AARCH64]
  #
  # It is not possible to prevent ARM compiler calls to generic intrinsic 
functions.
  # This library provides the instrinsic functions generated by a given 
compiler.
  # [LibraryClasses.ARM] and NULL mean link this library into all ARM images.
  #
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf

  #
  # Since software stack checking may be heuristically enabled by the compiler
  # include BaseStackCheckLib unconditionally.
  #
  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf


Mike

> -Original Message-
> From: Bi, Dandan 
> Sent: Monday, March 22, 2021 1:09 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liming Gao 
> ; Liu, Zhiguang
> ; Laszlo Ersek 
> Subject: [patch V2 02/29] MdePkg: Add MdeLibs.dsc.inc file to MdePkg
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
> 
> MdeLibs.dsc.inc is added for some default libraries provided by MdePkg.
> Platform can include MdeLibs.dsc.inc file to avoid some potential
> incompatible changes to platform dsc file in future.
> 
> Only add RegisterFilterLib into it as the first version of MdeLibs.dsc.inc.
> Can update and maintain MdeLibs.dsc.inc gradually later.
> 
> "MdeLibs.dsc.inc" for the [LibraryClasses*] section(s)
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Laszlo Ersek 
> Signed-off-by: Dandan Bi 
> ---
>  MdePkg/MdeLibs.dsc.inc | 14 ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 MdePkg/MdeLibs.dsc.inc
> 
> diff --git a/MdePkg/MdeLibs.dsc.inc b/MdePkg/MdeLibs.dsc.inc
> new file mode 100644
> index 00..75e516c21a
> --- /dev/null
> +++ b/MdePkg/MdeLibs.dsc.inc
> @@ -0,0 +1,14 @@
> +## @file
> +# Mde DSC include file for [LibraryClasses*] section of all Architectures.
> +#
> +# This file can be included to the [LibraryClasses*] section(s) of a 
> platform DSC file
> +# by using "!include MdePkg/MdeLibs.dsc.inc" to specify the library instances
> +# of some EDKII basic/common library classes.
> +#
> +# Copyright (c) 2021, Intel Corporation. All rights reserved.
> +#
> +#SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +  
> RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
> --
> 2.18.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73302): https://edk2.groups.io/g/devel/message/73302
Mute This Topic: https://groups.io/mt/81519241/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] SecurityPkg/Tcg2Smm: Initialize local Status variable

2021-03-25 Thread Michael Kubacki

From: Michael Kubacki 

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

Initializes the Status variable in TcgMmReadyToLock().

Fixes a Clang build failure:
Tcg2Smm.c - SecurityPkg\Tcg\Tcg2Smm\Tcg2Smm.c:254:7: error:
variable 'Status' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Qi Zhang 
Cc: Rahul Kumar 
Cc: Kun Qin 
Signed-off-by: Michael Kubacki 
---
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
index 589c08794bcf..f49eccb0bdf4 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
@@ -253,6 +253,8 @@ TcgMmReadyToLock (
 {
   EFI_STATUS Status;
 
+  Status = EFI_SUCCESS;
+
   if (mReadyToLockHandle != NULL) {
 Status = gMmst->MmiHandlerUnRegister (mReadyToLockHandle);
 mReadyToLockHandle = NULL;
-- 
2.28.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73301): https://edk2.groups.io/g/devel/message/73301
Mute This Topic: https://groups.io/mt/81617668/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 25/29] UefiCpuPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Dong, Eric

Reviewed-by: Eric Dong 

-Original Message-
From: Bi, Dandan  
Sent: Monday, March 22, 2021 4:10 PM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Ni, Ray ; Laszlo Ersek 
; Kumar, Rahul1 
Subject: [patch V2 25/29] UefiCpuPkg: Consume MdeLibs.dsc.inc for 
RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library instances provided by 
MdePkg and RegisterFilterLibNull Library was also added into it as the first 
version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for RegisterFilterLibNull 
which will be consumed by IoLib and BaseLib.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 
Signed-off-by: Dandan Bi 
---
 UefiCpuPkg/UefiCpuPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index 
7db419471d..6c7cc6b273 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -1,9 +1,9 @@
 ## @file
 #  UefiCpuPkg Package
 #
-#  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2021, Intel Corporation. All rights 
+reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent  #  ##
 
@@ -20,10 +20,12 @@ [Defines]
 #
 # External libraries to build package
 #
 
 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
--
2.18.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73300): https://edk2.groups.io/g/devel/message/73300
Mute This Topic: https://groups.io/mt/81519312/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 25/29] UefiCpuPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: devel@edk2.groups.io  on behalf of Laszlo Ersek 

Sent: Tuesday, March 23, 2021 2:32:02 AM
To: Bi, Dandan ; devel@edk2.groups.io 

Cc: Dong, Eric ; Ni, Ray ; Kumar, Rahul1 

Subject: Re: [edk2-devel] [patch V2 25/29] UefiCpuPkg: Consume MdeLibs.dsc.inc 
for RegisterFilterLib

On 03/22/21 09:09, Dandan Bi wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
>
> MdeLibs.dsc.inc was added for some basic/default library
> instances provided by MdePkg and RegisterFilterLibNull Library
> was also added into it as the first version of MdeLibs.dsc.inc.
>
> So update platform dsc to consume MdeLibs.dsc.inc for
> RegisterFilterLibNull which will be consumed by IoLib and BaseLib.
>
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Signed-off-by: Dandan Bi 
> ---
>  UefiCpuPkg/UefiCpuPkg.dsc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index 7db419471d..6c7cc6b273 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -1,9 +1,9 @@
>  ## @file
>  #  UefiCpuPkg Package
>  #
> -#  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
>
> @@ -20,10 +20,12 @@ [Defines]
>  #
>  # External libraries to build package
>  #
>
>  [LibraryClasses]
> +  !include MdePkg/MdeLibs.dsc.inc
> +
>BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
>DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>
> SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
>

I would suggest un-indenting the !include directive here as well.

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo








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

Re: [edk2-devel] [edk2-platforms] [patch V2 26/35] Silicon/IntelSiliconPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: devel@edk2.groups.io  on behalf of Dandan Bi 

Sent: Monday, March 22, 2021 4:53:52 PM
To: devel@edk2.groups.io 
Cc: Ni, Ray ; Chaganty, Rangasai V 

Subject: [edk2-devel] [edk2-platforms] [patch V2 26/35] 
Silicon/IntelSiliconPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Signed-off-by: Dandan Bi 
---
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
index 6dff68f681..62e405e1d5 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
@@ -1,9 +1,9 @@
 ## @file
 # This package provides common open source Intel silicon modules.
 #
-# Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 # Copyright (c) Microsoft Corporation.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -17,10 +17,12 @@ [Defines]
   SUPPORTED_ARCHITECTURES= IA32|X64
   BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
   SKUID_IDENTIFIER   = DEFAULT

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
--
2.18.0.windows.1








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

Re: [edk2-devel] [edk2-platforms] [patch V2 03/35] Drivers/OptionRomPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: Bi, Dandan 
Sent: Monday, March 22, 2021 4:20:08 PM
To: devel@edk2.groups.io 
Cc: Ni, Ray 
Subject: [edk2-platforms] [patch V2 03/35] Drivers/OptionRomPkg: Consume 
MdeLibs.dsc.inc for RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Ray Ni 
Signed-off-by: Dandan Bi 
---
 Drivers/OptionRomPkg/OptionRomPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Drivers/OptionRomPkg/OptionRomPkg.dsc 
b/Drivers/OptionRomPkg/OptionRomPkg.dsc
index 8a13cc54e6..d6bd88b58e 100644
--- a/Drivers/OptionRomPkg/OptionRomPkg.dsc
+++ b/Drivers/OptionRomPkg/OptionRomPkg.dsc
@@ -4,11 +4,11 @@
 # This package is designed to interoperate with the EDK II open source project
 # at http://www.tianocore.org, and this package is required to build PCI 
compliant
 # Option ROM image for all CPU architectures, including EBC target.
 # A single driver can support mixes of EFI 1.1, UEFI 2.0 and UEFI 2.1.
 #
-# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
 # Copyright (c) 2016, Linaro Ltd. All rights reserved.
 # Copyright (c) 2020, ARM Limited. All rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -37,10 +37,12 @@ [Defines]
 

 [SkuIds]
   0|DEFAULT  # The entry: 0|DEFAULT is reserved and always 
required.

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   DebugLib|MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   BltLib|OptionRomPkg/Library/GopBltLib/GopBltLib.inf
--
2.18.0.windows.1



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

Re: [edk2-devel] [edk2-platforms] [patch V2 26/35] Silicon/IntelSiliconPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: Bi, Dandan 
Sent: Monday, March 22, 2021 4:20:31 PM
To: devel@edk2.groups.io 
Cc: Ni, Ray ; Chaganty, Rangasai V 

Subject: [edk2-platforms] [patch V2 26/35] Silicon/IntelSiliconPkg: Consume 
MdeLibs.dsc.inc for RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Signed-off-by: Dandan Bi 
---
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 
b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
index 6dff68f681..62e405e1d5 100644
--- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
+++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
@@ -1,9 +1,9 @@
 ## @file
 # This package provides common open source Intel silicon modules.
 #
-# Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 # Copyright (c) Microsoft Corporation.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -17,10 +17,12 @@ [Defines]
   SUPPORTED_ARCHITECTURES= IA32|X64
   BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
   SKUID_IDENTIFIER   = DEFAULT

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
--
2.18.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73296): https://edk2.groups.io/g/devel/message/73296
Mute This Topic: https://groups.io/mt/81519811/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 18/29] PcAtChipsetPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: Bi, Dandan 
Sent: Monday, March 22, 2021 4:09:30 PM
To: devel@edk2.groups.io 
Cc: Ni, Ray 
Subject: [patch V2 18/29] PcAtChipsetPkg: Consume MdeLibs.dsc.inc for 
RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Ray Ni 
Signed-off-by: Dandan Bi 
---
 PcAtChipsetPkg/PcAtChipsetPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dsc 
b/PcAtChipsetPkg/PcAtChipsetPkg.dsc
index 3d1fb816f5..8598e689f9 100644
--- a/PcAtChipsetPkg/PcAtChipsetPkg.dsc
+++ b/PcAtChipsetPkg/PcAtChipsetPkg.dsc
@@ -1,9 +1,9 @@
 ## @file
 #  PC/AT Chipset Package
 #
-#  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
 #  Copyright (c) 2020, AMD Incorporated. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -17,10 +17,12 @@ [Defines]
   SUPPORTED_ARCHITECTURES= IA32|X64
   BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
   SKUID_IDENTIFIER   = DEFAULT

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
   DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
--
2.18.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73295): https://edk2.groups.io/g/devel/message/73295
Mute This Topic: https://groups.io/mt/81519269/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 10/29] FatPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: Bi, Dandan 
Sent: Monday, March 22, 2021 4:09:22 PM
To: devel@edk2.groups.io 
Cc: Ni, Ray 
Subject: [patch V2 10/29] FatPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Ray Ni 
Signed-off-by: Dandan Bi 
---
 FatPkg/FatPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc
index d86256068b..e0264db803 100644
--- a/FatPkg/FatPkg.dsc
+++ b/FatPkg/FatPkg.dsc
@@ -1,11 +1,11 @@
 ## @file
 #  Build Binary Enhanced Fat Driver Modules.
 #
 #  This Platform file is used to generate the Binary Fat Drivers
 #  for EDK II Prime release.
-#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
 #  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -26,10 +26,12 @@ [BuildOptions]
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
   RVCT:RELEASE_*_*_CC_FLAGS= -DMDEPKG_NDEBUG
   *_*_*_CC_FLAGS   = -D DISABLE_NEW_DEPRECATED_INTERFACES

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   #
   # Entry Point Libraries
   #
   
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
   #
--
2.18.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73294): https://edk2.groups.io/g/devel/message/73294
Mute This Topic: https://groups.io/mt/81519261/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 09/29] EmulatorPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Ni, Ray

Reviewed-by: ray...@intel.com

thanks,
ray

From: Bi, Dandan 
Sent: Monday, March 22, 2021 4:09:21 PM
To: devel@edk2.groups.io 
Cc: Andrew Fish ; Ni, Ray 
Subject: [patch V2 09/29] EmulatorPkg: Consume MdeLibs.dsc.inc for 
RegisterFilterLib

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

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Dandan Bi 
---
 EmulatorPkg/EmulatorPkg.dsc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index a7ded49000..b8d1d12ace 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -2,11 +2,11 @@
 # UEFI/PI Emulation Platform with UEFI HII interface supported.
 #
 # The Emulation Platform can be used to debug individual modules, prior to 
creating
 # a real platform. This also provides an example for how an DSC is created.
 #
-# Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2010 - 2011, Apple Inc. All rights reserved.
 # Copyright (c) Microsoft Corporation.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -43,10 +43,12 @@ [Defines]

 [SkuIds]
   0|DEFAULT

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   #
   # Entry point
   #
   PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
   PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
--
2.18.0.windows.1



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

Re: [EXTERNAL] Re: [edk2-devel] !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock

2021-03-25 Thread Bret Barkelew via groups.io

Yes, this is expected behavior. The messages are to encourage code owners to 
move from using the VariableLockRequestToLock() interface to the VariablePolicy 
interface so that the RTL interface may be removed in the future.

The correct solution is to find the offending code and submit a patch that 
updates it to not use RTL. My guess is that this is the location that you’re 
hitting, if you’re using the edk2 BdsDxe:
https://github.com/tianocore/edk2/blob/4bf2a5b045ebf8b5e90d9210ad5190699bddb592/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L723

I can try to submit a patch next week (I’m slammed this week) to port this over 
to VariablePolicy.
Note, however, that the messages are not affecting the functionality. They’re 
purely nag messages.

- Bret

From: Laszlo Ersek
Sent: Thursday, March 25, 2021 12:04 PM
To: Bret Barkelew
Cc: devel@edk2.groups.io; 
m...@semihalf.com
Subject: [EXTERNAL] Re: [edk2-devel] !!! DEPRECATED INTERFACE !!! 
VariableLockRequestToLock

Hi Bret,

can you help Marcin please?

Thanks
Laszlo

On 03/25/21 10:19, Marcin Wojtas wrote:
> Hi,
>
> When booting the latest edk2 on Marvell SoCs I get a number of prints as
> below:
>
> !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock() will go away soon!
> !!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!
> !!! DEPRECATED INTERFACE !!! Variable: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
> PlatformLangCodes
> !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock() will go away soon!
> !!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!
> !!! DEPRECATED INTERFACE !!! Variable: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
> LangCodes
> ...
>
> I cleared variable storage, looked into code, compared VariablePolicy
> library resolution to other platforms (it looks the same and was updated
> along with all others in
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-platforms%2Fcommit%2F8034e3b2ae9470adbdata=04%7C01%7Cbret.barkelew%40microsoft.com%7C98c3d9be0b2c4654874d08d8efc0cdb5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637522958656548916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mwHi%2BAwmh5rh%2BAfdXBBx0ZXobV1bT1%2Bsi8%2BpcLxVNsQ%3Dreserved=0),
>  but
> still don't see, how to get rid of those.
>
> Is it expected behavior? Any suggestions how to properly remove those
> messages?
>
> Best regards,
> Marcin
>
>
> 
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73292): https://edk2.groups.io/g/devel/message/73292
Mute This Topic: https://groups.io/mt/81614021/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] OvmfPkg: strip build paths in release builds

2021-03-25 Thread Andrew Fish via groups.io



> On Mar 25, 2021, at 10:19 AM, Laszlo Ersek  wrote:
> 
> On 03/25/21 00:25, Andrew Fish wrote:
>> This breaks some usage we have have in our fork. We have symbols turned on 
>> for Release builds, so this change would break that. 
>> 
>> It looks to me that the root cause of this issue might be that the GenFw is 
>> blindly writing the debug directory entry into the PE/COFF?
> 
> Yes, that's my understanding, from TianoCore#3256.
> 
>> For native PE/COFF I think this is controlled by linker flags? For 
>> Xcode/clang it is controlled by the *_XCODE5_*_MTOC_FLAGS. So at this point 
>> it is kind of up to each toolchain how they want to deal with symbols on 
>> release builds. 
>> 
>> 
>> It seems kind of strange to insert a section and then zero it. Almost seems 
>> like the intent of —zero was to post process compare images? 
>> 
>>  -z, --zeroZero the Debug Data Fields in the PE input image file.
>>It also zeros the time stamp fields.
>>This option can be used to compare the binary efi 
>> image.
>>It can't be combined with other action options
>>except for -o, -r option. It is a action option.
>>If it is combined with other action options, the later
>>input action option will override the previous one.
>> 
>> And in case you are going to ask our fork uses relative paths from the Build 
>> directory and/or a UUID string for the Debug Directory entry file name so it 
>> is a constant value and does not impact build reproducibility. 
> 
> I'd like if we could satisfy both your use case and Ross's (Yocto's).
> 
> Until we have a technical solution for that, is it important that we
> revert the patch upstream? (If it's urgent, I'm going to ask someone
> else to do that, because I'll be back in April.)
> 

Laszlo,

Per my other email about —keepexceptiontable it looks like source level debug 
is intertwined with GenFw flags that are global, and this has been going on for 
a long time. So I think I’ll just file a BZ about this issue in general and not 
ask for changes in this patch. 

Thanks,

Andrew Fish

>> From a feature stand point this change will break any hope of source level 
>> debugging with RELEASE builds. I also think it changes the exception handler 
>> code output in OVMF [1] for ELF toolchains. You are going to get the (No 
>> PDB) vs. the file and path you were getting today. I assume if you had tools 
>> that natively produce PE/COFF and did not have a Debug Directory entry the 
>> same thing would happen prior to this change. 
>> 
>>Status = PeCoffLoaderGetEntryPoint ((VOID *) Pe32Data, );
>>if (EFI_ERROR (Status)) {
>>  EntryPoint = NULL;
>>}
>>InternalPrintMessage (" Find image based on IP(0x%x) ", CurrentEip);
>>PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);
>>if (PdbPointer != NULL) {
>>  InternalPrintMessage ("%a", PdbPointer);
>>} else {
>>  InternalPrintMessage ("(No PDB) " );
>>}
>>InternalPrintMessage (
>>  " (ImageBase=%016lp, EntryPoint=%016p) \n",
>>  (VOID *) Pe32Data,
>>  EntryPoint
>>  );
>> 
>> Not saying we have to "stop the presses", but just trying to point out the 
>> side effects of this change. It is not so much that this change is bad, but 
>> that we have no way to turn off the Debug Directory Entry for ELF 
>> conversion, so we seem to be working around that issue with a bigger hammer?
> 
> I don't have suggestions alas, but am open to any solution that works
> for you and Ross both.
> 
> Thanks (and my apologies for breaking your process!),
> Laszlo
> 
>> 
>> [1] 
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c#L117
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Mar 24, 2021, at 4:58 AM, Ross Burton  wrote:
>>> 
>>> GenFw will embed a NB10 section which contains the path to the input file,
>>> which means the output files have build paths embedded in them.  To reduce
>>> information leakage and ensure reproducible builds, pass --zero in release
>>> builds to remove this information.
>>> 
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256
>>> Signed-off-by: Ross Burton 
>>> ---
>>> OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
>>> OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
>>> OvmfPkg/OvmfPkgIa32.dsc  | 1 +
>>> OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
>>> OvmfPkg/OvmfPkgX64.dsc   | 1 +
>>> OvmfPkg/OvmfXen.dsc  | 1 +
>>> 6 files changed, 6 insertions(+)
>>> 
>>> diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
>>> index 65c42284d9..69a05feea9 100644
>>> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
>>> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
>>> @@ -78,6 +78,7 @@
>>>  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
>>>  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
>>> !endif
>>> +  RELEASE_*_*_GENFW_FLAGS = --zero
>>> 
>>>  #
>>>  # Disable deprecated

Re: [edk2-devel] [PATCH] RISC-V/PlatformPkg: Fix compilation breakage in OpenSBI

2021-03-25 Thread Loic Devulder via groups.io

On Thu, Mar 25, 2021 at 01:46 AM, Abner Chang wrote:

> 
> Hi Loic,
> The current edk2 RISC-V is incorporated with opensbi v0.8, please check
> below link
> https://github.com/riscv/riscv-uefi-edk2-docs

Yes, I think this is the version I used. In fact I followed 
https://github.com/tianocore/edk2-platforms#submodules to add the needed 
submodule.

> 
> We have to update below library with the latest opensbi with your changes,
> 
> https://github.com/tianocore/edk2-platforms/tree/master/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib
> 
> 
> I believe your changes don't impact the build and the functionalities
> because we don't use those parameters in edk2.

Sounds like yes. I tested in qemu without any issue, but that was not a full 
regression test ;-)

> 
> However, this change should be adopted with Edk2OpenSbiLib upgrade.
> Daniel is currently working on edk2 RISC-V OVMF and also updated opensbi
> to the latest version. However there is a compatible issue when switching
> mode and we are fixing it now.
> We can share more information with you if you would like to know.

So if this fix will be included in Daniel's changes that fine. I just wanted to 
share the fix if anyone else had issue and also check if the issue was not on 
my side, I'm a newbie on edk2 and on RISC-V :D

> 
> 
> Thanks
> Abner


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

Re: [edk2-devel] !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock

2021-03-25 Thread Laszlo Ersek

Hi Bret,

can you help Marcin please?

Thanks
Laszlo

On 03/25/21 10:19, Marcin Wojtas wrote:
> Hi,
> 
> When booting the latest edk2 on Marvell SoCs I get a number of prints as
> below:
> 
> !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock() will go away soon!
> !!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!
> !!! DEPRECATED INTERFACE !!! Variable: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
> PlatformLangCodes
> !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock() will go away soon!
> !!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!
> !!! DEPRECATED INTERFACE !!! Variable: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
> LangCodes
> ...
> 
> I cleared variable storage, looked into code, compared VariablePolicy
> library resolution to other platforms (it looks the same and was updated
> along with all others in
> https://github.com/tianocore/edk2-platforms/commit/8034e3b2ae9470adb), but
> still don't see, how to get rid of those.
> 
> Is it expected behavior? Any suggestions how to properly remove those
> messages?
> 
> Best regards,
> Marcin
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [EXTERNAL] [patch V2 27/29] UnitTestFrameworkPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Bret Barkelew via groups.io

Thanks, Dandan!

Apologies if this has already been asked, but is this necessary because C 
doesn’t have any options for symbol namespacing?
In other words, would it be just as easy to do this with a new implementation 
of IoLib if we didn’t have to worry about the symbol collisions?

- Bret

From: Bi, Dandan
Sent: Monday, March 22, 2021 6:52 PM
To: Bret Barkelew; 
devel@edk2.groups.io
Cc: Kinney, Michael D; Sean 
Brogan
Subject: RE: [EXTERNAL] [patch V2 27/29] UnitTestFrameworkPkg: Consume 
MdeLibs.dsc.inc for RegisterFilterLib

Hi Bret,

Here is the branch and PR I just created for this change, please help review. 
Thanks.
https://github.com/dandanbi/edk2/tree/RegisterFilterLibV2
https://github.com/tianocore/edk2/pull/1509



Thanks,
Dandan

From: Bret Barkelew 
Sent: Tuesday, March 23, 2021 2:25 AM
To: Bi, Dandan ; devel@edk2.groups.io
Cc: Kinney, Michael D ; Sean Brogan 

Subject: RE: [EXTERNAL] [patch V2 27/29] UnitTestFrameworkPkg: Consume 
MdeLibs.dsc.inc for RegisterFilterLib

Is there a PR somewhere that has a branch with all these changes applied? I’d 
like to poke around a little.

Thanks!

- Bret

From: Dandan Bi
Sent: Monday, March 22, 2021 1:10 AM
To: devel@edk2.groups.io
Cc: Kinney, Michael D; Sean 
Brogan; Bret 
Barkelew
Subject: [EXTERNAL] [patch V2 27/29] UnitTestFrameworkPkg: Consume 
MdeLibs.dsc.inc for RegisterFilterLib

REF: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3246data=04%7C01%7CBret.Barkelew%40microsoft.com%7C77dd99e3296941afb9b408d8ed09fd3c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637519974445661033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=oDafPDNi1k2MRYGrp%2Frhy1dB43tk%2B0YwF8%2FxdLqBXt8%3Dreserved=0

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Michael D Kinney 
mailto:michael.d.kin...@intel.com>>
Cc: Sean Brogan mailto:sean.bro...@microsoft.com>>
Cc: Bret Barkelew 
mailto:bret.barke...@microsoft.com>>
Signed-off-by: Dandan Bi mailto:dandan...@intel.com>>
---
 UnitTestFrameworkPkg/UnitTestFrameworkPkgTarget.dsc.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/UnitTestFrameworkPkg/UnitTestFrameworkPkgTarget.dsc.inc 
b/UnitTestFrameworkPkg/UnitTestFrameworkPkgTarget.dsc.inc
index 8adf690098..4adb98aff5 100644
--- a/UnitTestFrameworkPkg/UnitTestFrameworkPkgTarget.dsc.inc
+++ b/UnitTestFrameworkPkg/UnitTestFrameworkPkgTarget.dsc.inc
@@ -1,14 +1,16 @@
 ## @file
 # UnitTestFrameworkPkg DSC include file for target based test DSC
 #
-# Copyright (c) 2019 - 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##

 [LibraryClasses]
+  !include MdePkg/MdeLibs.dsc.inc
+
   #
   # Entry point
   #
   PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
   
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
--
2.18.0.windows.1




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

Re: [edk2-devel] [PATCH v2 0/7] OvmfXen: Set PcdFSBClock at runtime

2021-03-25 Thread Laszlo Ersek

On 03/25/21 16:47, Anthony PERARD wrote:
> Patch series available in this git branch:
> git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v2

I'll get to this sometime in April, possibly after the SEV-SNP series.
That shouldn't discourage others from reviewing sooner, of course.

Thanks
Laszlo

> 
> Changes in v2:
> - main change is to allow mapping of Xen pages outside of the RAM
>   see patch: "OvmfPkg/XenPlatformPei: Map extra physical address"
> - that new function allows to map the Xen shared info page (where we can find
>   information about tsc frequency) at the highest physical address allowed.
> 
> Hi,
> 
> OvmfXen uses the APIC timer, but with an hard-coded frequency that may change
> as pointed out here:
>   https://edk2.groups.io/g/devel/message/45185
>   <20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger>
> 
> This series changes that so the frequency is calculated at runtime.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
> 
> There is also one cleanup patch that has nothing to do with the rest.
> 
> Cheers,
> 
> Anthony PERARD (7):
>   OvmfPkg/XenResetVector: Silent a warning from nasm
>   MdePkg: Allow PcdFSBClock to by Dynamic
>   OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to
> XEN_VCPU_TIME_INFO
>   OvmfPkg/IndustryStandard: Introduce PageTable.h
>   OvmfPkg/XenPlatformPei: Map extra physical address
>   OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
>   OvmfPkg/OvmfXen: Set PcdFSBClock
> 
>  MdePkg/MdePkg.dec |   8 +-
>  OvmfPkg/OvmfXen.dsc   |   4 +-
>  OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   4 +
>  .../IndustryStandard/PageTable.h} | 117 +---
>  OvmfPkg/Include/IndustryStandard/Xen/xen.h|  17 +-
>  .../BaseMemEncryptSevLib/X64/VirtualMemory.h  | 143 +-
>  OvmfPkg/XenPlatformPei/Platform.h |  10 +
>  OvmfPkg/XenPlatformPei/Platform.c |   1 +
>  OvmfPkg/XenPlatformPei/Xen.c  | 252 ++
>  OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm|   2 +-
>  10 files changed, 287 insertions(+), 271 deletions(-)
>  copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h => 
> Include/IndustryStandard/PageTable.h} (60%)
> 



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

Re: 回复: [edk2-devel] 回复: [RESEND v2] MdePkg: use CpuPause() in CpuDeadLoop()

2021-03-25 Thread Ankur Arora


On 2021-03-24 8:15 p.m., gaoliming wrote:

Create PR https://github.com/tianocore/edk2/pull/1515


Thanks Liming.

Ankur



Thanks
Liming

-邮件原件-
发件人: devel@edk2.groups.io  代表 gaoliming
发送时间: 2021年3月22日 9:40
收件人: 'Ankur Arora' ; devel@edk2.groups.io
抄送: 'Michael D Kinney' ; 'Laszlo Ersek'

主题: [edk2-devel] 回复: [RESEND v2] MdePkg: use CpuPause() in
CpuDeadLoop()

Reviewed-by: Liming Gao 

Thanks
Liming

-邮件原件-
发件人: Ankur Arora 
发送时间: 2021年3月20日 2:14
收件人: devel@edk2.groups.io
抄送: Ankur Arora ; Liming Gao
; Michael D Kinney
; Laszlo Ersek 
主题: [RESEND v2] MdePkg: use CpuPause() in CpuDeadLoop()

CpuPause() might allow the CPU to go into a lower power state
state while we spin.

On X86, CpuPause() executes a PAUSE instruction which the Intel
and AMD specs describe as follows:

Intel:
   "PAUSE: An additional function of the PAUSE instruction is to reduce
   the power consumed by a processor while executing a spin loop. A
   processor can execute a spin-wait loop extremely quickly, causing the
   processor to consume a lot of power while it waits for the resource it
   is spinning on to become available. Inserting a pause instruction in a
   spin-wait loop greatly reduces the processor’s power consumption."

AMD:
   "PAUSE: Improves the performance of spin loops, by providing a hint to
   the processor that the current code is in a spin loop. The processor
   may use this to optimize power consumption while in the spin loop.
   Architecturally, this instruction behaves like a NOP instruction."

On RISC-V and ARM64, CpuPause() executes a NOP, which is no worse than
the tight loop we have.

Cc: Liming Gao 
Signed-off-by: Ankur Arora 
Reviewed-by: Michael D Kinney 
Reviewed-by: Laszlo Ersek 
---
  MdePkg/Library/BaseLib/CpuDeadLoop.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/BaseLib/CpuDeadLoop.c
b/MdePkg/Library/BaseLib/CpuDeadLoop.c
index 9e110cacbc96..3cd304351a65 100644
--- a/MdePkg/Library/BaseLib/CpuDeadLoop.c
+++ b/MdePkg/Library/BaseLib/CpuDeadLoop.c
@@ -28,5 +28,7 @@ CpuDeadLoop (
  {
volatile UINTN  Index;

-  for (Index = 0; Index == 0;);
+  for (Index = 0; Index == 0;) {
+CpuPause();
+  }
  }
--
2.9.3















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

Re: [edk2-devel] SR-IOV setup in edk2

2021-03-25 Thread Laszlo Ersek

Hi Jon.

On 03/25/21 09:02, Jon Nettleton wrote:

> I have now implemented a driver connected to gEfiPciPlatformProtocolGuid
> and I can get events passed in for the platform setup hooks, is this where
> we should be doing the bus specific setup, rather than catching
> gEfiPciIoProtocolGuid?

Sorry, the topic you are working on is over my head.

Catching gEfiPciIoProtocolGuid (with a protocol notify registration) is
definitely wrong, from a UEFI driver model perspective.

EFI_PCI_PLATFORM_PROTOCOL *could* be what you are afrer. I recommend
reading through Chapter 11, "PCI Platform", in Volume 5 of the Platform
Init spec (latest release is, to my knowledge, v1.7). Chapter 10 could
be relevant too ("PCI Host Bridge").

I think the PCI maintainers in edk2 could be of more help than I; please
see Hao and Ray in Maintainers.txt.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73285): https://edk2.groups.io/g/devel/message/73285
Mute This Topic: https://groups.io/mt/81498733/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 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-25 Thread Laszlo Ersek

On 03/25/21 04:55, Andrew Fish wrote:
> Ray,
> 
> The other option would be to define a Library Class for the AcpiTableDxe 
> driver to consume and have a NULL version of it in the MdeModulePkg. That 
> would allow more flexibility? It kind of depends if you want to make the 
> implementation depend on a HOB or a LibraryClass? It at least gives the non 
> pure PI implementations more potential options? I’m not sure with the problem 
> you are trying to solve that helps or hurts, but I though I would throw out 
> another option. The other advantage about the lib is could let you define the 
> HOB in another package, if that makes more sense. 
> 
> Not trying to slow down the solution, but just giving some other options in 
> case another partitioning of this problem would be helpful? 

I agree this is another option for separating out the HOB consumption
logic, in case it is complex or large.

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73284): https://edk2.groups.io/g/devel/message/73284
Mute This Topic: https://groups.io/mt/81543419/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 0/2] Let AcpiTableDxe driver install Acpi table from Hob

2021-03-25 Thread Laszlo Ersek

On 03/25/21 02:10, Ni, Ray wrote:
> Ben,
> I understand your point.
> The purpose of changing the AcpiTableDxe to directly consume the HOB is to 
> reduce the overall system complexity.
> The complexity I see with your option is:
> 1. platform needs to include that driver to consume the ACPI table from 
> bootloader
> 2. that driver (consume HOB and install table through AcpiTable protocol) 
> needs to register a protocol notification on AcpiTable protocol and do the 
> table installation in the callback.
> 
> Laszlo,
> The change here is to meet the requirement that bootloader provides the ACPI 
> table.
> In OVMF case, it's not the bootloader but the virtual hardware who provides 
> the ACPI table.
> I can see the similarity between the two: the ACPI table is produced before 
> the UEFI Payload runs.
> Can you review the new option below and see whether it can meet the OVMF 
> needs as well?

Let me clarify: there's no way I'm touching that part of OVMF. I don't
want any potential regressions there. It's been working stably for years.

I'd just like to avoid a duplication of functionality -- if the new HOB
logic in MdeModulePkg  is heavy, then I'd like a possibility for
platforms to separate it out.

> 1. Define a new GUID gPldHobAcpiTable in MdeModulePkg.dec and a structure as 
> below in MdeModulePkg/Include/Guid/Acpi.h.
> typedef struct { 
>UINT64  TableAddress;
> }  PLD_HOB_ACPI_TABLE;

Looks good (but maybe use EFI_PHYSICAL_ADDRESS for type, and a more
telling name than "TableAddress" -- name precisely what ACPI table type
the pointer refers to?)

> 2. Change AcpiTableDxe driver to consume the HOB

Yes. And this is the part that, if it's complex or large, should go into
a separate source file (together with a new INF file), or be controlled
by a Feature PCD.

If it's not complex / large, and you can refactor AcpiTableDxe first
such that the HOB-based functionality is not littered over a bunch of
functions, then it's OK to stick with just one INF file (and no Feature
PCD).

> 3. Remove SYSTEM_TABLE_INFO. AcpiTableBase/AcpiTableSize.

Won't that break other systems that currently depend on it? Just asking.
I'm neutral, personally.

> 4. Remove the BlSupportDxe code that consume the ACPI table in 
> SYSTEM_TABLE_INFO.

Same compatibility question for existent, dependent platforms.

Thanks
Laszlo

> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Thursday, March 25, 2021 2:33 AM
>> To: Benjamin Doron ; devel@edk2.groups.io
>> Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install 
>> Acpi table from Hob
>>
>> On 03/24/21 17:55, Benjamin Doron wrote:


> Hi all,
> Would it be acceptable/feasible for AcpiTableDxe or AcpiPlatformDxe (in
> MdeModulePkg) to use `EfiGetSystemConfigurationTable` to get the RSDP
> and then install the tables? It's a solution that uses the regular
> UefiLib, so it avoids platform-specific quirks (and as I see it, if RSDP
> is in the configuration table, we probably always want those tables).

 I'm sorry, I don't understand how this would help.
>>>
>>> As I understand it, the issue is that this patchset changes MdeModulePkg to 
>>> do platform-specific parsing.
>>>
>>> Perhaps it would be an acceptable solution for platforms to retrieve the 
>>> tables, then add
>>> RSDP/them to the configuration table to be installed by 
>>> AcpiTableDxe/AcpiPlatformDxe.
>>> This allows MdeModulePkg to abstract away the parsing, only installing 
>>> tables
>>> available to it.
>>
>> But this is already the best approach, and already what's happening --
>> when you call EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() from the
>> platform's AcpiPlatformDxe, that's *how* you tell AcpiTableDxe in
>> MdeModulePkg to pick up the table and hook it into the RSDT / XSDT /
>> wherever, and also to manage RSD PTR as a UEFI configuration table.
>>
>> Are you (more or less) proposing a new EFI_ACPI_TABLE_PROTOCOL member
>> function for taking a forest of ACPI tables, passed in by RSD PTR?
>>
>> Sorry about being dense. :)
>>
>>> (Currently, UefiPayloadPkg's BlSupportDxe retrieves the data from a HOB and 
>>> calls
>>> `gBS->InstallConfigurationTable` with the address of RSDP).
>>>
>>> I understand that this may not work for OVMF if tables are located 
>>> differently in memory.
>>>


> Regarding UefiPayloadPkg: AcpiTableDxe is currently compiled (listed in
> DSC) but not added to a FV (not listed in FDF). So, how has this been
> tested?

 I assume through an out-of-tree platform. Many such core modules exist
 in edk2 that are not consumed by any of the virtual platforms in the
 edk2 repo itself (EmulatorPkg, ArmVirtPkg, OvmfPkg).
>>>
>>> This makes sense, but AcpiTableDxe must be added to UefiPayloadPkg's FDF
>>> if patch 2/2 is merged. Otherwise, ACPI tables will not be advertised.
>>>
>>
>> Good point; I missed that. (I'm not familiar with the

Re: [edk2-devel] [edk2-platforms] [patch V2 15/35] Platform/QuarkPlatformPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Steele, Kelly



Reviewed-by: Kelly Steele 

> -Original Message-
> From: Bi, Dandan 
> Sent: Monday, March 22, 2021 1:54 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Steele, Kelly
> 
> Subject: [edk2-platforms] [patch V2 15/35] Platform/QuarkPlatformPkg:
> Consume MdeLibs.dsc.inc for RegisterFilterLib
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
> 
> MdeLibs.dsc.inc was added for some basic/default library
> instances provided by MdePkg and RegisterFilterLibNull Library
> was also added into it as the first version of MdeLibs.dsc.inc.
> 
> So update platform dsc to consume MdeLibs.dsc.inc for
> RegisterFilterLibNull which will be consumed by IoLib and BaseLib.
> 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Signed-off-by: Dandan Bi 
> ---
>  Platform/Intel/QuarkPlatformPkg/Quark.dsc| 2 ++
>  Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> b/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> index c58da58348..c2643c2ae9 100644
> --- a/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> +++ b/Platform/Intel/QuarkPlatformPkg/Quark.dsc
> @@ -68,10 +68,12 @@ [SkuIds]
>  #
>  # Library Class section - list of all Library Classes needed by this 
> Platform.
>  #
> 
> ##
> ##
>  [LibraryClasses]
> +  !include MdePkg/MdeLibs.dsc.inc
> +
>#
># Entry point
>#
> 
> PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.in
> f
>PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
> diff --git a/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> b/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> index 6fdfba9a58..b7931e20ce 100644
> --- a/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> +++ b/Platform/Intel/QuarkPlatformPkg/QuarkMin.dsc
> @@ -56,10 +56,12 @@ [SkuIds]
>  #
>  # Library Class section - list of all Library Classes needed by this 
> Platform.
>  #
> 
> ##
> ##
>  [LibraryClasses]
> +  !include MdePkg/MdeLibs.dsc.inc
> +
>#
># Entry point
>#
> 
> PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.in
> f
>PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
> --
> 2.18.0.windows.1



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

Re: [edk2-devel] [edk2-platforms] [patch V2 28/35] Silicon/QuarkSocPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-25 Thread Steele, Kelly



Reviewed-by: Kelly Steele 

> -Original Message-
> From: Bi, Dandan 
> Sent: Monday, March 22, 2021 1:54 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Steele, Kelly
> 
> Subject: [edk2-platforms] [patch V2 28/35] Silicon/QuarkSocPkg: Consume
> MdeLibs.dsc.inc for RegisterFilterLib
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
> 
> MdeLibs.dsc.inc was added for some basic/default library
> instances provided by MdePkg and RegisterFilterLibNull Library
> was also added into it as the first version of MdeLibs.dsc.inc.
> 
> So update platform dsc to consume MdeLibs.dsc.inc for
> RegisterFilterLibNull which will be consumed by IoLib and BaseLib.
> 
> Cc: Michael D Kinney 
> Cc: Kelly Steele 
> Signed-off-by: Dandan Bi 
> ---
>  Silicon/Intel/QuarkSocPkg/QuarkSocPkg.dsc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Silicon/Intel/QuarkSocPkg/QuarkSocPkg.dsc
> b/Silicon/Intel/QuarkSocPkg/QuarkSocPkg.dsc
> index e743a5e272..815ca74dbc 100644
> --- a/Silicon/Intel/QuarkSocPkg/QuarkSocPkg.dsc
> +++ b/Silicon/Intel/QuarkSocPkg/QuarkSocPkg.dsc
> @@ -2,11 +2,11 @@
>  # INTEL Quark SoC Module Package Reference Implementations
>  #
>  # This DSC file is used for Package Level build.
>  #
>  # This Module provides FRAMEWORK reference implementation for INTEL
> Quark SoC.
> -#   Copyright (c) 2013-2016 Intel Corporation.
> +#   Copyright (c) 2013-2021 Intel Corporation.
>  #
>  #   SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> 
> @@ -38,10 +38,12 @@ [SkuIds]
>  #
>  # Library Class section - list of all Library Classes needed by this 
> Platform.
>  #
> 
> ##
> ##
>  [LibraryClasses]
> +  !include MdePkg/MdeLibs.dsc.inc
> +
>#
># Entry point
>#
>PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
> 
> UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntry
> Point.inf
> --
> 2.18.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73281): https://edk2.groups.io/g/devel/message/73281
Mute This Topic: https://groups.io/mt/81519813/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] OvmfPkg: strip build paths in release builds

2021-03-25 Thread Laszlo Ersek

On 03/25/21 04:47, Andrew Fish wrote:
> While we are talking about what toolchain targets should do I don’t 
> understand this [1]? Why does OVMF need to turn on —keepexceptiontable? If 
> these toolchains require it why don’t they turn it on? I see Mike fixed 
> it[2]. Is this another case of a global GENFW_FLAG breaking things? Looks 
> like the CLANGPDB toolchain does what I would expect, and the other 
> toolchains do not? Is there some history here I’m missing?

Unfortunately, I can't provide any background on this change. I still
have the original 2012 email thread in my local archives that led to
this commit (message ID of Mike's thread starter:
),
but there's really no more info in that than what the commit message
says -- "SOURCE_DEBUG_ENABLE needs it".

I basically never use SOURCE_DEBUG_ENABLE, so I don't know what the
needs and drawbacks are.

Adding Mike to the CC list.

Thanks
Laszlo

> 
> [1]  $ git grep "keepexceptiontable"
> BaseTools/Conf/tools_def.template:2872:DEBUG_CLANGPDB_X64_GENFW_FLAGS  = 
> --keepexceptiontable
> BaseTools/Conf/tools_def.template:2882:NOOPT_CLANGPDB_X64_GENFW_FLAGS  = 
> --keepexceptiontable
> …
> OvmfPkg/OvmfPkgIa32X64.dsc:80:  MSFT:*_*_X64_GENFW_FLAGS  = 
> --keepexceptiontable
> OvmfPkg/OvmfPkgIa32X64.dsc:81:  GCC:*_*_X64_GENFW_FLAGS   = 
> --keepexceptiontable
> OvmfPkg/OvmfPkgIa32X64.dsc:82:  INTEL:*_*_X64_GENFW_FLAGS = 
> --keepexceptiontable
> OvmfPkg/OvmfPkgX64.dsc:80:  MSFT:*_*_X64_GENFW_FLAGS  = --keepexceptiontable
> OvmfPkg/OvmfPkgX64.dsc:81:  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
> OvmfPkg/OvmfPkgX64.dsc:82:  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
> OvmfPkg/OvmfXen.dsc:71:  MSFT:*_*_X64_GENFW_FLAGS  = --keepexceptiontable
> OvmfPkg/OvmfXen.dsc:72:  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
> OvmfPkg/OvmfXen.dsc:73:  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
> 
> [2] $ git show bbcafc442b2db
> commit bbcafc442b2db91322dd3ba04e166236a41b111d
> Author: mdkinney 
> Date:   Wed Oct 3 21:00:26 2012 +
> 
> The exception table information in X64 PE/COFF images is being stripped 
> by default in the OvmfPkg.
> 
> This patch preserves this information when SOURCE_DEBUG_ENABLE is set.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> Reviewed-by: Laszlo Ersek
> 
> git-svn-id: 
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13780 
> 6f19259b-4bc3-4df7-8a09-765794883524
> 
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 9b2ba8626ab3..40fd5e97b24e 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -41,7 +41,12 @@ [BuildOptions]
>INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
>GCC:*_*_*_CC_FLAGS   = -mno-mmx -mno-sse
> -
> +!ifdef $(SOURCE_DEBUG_ENABLE)
> +  MSFT:*_*_X64_GENFW_FLAGS  = --keepexceptiontable
> +  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
> +  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
> +!endif
> +  
>  
> 
>  #
>  # SKU Identification section - list of all SKU IDs supported by this 
> Platform.
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 9ff4a5de1005..c61d41dccbbe 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -41,6 +41,11 @@ [BuildOptions]
>INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
>GCC:*_*_*_CC_FLAGS   = -mno-mmx -mno-sse
> +!ifdef $(SOURCE_DEBUG_ENABLE)
> +  MSFT:*_*_X64_GENFW_FLAGS  = --keepexceptiontable
> +  GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
> +  INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
> +!endif
>  
>  
> 
>  #
> 
> 
> Thanks,
> 
> Andrew Fish
> 
>> On Mar 24, 2021, at 8:38 PM, Andrew Fish  wrote:
>>
>> Liming,
>>
>> I understand how the tool works, but that is not how it is used. To make it 
>> work like other toolchains *_*_*_GENFW_FLAGS for ELF targets should pass 
>> —zero for builds that do not contain symbols. This is how it works today [1].
>>
>> The proposed fix is a global hammer ` RELEASE_*_*_GENFW_FLAGS = --zero` and 
>> it prevents some one from overriding the toolchain definition to turn on 
>> source level debugging for Release builds. In all the other places this is a 
>> tool chain choice. So my complaint is solving this globally vs. on a per 
>> toolchain basis. All the other toolchains don’t produce.
>>
>> If you look at the XCODE5 toolchian that we override the edk2 default   
>> DEBUG_XCODE5_X64_CC_FLAGS has -g and RELEASE_XCODE5_X64_CC_FLAGS does not. 
>> So the source level debugging or not is part of the compiler target choice. 
>>   DEBUG_XCODE5_*_MTOC_FLAGS = -align 0x20 -d

Re: [edk2-devel] [PATCH v2] OvmfPkg: strip build paths in release builds

2021-03-25 Thread Laszlo Ersek

On 03/25/21 00:25, Andrew Fish wrote:
> This breaks some usage we have have in our fork. We have symbols turned on 
> for Release builds, so this change would break that. 
> 
> It looks to me that the root cause of this issue might be that the GenFw is 
> blindly writing the debug directory entry into the PE/COFF?

Yes, that's my understanding, from TianoCore#3256.

> For native PE/COFF I think this is controlled by linker flags? For 
> Xcode/clang it is controlled by the *_XCODE5_*_MTOC_FLAGS. So at this point 
> it is kind of up to each toolchain how they want to deal with symbols on 
> release builds. 
> 
> 
> It seems kind of strange to insert a section and then zero it. Almost seems 
> like the intent of —zero was to post process compare images? 
> 
>   -z, --zeroZero the Debug Data Fields in the PE input image file.
> It also zeros the time stamp fields.
> This option can be used to compare the binary efi 
> image.
> It can't be combined with other action options
> except for -o, -r option. It is a action option.
> If it is combined with other action options, the later
> input action option will override the previous one.
> 
> And in case you are going to ask our fork uses relative paths from the Build 
> directory and/or a UUID string for the Debug Directory entry file name so it 
> is a constant value and does not impact build reproducibility. 

I'd like if we could satisfy both your use case and Ross's (Yocto's).

Until we have a technical solution for that, is it important that we
revert the patch upstream? (If it's urgent, I'm going to ask someone
else to do that, because I'll be back in April.)

> From a feature stand point this change will break any hope of source level 
> debugging with RELEASE builds. I also think it changes the exception handler 
> code output in OVMF [1] for ELF toolchains. You are going to get the (No PDB) 
> vs. the file and path you were getting today. I assume if you had tools that 
> natively produce PE/COFF and did not have a Debug Directory entry the same 
> thing would happen prior to this change. 
> 
> Status = PeCoffLoaderGetEntryPoint ((VOID *) Pe32Data, );
> if (EFI_ERROR (Status)) {
>   EntryPoint = NULL;
> }
> InternalPrintMessage (" Find image based on IP(0x%x) ", CurrentEip);
> PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);
> if (PdbPointer != NULL) {
>   InternalPrintMessage ("%a", PdbPointer);
> } else {
>   InternalPrintMessage ("(No PDB) " );
> }
> InternalPrintMessage (
>   " (ImageBase=%016lp, EntryPoint=%016p) \n",
>   (VOID *) Pe32Data,
>   EntryPoint
>   );
> 
> Not saying we have to "stop the presses", but just trying to point out the 
> side effects of this change. It is not so much that this change is bad, but 
> that we have no way to turn off the Debug Directory Entry for ELF conversion, 
> so we seem to be working around that issue with a bigger hammer?

I don't have suggestions alas, but am open to any solution that works
for you and Ross both.

Thanks (and my apologies for breaking your process!),
Laszlo

> 
> [1] 
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c#L117
> 
> Thanks,
> 
> Andrew Fish
> 
>> On Mar 24, 2021, at 4:58 AM, Ross Burton  wrote:
>>
>> GenFw will embed a NB10 section which contains the path to the input file,
>> which means the output files have build paths embedded in them.  To reduce
>> information leakage and ensure reproducible builds, pass --zero in release
>> builds to remove this information.
>>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256
>> Signed-off-by: Ross Burton 
>> ---
>> OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
>> OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
>> OvmfPkg/OvmfPkgIa32.dsc  | 1 +
>> OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
>> OvmfPkg/OvmfPkgX64.dsc   | 1 +
>> OvmfPkg/OvmfXen.dsc  | 1 +
>> 6 files changed, 6 insertions(+)
>>
>> diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
>> index 65c42284d9..69a05feea9 100644
>> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
>> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
>> @@ -78,6 +78,7 @@
>>   GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
>>   INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
>> !endif
>> +  RELEASE_*_*_GENFW_FLAGS = --zero
>>
>>   #
>>   # Disable deprecated APIs.
>> diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
>> index 4a1cdf5aca..132f55cf69 100644
>> --- a/OvmfPkg/Bhyve/BhyveX64.dsc
>> +++ b/OvmfPkg/Bhyve/BhyveX64.dsc
>> @@ -76,6 +76,7 @@
>>   GCC:*_*_X64_GENFW_FLAGS   = --keepexceptiontable
>>   INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
>> !endif
>> +  RELEASE_*_*_GENFW_FLAGS = --zero
>>
>>   #
>>   # Disable deprecated APIs.
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc

[edk2-devel] [PATCH v2 5/7] OvmfPkg/XenPlatformPei: Map extra physical address

2021-03-25 Thread Anthony PERARD via groups.io

Some information available in a Xen guest can be mapped anywhere in
the physical address space and they don't need to be backed by RAM.
For example, the shared info page.

While it's easier to put those pages anywhere, it is better to avoid
mapping it where the RAM is. It might split a nice 1G guest page table
into 4k pages and thus reducing performance of the guest when it
access its memory. Also mapping a page like the shared info page and
then unmapping it or mapping it somewhere else would live a hole in
the RAM that the guest would propably not been able to use anymore.

So the patch introduce a new function which can be used to 1:1
mapping of guest physical memory above 4G during the PEI phase so we
can map the Xen shared pages outside of memory that can be used by
guest, and as high as possible.

Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- new patch

 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |  1 +
 OvmfPkg/XenPlatformPei/Platform.h |  5 ++
 OvmfPkg/XenPlatformPei/Xen.c  | 71 +++
 3 files changed, 77 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 0ef77db92c03..8790d907d3ec 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -66,6 +66,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 7661f4a8de0a..e70ca58078eb 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -127,6 +127,11 @@ XenGetE820Map (
   UINT32 *Count
   );
 
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+  IN EFI_PHYSICAL_ADDRESS AddressToMap
+  );
+
 extern EFI_BOOT_MODE mBootMode;
 
 extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c41fecdc486e..b2a7d1c21dac 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -17,6 +17,8 @@
 //
 // The Library classes this module consumes
 //
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -386,3 +389,71 @@ InitializeXen (
 
   return EFI_SUCCESS;
 }
+
+EFI_STATUS
+PhysicalAddressIdentityMapping (
+  IN EFI_PHYSICAL_ADDRESS   AddressToMap
+  )
+{
+  INTNIndex;
+  PAGE_MAP_AND_DIRECTORY_POINTER  *L4, *L3;
+  PAGE_TABLE_ENTRY*PageTable;
+
+  DEBUG ((DEBUG_INFO, "Mapping 1:1 of address 0x%lx\n", (UINT64)AddressToMap));
+
+  // L4 / Top level Page Directory Pointers
+
+  L4 = (VOID*)(UINTN)PcdGet32 (PcdOvmfSecPageTablesBase);
+  Index = PML4_OFFSET (AddressToMap);
+
+  if (!L4[Index].Bits.Present) {
+L3 = AllocatePages (1);
+if (L3 == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (L3, EFI_PAGE_SIZE);
+
+L4[Index].Bits.ReadWrite = 1;
+L4[Index].Bits.Accessed = 1;
+L4[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)L3 >> 12;
+L4[Index].Bits.Present = 1;
+  }
+
+  // L3 / Next level Page Directory Pointers
+
+  L3 = (VOID*)(EFI_PHYSICAL_ADDRESS)(L4[Index].Bits.PageTableBaseAddress << 
12);
+  Index = PDP_OFFSET (AddressToMap);
+
+  if (!L3[Index].Bits.Present) {
+PageTable = AllocatePages (1);
+if (PageTable == NULL) {
+  return EFI_OUT_OF_RESOURCES;
+}
+
+ZeroMem (PageTable, EFI_PAGE_SIZE);
+
+L3[Index].Bits.ReadWrite = 1;
+L3[Index].Bits.Accessed = 1;
+L3[Index].Bits.PageTableBaseAddress = (EFI_PHYSICAL_ADDRESS)PageTable >> 
12;
+L3[Index].Bits.Present = 1;
+  }
+
+  // L2 / Page Table Entries
+
+  PageTable = 
(VOID*)(EFI_PHYSICAL_ADDRESS)(L3[Index].Bits.PageTableBaseAddress << 12);
+  Index = PDE_OFFSET (AddressToMap);
+
+  if (!PageTable[Index].Bits.Present) {
+PageTable[Index].Bits.ReadWrite = 1;
+PageTable[Index].Bits.Accessed = 1;
+PageTable[Index].Bits.Dirty = 1;
+PageTable[Index].Bits.MustBe1 = 1;
+PageTable[Index].Bits.PageTableBaseAddress = AddressToMap >> 21;
+PageTable[Index].Bits.Present = 1;
+  }
+
+  CpuFlushTlb ();
+
+  return EFI_SUCCESS;
+}
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v2 6/7] OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency

2021-03-25 Thread Anthony PERARD via groups.io

Calculate the frequency of the APIC timer that Xen provides.

Even though the frequency is currently hard-coded, it isn't part of
the public ABI that Xen provides and thus may change at any time. OVMF
needs to determine the frequency by an other mean.

Fortunately, Xen provides a way to determines the frequency of the
TSC, so we can use TSC to calibrate the frequency of the APIC timer.
That information is found in the shared_info page which we map and
unmap once done (XenBusDxe is going to map the page somewhere else).

The shared_info page is map at the highest physical address allowed as
it doesn't need to be in the RAM, thus there's a call to update the
page table.

The calculated frequency is only logged in this patch, it will be used
in a following patch.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
---
CC: Roger Pau Monné 
---

Notes:
v2:
- fix CamelCases
- Use U64 multiplication and division helpers
- don't read TscShift from the SharedInfo page again
- change the location of the shared info page to be outside of the ram
- check for overflow in XenDelay
- check for overflow when calculating the calculating APIC frequency

 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   2 +
 OvmfPkg/XenPlatformPei/Platform.h |   5 +
 OvmfPkg/XenPlatformPei/Platform.c |   1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 177 ++
 4 files changed, 185 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 8790d907d3ec..5732d2188871 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -52,6 +52,7 @@ [LibraryClasses]
   DebugLib
   HobLib
   IoLib
+  LocalApicLib
   PciLib
   ResourcePublicationLib
   PeiServicesLib
@@ -59,6 +60,7 @@ [LibraryClasses]
   MtrrLib
   MemEncryptSevLib
   PcdLib
+  SafeIntLib
   XenHypercallLib
 
 [Pcd]
diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index e70ca58078eb..77d88fc159d7 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -132,6 +132,11 @@ PhysicalAddressIdentityMapping (
   IN EFI_PHYSICAL_ADDRESS AddressToMap
   );
 
+VOID
+CalibrateLapicTimer (
+  VOID
+  );
+
 extern EFI_BOOT_MODE mBootMode;
 
 extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
b/OvmfPkg/XenPlatformPei/Platform.c
index 717fd0ab1a45..e9511eb40c62 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -448,6 +448,7 @@ InitializeXenPlatform (
   InitializeRamRegions ();
 
   InitializeXen ();
+  CalibrateLapicTimer ();
 
   if (mBootMode != BOOT_ON_S3_RESUME) {
 ReserveEmuVariableNvStore ();
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b2a7d1c21dac..7524aaa11a29 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -21,8 +21,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -457,3 +459,178 @@ PhysicalAddressIdentityMapping (
 
   return EFI_SUCCESS;
 }
+
+STATIC
+EFI_STATUS
+MapSharedInfoPage (
+  IN VOID *PagePtr
+  )
+{
+  xen_add_to_physmap_t  Parameters;
+  INTN  ReturnCode;
+
+  Parameters.domid = DOMID_SELF;
+  Parameters.space = XENMAPSPACE_shared_info;
+  Parameters.idx = 0;
+  Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+  ReturnCode = XenHypercallMemoryOp (XENMEM_add_to_physmap, );
+  if (ReturnCode != 0) {
+return EFI_NO_MAPPING;
+  }
+  return EFI_SUCCESS;
+}
+
+STATIC
+VOID
+UnmapXenPage (
+  IN VOID *PagePtr
+  )
+{
+  xen_remove_from_physmap_t Parameters;
+  INTN  ReturnCode;
+
+  Parameters.domid = DOMID_SELF;
+  Parameters.gpfn = (UINTN)PagePtr >> EFI_PAGE_SHIFT;
+  ReturnCode = XenHypercallMemoryOp (XENMEM_remove_from_physmap, );
+  ASSERT (ReturnCode == 0);
+}
+
+
+STATIC
+UINT64
+GetCpuFreq (
+  IN XEN_VCPU_TIME_INFO *VcpuTime
+  )
+{
+  UINT32 Version;
+  UINT32 TscToSystemMultiplier;
+  INT8   TscShift;
+  UINT64 CpuFreq;
+
+  do {
+Version = VcpuTime->Version;
+MemoryFence ();
+TscToSystemMultiplier = VcpuTime->TscToSystemMultiplier;
+TscShift = VcpuTime->TscShift;
+MemoryFence ();
+  } while (((Version & 1) != 0) && (Version != VcpuTime->Version));
+
+  CpuFreq = DivU64x32 (LShiftU64 (10ULL, 32), TscToSystemMultiplier);
+  if (TscShift >= 0) {
+  CpuFreq = RShiftU64 (CpuFreq, TscShift);
+  } else {
+  CpuFreq = LShiftU64 (CpuFreq, -TscShift);
+  }
+  return CpuFreq;
+}
+
+STATIC
+VOID
+XenDelay (
+  IN XEN_VCPU_TIME_INFO *VcpuTimeInfo,
+  IN UINT64 DelayNs
+  )
+{
+  UINT64Tick;
+  UINT64CpuFreq;
+  UINT64Delay;
+  UINT64DelayTick;
+  UINT64NewTick;
+  RETURN_STATUS Status;
+
+  Tick = AsmReadTsc ();
+
+  CpuFreq = GetCpuFreq (VcpuTimeInfo);
+  Status =

[edk2-devel] [PATCH v2 7/7] OvmfPkg/OvmfXen: Set PcdFSBClock

2021-03-25 Thread Anthony PERARD via groups.io

Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct
value when SecPeiDxeTimerLibCpu start to use it for the APIC timer.

Currently, nothing appear to use the value in PcdFSBClock before
XenPlatformPei had a chance to set it even though TimerLib is included
in modules runned before XenPlatformPei.

XenPlatformPei doesn't use any of the functions that would use that
value. No other modules in the PEI phase seems to use the TimerLib
before PcdFSBClock is set. There are currently two other modules in
the PEI phase that needs the TimerLib:
- S3Resume2Pei, but only because LocalApicLib needs it, but nothing is
  using the value from PcdFSBClock.
- CpuMpPei, but I believe it only runs after XenPlatformPei

Before the PEI phase, there's the SEC phase, and SecMain needs
TimerLib because of LocalApicLib. And it initialise the APIC timers
for the debug agent. But I don't think any of the DebugLib that
OvmfXen could use are actually using the *Delay functions in TimerLib,
and so would not use the value from PcdFSBClock which would be
uninitialised.

A simple runtime test showed that TimerLib doesn't use PcdFSBClock
value before it is set.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- keep the default value of PcdFSBClock because that is part of the syntax.

 OvmfPkg/OvmfXen.dsc   | 4 +---
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 4 
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 507029404f0b..faf3930ace04 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -442,9 +442,6 @@ [PcdsFixedAtBuild]
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
-  ## Xen vlapic's frequence is 100 MHz
-  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
-
   # We populate DXE IPL tables with 1G pages preferably on Xen
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable|TRUE
 
@@ -471,6 +468,7 @@ [PcdsDynamicDefault]
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
   gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x8
 
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 
   # Set video resolution for text setup.
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 5732d2188871..87dd4b24679a 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -85,6 +85,7 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
 
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 7524aaa11a29..a29b4e04086e 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -632,5 +632,9 @@ CalibrateLapicTimer (
   Freq = DivU64x64Remainder (Dividend, TscTick2 - TscTick, NULL);
   DEBUG ((DEBUG_INFO, "APIC Freq % 8lu Hz\n", Freq));
 
+  ASSERT (Freq <= MAX_UINT32);
+  Status = PcdSet32S (PcdFSBClock, Freq);
+  ASSERT_RETURN_ERROR (Status);
+
   UnmapXenPage (SharedInfo);
 }
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v2 4/7] OvmfPkg/IndustryStandard: Introduce PageTable.h

2021-03-25 Thread Anthony PERARD via groups.io

We are going to use the page table structure in yet another place,
collect the types and macro that can be used from another module
rather that making yet another copy.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
---
CC: Tom Lendacky 
CC: Brijesh Singh 
---

Notes:
v2:
- new patch

 .../IndustryStandard/PageTable.h} | 117 +-
 .../BaseMemEncryptSevLib/X64/VirtualMemory.h  | 143 +-
 2 files changed, 5 insertions(+), 255 deletions(-)
 copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h => 
Include/IndustryStandard/PageTable.h} (60%)

diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h 
b/OvmfPkg/Include/IndustryStandard/PageTable.h
similarity index 60%
copy from OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
copy to OvmfPkg/Include/IndustryStandard/PageTable.h
index 996f94f07ebb..e3da4e8cf21c 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
+++ b/OvmfPkg/Include/IndustryStandard/PageTable.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Virtual Memory Management Services to set or clear the memory encryption bit
+  x86_64 Page Tables structures
 
   Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
   Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
@@ -11,17 +11,10 @@
 
 **/
 
-#ifndef __VIRTUAL_MEMORY__
-#define __VIRTUAL_MEMORY__
+#ifndef __PAGE_TABLE_H__
+#define __PAGE_TABLE_H__
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define SYS_CODE64_SEL 0x38
+#include 
 
 #pragma pack(1)
 
@@ -165,106 +158,4 @@ typedef union {
 #define PTE_OFFSET(x)   ( (x >> 12) & PAGETABLE_ENTRY_MASK)
 #define PAGING_1G_ADDRESS_MASK_64   0x000FC000ull
 
-#define PAGE_TABLE_POOL_ALIGNMENT   BASE_2MB
-#define PAGE_TABLE_POOL_UNIT_SIZE   SIZE_2MB
-#define PAGE_TABLE_POOL_UNIT_PAGES  \
-  EFI_SIZE_TO_PAGES (PAGE_TABLE_POOL_UNIT_SIZE)
-#define PAGE_TABLE_POOL_ALIGN_MASK  \
-  (~(EFI_PHYSICAL_ADDRESS)(PAGE_TABLE_POOL_ALIGNMENT - 1))
-
-typedef struct {
-  VOID*NextPool;
-  UINTN   Offset;
-  UINTN   FreePages;
-} PAGE_TABLE_POOL;
-
-/**
-  Return the pagetable memory encryption mask.
-
-  @return  The pagetable memory encryption mask.
-
-**/
-UINT64
-EFIAPI
-InternalGetMemEncryptionAddressMask (
-  VOID
-  );
-
-/**
-  This function clears memory encryption bit for the memory region specified by
-  PhysicalAddress and Length from the current page table context.
-
-  @param[in]  Cr3BaseAddress  Cr3 Base Address (if zero then use
-  current CR3)
-  @param[in]  PhysicalAddress The physical address that is the start
-  address of a memory region.
-  @param[in]  Length  The length of memory region
-  @param[in]  Flush   Flush the caches before applying the
-  encryption mask
-
-  @retval RETURN_SUCCESS  The attributes were cleared for the
-  memory region.
-  @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
-  @retval RETURN_UNSUPPORTED  Clearing the memory encyrption attribute
-  is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryDecrypted (
-  IN  PHYSICAL_ADDRESSCr3BaseAddress,
-  IN  PHYSICAL_ADDRESSPhysicalAddress,
-  IN  UINTN   Length,
-  IN  BOOLEAN Flush
-  );
-
-/**
-  This function sets memory encryption bit for the memory region specified by
-  PhysicalAddress and Length from the current page table context.
-
-  @param[in]  Cr3BaseAddress  Cr3 Base Address (if zero then use
-  current CR3)
-  @param[in]  PhysicalAddress The physical address that is the start
-  address of a memory region.
-  @param[in]  Length  The length of memory region
-  @param[in]  Flush   Flush the caches before applying the
-  encryption mask
-
-  @retval RETURN_SUCCESS  The attributes were set for the memory
-  region.
-  @retval RETURN_INVALID_PARAMETERNumber of pages is zero.
-  @retval RETURN_UNSUPPORTED  Setting the memory encyrption attribute
-  is not supported
-**/
-RETURN_STATUS
-EFIAPI
-InternalMemEncryptSevSetMemoryEncrypted (
-  IN  PHYSICAL_ADDRESSCr3BaseAddress,
-  IN  PHYSICAL_ADDRESSPhysicalAddress,
-  IN  UINTN   Length,
-  IN  BOOLEAN Flush
-  );
-
-/**
-  Returns the encryption state of the specified virtual address range.
-
-  @param[in]  Cr3BaseAddress  Cr3 Base Address (if zero then use
-  current CR3)
-  @param[in]

[edk2-devel] [PATCH v2 1/7] OvmfPkg/XenResetVector: Silent a warning from nasm

2021-03-25 Thread Anthony PERARD via groups.io

To avoid nasm generating a warning, replace the macro by the value
expected to be stored in eax.
  Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds

Reported-by: Laszlo Ersek 
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm 
b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
index 2df0f12e18cb..c761e9d30729 100644
--- a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
+++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
@@ -73,7 +73,7 @@ xenPVHMain:
 ;
 ; parameter for Flat32SearchForBfvBase
 ;
-mov eax, ADDR_OF(fourGigabytes)
+mov eax, 0   ; ADDR_OF(fourGigabytes)
 add eax, edx ; add delta
 
 ;
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v2 3/7] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO

2021-03-25 Thread Anthony PERARD via groups.io

We are going to use new fields from the Xen headers. Apply the EDK2
coding style so that the code that is going to use it doesn't look out
of place.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v2:
- fix case of Tsc* field

 OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h 
b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
index e55d93263285..79a4e212e7c2 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h
@@ -183,10 +183,10 @@ struct vcpu_time_info {
  * The correct way to interact with the version number is similar to
  * Linux's seqlock: see the implementations of read_seqbegin/read_seqretry.
  */
-UINT32 version;
+UINT32 Version;
 UINT32 pad0;
-UINT64 tsc_timestamp;   /* TSC at last update of time vals.  */
-UINT64 system_time; /* Time, in nanosecs, since boot.*/
+UINT64 TscTimestamp;   /* TSC at last update of time vals.  */
+UINT64 SystemTime; /* Time, in nanosecs, since boot.*/
 /*
  * Current system time:
  *   system_time +
@@ -194,11 +194,11 @@ struct vcpu_time_info {
  * CPU frequency (Hz):
  *   ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
  */
-UINT32 tsc_to_system_mul;
-INT8   tsc_shift;
+UINT32 TscToSystemMultiplier;
+INT8   TscShift;
 INT8   pad1[3];
 }; /* 32 bytes */
-typedef struct vcpu_time_info vcpu_time_info_t;
+typedef struct vcpu_time_info XEN_VCPU_TIME_INFO;
 
 struct vcpu_info {
 /*
@@ -234,7 +234,7 @@ struct vcpu_info {
 #endif /* XEN_HAVE_PV_UPCALL_MASK */
 xen_ulong_t evtchn_pending_sel;
 struct arch_vcpu_info arch;
-struct vcpu_time_info time;
+struct vcpu_time_info Time;
 }; /* 64 bytes (x86) */
 #ifndef __XEN__
 typedef struct vcpu_info vcpu_info_t;
@@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t;
  * of this structure remaining constant.
  */
 struct shared_info {
-struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
+struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS];
 
 /*
  * A domain can create "event channels" on which it can send and receive
@@ -299,6 +299,7 @@ struct shared_info {
 };
 #ifndef __XEN__
 typedef struct shared_info shared_info_t;
+typedef struct shared_info XEN_SHARED_INFO;
 #endif
 
 /* Turn a plain number into a C UINTN constant. */
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v2 2/7] MdePkg: Allow PcdFSBClock to by Dynamic

2021-03-25 Thread Anthony PERARD via groups.io

We are going to want to change the value of PcdFSBClock at run time in
OvmfXen, so move it to the PcdsDynamic section.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Liming Gao 
---
CC: Bob Feng 
CC: Michael D Kinney 
CC: Zhiguang Liu 
---
 MdePkg/MdePkg.dec | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 1d2637acc22a..f0d3b91fc635 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2257,10 +2257,6 @@ [PcdsFixedAtBuild,PcdsPatchableInModule]
   # @ValidList  0x8001 | 8, 16, 32
   gEfiMdePkgTokenSpaceGuid.PcdPort80DataWidth|8|UINT8|0x002d
 
-  ## This value is used to configure X86 Processor FSB clock.
-  # @Prompt FSB Clock.
-  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
-
   ## The maximum printable number of characters. UefLib functions: 
AsciiPrint(), AsciiErrorPrint(),
   #  PrintXY(), AsciiPrintXY(), Print(), ErrorPrint() base on this PCD value 
to print characters.
   # @Prompt Maximum Printable Number of Characters.
@@ -2364,5 +2360,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # @Prompt Boot Timeout (s)
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0x|UINT16|0x002c
 
+  ## This value is used to configure X86 Processor FSB clock.
+  # @Prompt FSB Clock.
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|2|UINT32|0x000c
+
 [UserExtensions.TianoCore."ExtraFiles"]
   MdePkgExtra.uni
-- 
Anthony PERARD



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

[edk2-devel] [PATCH v2 0/7] OvmfXen: Set PcdFSBClock at runtime

2021-03-25 Thread Anthony PERARD via groups.io

Patch series available in this git branch:
git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v2

Changes in v2:
- main change is to allow mapping of Xen pages outside of the RAM
  see patch: "OvmfPkg/XenPlatformPei: Map extra physical address"
- that new function allows to map the Xen shared info page (where we can find
  information about tsc frequency) at the highest physical address allowed.

Hi,

OvmfXen uses the APIC timer, but with an hard-coded frequency that may change
as pointed out here:
  https://edk2.groups.io/g/devel/message/45185
  <20190808134423.ybqg3qkpw5ucfzk4@Air-de-Roger>

This series changes that so the frequency is calculated at runtime.

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

There is also one cleanup patch that has nothing to do with the rest.

Cheers,

Anthony PERARD (7):
  OvmfPkg/XenResetVector: Silent a warning from nasm
  MdePkg: Allow PcdFSBClock to by Dynamic
  OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to
XEN_VCPU_TIME_INFO
  OvmfPkg/IndustryStandard: Introduce PageTable.h
  OvmfPkg/XenPlatformPei: Map extra physical address
  OvmfPkg/XenPlatformPei: Calibrate APIC timer frequency
  OvmfPkg/OvmfXen: Set PcdFSBClock

 MdePkg/MdePkg.dec |   8 +-
 OvmfPkg/OvmfXen.dsc   |   4 +-
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   4 +
 .../IndustryStandard/PageTable.h} | 117 +---
 OvmfPkg/Include/IndustryStandard/Xen/xen.h|  17 +-
 .../BaseMemEncryptSevLib/X64/VirtualMemory.h  | 143 +-
 OvmfPkg/XenPlatformPei/Platform.h |  10 +
 OvmfPkg/XenPlatformPei/Platform.c |   1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 252 ++
 OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm|   2 +-
 10 files changed, 287 insertions(+), 271 deletions(-)
 copy OvmfPkg/{Library/BaseMemEncryptSevLib/X64/VirtualMemory.h => 
Include/IndustryStandard/PageTable.h} (60%)

-- 
Anthony PERARD



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

Re: [edk2-devel] [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

2021-03-25 Thread Abner Chang

Hi Zhichao,
I resend v4 patch, in which your R-B to the previous patch is removed and 
Liming is added to CC list. No others changes were made in this patches.
I will send v5 with the correction on copyright. Or can I just push to master 
with the correction and your R-B?

Thanks
Abner

> -Original Message-
> From: Gao, Zhichao [mailto:zhichao@intel.com]
> Sent: Thursday, March 25, 2021 5:09 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> devel@edk2.groups.io
> Cc: Ni, Ray ; Wang, Nickle (HPS SW)
> ; O'Hanley, Peter (EXL) ;
> Liming Gao 
> Subject: RE: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> Redfish protocols
> 
> First, thanks Liming's catch.
> 
> Abner,
> 
> The patch has been updated, you should remove my R-B for the V4 version.
> Otherwise the reviewers/maintainers may treated it as reviewed one.
> And please add the one who already gave the comment for your patch to the
> Cc list. They care about the about the change and this would help them to
> know the update and have a chance to view your patch in an early time.
> 
> For this patch, the copyright should be updated to 2021. With this updated,
> Reviewed-by: Zhichao Gao 
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Abner Chang 
> > Sent: Thursday, March 25, 2021 12:53 PM
> > To: devel@edk2.groups.io
> > Cc: Ni, Ray ; Gao, Zhichao ;
> > Nickle Wang ; Peter O'Hanley
> > 
> > Subject: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI
> Redfish
> > protocols
> >
> > Add handle parsing for EFI Redfish Discover protocol.
> > Add handle parsing for EFI RestEx protocol.
> >
> > Signed-off-by: Abner Chang 
> > Cc: Ray Ni 
> > Cc: Zhichao Gao 
> > Cc: Nickle Wang 
> > Cc: Peter O'Hanley 
> > Reviewed-by: Zhichao Gao 
> > ---
> >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++-
> >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.c   | 8 +++-
> >  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 4 +++-
> >  3 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > index 93b69cd8e9..446cd8d609 100644
> > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > @@ -2,7 +2,7 @@
> >  #  Provides interface to advanced shell functionality for parsing both
> handle
> > and protocol database.
> >  #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.  
> >  #
> (C)
> > Copyright 2013-2015 Hewlett-Packard Development Company, L.P. -#
> > (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> > +#  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> > +LP
> >  #
> >  #  SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -269,6 +269,8 @@
> >gEfiHttpProtocolGuid## UNDEFINED
> >gEfiHttpUtilitiesProtocolGuid   ## UNDEFINED
> >gEfiRestProtocolGuid## UNDEFINED
> > +  gEfiRestExProtocolGuid  ## UNDEFINED
> > +  gEfiRedfishDiscoverProtocolGuid ## UNDEFINED
> >gEfiMmEndOfDxeProtocolGuid  ## UNDEFINED
> >gEfiMmIoTrapDispatchProtocolGuid## UNDEFINED
> >gEfiMmPowerButtonDispatchProtocolGuid   ## UNDEFINED
> > diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > index 500a95a89a..e34cefd7b4 100644
> > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> > @@ -3,7 +3,7 @@
> >
> >Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
> >(C) Copyright 2013-2015 Hewlett-Packard Development Company,
> L.P.
> > -  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development
> LP
> > +  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> LP
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -2250,6 +2250,12 @@ STATIC CONST GUID_INFO_BLOCK
> > mGuidStringList[] = {
> >{STRING_TOKEN(STR_PARTITION_INFO),
> > ,
> > PartitionInfoProtocolDumpInformation},
> >{STRING_TOKEN(STR_HII_POPUP), ,
> > NULL},
> >
> > +//
> > +// UEFI 2.8
> > +//
> > +  {STRING_TOKEN(STR_REST_EX),   ,
> > NULL},
> > +  {STRING_TOKEN(STR_REDFISH_DISCOVER),
> > , NULL},
> > +
> >  //
> >  // PI Spec ones
> >  //
> > diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> > b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> > index 9c8028d0d5..69fcbdfe0e 100644
> > --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> > +++

[edk2-devel] [PATCH v4 RESEND 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

2021-03-25 Thread Abner Chang

Add handle parsing for EFI Redfish Discover protocol.
Add handle parsing for EFI RestEx protocol.

Signed-off-by: Abner Chang 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Nickle Wang 
Cc: Peter O'Hanley 
Cc: Liming Gao 
---
 .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++-
 .../Library/UefiHandleParsingLib/UefiHandleParsingLib.c   | 8 +++-
 .../Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 4 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
index 93b69cd8e9..446cd8d609 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
@@ -2,7 +2,7 @@
 #  Provides interface to advanced shell functionality for parsing both handle 
and protocol database.
 #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved. 
 #  (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-#  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
+#  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -269,6 +269,8 @@
   gEfiHttpProtocolGuid## UNDEFINED
   gEfiHttpUtilitiesProtocolGuid   ## UNDEFINED
   gEfiRestProtocolGuid## UNDEFINED
+  gEfiRestExProtocolGuid  ## UNDEFINED
+  gEfiRedfishDiscoverProtocolGuid ## UNDEFINED
   gEfiMmEndOfDxeProtocolGuid  ## UNDEFINED
   gEfiMmIoTrapDispatchProtocolGuid## UNDEFINED
   gEfiMmPowerButtonDispatchProtocolGuid   ## UNDEFINED
diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
index 500a95a89a..e34cefd7b4 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
@@ -3,7 +3,7 @@
 
   Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -2250,6 +2250,12 @@ STATIC CONST GUID_INFO_BLOCK mGuidStringList[] = {
   {STRING_TOKEN(STR_PARTITION_INFO),,
PartitionInfoProtocolDumpInformation},
   {STRING_TOKEN(STR_HII_POPUP), , 
NULL},
 
+//
+// UEFI 2.8
+//
+  {STRING_TOKEN(STR_REST_EX),   ,   
   NULL},
+  {STRING_TOKEN(STR_REDFISH_DISCOVER),  ,  
   NULL},
+
 //
 // PI Spec ones
 //
diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni 
b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
index 9c8028d0d5..69fcbdfe0e 100644
--- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
+++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
@@ -2,7 +2,7 @@
 //
 // Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved. 
 // (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-// (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
+// (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
 // SPDX-License-Identifier: BSD-2-Clause-Patent
 //
 // Module Name:
@@ -308,6 +308,8 @@
 #string STR_NET_HTTP  #language en-US "Http"
 #string STR_NET_HTTP_U#language en-US "HttpUtilities"
 #string STR_REST  #language en-US "Rest"
+#string STR_REST_EX   #language en-US "RestEx"
+#string STR_REDFISH_DISCOVER  #language en-US "RedfishDiscover"
 
 #string STR_MM_EOD#language en-US "MmEndOfDxe"
 #string STR_MM_ITD#language en-US "MmIoTrapDispatch"
-- 
2.17.1



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

[edk2-devel] [PATCH v4 RESEND 1/2] MdePkg/Include: EFI Redfish Discover protocol

2021-03-25 Thread Abner Chang

Move GUID definition of EFI Redfish Discover protocol
to under MdePkg. With this we don't have dependency of
RedfishPkg in ShellPkg.

Signed-off-by: Abner Chang 

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Nickle Wang 
Cc: Peter O'Hanley 
Reviewed-by: Liming Gao 
---
 MdePkg/MdePkg.dec |  5 +-
 RedfishPkg/RedfishPkg.dec |  3 -
 .../Include/Protocol/RedfishDiscover.h| 72 +--
 3 files changed, 37 insertions(+), 43 deletions(-)
 rename {RedfishPkg => MdePkg}/Include/Protocol/RedfishDiscover.h (79%)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 1d2637acc2..e667d44db5 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -6,7 +6,7 @@
 #
 # Copyright (c) 2007 - 2020, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-# (C) Copyright 2016 - 2020 Hewlett Packard Enterprise Development LP
+# (C) Copyright 2016 - 2021 Hewlett Packard Enterprise Development LP
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -1863,6 +1863,9 @@
   ## Include/Protocol/RestJsonStructure.h
   gEfiRestJsonStructureProtocolGuid  = { 0xa9a048f6, 0x48a0, 0x4714, {0xb7, 
0xda, 0xa9, 0xad,0x87, 0xd4, 0xda, 0xc9 }}
 
+  ## Include/Protocol/RedfishDiscover.h
+  gEfiRedfishDiscoverProtocolGuid  = { 0x5db12509, 0x4550, 0x4347, { 0x96, 
0xb3, 0x73, 0xc0, 0xff, 0x6e, 0x86, 0x9f }}
+
   #
   # Protocols defined in Shell2.0
   #
diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index b3e25268a0..846c19fd5e 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -67,9 +67,6 @@
   RedfishLib|PrivateInclude/Library/RedfishLib.h
 
 [Protocols]
-  ## Include/Protocol/RedfishDiscover.h
-  gEfiRedfishDiscoverProtocolGuid  = { 0x5db12509, 0x4550, 0x4347, { 0x96, 
0xb3, 0x73, 0xc0, 0xff, 0x6e, 0x86, 0x9f }}
-
   ## Include/Protocol/EdkIIRedfishCredential.h
   gEdkIIRedfishCredentialProtocolGuid = { 0x8804377, 0xaf7a, 0x4496, { 0x8a, 
0x7b, 0x17, 0x59, 0x0, 0xe9, 0xab, 0x46 } }
 
diff --git a/RedfishPkg/Include/Protocol/RedfishDiscover.h 
b/MdePkg/Include/Protocol/RedfishDiscover.h
similarity index 79%
rename from RedfishPkg/Include/Protocol/RedfishDiscover.h
rename to MdePkg/Include/Protocol/RedfishDiscover.h
index 4c91605c4e..8dbb70b082 100644
--- a/RedfishPkg/Include/Protocol/RedfishDiscover.h
+++ b/MdePkg/Include/Protocol/RedfishDiscover.h
@@ -1,20 +1,19 @@
 /** @file
   This file defines the EFI Redfish Discover Protocol interface.
 
-  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
+  @par Revision Reference:
+  - Some corrections and revises are added to UEFI Specification 2.9.
+  - This Protocol is introduced in UEFI Specification 2.8.
+
 **/
 
 #ifndef EFI_REDFISH_DISCOVER_PROTOCOL_H_
 #define EFI_REDFISH_DISCOVER_PROTOCOL_H_
 
-#include 
-#include 
-#include 
-#include 
-
 //
 // GUID definitions
 //
@@ -40,24 +39,21 @@ typedef UINT32 EFI_REDFISH_DISCOVER_FLAG;
///< 3 to 15. The 
corresponding duration is 8 to 2^15 seconds.
///< Duration is only 
valid when EFI_REDFISH_DISCOVER_KEEP_ALIVE
///< is set to 1.
-#define EFI_REDFISH_DISCOVER_DURATION_BIT_POS 8
-
 typedef struct _EFI_REDFISH_DISCOVER_PROTOCOL EFI_REDFISH_DISCOVER_PROTOCOL;
-typedef struct _EFI_REDFISH_DISCOVERED_INFORMATION 
EFI_REDFISH_DISCOVERED_INFORMATION;
-
-typedef struct _EFI_REDFISH_DISCOVERED_INFORMATION {
-  EFI_HANDLE RedfishRestExHandle;   ///< REST EX EFI handle associated 
with this Redfish service.
-  BOOLEAN IsUdp6;   ///< Indicates it's IP versino 6.
-  EFI_IP_ADDRESS  RedfishHostIpAddress; ///< IP address of Redfish service.
-  UINTN RedfishVersion; ///< Redfish service version.
-  CHAR16 *Location; ///< Redfish service location.
-  CHAR16 *Uuid; ///< Redfish service UUID.
-  CHAR16 *Os;   ///< Redfish service OS.
-  CHAR16 *OSVersion;///< Redfish service OS version.
-  CHAR16 *Product;  ///< Redfish service product name.
-  CHAR16 *ProductVer;   ///< Redfish service product 
version.
-  BOOLEAN UseHttps; ///< Using HTTPS.
-};
+
+typedef struct {
+  EFI_HANDLERedfishRestExHandle;///< REST EX EFI handle associated 
with this Redfish service.
+  BOOLEAN   IsUdp6; ///< Indicates it's IP versino 6.
+  EFI_IP_ADDRESSRedfishHostIpAddress;   ///< IP address of Redfish service.
+  UINTN RedfishVersion; ///< Redfish service version.
+  CHAR16*Location;  ///< Redfish

[edk2-devel] [PATCH v4 RESEND 0/2] Support EFI Redfish protocols

2021-03-25 Thread Abner Chang

In v4: In UefiHandleParsingLib.c, move the changes for UEFI 2.8 to
   below UEFI 2.7 section
In v3: Correct the mismatched definitions in both
   RedfishDiscover.h and UEFI spec 2.8 (Refer to v2.9).
In v2: Address comments given by Liming on patch 1/2.

Add handle parsing for EFI Redfish Discover protocol and
EFI RestEx protocol.

This change also moves the GUID definition of EFI Redfish Discover
protocol to under MdePkg. With this we don't have dependency of
RedfishPkg in ShellPkg.

Signed-off-by: Abner Chang 

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Nickle Wang 
Cc: Peter O'Hanley 

Abner Chang (2):
  MdePkg/Include: EFI Redfish Discover protocol
  ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

 MdePkg/MdePkg.dec |  5 +-
 RedfishPkg/RedfishPkg.dec |  3 -
 .../UefiHandleParsingLib.inf  |  4 +-
 .../Include/Protocol/RedfishDiscover.h| 72 +--
 .../UefiHandleParsingLib.c|  8 ++-
 .../UefiHandleParsingLib.uni  |  4 +-
 6 files changed, 50 insertions(+), 46 deletions(-)
 rename {RedfishPkg => MdePkg}/Include/Protocol/RedfishDiscover.h (79%)

-- 
2.17.1



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

Re: 回复: [edk2-devel] [RFC PATCH 09/19] MdePkg: Add AsmPvalidate() support

2021-03-25 Thread Brijesh Singh

On 3/24/21 9:49 PM, gaoliming wrote:
> Is this API X64 only? Or IA32 and X64 both?


Theoretically the instruction is available on both IA32 and X64 but its
used only in X64. AMD SEV, SEV-ES and SEV-SNP support is available for
X64 arch only. I was not sure if the EDK2 community is okay with the
dead-code. Do you think it still makes sense to add the IA32 API for it ?


>
> Thanks
> Liming
>> -邮件原件-
>> 发件人: devel@edk2.groups.io  代表 Brijesh Singh
>> 发送时间: 2021年3月24日 23:32
>> 收件人: devel@edk2.groups.io
>> 抄送: Brijesh Singh ; James Bottomley
>> ; Min Xu ; Jiewen Yao
>> ; Tom Lendacky ;
>> Jordan Justen ; Ard Biesheuvel
>> ; Laszlo Ersek 
>> 主题: [edk2-devel] [RFC PATCH 09/19] MdePkg: Add AsmPvalidate() support
>>
>> BZ: 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3275data=04%7C01%7Cbrijesh.singh%40amd.com%7C125d11ea64cf4f4ecd2108d8ef38a8e7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637522373939810930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=f3fM%2Fnw3X1lHhf7SPKTxDOLo0GcnU465yvyf0IIyD80%3Dreserved=0
>>
>> The PVALIDATE instruction validates or rescinds validation of a guest
>> page RMP entry. Upon completion, a return code is stored in EAX, rFLAGS
>> bits OF, ZF, AF, PF and SF are set based on this return code. If the
>> instruction completed succesfully, the rFLAGS bit CF indicates if the
>> contents of the RMP entry were changed or not.
>>
>> For more information about the instruction see AMD APM volume 3.
>>
>> Cc: James Bottomley 
>> Cc: Min Xu 
>> Cc: Jiewen Yao 
>> Cc: Tom Lendacky 
>> Cc: Jordan Justen 
>> Cc: Ard Biesheuvel 
>> Cc: Laszlo Ersek 
>> Signed-off-by: Brijesh Singh 
>> ---
>>  MdePkg/Include/Library/BaseLib.h  | 37 +
>>  MdePkg/Library/BaseLib/BaseLib.inf|  1 +
>>  MdePkg/Library/BaseLib/X64/Pvalidate.nasm | 43 
>>  3 files changed, 81 insertions(+)
>>
>> diff --git a/MdePkg/Include/Library/BaseLib.h
>> b/MdePkg/Include/Library/BaseLib.h
>> index 1171a0ffb5..fee27e9a1b 100644
>> --- a/MdePkg/Include/Library/BaseLib.h
>> +++ b/MdePkg/Include/Library/BaseLib.h
>> @@ -7495,5 +7495,42 @@ PatchInstructionX86 (
>>IN  UINTNValueSize
>>);
>>
>> +/**
>> + Execute a PVALIDATE instruction to validate or rescnids validation of a
> guest
>> + page's RMP entry.
>> +
>> + Upon completion, in addition to the return value the instruction also
>> updates
>> + the eFlags. A caller must check both the return code as well as eFlags
> to
>> + determine if the RMP entry has been updated.
>> +
>> + The function is available on x64.
>> +
>> + @param[in]AddressThe guest virtual address to validate.
>> + @param[in]PageSize   The page size to use.
>> + @param[i] Validate   Validate or rescinds.
>> + @param[out]   Eflags The value of Eflags after PVALIDATE
>> completion.
>> +
>> + @retval   PvalidateRetValue  The return value from the PVALIDATE
>> instruction.
>> +**/
>> +typedef enum {
>> +  PVALIDATE_PAGE_SIZE_4K = 0,
>> +  PVALIDATE_PAGE_SIZE_2M,
>> +} PvalidatePageSize;
>> +
>> +typedef enum {
>> +  PVALIDATE_RET_SUCCESS = 0,
>> +  PVALIDATE_RET_FAIL_INPUT = 1,
>> +  PVALIDATE_RET_FAIL_SIZEMISMATCH = 6,
>> +} PvalidateRetValue;
>> +
>> +PvalidateRetValue
>> +EFIAPI
>> +AsmPvalidate (
>> +  IN   PvalidatePageSize   PageSize,
>> +  IN   BOOLEAN Validate,
>> +  IN   UINTN   Address,
>> +  OUT  IA32_EFLAGS32   *Eflags
>> +  );
>> +
>>  #endif // defined (MDE_CPU_IA32) || defined (MDE_CPU_X64)
>>  #endif // !defined (__BASE_LIB__)
>> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
>> b/MdePkg/Library/BaseLib/BaseLib.inf
>> index 3b85c56c3c..01aa5cc7a4 100644
>> --- a/MdePkg/Library/BaseLib/BaseLib.inf
>> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
>> @@ -319,6 +319,7 @@
>>X64/RdRand.nasm
>>X64/XGetBv.nasm
>>X64/VmgExit.nasm
>> +  X64/Pvalidate.nasm
>>ChkStkGcc.c  | GCC
>>
>>  [Sources.EBC]
>> diff --git a/MdePkg/Library/BaseLib/X64/Pvalidate.nasm
>> b/MdePkg/Library/BaseLib/X64/Pvalidate.nasm
>> new file mode 100644
>> index 00..f2aba114ac
>> --- /dev/null
>> +++ b/MdePkg/Library/BaseLib/X64/Pvalidate.nasm
>> @@ -0,0 +1,43 @@
>>
> +;--
> ---
>> +;
>> +; Copyright (c) 2020-2021, AMD. All rights reserved.
>> +; SPDX-License-Identifier: BSD-2-Clause-Patent
>> +;
>> +; Module Name:
>> +;
>> +;   Pvalidate.Asm
>> +;
>> +; Abstract:
>> +;
>> +;   AsmPvalidate function
>> +;
>> +; Notes:
>> +;
>>
> +;--
> ---
>> +
>> +SECTION .text
>> +
>>
> +;--
> ---
>> +;  PvalidateRetValue
>> +;  EFIAPI
>> +;  AsmPvalidate (
>> +;IN   UINT32  RmpPageSize
>> +;IN   UINT32  Validate,
>> +;IN

[edk2-devel] !!! DEPRECATED INTERFACE !!! VariableLockRequestToLock

2021-03-25 Thread Marcin Wojtas

Hi,

When booting the latest edk2 on Marvell SoCs I get a number of prints as
below:

!!! DEPRECATED INTERFACE !!! VariableLockRequestToLock() will go away soon!
!!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!
!!! DEPRECATED INTERFACE !!! Variable: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
PlatformLangCodes
!!! DEPRECATED INTERFACE !!! VariableLockRequestToLock() will go away soon!
!!! DEPRECATED INTERFACE !!! Please move to use Variable Policy!
!!! DEPRECATED INTERFACE !!! Variable: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
LangCodes
...

I cleared variable storage, looked into code, compared VariablePolicy
library resolution to other platforms (it looks the same and was updated
along with all others in
https://github.com/tianocore/edk2-platforms/commit/8034e3b2ae9470adb), but
still don't see, how to get rid of those.

Is it expected behavior? Any suggestions how to properly remove those
messages?

Best regards,
Marcin


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

Re: [edk2-devel] [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

2021-03-25 Thread Gao, Zhichao

First, thanks Liming's catch.

Abner,

The patch has been updated, you should remove my R-B for the V4 version. 
Otherwise the reviewers/maintainers may treated it as reviewed one.
And please add the one who already gave the comment for your patch to the Cc 
list. They care about the about the change and this would help them to know the 
update and have a chance to view your patch in an early time.

For this patch, the copyright should be updated to 2021. With this updated, 
Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: Abner Chang 
> Sent: Thursday, March 25, 2021 12:53 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Gao, Zhichao ;
> Nickle Wang ; Peter O'Hanley
> 
> Subject: [PATCH v4 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish
> protocols
> 
> Add handle parsing for EFI Redfish Discover protocol.
> Add handle parsing for EFI RestEx protocol.
> 
> Signed-off-by: Abner Chang 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Nickle Wang 
> Cc: Peter O'Hanley 
> Reviewed-by: Zhichao Gao 
> ---
>  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++-
>  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.c   | 8 +++-
>  .../Library/UefiHandleParsingLib/UefiHandleParsingLib.uni | 4 +++-
>  3 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> index 93b69cd8e9..446cd8d609 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> @@ -2,7 +2,7 @@
>  #  Provides interface to advanced shell functionality for parsing both handle
> and protocol database.
>  #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.   
> #  (C)
> Copyright 2013-2015 Hewlett-Packard Development Company, L.P. -#
> (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> +#  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> +LP
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -269,6 +269,8 @@
>gEfiHttpProtocolGuid## UNDEFINED
>gEfiHttpUtilitiesProtocolGuid   ## UNDEFINED
>gEfiRestProtocolGuid## UNDEFINED
> +  gEfiRestExProtocolGuid  ## UNDEFINED
> +  gEfiRedfishDiscoverProtocolGuid ## UNDEFINED
>gEfiMmEndOfDxeProtocolGuid  ## UNDEFINED
>gEfiMmIoTrapDispatchProtocolGuid## UNDEFINED
>gEfiMmPowerButtonDispatchProtocolGuid   ## UNDEFINED
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> index 500a95a89a..e34cefd7b4 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> @@ -3,7 +3,7 @@
> 
>Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
>(C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
> -  (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
> +  (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -2250,6 +2250,12 @@ STATIC CONST GUID_INFO_BLOCK
> mGuidStringList[] = {
>{STRING_TOKEN(STR_PARTITION_INFO),
> ,
> PartitionInfoProtocolDumpInformation},
>{STRING_TOKEN(STR_HII_POPUP), ,
> NULL},
> 
> +//
> +// UEFI 2.8
> +//
> +  {STRING_TOKEN(STR_REST_EX),   ,
> NULL},
> +  {STRING_TOKEN(STR_REDFISH_DISCOVER),
> , NULL},
> +
>  //
>  // PI Spec ones
>  //
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> index 9c8028d0d5..69fcbdfe0e 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> @@ -2,7 +2,7 @@
>  //
>  // Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.   
> // (C)
> Copyright 2013-2015 Hewlett-Packard Development Company, L.P. -//
> (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
> +// (C) Copyright 2015-2020 Hewlett Packard Enterprise Development
> +LP
>  // SPDX-License-Identifier: BSD-2-Clause-Patent  //  // Module Name:
> @@ -308,6 +308,8 @@
>  #string STR_NET_HTTP  #language en-US "Http"
>  #string STR_NET_HTTP_U#language en-US "HttpUtilities"
>  #string STR_REST  #language en-US "Rest"
> +#string STR_REST_EX   #language en-US "RestEx"
> +#string STR_REDFISH_DISCOVER  #language en-US "RedfishDiscover"
> 
>  #string STR_MM_EOD#language en-US "MmEndOfDxe"
>  #string STR_MM_ITD#language

[edk2-devel] [PATCH] [edk2-staging] BaseTools/Fmmt: Fix rebuild FFS lost dependency section.

2021-03-25 Thread GregX Yeh

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

Dependency section data lost when rebuild FFS.
Add pei dxe smm dependency section to FFS and Encap_INFO_DATA structure.
Restore dependency section when build FFS.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: GregX Yeh 
---
 BaseTools/Source/C/FMMT/FirmwareModuleManagement.h |  28 +-
 BaseTools/Source/C/FMMT/FmmtLib.c  | 443 +++--
 2 files changed, 334 insertions(+), 137 deletions(-)

diff --git a/BaseTools/Source/C/FMMT/FirmwareModuleManagement.h 
b/BaseTools/Source/C/FMMT/FirmwareModuleManagement.h
index 9d09c9160a..84ccfaed1d 100644
--- a/BaseTools/Source/C/FMMT/FirmwareModuleManagement.h
+++ b/BaseTools/Source/C/FMMT/FirmwareModuleManagement.h
@@ -2,7 +2,7 @@
 
  Structures and functions declaration.
 
- Copyright (c) 2019, Intel Corporation. All rights reserved.
+ Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
  SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -195,7 +195,7 @@ typedef struct {
   // UI Name for this FFS file, if has.
   //
   CHAR16   UiName[_MAX_PATH];
-   UINT32   UiNameSize;
+  UINT32   UiNameSize;
   //
   // Total section number in this FFS.
   //
@@ -223,8 +223,12 @@ typedef struct {
   UINT32  Offset;
   UINT8   FvLevel;
   EFI_GUIDGuidName;
-  UINT8   *Depex;
-  UINT32  DepexLen;
+  UINT8   *PeiDepex;
+  UINT32  PeiDepexLen;
+  UINT8   *DxeDepex;
+  UINT32  DxeDepexLen;
+  UINT8   *SmmDepex;
+  UINT32  SmmDepexLen;
   BOOLEAN IsHandle;
   BOOLEAN IsFvStart;
   BOOLEAN IsFvEnd;
@@ -259,8 +263,12 @@ typedef struct __ENCAP_INFO_DATA{
 
   CHAR16   UiName[_MAX_PATH];
   UINT32   UiNameSize;
-  UINT8*Depex;
-  UINT32   DepexLen;
+  UINT8*PeiDepex;
+  UINT32   PeiDepexLen;
+  UINT8*DxeDepex;
+  UINT32   DxeDepexLen;
+  UINT8*SmmDepex;
+  UINT32   SmmDepexLen;
 
   //
   // Next node.
@@ -281,8 +289,12 @@ typedef struct _FFS_INFOMATION{
   BOOLEANIsFFS;
   CHAR16 UiName[_MAX_PATH];
   UINT32 UiNameSize;
-  UINT8  *Depex;
-  UINT32 DepexLen;
+  UINT8  *PeiDepex;
+  UINT32 PeiDepexLen;
+  UINT8  *DxeDepex;
+  UINT32 DxeDepexLen;
+  UINT8  *SmmDepex;
+  UINT32 SmmDepexLen;
   BOOLEANFfsFoundFlag;
   struct _FFS_INFOMATION *Next;
 } FFS_INFORMATION;
diff --git a/BaseTools/Source/C/FMMT/FmmtLib.c 
b/BaseTools/Source/C/FMMT/FmmtLib.c
index 9a9ba8b56f..fa77ed7317 100644
--- a/BaseTools/Source/C/FMMT/FmmtLib.c
+++ b/BaseTools/Source/C/FMMT/FmmtLib.c
@@ -164,8 +164,12 @@ LibInitializeFvStruct (
 Fv->FfsAttuibutes[Index].IsLeaf   = TRUE;
 Fv->FfsAttuibutes[Index].Level= 0xFF;
 Fv->FfsAttuibutes[Index].TotalSectionNum  = 0;
-Fv->FfsAttuibutes[Index].Depex= NULL;
-Fv->FfsAttuibutes[Index].DepexLen = 0;
+Fv->FfsAttuibutes[Index].PeiDepex= NULL;
+Fv->FfsAttuibutes[Index].PeiDepexLen = 0;
+Fv->FfsAttuibutes[Index].DxeDepex= NULL;
+Fv->FfsAttuibutes[Index].DxeDepexLen = 0;
+Fv->FfsAttuibutes[Index].SmmDepex= NULL;
+Fv->FfsAttuibutes[Index].SmmDepexLen = 0;
 Fv->FfsAttuibutes[Index].IsHandle = FALSE;
 Fv->FfsAttuibutes[Index].IsFvStart= FALSE;
 Fv->FfsAttuibutes[Index].IsFvEnd  = FALSE;
@@ -835,6 +839,7 @@ LibParseSection (
   CHAR8   *ToolOutputFileName;
   BOOLEAN  HasUiSection;
   BOOLEAN  FirstInFlag;
+  UINT32   KeepFfsCount;
 
   DataOffset = 0;
   GuidAttr   = 0;
@@ -871,6 +876,7 @@ LibParseSection (
   LargeHeaderOffset  = 0;
   HasUiSection   = FALSE;
   FirstInFlag= TRUE;
+  KeepFfsCount   = *FfsCount;
 
 
   while (ParsedLength < BufferLength) {
@@ -945,9 +951,13 @@ LibParseSection (
 LocalEncapData->Data= NULL;
 LocalEncapData->FvExtHeader = NULL;
 LocalEncapData->NextNode= NULL;
-LocalEncapData->RightNode = NULL;
-LocalEncapData->Depex = NULL;
-LocalEncapData->DepexLen = 0;
+LocalEncapData->RightNode = NULL;
+LocalEncapData->PeiDepex = NULL;
+LocalEncapData->PeiDepexLen = 0;
+LocalEncapData->DxeDepex = NULL;
+LocalEncapData->DxeDepexLen = 0;
+LocalEncapData->SmmDepex = NULL;
+LocalEncapData->SmmDepexLen = 0;

Re: [edk2-devel] [PATCH v1 1/1] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.

2021-03-25 Thread Jason Lou

Hi Star, sorry for my late response.

Yes, HOB search time is related to the sequence of HOB generation.

Some data collected on the test platform:
1. The time range required to search for the specified HOB: 20ns ~ 2700ns
Search for the 1st HOB(PHIT HOB): 20ns
Search for the last HOB: about 2700ns
2. The time required to search for CpuCrystalFrequencyHob HOB: about 2000ns.

The actual delay of NanoSecondDelay function is longer than the expected delay.

If any questions, please feel free let me know, thanks

Jason Lou


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

Re: [edk2-devel] SR-IOV setup in edk2

2021-03-25 Thread Jon Nettleton

On Mon, Mar 22, 2021 at 8:04 PM Laszlo Ersek  wrote:
>
> On 03/21/21 13:46, Jon Nettleton wrote:
> > I am looking for some example code, or direction in how SR-IOV
> > functions are expected to be picked up by the platform pcie host
> > library so it can setup required bits like LUTs.  Currently the
> > HostLib is getting the gEfiPciIoProtocolGuid event and then setting
> > the controller up based on the BDF.  I see that PciScanBus is
> > detecting the VF's and calling PciAllocateBusNumber().
> >
> > PCI-IOV ScanBus - SubBusNumber - 0x2
> > PciBus: Discovered PPB @ [00|00|00]
> >
> > However my setup function is only ever triggered with the real device
> > BDF's...
>
> What do you mean by "setup function"?

Well currently we followed the methodology of most the other
PCI Host Bus drivers and as I said above get the Io event and then
finish the completion of the device setup.  This includes setting up
the Luts, adding the device to the SMMU tables, and a few other
operations.

The VFs for SR-IOV are different as they are treated as hot
pluggable devices in both edk2 and linux, however there is still
setup that needs to be done to the host controller to support the
VFs on the bus.  The PciScanBus is obviously partially wired to
do some enumeration for PCI-IOV but I am unclear where the
platform code should hook into this for the additional proving
and setup.

I have now implemented a driver connected to gEfiPciPlatformProtocolGuid
and I can get events passed in for the platform setup hooks, is this where
we should be doing the bus specific setup, rather than catching
gEfiPciIoProtocolGuid?

>
> If you have a UEFI driver that follows the UEFI driver model, i.e. it
> installs at least one instance of the Driver Binding protocol, then it's
> up to platform BDS to call ConnectController() on those devices that
> should be connected per platform policy.
>
> > Is it up to me to check for the VFs if SR-IOV is enabled and
> > set them up manually?  Is there another event I should be listening to
> > that will be triggered for VF's vs PF's?
>
> My guess is that platform BDS does not try to connect the PciIo
> instances that stand for VFs to any drivers.
>
> In the UEFI shell, try running
>
>   dh -d -v -p PciIo
>
> Pick a handle ID that appears to stand for a VF, then run

No handles are created for the VFs as they aren't setup yet.

Thanks,
Jon

>
>   connect 
>
> Thanks
> Laszlo
>
> >
> > Any pointers would be very helpful.
> >
> > -Jon
> >
> >
> > 
> >
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73262): https://edk2.groups.io/g/devel/message/73262
Mute This Topic: https://groups.io/mt/81498733/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 00/29] Add a new library class RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access

2021-03-25 Thread Dandan Bi

Thank you Liming.
If no more comments, I plan to submit following 2 patches firstly tomorrow.

[patch V2 01/29] MdePkg: Add RegisterFilterLib class and NULL instance 
(https://edk2.groups.io/g/devel/message/73072)
[patch V2 02/29] MdePkg: Add MdeLibs.dsc.inc file to MdePkg 
(https://edk2.groups.io/g/devel/message/73073)

Then we can submit following dsc patches and IoLib and BaseLib update patches.
Please let me know if you have any concern.

Thanks,
Dandan
> -Original Message-
> From: gaoliming 
> Sent: Tuesday, March 23, 2021 4:40 PM
> To: Bi, Dandan ; devel@edk2.groups.io
> Cc: 'Andrew Fish' ; 'Leif Lindholm' ;
> 'Laszlo Ersek' ; Kinney, Michael D
> ; Liu, Zhiguang 
> Subject: 回复: [edk2-devel] [patch V2 00/29] Add a new library class
> RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access
> 
> Dandan:
>   This change is good to me. Reviewed-by: Liming Gao 
> for the patch set.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: Bi, Dandan 
> > 发送时间: 2021年3月23日 10:06
> > 收件人: devel@edk2.groups.io; Bi, Dandan 
> > 抄送: Andrew Fish ; Leif Lindholm ;
> > Laszlo Ersek ; Kinney, Michael D
> > ; Liming Gao ;
> > Liu, Zhiguang 
> > 主题: RE: [edk2-devel] [patch V2 00/29] Add a new library class
> > RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access
> >
> > Hi All,
> >
> > Here is the branch for these changes in Edk2.
> > https://github.com/dandanbi/edk2/tree/RegisterFilterLibV2
> > https://github.com/tianocore/edk2/pull/1509
> >
> > Hi Mike, Liming and Zhiguang,
> >
> > Could you help review the first and last 2 patches in MdePkg?
> > Since we should submit the first 2 patches firstly before the changes
> > of
> dsc
> > files .
> >
> >
> > Thanks,
> > Dandan
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of
> > > Dandan Bi
> > > Sent: Monday, March 22, 2021 4:09 PM
> > > To: devel@edk2.groups.io
> > > Cc: Andrew Fish ; Leif Lindholm
> > > ; Laszlo Ersek ; Kinney,
> > > Michael D ; Liming Gao
> > > ; Liu, Zhiguang 
> > > Subject: [edk2-devel] [patch V2 00/29] Add a new library class
> > > RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
> > > RFC: https://edk2.groups.io/g/devel/message/72530
> > >
> > > Patch 1 is to add RegisterFilterLib Library Class in edk2 to
> filter/trace port
> > > IO/MMIO/MSR access and add a RegisterFilterLibNull instance.
> > > Patch 2 is to add the MdeLibs.dsc.inc file to MdePkg for some
> > > default
> > libraries
> > > provided by MdePkg and add RegisterFilterLib into it as the first
> version of
> > > MdeLibs.dsc.inc.
> > > Last 2 patches are to update APIs in IoLib and BaseLib to
> > > filter/trace
> port
> > > IO/MMIO/MSR access.
> > > Remaining patches are to update related dsc files to consume
> > > MdeLibs.dsc.inc for RegisterFilterLib.
> > >
> > > Will submit patch 1 and 2 firstly.
> > > And then update related dsc files in edk2 and edk2platform repo to
> consume
> > > MdeLibs.dsc.inc for RegisterFilterLib.
> > > At last will submit the patches to update IoLib and BaseLib to
> filter/trace
> > port
> > > IO/MMIO/MSR access.
> > >
> > > --
> > > V2:
> > > Introduce MdeLibs.dsc.inc and add RegisterFilterLib into it as the
> > > first
> > version
> > > of MdeLibs.dsc.inc.
> > > Update Platform dsc to consume the MdeLibs.dsc.inc.
> > > Add the description for the return flag in FilterBefore
> > > functions in header file source code.
> > > Extend the years for Intel copyright.
> > > Add mssing change the dsc files in OvmfPkg.
> > >
> > > Cc: Andrew Fish 
> > > Cc: Leif Lindholm 
> > > Cc: Laszlo Ersek 
> > > Cc: Michael D Kinney 
> > > Cc: Liming Gao 
> > > Cc: Zhiguang Liu 
> > >
> > > Dandan Bi (29):
> > >   MdePkg: Add RegisterFilterLib class and NULL instance
> > >   MdePkg: Add MdeLibs.dsc.inc file to MdePkg
> > >   ArmPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   ArmPlatformPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   ArmVirtPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   CryptoPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   DynamicTablesPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   EmbeddedPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   EmulatorPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   FatPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   FmpDevicePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   IntelFsp2Pkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   IntelFsp2WrapperPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   MdeModulePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   MdePkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   NetworkPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   PcAtChipsetPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> > >   RedfishPkg: Consume MdeLibs.dsc.inc for RegisterFilterLib
> >

49 matches

Mail list logo