Re: [edk2-devel] [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector

2020-06-22 Thread Dong, Eric
Reviewed-by: Eric Dong eric.d...@intel.com

Pushed:
SHA-1: 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa

* UefiCpuPkg/SecCore: Add pre-memory AP vector

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


Thanks,
Eric
From: Ni, Ray 
Sent: Tuesday, June 23, 2020 8:57 AM
To: Cole, Deric ; devel@edk2.groups.io
Cc: Dong, Eric ; Laszlo Ersek 
Subject: RE: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector

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


> -Original Message-
> From: Cole, Deric mailto:deric.c...@intel.com>>
> Sent: Wednesday, June 3, 2020 12:42 AM
> To: Ni, Ray mailto:ray...@intel.com>>; 
> devel@edk2.groups.io
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Laszlo 
> Ersek mailto:ler...@redhat.com>>
> Subject: RE: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector
>
> Ray,
>
> The NOP is not a functional change, it's just for ease of debug.
>
> Before, this file was padding with zeros in various places. When viewing this 
> memory using a disassembler, two
> subsequent zero-bytes show up as an ADD instruction, which I found confusing. 
> But worse, if the number of zero-bytes was
> odd, the disassembler might try to "consume" part of the next (real) 
> instruction as an operand to the last hypothetical
> ADD.
>
> Since NOP is a 1-byte instruction, I used that instead, so it is easier to 
> visually identify the real code versus the padding
> when viewing disassembly.
>
> -Deric
>
> -Original Message-
> From: Ni, Ray mailto:ray...@intel.com>>
> Sent: Monday, June 1, 2020 9:51 PM
> To: Cole, Deric mailto:deric.c...@intel.com>>; 
> devel@edk2.groups.io
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Laszlo 
> Ersek mailto:ler...@redhat.com>>
> Subject: RE: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector
>
> Deric,
> Can you explain why changing all padding 0x0 to 0x90 (nop) in your patch?
>
> Is it required to enable AP start up in pre-mem?
>
> Thanks,
> Ray
>
> > -Original Message-
> > From: Cole, Deric mailto:deric.c...@intel.com>>
> > Sent: Tuesday, June 2, 2020 6:32 AM
> > To: devel@edk2.groups.io
> > Cc: Cole, Deric mailto:deric.c...@intel.com>>; Dong, 
> > Eric
> > mailto:eric.d...@intel.com>>; Ni, Ray 
> > mailto:ray...@intel.com>>; Laszlo Ersek
> > mailto:ler...@redhat.com>>
> > Subject: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2776
> >
> > Add a vector at 0xFF000 (0xF000) that can be used by
> > Init-SIPI-SIPI to start an AP before memory is initialized. This
> > vector jumps into the same SEC entry point as the ordinary reset
> > vector, with a special value of "AP" in the DI register. The
> > platform-specific SEC code is expected to check for that value and
> > take a different path for APs, if this feature is supported by the platform.
> >
> > Cc: Eric Dong mailto:eric.d...@intel.com>>
> > Cc: Ray Ni mailto:ray...@intel.com>>
> > Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> > Signed-off-by: Deric Cole 
> > mailto:deric.c...@intel.com>>
> > ---
> >  UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb | 31
> > ---
> >  1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > b/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > index f41b9669d0..1dfc4efe4c 100644
> > --- a/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > +++ b/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > @@ -10,7 +10,7 @@
> >  ; Abstract:
> >
> >  ;
> >
> >  ;  Reset Vector Data structure
> >
> > -;  This structure is located at 0xFFC0
> >
> > +;  This structure is located at 0xF000
> >
> >  ;
> >
> >
> > ;-
> > -
> >
> >
> >
> > @@ -23,19 +23,36 @@ USE16
> >  ;
> >
> >
> >
> >  ORG 0h
> >
> > +
> >
> > +;
> >
> > +; 0xF000
> >
> > +;
> >
> > +; We enter here with CS:IP = 0xFF00:0x. Do a far-jump to change
> > +CS to
> > 0xF000
> >
> > +; and IP to ApStartup.
> >
> > +;
> >
> > +ApVector:
> >
> > +mov di, "AP"
> >
> > +jmp 0xF000:0xF000+ApStartup
> >
> > +
> >
> > +TIMES 0xFC0-($-$$) nop
> >
> > +
> >
> > +;
> >
> > +; This should be at 0xFFC0
> >
> > +;
> >
> > +
> >
> >  ;
> >
> >  ; Reserved
> >
> >  ;
> >
> >  ReservedData:DD 0h, 0h
> >
> >
> >
> > -TIMES 0x10-($-$$) DB 0
> >
> > +TIMES 0xFD0-($-$$) nop
> >
> >  ;
> >
> > -; This is located at 0xFFD0h
> >
> > +; This is located at 0xFFD0
> >
> >  ;
> >
> >  mov di, "PA"
> >
> >  jmp ApStartup
> >
> >
> >
> > -TIMES 0x20-($-$$) DB 0
> >
> > +TIMES 0xFE0-($-$$) nop
> >
> >  ;
> >
> >  ; Pointer to the entry point of the PEI core
> >
> >  ; It is located at 0xFFE0, and is fixed up by some build tool
> >
> > @@ -53,7 +70,7 @@ ASM_PFX(InterruptHandler):
> >  jmp $
> >
> >  iret
> >
> >
> >
> > 

Re: [edk2-devel] [PATCH v4 1/1] ProcessorPkg/Library: Add RiscVEdk2SbiLib

2020-06-22 Thread Abner Chang
Thanks for spent time on reviewing this. Yes, we can have further discussions 
on where to merge RISC-V code. For now, we will merge those code to 
edk2-platforms master branch as the temporary home for RISC-V.

Another matter regards to the inconsistent naming of "RISC-V", "RiscV" and etc. 
brought up by Mike, any one else has the same concerns as  Mike of using 
"RISC-V" as folder name, however "RiscV" as the leading in file name?
I still don't think it does matter though, but I would like to see more 
opinions on this.

Thanks
Abner

> -Original Message-
> From: Leif Lindholm [mailto:l...@nuviainc.com]
> Sent: Friday, June 19, 2020 12:50 AM
> To: devel@edk2.groups.io; Schaefer, Daniel (DualStudy)
> 
> Cc: Chen, Gilbert ; Chang, Abner (HPS SW/FW
> Technologist) ; Michael D . Kinney
> 
> Subject: Re: [edk2-devel] [PATCH v4 1/1] ProcessorPkg/Library: Add
> RiscVEdk2SbiLib
> 
> On Tue, Jun 02, 2020 at 18:51:52 +0200, Daniel Schaefer wrote:
> > Library provides interfaces to invoke SBI ecalls.
> >
> > Signed-off-by: Daniel Schaefer 
> 
> All of my feedback on previous revision addressed - where to actually
> *merge* it remains undecided, but for the contents:
> Reviewed-by: Leif Lindholm 
> 
> Thanks!
> 
> > Cc: Leif Lindholm 
> > Cc: Gilbert Chen 
> > Cc: Abner Chang 
> > Cc: Michael D. Kinney 
> > ---
> >  Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf |
> 28 +
> >  Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h   | 
> > 563
> 
> >  Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c   |
> 897 
> >  3 files changed, 1488 insertions(+)
> >
> > diff --git a/Silicon/RISC-
> V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf b/Silicon/RISC-
> V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf
> > new file mode 100644
> > index ..665dcbf40e01
> > --- /dev/null
> > +++ b/Silicon/RISC-
> V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf
> > @@ -0,0 +1,28 @@
> > +## @file
> > +# RISC-V Library to call SBI ecalls
> > +#
> > +#  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> > +#
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +[Defines]
> > +  INF_VERSION= 0x0001001b
> > +  BASE_NAME  = RiscVEdk2SbiLib
> > +  FILE_GUID  = 0DF1BBBD-F7E5-4E8A-BCF1-9D63D2DD9FDD
> > +  MODULE_TYPE= BASE
> > +  VERSION_STRING = 1.0
> > +  LIBRARY_CLASS  = RiscVEdk2SbiLib
> > +
> > +[Sources]
> > +  RiscVEdk2SbiLib.c
> > +
> > +[Packages]
> > +  MdePkg/MdePkg.dec
> > +  Silicon/RISC-V/ProcessorPkg/RiscVProcessorPkg.dec
> > +  Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec
> > +
> > +[LibraryClasses]
> > +  BaseLib
> > +  RiscVOpensbiLib
> > diff --git a/Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h
> b/Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h
> > new file mode 100644
> > index ..c1ae3176147f
> > --- /dev/null
> > +++ b/Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h
> > @@ -0,0 +1,563 @@
> > +/** @file
> > +  Library to call the RISC-V SBI ecalls
> > +
> > +  Copyright (c) 2020, Hewlett Packard Development LP. All rights
> reserved.
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +  @par Glossary:
> > +- Hart - Hardware Thread, similar to a CPU core
> > +**/
> > +
> > +#ifndef RISCV_SBI_LIB_H_
> > +#define RISCV_SBI_LIB_H_
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +//
> > +// EDK2 OpenSBI Firmware extension.
> > +//
> > +#define SBI_EDK2_FW_EXT (SBI_EXT_FIRMWARE_CODE_BASE_START |
> SBI_OPENSBI_IMPID)
> > +//
> > +// EDK2 OpenSBI Firmware extension functions.
> > +//
> > +#define SBI_EXT_FW_MSCRATCH_FUNC0
> > +#define SBI_EXT_FW_MSCRATCH_HARTID_FUNC 1
> > +
> > +//
> > +// EDK2 OpenSBI firmware extension return status.
> > +//
> > +typedef struct {
> > +  UINTN Error;   ///< SBI status code
> > +  UINTN Value;   ///< Value returned
> > +} SbiRet;
> > +
> > +/**
> > +  Get the implemented SBI specification version
> > +
> > +  The minor number of the SBI specification is encoded in the low 24 bits,
> > +  with the major number encoded in the next 7 bits.  Bit 32 must be 0 and
> is
> > +  reserved for future expansion.
> > +
> > +  @param[out] SpecVersion  The Version of the SBI specification.
> > +**/
> > +VOID
> > +EFIAPI
> > +SbiGetSpecVersion (
> > +  OUT UINTN   *SpecVersion
> > +  );
> > +
> > +/**
> > +  Get the SBI implementation ID
> > +
> > +  This ID is used to idenetify a specific SBI implementation in order to 
> > work
> > +  around any quirks it might have.
> > +
> > +  @param[out] ImplId   The ID of the SBI implementation.
> > +**/
> > +VOID
> > +EFIAPI
> > +SbiGetImplId (
> > +  OUT UINTN  *ImplId
> > +  );
> > +
> > +/**
> > +  Get the SBI implementation version
> > +
> > +  The version of this SBI 

Re: [edk2-devel] [PATCH v3 0/7] Standalone AcpiView Application

2020-06-22 Thread Gao, Zhichao
Already give the R-B to the remain patches.

Thanks,
Zhichao

> -Original Message-
> From: Tomas Pilar 
> Sent: Monday, June 22, 2020 8:24 PM
> To: devel@edk2.groups.io
> Cc: nd ; Ni, Ray ; Gao, Zhichao
> 
> Subject: RE: [edk2-devel] [PATCH v3 0/7] Standalone AcpiView Application
> 
> Hi Ray, Zhichao,
> 
> Do you have any opinions on the respun patches?
> 
> Cheers,
> Tom
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tomas Pilar
> (tpilar) via groups.io
> Sent: 15 June 2020 15:04
> To: devel@edk2.groups.io
> Cc: nd ; Ray Ni ; Zhichao Gao
> 
> Subject: [edk2-devel] [PATCH v3 0/7] Standalone AcpiView Application
> 
> This patchset adds a new application module to the ShellPkg with the
> functionality of the 'acpiview' command.
> 
> The existing code is tidied and a clean boundary between the UEFI shell 
> command
> wrapper and the acpiview functionality is created. Then, a new application
> wrapper is added.
> 
> The motivation for a standalone AcpiView application lies in the desire to 
> test
> implementation of the Acpi tables on a wide selection of platforms, 
> particularly
> platforms still in development, platforms that might have an older
> implementation of the UEFI shell or platforms that might not include the
> 'acpiview'
> command in the internal build of the UEFI shell. Furthermore, this 
> application can
> then be integrated in larger firmware testing frameworks.
> 
> ---
> v3: Fix pointer dereference in GetSelectedTable. Create library
> interface for the UefiShellAcpiViewCommandLib and convert to
> named library. Tidy help text shell hook in standalone app.
> v2: Patch formatting
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> 
> Tomas Pilar (7):
>   ShellPkg/AcpiView: Move log reset to main method
>   ShellPkg/AcpiView: Refactor configuration
>   ShellPkg/AcpiView: Move table count reset
>   ShellPkg/AcpiView: Move parameter parsing
>   ShellPkg/AcpiView: Refactor DumpAcpiTableToFile
>   ShellPkg: Add AcpiViewCommandLib
>   ShellPkg/AcpiView: Add application wrapper
> 
>  .../Application/AcpiViewApp/AcpiViewApp.c |  40 ++
>  .../Application/AcpiViewApp/AcpiViewApp.inf   |  34 ++
>  .../Application/AcpiViewApp/AcpiViewApp.uni   | 122 +
>  ShellPkg/Include/Library/AcpiViewCommandLib.h |  46 ++
>  .../UefiShellAcpiViewCommandLib/AcpiParser.c  |   1 +
>  .../AcpiTableParser.c |   1 +
>  .../UefiShellAcpiViewCommandLib/AcpiView.c| 474 ++
>  .../UefiShellAcpiViewCommandLib/AcpiView.h| 113 +
>  .../AcpiViewConfig.c  | 246 +
>  .../AcpiViewConfig.h  | 177 +++
>  .../Parsers/Gtdt/GtdtParser.c |   1 +
>  .../Parsers/Iort/IortParser.c |   1 +
>  .../Parsers/Madt/MadtParser.c |   1 +
>  .../Parsers/Pptt/PpttParser.c |   1 +
>  .../Parsers/Srat/SratParser.c |   1 +
>  .../UefiShellAcpiViewCommandLib.c | 279 ++-
>  .../UefiShellAcpiViewCommandLib.h |  26 -
>  .../UefiShellAcpiViewCommandLib.inf   |  33 +-
>  ShellPkg/ShellPkg.dec |   3 +
>  ShellPkg/ShellPkg.dsc |   4 +-
>  20 files changed, 1019 insertions(+), 585 deletions(-)  create mode 100644
> ShellPkg/Application/AcpiViewApp/AcpiViewApp.c
>  create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.inf
>  create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni
>  create mode 100644 ShellPkg/Include/Library/AcpiViewCommandLib.h
>  create mode 100644
> ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiViewConfig.c
>  create mode 100644
> ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiViewConfig.h
>  delete mode 100644
> ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.
> h
> 
> --
> 2.24.1.windows.2
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61578): https://edk2.groups.io/g/devel/message/61578
Mute This Topic: https://groups.io/mt/74894926/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] Upcoming Event: TianoCore Bug Triage - APAC / NAMO - Tue, 06/23/2020 6:30pm-7:30pm #cal-reminder

2020-06-22 Thread devel@edk2.groups.io Calendar
*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Tuesday, 23 June 2020, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

*Where:* https://bluejeans.com/889357567?src=join_info

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=816013 )

*Organizer:* Brian Richardson brian.richard...@intel.com ( 
brian.richard...@intel.com?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

*Description:*

https://www.tianocore.org/bug-triage

Meeting URL

https://bluejeans.com/889357567?src=join_info

Meeting ID

889 357 567

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61577): https://edk2.groups.io/g/devel/message/61577
Mute This Topic: https://groups.io/mt/75052555/21656
Mute #cal-reminder: https://groups.io/g/edk2/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v3 7/7] ShellPkg/AcpiView: Add application wrapper

2020-06-22 Thread Gao, Zhichao
Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: Tomas Pilar 
> Sent: Monday, June 15, 2020 10:04 PM
> To: devel@edk2.groups.io
> Cc: n...@arm.com; Ni, Ray ; Gao, Zhichao
> 
> Subject: [PATCH v3 7/7] ShellPkg/AcpiView: Add application wrapper
> 
> Simple application wrapper that invokes the shell command wrapper for
> 'acpiview'.
> 
> This allows the AcpiView functionality to be used on platforms with older
> specifications of the UEFI shell or where the 'acpiview' command is not built 
> in
> due to platform build configuration.
> 
> Furthermore, this app can be integrated into more comprehensive testing
> frameworks as a single component of a more thorough specification compliance
> validation strategy.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Tomas Pilar 
> ---
>  .../Application/AcpiViewApp/AcpiViewApp.c |  40 ++
>  .../Application/AcpiViewApp/AcpiViewApp.inf   |  34 +
>  .../Application/AcpiViewApp/AcpiViewApp.uni   | 122 ++
>  ShellPkg/ShellPkg.dsc |   1 +
>  4 files changed, 197 insertions(+)
>  create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.c
>  create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.inf
>  create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni
> 
> diff --git a/ShellPkg/Application/AcpiViewApp/AcpiViewApp.c
> b/ShellPkg/Application/AcpiViewApp/AcpiViewApp.c
> new file mode 100644
> index ..2f650c9d92d2
> --- /dev/null
> +++ b/ShellPkg/Application/AcpiViewApp/AcpiViewApp.c
> @@ -0,0 +1,40 @@
> +/** @file
> +  Main file for AcpiViewApp application
> +
> +  Copyright (c) 2020, ARM Limited. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent **/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +//
> +// String token ID of help message text.
> +// Shell supports to find help message in the resource section of an
> +application image if // .MAN file is not found. This global variable is
> +added to make build tool recognizes // that the help string is consumed
> +by user and then build tool will add the string into // the resource
> +section. Thus the application can use '-?' option to show help message in // 
> Shell.
> +//
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_STRING_ID mStringHelpTokenId =
> +STRING_TOKEN (STR_GET_HELP_ACPIVIEW);
> +
> +/**
> +  Application Entry Point wrapper around the shell command
> +
> +  @param[in] ImageHandle  Handle to the Image (NULL if internal).
> +  @param[in] SystemTable  Pointer to the System Table (NULL if internal).
> +**/
> +EFI_STATUS
> +EFIAPI
> +AcpiViewAppMain (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +{
> +  return ShellCommandRunAcpiView (gImageHandle, SystemTable); }
> diff --git a/ShellPkg/Application/AcpiViewApp/AcpiViewApp.inf
> b/ShellPkg/Application/AcpiViewApp/AcpiViewApp.inf
> new file mode 100644
> index ..2ed1d185339d
> --- /dev/null
> +++ b/ShellPkg/Application/AcpiViewApp/AcpiViewApp.inf
> @@ -0,0 +1,34 @@
> +##  @file
> +#  EFI application that displays and verifies ACPI tables # #
> +Copyright (c) 2020, ARM Limited. All rights reserved. # #
> +SPDX-License-Identifier: BSD-2-Clause-Patent # # ##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001B
> +  BASE_NAME  = AcpiViewApp
> +  FILE_GUID  = 46361B5B-AF17-41FF-95F9-E1BCE08435B9
> +  MODULE_TYPE= UEFI_APPLICATION
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= AcpiViewAppMain
> +  UEFI_HII_RESOURCE_SECTION  = TRUE
> +
> +[Sources.common]
> +  AcpiViewApp.c
> +  AcpiViewApp.uni
> +
> +[Packages]
> +  MdeModulePkg/MdeModulePkg.dec
> +  MdePkg/MdePkg.dec
> +  ShellPkg/ShellPkg.dec
> +
> +[LibraryClasses]
> +  UefiBootServicesTableLib
> +  UefiLib
> +  BaseLib
> +  UefiApplicationEntryPoint
> +  AcpiViewCommandLib
> diff --git a/ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni
> b/ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni
> new file mode 100644
> index ..c56f21084356
> --- /dev/null
> +++ b/ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni
> @@ -0,0 +1,122 @@
> +// @file
> +//
> +// Standalone EFI application that displays and verifies ACPI tables //
> +// Copyright (c) 2020, ARM Limited. All rights reserved. //
> +SPDX-License-Identifier: BSD-2-Clause-Patent //
> +
> +/=#
> +
> +#langdef   en-US "english"
> +
> +#string STR_GET_HELP_ACPIVIEW   #language en-US ""
> +".TH acpiview 0 "Display ACPI information."\r\n"
> +".SH NAME\r\n"
> +"Display ACPI Table information.\r\n"
> +".SH SYNOPSIS\r\n"
> +" \r\n"
> +"ACPIVIEWAPP.EFI [[-?] | -l] | [-s AcpiTable [-d]]] [-q] [-h]] [-r 
> Spec]]]\r\n"
> +" \r\n"
> +".SH OPTIONS\r\n"
> +" \r\n"
> +"  -l - Display list of installed ACPI Tables.\r\n"
> +"  -s - Display only the specified AcpiTable type and only support 
> single\r\n"
> +"   invocation 

Re: [edk2-devel] [PATCH v3 6/7] ShellPkg: Add AcpiViewCommandLib

2020-06-22 Thread Gao, Zhichao
Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tomas Pilar
> (tpilar)
> Sent: Monday, June 15, 2020 10:04 PM
> To: devel@edk2.groups.io
> Cc: n...@arm.com; Ni, Ray ; Gao, Zhichao
> 
> Subject: [edk2-devel] [PATCH v3 6/7] ShellPkg: Add AcpiViewCommandLib
> 
> The UefiShellAcpiViewCommandLib is converted from NULL library to a named
> library so that it may be used in modules other than shell.
> The library interface exposes the main method for to AcpiView functionality as
> well as a helper method to dump a buffer to a file.
> 
> The Shell module is still built by pulling UefiShellAcpiViewCommandLib as a 
> NULL
> library to preserve the modularity of shell builds.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Tomas Pilar 
> ---
>  .../Library/AcpiViewCommandLib.h} | 15 ---
>  .../UefiShellAcpiViewCommandLib/AcpiView.c|  2 +-
>  .../UefiShellAcpiViewCommandLib.c |  2 +-
>  .../UefiShellAcpiViewCommandLib.inf   |  3 +--
>  ShellPkg/ShellPkg.dec |  3 +++
>  ShellPkg/ShellPkg.dsc |  3 ++-
>  6 files changed, 16 insertions(+), 12 deletions(-)  rename
> ShellPkg/{Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.
> h => Include/Library/AcpiViewCommandLib.h} (72%)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.h b/ShellPkg/Include/Library/AcpiViewCommandLib.h
> similarity index 72%
> rename from
> ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.
> h
> rename to ShellPkg/Include/Library/AcpiViewCommandLib.h
> index b1b1ffe63e28..11cf96c6e0d7 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.h
> +++ b/ShellPkg/Include/Library/AcpiViewCommandLib.h
> @@ -1,12 +1,13 @@
>  /** @file
> -  Header file for 'acpiview' Shell command functions.
> +  Library providing 'acpiview' functionality to display and  validate
> + installed ACPI tables.
> 
>Copyright (c) 2016 - 2020, ARM Limited. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent  **/
> 
> -#ifndef UEFI_SHELL_ACPIVIEW_COMMAND_LIB_H_
> -#define UEFI_SHELL_ACPIVIEW_COMMAND_LIB_H_
> +#ifndef ACPI_VIEW_COMMAND_LIB_H_
> +#define ACPI_VIEW_COMMAND_LIB_H_
> 
>  /**
>Dump a buffer to a file. Print error message if a file cannot be created.
> @@ -26,14 +27,14 @@ ShellDumpBufferToFile (
>);
> 
>  /**
> -  Function for 'acpiview' command.
> +  Display and validate ACPI tables.
> 
>@param[in] ImageHandle  Handle to the Image (NULL if internal).
>@param[in] SystemTable  Pointer to the System Table (NULL if internal).
> 
> -  @retval SHELL_INVALID_PARAMETER The command line invocation could not
> be parsed
> -  @retval SHELL_NOT_FOUND The command failed
> -  @retval SHELL_SUCCESS   The command was successful
> +  @retval SHELL_INVALID_PARAMETER The command line invocation could not
> be parsed.
> +  @retval SHELL_NOT_FOUND The command failed.
> +  @retval SHELL_SUCCESS   The command was successful.
>  **/
>  SHELL_STATUS
>  EFIAPI
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> index 1b6721e6734f..5a46d896c52b 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> @@ -17,11 +17,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "AcpiParser.h"
>  #include "AcpiTableParser.h"
>  #include "AcpiView.h"
>  #include "AcpiViewConfig.h"
> -#include "UefiShellAcpiViewCommandLib.h"
> 
>  #if defined(MDE_CPU_ARM) || defined (MDE_CPU_AARCH64)  #include
> "Arm/SbbrValidator.h"
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.c
> index e6a65d5bc5f7..d2f26ff89f12 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> +++ andLib.c
> @@ -16,13 +16,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "AcpiParser.h"
>  #include "AcpiTableParser.h"
>  #include "AcpiView.h"
>  #include "AcpiViewConfig.h"
> -#include "UefiShellAcpiViewCommandLib.h"
> 
>  CONST CHAR16 gShellAcpiViewFileName[] = L"ShellCommand";
> EFI_HII_HANDLE gShellAcpiViewHiiHandle = NULL; diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.inf
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.inf
> index 92de2391b09f..91459f9ec632 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.inf
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> +++ andLib.inf
> @@ 

Re: [edk2-devel] [PATCH v3 5/7] ShellPkg/AcpiView: Refactor DumpAcpiTableToFile

2020-06-22 Thread Gao, Zhichao
Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: Tomas Pilar 
> Sent: Monday, June 15, 2020 10:04 PM
> To: devel@edk2.groups.io
> Cc: n...@arm.com; Ni, Ray ; Gao, Zhichao
> 
> Subject: [PATCH v3 5/7] ShellPkg/AcpiView: Refactor DumpAcpiTableToFile
> 
> Method is refactored into two parts. A new method is created that dumps
> arbitrary buffers into a newly created file. This method is called from core 
> code
> after the core code determined the appropriate filename to be used.
> 
> This improves the modular design.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Tomas Pilar 
> ---
>  .../UefiShellAcpiViewCommandLib/AcpiView.c| 38 +---
>  .../UefiShellAcpiViewCommandLib.c | 59 +++
>  .../UefiShellAcpiViewCommandLib.h | 17 +-
>  3 files changed, 76 insertions(+), 38 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> index 2507ec78204b..1b6721e6734f 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> @@ -27,8 +27,6 @@
>  #include "Arm/SbbrValidator.h"
>  #endif
> 
> -EFI_HII_HANDLE gShellAcpiViewHiiHandle = NULL;
> -
>  STATIC UINT32 mTableCount;
>  STATIC UINT32 mBinTableCount;
> 
> @@ -48,14 +46,10 @@ DumpAcpiTableToFile (
>IN CONST UINTN   Length
>)
>  {
> -  EFI_STATUS  Status;
>CHAR16  FileNameBuffer[MAX_FILE_NAME_LEN];
> -  SHELL_FILE_HANDLE   DumpFileHandle;
>UINTN   TransferBytes;
>SELECTED_ACPI_TABLE *SelectedTable;
> 
> -  DumpFileHandle = NULL;
> -  TransferBytes = Length;
>GetSelectedAcpiTable ();
> 
>UnicodeSPrint (
> @@ -66,39 +60,9 @@ DumpAcpiTableToFile (
>  mBinTableCount++
>  );
> 
> -  Status = ShellOpenFileByName (
> - FileNameBuffer,
> - ,
> - EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE |
> EFI_FILE_MODE_CREATE,
> - 0
> - );
> -  if (EFI_ERROR (Status)) {
> -ShellPrintHiiEx (
> -  -1,
> -  -1,
> -  NULL,
> -  STRING_TOKEN (STR_GEN_READONLY_MEDIA),
> -  gShellAcpiViewHiiHandle,
> -  L"acpiview"
> -  );
> -return FALSE;
> -  }
> -
>Print (L"Dumping ACPI table to : %s ... ", FileNameBuffer);
> 
> -  Status = ShellWriteFile (
> - DumpFileHandle,
> - ,
> - (VOID*)Ptr
> - );
> -  if (EFI_ERROR (Status)) {
> -Print (L"ERROR: Failed to dump table to binary file.\n");
> -TransferBytes = 0;
> -  } else {
> -Print (L"DONE.\n");
> -  }
> -
> -  ShellCloseFile ();
> +  TransferBytes = ShellDumpBufferToFile (FileNameBuffer, Ptr, Length);
>return (Length == TransferBytes);
>  }
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.c
> index c3942ad24e5b..e6a65d5bc5f7 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLi
> b.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> +++ andLib.c
> @@ -25,6 +25,7 @@
>  #include "UefiShellAcpiViewCommandLib.h"
> 
>  CONST CHAR16 gShellAcpiViewFileName[] = L"ShellCommand";
> +EFI_HII_HANDLE gShellAcpiViewHiiHandle = NULL;
> 
>  /**
>An array of acpiview command line parameters.
> @@ -98,6 +99,64 @@ RegisterAllParsers (
>return Status;
>  }
> 
> +/**
> +  Dump a buffer to a file. Print error message if a file cannot be created.
> +
> +  @param[in] FileName   The filename that shall be created to contain the 
> buffer.
> +  @param[in] Buffer Pointer to buffer that shall be dumped.
> +  @param[in] BufferSize The size of buffer to be dumped in bytes.
> +
> +  @return The number of bytes that were written **/ UINTN EFIAPI
> +ShellDumpBufferToFile (
> +  IN CONST CHAR16* FileNameBuffer,
> +  IN CONST VOID*   Buffer,
> +  IN CONST UINTN   BufferSize
> +  )
> +{
> +  EFI_STATUS  Status;
> +  SHELL_FILE_HANDLE   DumpFileHandle;
> +  UINTN   TransferBytes;
> +
> +  Status = ShellOpenFileByName (
> + FileNameBuffer,
> + ,
> + EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE |
> EFI_FILE_MODE_CREATE,
> + 0
> + );
> +
> +  if (EFI_ERROR (Status)) {
> +ShellPrintHiiEx (
> +  -1,
> +  -1,
> +  NULL,
> +  STRING_TOKEN (STR_GEN_READONLY_MEDIA),
> +  gShellAcpiViewHiiHandle,
> +  L"acpiview"
> +  );
> +return 0;
> +  }
> +
> +  TransferBytes = BufferSize;
> +  Status = ShellWriteFile (
> + DumpFileHandle,
> + ,
> + (VOID *) Buffer
> + );
> +
> +  if (EFI_ERROR (Status)) {
> +Print (L"ERROR: Failed to write binary file.\n");
> +TransferBytes = 0;
> +  } else {
> +Print (L"DONE.\n");
> +  }
> +
> +  

Re: [edk2-devel] [PATCH v3 2/7] ShellPkg/AcpiView: Refactor configuration

2020-06-22 Thread Gao, Zhichao
See below.

> -Original Message-
> From: Tomas Pilar 
> Sent: Monday, June 15, 2020 10:04 PM
> To: devel@edk2.groups.io
> Cc: n...@arm.com; Ni, Ray ; Gao, Zhichao
> 
> Subject: [PATCH v3 2/7] ShellPkg/AcpiView: Refactor configuration
> 
> A new file and header (AcpiViewConfig.[ch]) is created that houses the user
> configuration. This declutters the core code and improves modularity of the
> design.
> 
> The module level symbols for verbosity, table selection, and highlighting are
> refactored into the new file.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Tomas Pilar 
> ---
>  .../UefiShellAcpiViewCommandLib/AcpiParser.c  |   1 +
>  .../AcpiTableParser.c |   1 +
>  .../UefiShellAcpiViewCommandLib/AcpiView.c| 237 +++--
>  .../UefiShellAcpiViewCommandLib/AcpiView.h|  95 ---
>  .../AcpiViewConfig.c  | 246 ++
>  .../AcpiViewConfig.h  | 177 +
>  .../Parsers/Gtdt/GtdtParser.c |   1 +
>  .../Parsers/Iort/IortParser.c |   1 +
>  .../Parsers/Madt/MadtParser.c |   1 +
>  .../Parsers/Pptt/PpttParser.c |   1 +
>  .../Parsers/Srat/SratParser.c |   1 +
>  .../UefiShellAcpiViewCommandLib.inf   |  32 +--
>  12 files changed, 479 insertions(+), 315 deletions(-)  create mode 100644
> ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiViewConfig.c
>  create mode 100644
> ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiViewConfig.h
> 
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> index 3f12a33050a4..02f6d771c7e1 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include "AcpiParser.h"
>  #include "AcpiView.h"
> +#include "AcpiViewConfig.h"
> 
>  STATIC UINT32   gIndent;
>  STATIC UINT32   mTableErrorCount;
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.c
> index d5b9eee52323..4b618f131eac 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.c
> @@ -17,6 +17,7 @@
>  #include "AcpiParser.h"
>  #include "AcpiTableParser.h"
>  #include "AcpiView.h"
> +#include "AcpiViewConfig.h"
> 
>  #if defined(MDE_CPU_ARM) || defined (MDE_CPU_AARCH64)  #include
> "Arm/SbbrValidator.h"
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> index f1a95b7b8f03..390e378e9a6c 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> @@ -20,6 +20,7 @@
>  #include "AcpiParser.h"
>  #include "AcpiTableParser.h"
>  #include "AcpiView.h"
> +#include "AcpiViewConfig.h"
>  #include "UefiShellAcpiViewCommandLib.h"
> 
>  #if defined(MDE_CPU_ARM) || defined (MDE_CPU_AARCH64) @@ -28,17 +29,8
> @@
> 
>  EFI_HII_HANDLE gShellAcpiViewHiiHandle = NULL;
> 
> -// Report variables
> -STATIC UINT32 mSelectedAcpiTable;
> -STATIC CONST CHAR16*  mSelectedAcpiTableName;
> -STATIC BOOLEANmSelectedAcpiTableFound;
> -STATIC EREPORT_OPTION mReportType;
>  STATIC UINT32 mTableCount;
>  STATIC UINT32 mBinTableCount;
> -STATIC BOOLEANmConsistencyCheck;
> -STATIC BOOLEANmColourHighlighting;
> -STATIC BOOLEANmMandatoryTableValidate;
> -STATIC UINTN  mMandatoryTableSpec;
> 
>  /**
>An array of acpiview command line parameters.
> @@ -53,142 +45,6 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>{NULL, TypeMax}
>  };
> 
> -/**
> -  This function returns the colour highlighting status.
> -
> -  @retval TRUE if colour highlighting is enabled.
> -**/
> -BOOLEAN
> -GetColourHighlighting (
> -  VOID
> -  )
> -{
> -  return mColourHighlighting;
> -}
> -
> -/**
> -  This function sets the colour highlighting status.
> -
> -  @param  Highlight   The Highlight status.
> -
> -**/
> -VOID
> -SetColourHighlighting (
> -  BOOLEAN Highlight
> -  )
> -{
> -  mColourHighlighting = Highlight;
> -}
> -
> -/**
> -  This function returns the consistency checking status.
> -
> -  @retval TRUE if consistency checking is enabled.
> -**/
> -BOOLEAN
> -GetConsistencyChecking (
> -  VOID
> -  )
> -{
> -  return mConsistencyCheck;
> -}
> -
> -/**
> -  This function sets the consistency checking status.
> -
> -  @param  ConsistencyChecking   The consistency checking status.
> -
> -**/
> -VOID
> -SetConsistencyChecking (
> -  BOOLEAN ConsistencyChecking
> -  )
> -{
> -  mConsistencyCheck = ConsistencyChecking; -}
> -
> -/**
> -  This function returns the ACPI table requirements validation flag.
> -
> -  @retval TRUE if 

Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement library support for VMGEXIT

2020-06-22 Thread Dong, Eric


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: Friday, June 19, 2020 11:39 PM
> To: Tom Lendacky ; devel@edk2.groups.io;
> Dong, Eric 
> Cc: Brijesh Singh ; Ard Biesheuvel
> ; Justen, Jordan L ;
> Gao, Liming ; Kinney, Michael D
> ; Ni, Ray 
> Subject: Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement library
> support for VMGEXIT
> 
> On 06/19/20 15:50, Tom Lendacky wrote:
> > On 6/19/20 2:47 AM, Dong, Eric via groups.io wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: devel@edk2.groups.io  On Behalf Of
> >>> Lendacky, Thomas
> >>> Sent: Thursday, June 18, 2020 10:09 PM
> >>> To: Dong, Eric ; devel@edk2.groups.io
> >>> Cc: Brijesh Singh ; Ard Biesheuvel
> >>> ; Justen, Jordan L
> ;
> >>> Laszlo Ersek ; Gao, Liming ;
> >>> Kinney, Michael D ; Ni, Ray
> >>> 
> >>> Subject: Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement
> library
> >>> support for VMGEXIT
> >>>
> >>> On 6/18/20 2:23 AM, Dong, Eric wrote:
>  Hi Tom,
> 
>  When use VS2015 to build this code, it reports below error. Please
>  help to
> >>> fix it.
> 
>  k:\edk2\UefiCpuPkg\Include\Library/VmgExitLib.h: error C2220:
> warning
>  treated as error - no 'object' file generated
>  k:\edk2\UefiCpuPkg\Include\Library/VmgExitLib.h: warning C4335:
> Mac
>  file format detected: please convert the source file to either DOS or
>  UNIX format
> >>>
> >>> That is strange...  I didn't see this when I ran through the CI. When
> >>> I do a file
> >>> command against the file it reports:
> >>>
> >>> UefiCpuPkg/Include/Library/VmgExitLib.h: C source, ASCII text, with
> CRLF
> >>> line terminators
> >>>
> >>> I'll investigate this and try and figure out what's going on, but if
> >>> anyone else
> >>> has some ideas, please let me know.
> >>
> >> Hi Tom,
> >>
> >> I met this error again when I trig below patch from AMD again for CPU
> >> change.
> >> "UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to
> BaseUefiCpuLib"
> >
> > Hmmm... I think we could be running into issues with sending patches
> > through our mail servers. Let me send you the patch series directly
> > using some changes I made to my git config file to see if that helps.
> > Would that be ok?
> 
> both sender and recipient git clones should have
> 
> [core]
> whitespace = cr-at-eol
> 
> and the recipient clone should have
> 
> [am]
> keepcr = true
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-05
> 
> These are also set by "BaseTools/Scripts/SetupGit.py".
> 

Hi Tom,

I see below context in another mail thread and base on the latest status, this 
solution works and that patch has fixed the issue. Can you follow below suggest 
fixing your issue?

Hi Garrett,

I encounter below error when build
UefiCpuPkg\Library\BaseUefiCpuLib\BaseUefiCpuLib.c: warning C4335: Mac 
file format detected: please convert the source file to either DOS or UNIX 
format'

I encounter the issue ever, it result by mail encoding.
To resolve this issue, you can run [BaseTools\ Scripts\SetupGit.py] 
first, and then send the patch again.

Could you try it and send the patch again?

Thanks,
Eric

> Thanks
> Laszlo
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61572): https://edk2.groups.io/g/devel/message/61572
Mute This Topic: https://groups.io/mt/74692413/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector

2020-06-22 Thread Ni, Ray
Reviewed-by: Ray Ni 


> -Original Message-
> From: Cole, Deric 
> Sent: Wednesday, June 3, 2020 12:42 AM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Dong, Eric ; Laszlo Ersek 
> Subject: RE: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector
> 
> Ray,
> 
> The NOP is not a functional change, it's just for ease of debug.
> 
> Before, this file was padding with zeros in various places. When viewing this 
> memory using a disassembler, two
> subsequent zero-bytes show up as an ADD instruction, which I found confusing. 
> But worse, if the number of zero-bytes was
> odd, the disassembler might try to "consume" part of the next (real) 
> instruction as an operand to the last hypothetical
> ADD.
> 
> Since NOP is a 1-byte instruction, I used that instead, so it is easier to 
> visually identify the real code versus the padding
> when viewing disassembly.
> 
> -Deric
> 
> -Original Message-
> From: Ni, Ray 
> Sent: Monday, June 1, 2020 9:51 PM
> To: Cole, Deric ; devel@edk2.groups.io
> Cc: Dong, Eric ; Laszlo Ersek 
> Subject: RE: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector
> 
> Deric,
> Can you explain why changing all padding 0x0 to 0x90 (nop) in your patch?
> 
> Is it required to enable AP start up in pre-mem?
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: Cole, Deric 
> > Sent: Tuesday, June 2, 2020 6:32 AM
> > To: devel@edk2.groups.io
> > Cc: Cole, Deric ; Dong, Eric
> > ; Ni, Ray ; Laszlo Ersek
> > 
> > Subject: [PATCH] UefiCpuPkg/SecCore: Add pre-memory AP vector
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2776
> >
> > Add a vector at 0xFF000 (0xF000) that can be used by
> > Init-SIPI-SIPI to start an AP before memory is initialized. This
> > vector jumps into the same SEC entry point as the ordinary reset
> > vector, with a special value of "AP" in the DI register. The
> > platform-specific SEC code is expected to check for that value and
> > take a different path for APs, if this feature is supported by the platform.
> >
> > Cc: Eric Dong 
> > Cc: Ray Ni 
> > Cc: Laszlo Ersek 
> > Signed-off-by: Deric Cole 
> > ---
> >  UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb | 31
> > ---
> >  1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > b/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > index f41b9669d0..1dfc4efe4c 100644
> > --- a/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > +++ b/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb
> > @@ -10,7 +10,7 @@
> >  ; Abstract:
> >
> >  ;
> >
> >  ;  Reset Vector Data structure
> >
> > -;  This structure is located at 0xFFC0
> >
> > +;  This structure is located at 0xF000
> >
> >  ;
> >
> >
> > ;-
> > -
> >
> >
> >
> > @@ -23,19 +23,36 @@ USE16
> >  ;
> >
> >
> >
> >  ORG 0h
> >
> > +
> >
> > +;
> >
> > +; 0xF000
> >
> > +;
> >
> > +; We enter here with CS:IP = 0xFF00:0x. Do a far-jump to change
> > +CS to
> > 0xF000
> >
> > +; and IP to ApStartup.
> >
> > +;
> >
> > +ApVector:
> >
> > +mov di, "AP"
> >
> > +jmp 0xF000:0xF000+ApStartup
> >
> > +
> >
> > +TIMES 0xFC0-($-$$) nop
> >
> > +
> >
> > +;
> >
> > +; This should be at 0xFFC0
> >
> > +;
> >
> > +
> >
> >  ;
> >
> >  ; Reserved
> >
> >  ;
> >
> >  ReservedData:DD 0h, 0h
> >
> >
> >
> > -TIMES 0x10-($-$$) DB 0
> >
> > +TIMES 0xFD0-($-$$) nop
> >
> >  ;
> >
> > -; This is located at 0xFFD0h
> >
> > +; This is located at 0xFFD0
> >
> >  ;
> >
> >  mov di, "PA"
> >
> >  jmp ApStartup
> >
> >
> >
> > -TIMES 0x20-($-$$) DB 0
> >
> > +TIMES 0xFE0-($-$$) nop
> >
> >  ;
> >
> >  ; Pointer to the entry point of the PEI core
> >
> >  ; It is located at 0xFFE0, and is fixed up by some build tool
> >
> > @@ -53,7 +70,7 @@ ASM_PFX(InterruptHandler):
> >  jmp $
> >
> >  iret
> >
> >
> >
> > -TIMES 0x30-($-$$) DB 0
> >
> > +TIMES 0xFF0-($-$$) nop
> >
> >  ;
> >
> >  ; For IA32, the reset vector must be at 0xFFF0, i.e., 4G-16 byte
> >
> >  ; Execution starts here upon power-on/platform-reset.
> >
> > @@ -74,7 +91,7 @@ ApStartup:
> >  DW  -3
> >
> >
> >
> >
> >
> > -TIMES 0x38-($-$$) DB 0
> >
> > +TIMES 0xFF8-($-$$) nop
> >
> >  ;
> >
> >  ; Ap reset vector segment address is at 0xFFF8
> >
> >  ; This will be fixed up by some build tool,
> >
> > @@ -83,7 +100,7 @@ ApStartup:
> >  ;
> >
> >  ApSegAddress:dd  12345678h
> >
> >
> >
> > -TIMES 0x3c-($-$$) DB 0
> >
> > +TIMES 0xFFC-($-$$) nop
> >
> >  ;
> >
> >  ; BFV Base is at 0xFFFC
> >
> >  ; This will be fixed up by some build tool,
> >
> > --
> > 2.26.2.windows.1
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61571): https://edk2.groups.io/g/devel/message/61571
Mute This Topic: https://groups.io/mt/74621927/21656
Group Owner: 

Re: [edk2-devel] [PATCH v6 1/4] PcAtChipsetPkg: PcAtChipsetPkg.dsc add UefiCpuLib LibraryClass

2020-06-22 Thread Guomin Jiang
Hi Garrett,

Thanks for report quickly and it work and the 'Mac format issue disappear'.

But another build error occur 'error LNK2005: _InitializeFloatingPointUnits 
already defined in FspSecCoreT.lib(InitializeFpu.obj)'
It seem that result by ApicLib who depend UefiCpuLib now.

I want to know why you add this dependency, have any other way to do it, for 
example, add the dependency to the dsc file.

Best Regards
Guomin
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Kirkendall, Garrett
> Sent: Monday, June 22, 2020 9:18 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray 
> Subject: [edk2-devel] [PATCH v6 1/4] PcAtChipsetPkg: PcAtChipsetPkg.dsc
> add UefiCpuLib LibraryClass
> 
> In preparation for moving StandardSignatureIsAuthenticAMD to UefiCpuLib
> in UefiCpuPkg, PcAtChipset/PcAtChipsetPkg.dsc needs LibraryClass
> UefiCpuLib.
> LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf will need
> UefiCpuLib LibraryClass.  Likely most "real" platforms will be using
> BaseX2XApicLib instance which already required UefiCpuLib.
> 
> Cc: Ray Ni 
> Signed-off-by: Garrett Kirkendall 
> ---
>  PcAtChipsetPkg/PcAtChipsetPkg.dsc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dsc
> b/PcAtChipsetPkg/PcAtChipsetPkg.dsc
> index 01a3ee716a98..b61b7d1f528e 100644
> --- a/PcAtChipsetPkg/PcAtChipsetPkg.dsc
> +++ b/PcAtChipsetPkg/PcAtChipsetPkg.dsc
> @@ -2,6 +2,7 @@
>  #  PC/AT Chipset Package
>  #
>  #  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2020, AMD Incorporated. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -39,6 +40,7 @@
> [LibraryClasses]
> 
> ResetSystemLib|PcAtChipsetPkg/Library/ResetSystemLib/ResetSystemLib.in
> f
>IoApicLib|PcAtChipsetPkg/Library/BaseIoApicLib/BaseIoApicLib.inf
>LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
> +  UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
> 
> ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseR
> eportStatusCodeLibNull.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> 
> --
> 2.27.0
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61570): https://edk2.groups.io/g/devel/message/61570
Mute This Topic: https://groups.io/mt/75037835/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] ArmPlatformPkg/PL011UartLib: Check PID2 if FiFoDepth is zero

2020-06-22 Thread Samer El-Haj-Mahmoud
Adding Ard's new Arm e-mail address, and removing the old Linaro e-mail.

Thanks,
--Samer

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Irene
> Park via groups.io
> Sent: Monday, June 22, 2020 4:15 PM
> To: devel@edk2.groups.io; ard.biesheu...@linaro.org
> Subject: Re: [edk2-devel] [PATCH v2] ArmPlatformPkg/PL011UartLib: Check
> PID2 if FiFoDepth is zero
>
> Hi Ard,
> Would you please review this change ?
> I also wonder what you think of the following.
>
> #if FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth) == 0 VS if
> (FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth) == 0) or if
> (HardwareFifoDepth == 0)
>
> Thank you,
> Irene
>
> -Original Message-
> From: Irene Park 
> Sent: Tuesday, June 9, 2020 1:59 PM
> To: devel@edk2.groups.io
> Cc: Irene Park 
> Subject: [PATCH v2] ArmPlatformPkg/PL011UartLib: Check PID2 if FiFoDepth
> is zero
>
> From: Irene Park 
>
> PL011UartLib determines its FIFO depth based on the PID2 value but the
> register PID2 is not mandatory as per the SBSA spec.
> This change won't check PID2 if PcdUartDefaultReceiveFifoDepth is set to a
> value > 0.
>
> Signed-off-by: Irene Park 
> ---
>  ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c   | 4 
>  ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf | 1 +
>  2 files changed, 5 insertions(+)
>
> diff --git a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
> b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
> index 801990d..05ad1ad 100644
> --- a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
> +++ b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
> @@ -79,9 +79,13 @@ PL011UartInitializePort (
>UINT32  Fractional;
>UINT32  HardwareFifoDepth;
>
> +  HardwareFifoDepth = FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth);
> +#if FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth) == 0
>HardwareFifoDepth = (PL011_UARTPID2_VER (MmioRead32 (UartBase +
> UARTPID2)) \
> > PL011_VER_R1P4) \
>? 32 : 16 ;
> +#endif
> +
>// The PL011 supports a buffer of 1, 16 or 32 chars. Therefore we can
> accept
>// 1 char buffer as the minimum FIFO size. Because everything can be
> rounded
>// down, there is no maximum FIFO size.
> diff --git a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> index d99e89f..e3da507 100644
> --- a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> +++ b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> @@ -30,6 +30,7 @@
>ArmPlatformPkg/ArmPlatformPkg.dec
>
>  [FixedPcd]
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate
>
>gArmPlatformTokenSpaceGuid.PL011UartInteger
> --
> 2.7.4
>
>
> 

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61569): https://edk2.groups.io/g/devel/message/61569
Mute This Topic: https://groups.io/mt/75047196/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] ArmPlatformPkg/PL011UartLib: Check PID2 if FiFoDepth is zero

2020-06-22 Thread Irene Park
Hi Ard,
Would you please review this change ?
I also wonder what you think of the following.

#if FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth) == 0
VS
if (FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth) == 0) or if 
(HardwareFifoDepth == 0)

Thank you,
Irene

-Original Message-
From: Irene Park  
Sent: Tuesday, June 9, 2020 1:59 PM
To: devel@edk2.groups.io
Cc: Irene Park 
Subject: [PATCH v2] ArmPlatformPkg/PL011UartLib: Check PID2 if FiFoDepth is zero

From: Irene Park 

PL011UartLib determines its FIFO depth based on the PID2 value but the register 
PID2 is not mandatory as per the SBSA spec.
This change won't check PID2 if PcdUartDefaultReceiveFifoDepth is set to a 
value > 0.

Signed-off-by: Irene Park 
---
 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c   | 4 
 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf | 1 +
 2 files changed, 5 insertions(+)

diff --git a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c 
b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
index 801990d..05ad1ad 100644
--- a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
+++ b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
@@ -79,9 +79,13 @@ PL011UartInitializePort (
   UINT32  Fractional;
   UINT32  HardwareFifoDepth;
 
+  HardwareFifoDepth = FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth); 
+#if FixedPcdGet16 (PcdUartDefaultReceiveFifoDepth) == 0
   HardwareFifoDepth = (PL011_UARTPID2_VER (MmioRead32 (UartBase + UARTPID2)) \
> PL011_VER_R1P4) \
   ? 32 : 16 ;
+#endif
+
   // The PL011 supports a buffer of 1, 16 or 32 chars. Therefore we can accept
   // 1 char buffer as the minimum FIFO size. Because everything can be rounded
   // down, there is no maximum FIFO size.
diff --git a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf 
b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
index d99e89f..e3da507 100644
--- a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
+++ b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
@@ -30,6 +30,7 @@
   ArmPlatformPkg/ArmPlatformPkg.dec
 
 [FixedPcd]
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate
 
   gArmPlatformTokenSpaceGuid.PL011UartInteger
--
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61568): https://edk2.groups.io/g/devel/message/61568
Mute This Topic: https://groups.io/mt/75047196/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] uefi-sct/SctPkg: Remove gEfiFormBrowserExProtocolGuid

2020-06-22 Thread Irene Park
Hi Edhaya,
Thank you for the review.
By the way, I don’t see it got mainlined yet.
Do you mind to share when you’re going to pick it up ?
Thank you,
Irene

From: devel@edk2.groups.io  On Behalf Of G Edhaya Chandran
Sent: Friday, June 5, 2020 4:12 AM
To: Irene Park ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] uefi-sct/SctPkg: Remove 
gEfiFormBrowserExProtocolGuid

External email: Use caution opening links or attachments


Reviewed-by: G Edhaya 
Chandranmailto:edhaya.chand...@arm.com>>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61567): https://edk2.groups.io/g/devel/message/61567
Mute This Topic: https://groups.io/mt/74529350/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2] MdeModulePkg/DxeCorePerformanceLib: Switch to UnicodeStrnToAsciiStrS

2020-06-22 Thread Jeff Brasen
UnicodeStrToAsciiStrS requires that the source string is shorter than
the destination buffer and will ASSERT if this is not true. Switch to
UnicodeStrnToAsciiStrS as there are cases where the source string is
longer than the buffer allocated for the device path.

Signed-off-by: Jeff Brasen 
---
 .../Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
index f500e20b32..d378c59dd9 100644
--- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
+++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
@@ -837,7 +837,7 @@ GetDeviceInfoFromHandleAndUpdateLength (
   ControllerNameStringSize = FPDT_MAX_PERF_RECORD_SIZE - (*Length) - 1;
 }
 
-UnicodeStrToAsciiStrS(StringPtr, ComponentNameString, 
ControllerNameStringSize);
+UnicodeStrnToAsciiStrS(StringPtr, ControllerNameStringSize - 1, 
ComponentNameString, ControllerNameStringSize, );
 
 //
 // Add a space in the end of the ControllerName
@@ -879,7 +879,7 @@ GetDeviceInfoFromHandleAndUpdateLength (
 AsciiStringPtr = ComponentNameString;
   }
 
-  UnicodeStrToAsciiStrS(StringPtr, AsciiStringPtr, DevicePathStringSize);
+  UnicodeStrnToAsciiStrS(StringPtr, DevicePathStringSize - 1, 
AsciiStringPtr, DevicePathStringSize, );
   *Length += (UINT8)DevicePathStringSize;
   return EFI_SUCCESS;
 }
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61566): https://edk2.groups.io/g/devel/message/61566
Mute This Topic: https://groups.io/mt/75044750/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-staging/EdkRepo] [PATCH] EdkRepo: EdkRepo Sync Fails to Update Local Manifest

2020-06-22 Thread Bjorge, Erik C
It seems when patches are being applied we are getting mixed line endings.  
This is making the patches a bit more difficult to review.  We may want to look 
into fixing this.  The quick fix would be to convert all Python files to CRLF.

Reviewed-by: Erik Bjorge 

-Original Message-
From: Desimone, Ashley E  
Sent: Friday, June 19, 2020 4:33 PM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Pandya, Puja 
; Bjorge, Erik C ; Bret 
Barkelew ; Agyeman, Prince 

Subject: [edk2-staging/EdkRepo] [PATCH] EdkRepo: EdkRepo Sync Fails to Update 
Local Manifest

Only use the new manifests default combination if the current manifest is not 
present in the list of new combos

Remove the extranous comparison of repo sources as that content is checked 
later in the function.

Signed-off-by: Ashley E Desimone 
Cc: Nate DeSimone 
Cc: Puja Pandya 
Cc: Erik Bjorge 
Cc: Bret Barkelew 
Cc: Prince Agyeman 
---
 edkrepo/commands/sync_command.py | 45 ++--
 1 file changed, 20 insertions(+), 25 deletions(-)

diff --git a/edkrepo/commands/sync_command.py b/edkrepo/commands/sync_command.py
index dd7202d..c87861b 100644
--- a/edkrepo/commands/sync_command.py
+++ b/edkrepo/commands/sync_command.py
@@ -38,7 +38,7 @@ from edkrepo.common.common_repo_functions import 
checkout_repos, check_dirty_rep  from edkrepo.common.common_repo_functions 
import update_editor_config  from edkrepo.common.common_repo_functions import 
update_repo_commit_template, get_latest_sha  from 
edkrepo.common.common_repo_functions import has_primary_repo_remote, 
fetch_from_primary_repo, in_sync_with_primary -from 
edkrepo.common.common_repo_functions import update_hooks, 
combinations_in_manifest+from edkrepo.common.common_repo_functions import 
update_hooks, combinations_in_manifest  from 
edkrepo.common.common_repo_functions import write_included_config, 
remove_included_config  from 
edkrepo.common.workspace_maintenance.workspace_maintenance import 
generate_name_for_obsolete_backup  from 
edkrepo.common.workspace_maintenance.manifest_repos_maintenance import 
pull_workspace_manifest_repo @@ -48,7 +48,7 @@ from edkrepo.common.ui_functions 
import init_color_console  from edkrepo.config.config_factory import 
get_workspace_path, get_workspace_manifest, get_edkrepo_global_data_directory  
from edkrepo.config.config_factory import get_workspace_manifest_file  from 
edkrepo_manifest_parser.edk_manifest import CiIndexXml, ManifestXml -from 
project_utils.submodule import deinit_submodules, maintain_submodules+from 
project_utils.submodule import deinit_submodules, maintain_submodules
 
 
 class SyncCommand(EdkrepoCommand):
@@ -85,7 +85,7 @@ class SyncCommand(EdkrepoCommand):
 current_combo = initial_manifest.general_config.current_combo
 initial_sources = initial_manifest.get_repo_sources(current_combo)
 initial_hooks = initial_manifest.repo_hooks
-initial_combo = current_combo+initial_combo = current_combo
 
 source_global_manifest_repo = 
find_source_manifest_repo(initial_manifest, config['cfg_file'], 
config['user_cfg_file'], args.source_manifest_repo)
 pull_workspace_manifest_repo(initial_manifest, config['cfg_file'], 
config['user_cfg_file'], args.source_manifest_repo, False) @@ -102,7 +102,7 @@ 
class SyncCommand(EdkrepoCommand):
 if not args.update_local_manifest:
 self.__check_for_new_manifest(args, config, initial_manifest, 
workspace_path, global_manifest_directory)
 check_dirty_repos(initial_manifest, workspace_path)
-+
 # Determine if sparse checkout needs to be disabled for this operation
 sparse_settings = initial_manifest.sparse_settings
 sparse_enabled = sparse_checkout_enabled(workspace_path, 
initial_sources) @@ -116,7 +116,7 @@ class SyncCommand(EdkrepoCommand):
 reset_sparse_checkout(workspace_path, initial_sources)
 
 # Get the latest manifest if requested
-if args.update_local_manifest:  # NOTE: hyphens in arg name replaced 
with underscores due to argparse+if args.update_local_manifest:  # 
NOTE: hyphens in arg name replaced with underscores due to argparse
 self.__update_local_manifest(args, config, initial_manifest, 
workspace_path, global_manifest_directory)
 manifest = get_workspace_manifest()
 if args.update_local_manifest:
@@ -130,12 +130,12 @@ class SyncCommand(EdkrepoCommand):
 repo_sources_to_sync = manifest.get_repo_sources(current_combo)
 manifest.write_current_combo(current_combo)
 
-# At this point both new and old manifest files are ready so we can 
deinit any-# submodules that are removed due to a manifest update.- 
   if not args.skip_submodule:-deinit_submodules(workspace_path, 
initial_manifest, initial_combo,-  manifest, 
current_combo, args.verbose)-+# At this point both new and old manifest 
files are ready so we can deinit 

Re: [edk2-devel] [PATCH V1] UefiPayloadPkg:Fix NOOPT build failure

2020-06-22 Thread Ma, Maurice
Reviewed-by: Maurice Ma 


> -Original Message-
> From: Dong, Guo 
> Sent: Saturday, June 20, 2020 19:15
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; You, Benjamin
> ; Dong, Guo 
> Subject: [edk2-devel] [PATCH V1] UefiPayloadPkg:Fix NOOPT build failure
> 
> When build UEFI payload using NOOPT, it would build failure since the FV size.
> So this patch increases FV size to support NOOPT.
> If not NOOPT build, there is no change to FV size.
> 
> Signed-off-by: Guo Dong 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.fdf | 32 
>  1 file changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index dfbcde5668..a04fcd2ec2 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -8,23 +8,39 @@
>  #
>  ##
> 
> +[Defines]
> +DEFINE FD_BASE   = 0x0080
> +DEFINE FD_BLOCK_SIZE = 0x1000
> +
> +!if $(TARGET) == "NOOPT"
> +DEFINE PEI_FV_SIZE = 0x0005
> +DEFINE DXE_FV_SIZE = 0x0080
> +DEFINE FD_SIZE = 0x0085
> +DEFINE NUM_BLOCKS  = 0x850
> +!else
> +DEFINE PEI_FV_SIZE = 0x3
> +DEFINE DXE_FV_SIZE = 0x3E
> +DEFINE FD_SIZE = 0x0041
> +DEFINE NUM_BLOCKS  = 0x410
> +!endif
> +
> 
> #
> ###
>  [FD.UefiPayload]
> -BaseAddress   =
> 0x80|gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemBase
> -Size  =
> 0x41|gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemSize
> +BaseAddress   = $(FD_BASE) |
> gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemBase
> +Size  = $(FD_SIZE) |
> gUefiPayloadPkgTokenSpaceGuid.PcdPayloadFdMemSize
>  ErasePolarity = 1
> -BlockSize = 0x1000
> -NumBlocks = 0x410
> +BlockSize = $(FD_BLOCK_SIZE)
> +NumBlocks = $(NUM_BLOCKS)
> 
> -0x|0x03
> +0x|$(PEI_FV_SIZE)
>  FV = PEIFV
> 
> -0x0003|0x3E
> +$(PEI_FV_SIZE)|$(DXE_FV_SIZE)
>  FV = DXEFV
> 
> 
> #
> ###
>  [FV.PEIFV]
> -BlockSize  = 0x1000
> +BlockSize  = $(FD_BLOCK_SIZE)
>  FvAlignment= 16
>  ERASE_POLARITY = 1
>  MEMORY_MAPPED  = TRUE
> @@ -54,7 +70,7 @@ INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> 
> #
> ###
> 
>  [FV.DXEFV]
> -BlockSize  = 0x1000
> +BlockSize  = $(FD_BLOCK_SIZE)
>  FvForceRebase  = FALSE
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> --
> 2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61564): https://edk2.groups.io/g/devel/message/61564
Mute This Topic: https://groups.io/mt/75013473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] EDK2 code standard question

2020-06-22 Thread Laszlo Ersek
On 06/19/20 19:25, Hernan via groups.io wrote:
> Hi,
> 
> I am a new to this group and I found something I think it is a problem in the 
> documentation for code standards of edk2.
> Can you help me understand who/how I can request a revision on such detail in 
> the documentation?
> 
> https://edk2-docs.gitbook.io/edk-ii-c-coding-standards-specification/5_source_files/57_c_programming
> 
> Section 5.7.1.10, specifically.

(1) Please register in the tianocore bugzilla at
, and then file a new bug with the
following details:

- product: EDK2
- Component: documentation
- package: N/A
- Tianocore documents: EDK II C Coding Standards

In case you'd like to post patches too:

(2) You can clone the source repository for the document from:

- repo URL:
https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification.git

- web UI:
https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification

(3) Once you push your patches to your personal fork on github.com, you
can also sign up at , and configure
integration with github.com. This will let you check a rendered view of
your changes before posting the patches. IIRC you can select, on
gitbook.com, the branch whose HEAD you'd like to render.

(4) For posting patches, please use the subject prefix "PATCH
edk2-CCodingStandardsSpecification" or "PATCH edk2-CCSS".

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61563): https://edk2.groups.io/g/devel/message/61563
Mute This Topic: https://groups.io/mt/74985159/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v6 4/4] UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE manipulation on AMD

2020-06-22 Thread Laszlo Ersek
On 06/22/20 15:18, Garrett Kirkendall wrote:
> AMD does not support MSR_IA32_MISC_ENABLE.  Accessing that register
> causes and exception on AMD processors.  If Execution Disable is
> supported, but if the processor is an AMD processor, skip manipulating
> MSR_IA32_MISC_ENABLE[34] XD Disable bit.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Garrett Kirkendall 
> ---

When carrying forward a patch unmodified from the previous version of
the series, then please pick up the feedback tags given under the
previous version.

See e.g.:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-28

So, from  /
http://mid.mail-archive.com/dcfe4164-c021-7ddc-2891-fffc9b1c279d@redhat.com>:

Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

BTW the series looks well-formatted to me, on the list, this time around.

Thanks
Laszlo



> 
> Notes:
> Tested on Intel hardware with Laszlo Ersek's help
> 
> (1) downloaded two Linux images from provided links.
> (2) Test using a 32-bit guest on an Intel host (standing in your edk2 
> tree, with the patches applied):
> 
> $ build -a IA32 -b DEBUG -p OvmfPkg/OvmfPkgIa32.dsc -t GCC5 -D SMM_REQUIRE
> 
> $ qemu-system-i386 \
> -cpu coreduo,-nx \
> -machine q35,smm=on,accel=kvm \
> -m 4096 \
> -smp 4 \
> -global driver=cfi.pflash01,property=secure,value=on \
> -drive 
> if=pflash,format=raw,unit=0,readonly=on,file=Build/OvmfIa32/DEBUG_GCC5/FV/OVMF_CODE.fd
>  \
> -drive 
> if=pflash,format=raw,unit=1,snapshot=on,file=Build/OvmfIa32/DEBUG_GCC5/FV/OVMF_VARS.fd
>  \
> -drive 
> id=hdd,if=none,format=qcow2,snapshot=on,file=fedora-30-efi-systemd-i686.qcow2 
> \
> -device virtio-scsi-pci,id=scsi0 \
> -device scsi-hd,drive=hdd,bus=scsi0.0,bootindex=1
> 
> (Once you get a login prompt, feel free to interrupt QEMU with Ctrl-C.)
> 
> (3) Test using a 64-bit guest on an Intel host:
> 
> $ build -a IA32 -a X64 -b DEBUG -p OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -D 
> SMM_REQUIRE
> 
> $ qemu-system-x86_64 \
> -cpu host \
> -machine q35,smm=on,accel=kvm \
> -m 4096 \
> -smp 4 \
> -global driver=cfi.pflash01,property=secure,value=on \
> -drive 
> if=pflash,format=raw,unit=0,readonly=on,file=Build/Ovmf3264/DEBUG_GCC5/FV/OVMF_CODE.fd
>  \
> -drive 
> if=pflash,format=raw,unit=1,snapshot=on,file=Build/Ovmf3264/DEBUG_GCC5/FV/OVMF_VARS.fd
>  \
> -drive 
> id=hdd,if=none,format=qcow2,snapshot=on,file=fedora-31-efi-grub2-x86_64.qcow2 
> \
> -device virtio-scsi-pci,id=scsi0 \
> -device scsi-hd,drive=hdd,bus=scsi0.0,bootindex=1
> 
> Tested on real AMD Hardware
> 
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  3 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  9 -
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm   | 19 +--
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm| 20 ++--
>  4 files changed, 46 insertions(+), 5 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
> index 43f6935cf9dc..993360a8a8c1 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
> @@ -2,6 +2,7 @@
>  SMM profile internal header file.
>  
>  Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2020, AMD Incorporated. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -13,6 +14,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "SmmProfileArch.h"
> @@ -99,6 +101,7 @@ extern SMM_S3_RESUME_STATE   *mSmmS3ResumeState;
>  extern UINTN gSmiExceptionHandlers[];
>  extern BOOLEAN   mXdSupported;
>  X86_ASSEMBLY_PATCH_LABEL gPatchXdSupported;
> +X86_ASSEMBLY_PATCH_LABEL gPatchMsrIa32MiscEnableSupported;
>  extern UINTN *mPFEntryCount;
>  extern UINT64(*mLastPFEntryValue)[MAX_PF_ENTRY_COUNT];
>  extern UINT64*(*mLastPFEntryPointer)[MAX_PF_ENTRY_COUNT];
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index c47b5573e366..d7ed9ab7a770 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -2,7 +2,7 @@
>  Enable SMM profile.
>  
>  Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
> -Copyright (c) 2017, AMD Incorporated. All rights reserved.
> +Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
>  
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> 

Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

2020-06-22 Thread Laszlo Ersek
On 06/22/20 06:57, Bi, Dandan wrote:
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo
>> Ersek
>> Sent: Friday, June 19, 2020 8:48 PM
>> To: r...@edk2.groups.io; Bi, Dandan ;
>> devel@edk2.groups.io
>> Cc: Dong, Eric ; Ni, Ray ; Wang,
>> Jian J ; Wu, Hao A ; Tan,
>> Ming 
>> Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler:
>> Separate NULL class libraries for Memory and serial handlers from
>> MdeModulePkg/Universal/StatusCodeHandler modules
>>
>> On 06/18/20 09:01, Dandan Bi wrote:
>>> Hi All,
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2816
>>>
>>> We plan to separate two kinds of NULL class libraries for Memory and serial
>> handlers from MdeModulePkg/Universal/StatusCodeHandler/.../
>> StatusCodeHandlerPei/RuntimeDxe/Smm modules.
>>> The benefit we want to gain from this separation is to 1) make the code
>> clear and easy to maintain, 2) make platform flexible to choose any handler
>> library they need, and it also can reduce image size since the unused
>> handlers can be excluded.
>>> If you have any concern or comments for this separation, please let me
>> know.
>>>
>>> We plan to add new separated NULL class library
>> MemoryStausCodeHandlerLib and SerialStatusCodeHandlerLib with different
>> phase implementation into MdeModulePkg\Library\ directory.
>>> The main tree structure may like below:
>>> MdeModulePkg\Library
>>> |--MemoryStausCodeHandlerLib
>>> |--|-- PeiMemoryStausCodeHandlerLib.inf
>>> |--|-- RuntimeDxeMemoryStatusCodeHandlerLib.inf
>>> |--|-- SmmMemoryStausCodeHandlerLib.inf
>>> |--SerialStatusCodeHandlerLib
>>> |--|-- PeiSerialStatusCodeHandlerLib.inf
>>> |--|-- RuntimeDxeSerialStatusCodeHandlerLib.inf
>>> |--|-- SmmSerialStatusCodeHandlerLib.inf
>>>
>>>
>>> We will update existing platform use cases in edk2 and edk2-platform repo
>> to cover the new NULL class library to make sure this change doesn't impact
>> any platform.
>>> After this separation, StatusCodeHandler module usage will like below, and
>> it's also very flexible for platform to cover more handler libraries to meet
>> their requirements.
>>>
>> MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.in
>> f {
>>>   
>>>
>> NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemorySt
>> ausCode
>>> NULL|HandlerLib.inf
>>>
>> NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusC
>> o
>>> NULL|deHandlerLib.inf
>>> ...
>>> }
>>>
>>>
>> MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHan
>> dlerRuntimeDxe.inf  {
>>>   
>>>
>> NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeM
>> emorySt
>>> NULL|ausCodeHandlerLib.inf
>>>
>> NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSeri
>> alS
>>> NULL|tatusCodeHandlerLib.inf
>>> ...
>>> }
>>>
>>>
>> MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSm
>> m.inf {
>>>   
>>>
>>>
>> NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemory
>> StausCode
>>> HandlerLib.inf
>>>
>> NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatus
>> Co
>>> NULL|deHandlerLib.inf
>>> ...
>>> }
>>
>> So I assume you're going to remove PcdStatusCodeUseSerial and
>> PcdStatusCodeUseMemory, and when converting the existent platforms,
>> the new NULL class resolutions in the DSC files will reflect the specific PCD
>> values used in those DSC files until then. Is that right?
>>
> Thanks for pointing out the PCD part which I miss in this RFC.
> This commit 
> https://github.com/tianocore/edk2/commit/45bc28172fbf38ac21e2592c07189b55f57695e3
>  have updated PcdStatusCodeUseSerial and PcdStatusCodeUseMemory type.
> We plan to keep PcdStatusCodeUseSerial and PcdStatusCodeUseMemory.  Through 
> NULL class resolutions in the DSC can make the code handler code included or 
> not, then we still can control handler enable/disable through the PCD 
> dynamically if the handler is included.
> What do you think of this?

Hm... OK.

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61561): https://edk2.groups.io/g/devel/message/61561
Mute This Topic: https://groups.io/mt/74953841/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v6 1/4] PcAtChipsetPkg: PcAtChipsetPkg.dsc add UefiCpuLib LibraryClass

2020-06-22 Thread Kirkendall, Garrett
In preparation for moving StandardSignatureIsAuthenticAMD to UefiCpuLib
in UefiCpuPkg, PcAtChipset/PcAtChipsetPkg.dsc needs LibraryClass
UefiCpuLib.
LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf will need
UefiCpuLib LibraryClass.  Likely most "real" platforms will be using
BaseX2XApicLib instance which already required UefiCpuLib.

Cc: Ray Ni 
Signed-off-by: Garrett Kirkendall 
---
 PcAtChipsetPkg/PcAtChipsetPkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dsc 
b/PcAtChipsetPkg/PcAtChipsetPkg.dsc
index 01a3ee716a98..b61b7d1f528e 100644
--- a/PcAtChipsetPkg/PcAtChipsetPkg.dsc
+++ b/PcAtChipsetPkg/PcAtChipsetPkg.dsc
@@ -2,6 +2,7 @@
 #  PC/AT Chipset Package
 #
 #  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2020, AMD Incorporated. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -39,6 +40,7 @@ [LibraryClasses]
   ResetSystemLib|PcAtChipsetPkg/Library/ResetSystemLib/ResetSystemLib.inf
   IoApicLib|PcAtChipsetPkg/Library/BaseIoApicLib/BaseIoApicLib.inf
   LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
+  UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
   
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
 
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61557): https://edk2.groups.io/g/devel/message/61557
Mute This Topic: https://groups.io/mt/75037835/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v6 0/4] AMD processor MSR_IA32_MISC_ENABLE

2020-06-22 Thread Kirkendall, Garrett
AMD processor does not support MSR_IA32_MISC_ENABLE register.  Accessing
this register on AMD causes an unhandled exception in SmmEntry.nasm and
a subsequent failure to boot since this is too early in SMM path for the
exception handler to be loaded.

1. Prepare PcAtChipsetPkg/PcAtChipsetPkg.dsc to move
StandardSignatureIsAuthenticAMD into UefiCpuLib LibraryClass
BaseUefiCpuLib in UefiCpuPkg.

2. To distinguish between AMD and other processors, refactor
StandardSignatureIsAuthenticAMD into BaseUefiCpuLib.  So there is only
one copy in the source.

3. Skip manipulation of MSR_IA32_MISC_ENABLE register if running
on an AMD processor.

Tested on AMD X64 hardware.
OvmfIa32 and OvmfIa32X64 on Intel hardware.

v1: Move StandardSignatureIsAuthenticAMD. Handle MSR_IA32_MISC_ENABLE
v2: Incorporate Laszlo's feedback
v3: Typo, not sent
v4: Patch in to add UefiCpuLib to PcAtChipsetPkg.dsc
v5: Patch in to add UefiCpuLib to SourceLevelDebugPkg.dsc
v6: Hopefully reformat patch when sending

Garrett Kirkendall (4):
  PcAtChipsetPkg: PcAtChipsetPkg.dsc add UefiCpuLib LibraryClass
  SourceLevelDebugPkg: SourceLevelDebugPkg.dsc add UefiCpuLib
LibraryClass
  UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to BaseUefiCpuLib
  UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE manipulation on
AMD

 PcAtChipsetPkg/PcAtChipsetPkg.dsc|  2 ++
 SourceLevelDebugPkg/SourceLevelDebugPkg.dsc  |  2 ++
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf |  7 
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf |  2 ++
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf |  2 ++
 UefiCpuPkg/Include/Library/UefiCpuLib.h  | 14 
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h   |  3 ++
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c   | 38 

 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c   | 25 ++---
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c   | 25 ++---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c   |  9 -
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 19 --
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm  | 20 +--
 14 files changed, 117 insertions(+), 74 deletions(-)
 create mode 100644 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c

Changes at:
https://github.com/gkirkendall-amd/edk2/tree/smmentry_nasm_skip_msr_xd_bit_on_amd_v6

Pull Request:
https://github.com/tianocore/edk2/pull/716

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Hao A Wu 
Signed-off-by: Garrett Kirkendall 

-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61556): https://edk2.groups.io/g/devel/message/61556
Mute This Topic: https://groups.io/mt/75037833/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v6 2/4] SourceLevelDebugPkg: SourceLevelDebugPkg.dsc add UefiCpuLib LibraryClass

2020-06-22 Thread Kirkendall, Garrett
In preparation for moving StandardSignatureIsAuthenticAMD to UefiCpuLib
in UefiCpuPkg, SourceLevelDebugPkg/SourceLevelDebugPkg.dsc needs
LibraryClass UefiCpuLib.
LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf will need
UefiCpuLib LibraryClass.  Likely most "real" platforms will be using
BaseX2XApicLib instance which already required UefiCpuLib.

Cc: Hao A Wu 
Signed-off-by: Garrett Kirkendall 
---
 SourceLevelDebugPkg/SourceLevelDebugPkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc 
b/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
index a1a1b81d03cb..20eb10ba07f8 100644
--- a/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
+++ b/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
@@ -2,6 +2,7 @@
 # Source Level Debug Package.
 #
 # Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2020, AMD Incorporated. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -32,6 +33,7 @@ [LibraryClasses.common]
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
+  UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
   
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
-- 
2.27.0


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61558): https://edk2.groups.io/g/devel/message/61558
Mute This Topic: https://groups.io/mt/75037837/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v6 3/4] UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to BaseUefiCpuLib

2020-06-22 Thread Kirkendall, Garrett
Refactor StandardSignatureIsAuthenticAMD into BaseUefiCpuLib from
separate copies in BaseXApicLib, BaseXApicX2ApicLib, and MpInitLib.
This allows for future use of StandarSignatureIsAuthinticAMD without
creating more instances in other modules.

This function allows IA32/X64 code to determine if it is running on an
AMD brand processor.

UefiCpuLib is already included directly or indirectly in all modified
modules.  Complete move is made in this change.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Garrett Kirkendall 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Eric Dong 
---
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf |  7 
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf |  2 ++
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf |  2 ++
 UefiCpuPkg/Include/Library/UefiCpuLib.h  | 14 
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c   | 38 

 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c   | 25 ++---
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c   | 25 ++---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 
 8 files changed, 67 insertions(+), 69 deletions(-)

diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf 
b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
index 006b7acbf14e..34d3a7bb4303 100644
--- a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
+++ b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
@@ -4,6 +4,7 @@
 #  The library routines are UEFI specification compliant.
 #
 #  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2020, AMD Inc. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -29,6 +30,12 @@ [Sources.IA32]
 [Sources.X64]
   X64/InitializeFpu.nasm
 
+[Sources]
+  BaseUefiCpuLib.c
+
 [Packages]
   MdePkg/MdePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+  BaseLib
diff --git a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf 
b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
index bdb2ff372677..561baa44b0e6 100644
--- a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
+++ b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
@@ -5,6 +5,7 @@
 #  where local APIC is disabled.
 #
 #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2020, AMD Inc. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -37,6 +38,7 @@ [LibraryClasses]
   TimerLib
   IoLib
   PcdLib
+  UefiCpuLib
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuInitIpiDelayInMicroSeconds  ## 
SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf 
b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
index ac1e0a1c9896..1e2a4f8b790f 100644
--- a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
+++ b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
@@ -5,6 +5,7 @@
 #  where local APIC is disabled.
 #
 #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2020, AMD Inc. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -37,6 +38,7 @@ [LibraryClasses]
   TimerLib
   IoLib
   PcdLib
+  UefiCpuLib
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuInitIpiDelayInMicroSeconds  ## 
SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/Include/Library/UefiCpuLib.h 
b/UefiCpuPkg/Include/Library/UefiCpuLib.h
index 82e53bab3a0f..5326e7246301 100644
--- a/UefiCpuPkg/Include/Library/UefiCpuLib.h
+++ b/UefiCpuPkg/Include/Library/UefiCpuLib.h
@@ -5,6 +5,7 @@
   to be UEFI specification compliant.
 
   Copyright (c) 2009, Intel Corporation. All rights reserved.
+  Copyright (c) 2020, AMD Inc. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -29,4 +30,17 @@ InitializeFloatingPointUnits (
   VOID
   );
 
+/**
+  Determine if the standard CPU signature is "AuthenticAMD".
+
+  @retval TRUE  The CPU signature matches.
+  @retval FALSE The CPU signature does not match.
+
+**/
+BOOLEAN
+EFIAPI
+StandardSignatureIsAuthenticAMD (
+  VOID
+  );
+
 #endif
diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c 
b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c
new file mode 100644
index ..c2cc3ff9a709
--- /dev/null
+++ b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c
@@ -0,0 +1,38 @@
+/** @file
+  This library defines some routines that are generic for IA32 family CPU.
+
+  The library routines are UEFI specification compliant.
+
+  Copyright (c) 2020, AMD Inc. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+#include 
+#include 
+
+/**
+  Determine if the standard CPU signature is "AuthenticAMD".
+
+  @retval TRUE  The CPU signature matches.
+  @retval FALSE The CPU signature does not match.
+
+**/
+BOOLEAN
+EFIAPI
+StandardSignatureIsAuthenticAMD (
+  VOID
+  )
+{
+  UINT32  RegEbx;
+  

[edk2-devel] [PATCH v6 4/4] UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE manipulation on AMD

2020-06-22 Thread Kirkendall, Garrett
AMD does not support MSR_IA32_MISC_ENABLE.  Accessing that register
causes and exception on AMD processors.  If Execution Disable is
supported, but if the processor is an AMD processor, skip manipulating
MSR_IA32_MISC_ENABLE[34] XD Disable bit.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Garrett Kirkendall 
---

Notes:
Tested on Intel hardware with Laszlo Ersek's help

(1) downloaded two Linux images from provided links.
(2) Test using a 32-bit guest on an Intel host (standing in your edk2 tree, 
with the patches applied):

$ build -a IA32 -b DEBUG -p OvmfPkg/OvmfPkgIa32.dsc -t GCC5 -D SMM_REQUIRE

$ qemu-system-i386 \
-cpu coreduo,-nx \
-machine q35,smm=on,accel=kvm \
-m 4096 \
-smp 4 \
-global driver=cfi.pflash01,property=secure,value=on \
-drive 
if=pflash,format=raw,unit=0,readonly=on,file=Build/OvmfIa32/DEBUG_GCC5/FV/OVMF_CODE.fd
 \
-drive 
if=pflash,format=raw,unit=1,snapshot=on,file=Build/OvmfIa32/DEBUG_GCC5/FV/OVMF_VARS.fd
 \
-drive 
id=hdd,if=none,format=qcow2,snapshot=on,file=fedora-30-efi-systemd-i686.qcow2 \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=hdd,bus=scsi0.0,bootindex=1

(Once you get a login prompt, feel free to interrupt QEMU with Ctrl-C.)

(3) Test using a 64-bit guest on an Intel host:

$ build -a IA32 -a X64 -b DEBUG -p OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -D 
SMM_REQUIRE

$ qemu-system-x86_64 \
-cpu host \
-machine q35,smm=on,accel=kvm \
-m 4096 \
-smp 4 \
-global driver=cfi.pflash01,property=secure,value=on \
-drive 
if=pflash,format=raw,unit=0,readonly=on,file=Build/Ovmf3264/DEBUG_GCC5/FV/OVMF_CODE.fd
 \
-drive 
if=pflash,format=raw,unit=1,snapshot=on,file=Build/Ovmf3264/DEBUG_GCC5/FV/OVMF_VARS.fd
 \
-drive 
id=hdd,if=none,format=qcow2,snapshot=on,file=fedora-31-efi-grub2-x86_64.qcow2 \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=hdd,bus=scsi0.0,bootindex=1

Tested on real AMD Hardware

 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  3 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  9 -
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm   | 19 +--
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm| 20 ++--
 4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
index 43f6935cf9dc..993360a8a8c1 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
@@ -2,6 +2,7 @@
 SMM profile internal header file.
 
 Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2020, AMD Incorporated. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -13,6 +14,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "SmmProfileArch.h"
@@ -99,6 +101,7 @@ extern SMM_S3_RESUME_STATE   *mSmmS3ResumeState;
 extern UINTN gSmiExceptionHandlers[];
 extern BOOLEAN   mXdSupported;
 X86_ASSEMBLY_PATCH_LABEL gPatchXdSupported;
+X86_ASSEMBLY_PATCH_LABEL gPatchMsrIa32MiscEnableSupported;
 extern UINTN *mPFEntryCount;
 extern UINT64(*mLastPFEntryValue)[MAX_PF_ENTRY_COUNT];
 extern UINT64*(*mLastPFEntryPointer)[MAX_PF_ENTRY_COUNT];
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index c47b5573e366..d7ed9ab7a770 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -2,7 +2,7 @@
 Enable SMM profile.
 
 Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
-Copyright (c) 2017, AMD Incorporated. All rights reserved.
+Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -1015,6 +1015,13 @@ CheckFeatureSupported (
   mXdSupported = FALSE;
   PatchInstructionX86 (gPatchXdSupported, mXdSupported, 1);
 }
+
+if (StandardSignatureIsAuthenticAMD ()) {
+  //
+  // AMD processors do not support MSR_IA32_MISC_ENABLE
+  //
+  PatchInstructionX86 (gPatchMsrIa32MiscEnableSupported, FALSE, 1);
+}
   }
 
   if (mBtsSupported) {
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
index f96de9bdeb43..167f5e14dbd4 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
@@ -1,5 +1,6 @@
 
;-- 
;
 ; Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
+; Copyright (c) 2020, AMD Incorporated. All rights reserved.
 ; SPDX-License-Identifier: BSD-2-Clause-Patent
 ;
 ; Module Name:
@@ 

Re: [edk2-devel] [PATCH v3 0/7] Standalone AcpiView Application

2020-06-22 Thread Tomas Pilar (tpilar)
Hi Ray, Zhichao,

Do you have any opinions on the respun patches?

Cheers,
Tom

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tomas Pilar 
(tpilar) via groups.io
Sent: 15 June 2020 15:04
To: devel@edk2.groups.io
Cc: nd ; Ray Ni ; Zhichao Gao 

Subject: [edk2-devel] [PATCH v3 0/7] Standalone AcpiView Application

This patchset adds a new application module to the 
ShellPkg with the functionality of the 'acpiview' command.

The existing code is tidied and a clean boundary between
the UEFI shell command wrapper and the acpiview functionality
is created. Then, a new application wrapper is added.

The motivation for a standalone AcpiView application lies
in the desire to test implementation of the Acpi tables on 
a wide selection of platforms, particularly platforms still
in development, platforms that might have an older implementation
of the UEFI shell or platforms that might not include the 'acpiview'
command in the internal build of the UEFI shell. Furthermore,
this application can then be integrated in larger firmware
testing frameworks.

---
v3: Fix pointer dereference in GetSelectedTable. Create library
interface for the UefiShellAcpiViewCommandLib and convert to
named library. Tidy help text shell hook in standalone app.
v2: Patch formatting

Cc: Ray Ni 
Cc: Zhichao Gao 

Tomas Pilar (7):
  ShellPkg/AcpiView: Move log reset to main method
  ShellPkg/AcpiView: Refactor configuration
  ShellPkg/AcpiView: Move table count reset
  ShellPkg/AcpiView: Move parameter parsing
  ShellPkg/AcpiView: Refactor DumpAcpiTableToFile
  ShellPkg: Add AcpiViewCommandLib
  ShellPkg/AcpiView: Add application wrapper

 .../Application/AcpiViewApp/AcpiViewApp.c |  40 ++
 .../Application/AcpiViewApp/AcpiViewApp.inf   |  34 ++
 .../Application/AcpiViewApp/AcpiViewApp.uni   | 122 +
 ShellPkg/Include/Library/AcpiViewCommandLib.h |  46 ++
 .../UefiShellAcpiViewCommandLib/AcpiParser.c  |   1 +
 .../AcpiTableParser.c |   1 +
 .../UefiShellAcpiViewCommandLib/AcpiView.c| 474 ++
 .../UefiShellAcpiViewCommandLib/AcpiView.h| 113 +
 .../AcpiViewConfig.c  | 246 +
 .../AcpiViewConfig.h  | 177 +++
 .../Parsers/Gtdt/GtdtParser.c |   1 +
 .../Parsers/Iort/IortParser.c |   1 +
 .../Parsers/Madt/MadtParser.c |   1 +
 .../Parsers/Pptt/PpttParser.c |   1 +
 .../Parsers/Srat/SratParser.c |   1 +
 .../UefiShellAcpiViewCommandLib.c | 279 ++-
 .../UefiShellAcpiViewCommandLib.h |  26 -
 .../UefiShellAcpiViewCommandLib.inf   |  33 +-
 ShellPkg/ShellPkg.dec |   3 +
 ShellPkg/ShellPkg.dsc |   4 +-
 20 files changed, 1019 insertions(+), 585 deletions(-)
 create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.c
 create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.inf
 create mode 100644 ShellPkg/Application/AcpiViewApp/AcpiViewApp.uni
 create mode 100644 ShellPkg/Include/Library/AcpiViewCommandLib.h
 create mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiViewConfig.c
 create mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiViewConfig.h
 delete mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.h

-- 
2.24.1.windows.2






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61555): https://edk2.groups.io/g/devel/message/61555
Mute This Topic: https://groups.io/mt/74894926/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] MdeModulePkg: Upon BootOption failure, Destroy RamDisk memory before RSC.

2020-06-22 Thread Wang, Sunny (HPS SW)
Looks good to me. Not sure if there was a reason to call BmDestroyRamDisk 
before ReportStatusCode. 
By the way, it is an interesting case that there is a custom boot option or 
application that needs the memory that was occupied by the RAM disk. It looks 
to me like the custom boot option or application would like to create the other 
RAM disk with allocating large memory for recovering the failed boot option. 

Reviewed-by: Sunny Wang 

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
KrishnadasX Veliyathuparambil Prakashan
Sent: Friday, June 19, 2020 10:40 AM
To: devel@edk2.groups.io
Cc: Gao, Zhichao ; Ni, Ray 
Subject: [edk2-devel] [PATCH] MdeModulePkg: Upon BootOption failure, Destroy 
RamDisk memory before RSC.

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

For better memory management, re-ordered the DestroyRamDisk and 
ReportStatusCode calls inside the EfiBootManagerBoot() function.

This will help to clean the unused memory before reporting the failure status, 
so that OEMs can use RSC Listener to launch custom boot option or application 
for recovering the failed hard drive.

This change will help to ensure that the allocated pool of memory for the 
failed boot option is freed before executing OEM's RSC listener callback to 
handle every boot option failure.

Signed-off-by: KrishnadasX Veliyathuparambil Prakashan 

Cc: "Gao, Zhichao" 
Cc: "Ni, Ray" 
---
 .../Library/UefiBootManagerLib/BmBoot.c   | 28 ++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 540d169ec1..aff620ad52 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2,7 +2,7 @@
   Library functions which relates with booting.
 
 Copyright (c) 2019, NVIDIA CORPORATION. All rights reserved.
-Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2020, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -1903,17 +1903,17 @@ EfiBootManagerBoot (
 gBS->UnloadImage (ImageHandle);
   }
   //
-  // Report Status Code with the failure status to indicate that the 
failure to load boot option
-  //
-  BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
-  BootOption->Status = Status;
-  //
   // Destroy the RAM disk
   //
   if (RamDiskDevicePath != NULL) {
 BmDestroyRamDisk (RamDiskDevicePath);
 FreePool (RamDiskDevicePath);
   }
+  //
+  // Report Status Code with the failure status to indicate that the 
failure to load boot option
+  //
+  BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
+  BootOption->Status = Status;
   return;
 }
   }
@@ -1982,13 +1982,6 @@ EfiBootManagerBoot (
   Status = gBS->StartImage (ImageHandle, >ExitDataSize, 
>ExitData);
   DEBUG ((DEBUG_INFO | DEBUG_LOAD, "Image Return Status = %r\n", Status));
   BootOption->Status = Status;
-  if (EFI_ERROR (Status)) {
-//
-// Report Status Code with the failure status to indicate that boot failure
-//
-BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status);
-  }
-  PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) OptionNumber);
 
   //
   // Destroy the RAM disk
@@ -1998,6 +1991,15 @@ EfiBootManagerBoot (
 FreePool (RamDiskDevicePath);
   }
 
+  if (EFI_ERROR (Status)) {
+//
+// Report Status Code with the failure status to indicate that boot failure
+//
+BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status);
+ }  PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) 
+ OptionNumber);
+
+
   //
   // Clear the Watchdog Timer after the image returns
   //
--
2.27.0.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61554): https://edk2.groups.io/g/devel/message/61554
Mute This Topic: https://groups.io/mt/74978785/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] Features/Intel/Debugging: Fix build error when use Xcode

2020-06-22 Thread Dong, Eric
Reviewed-by: Eric Dong 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Tan,
> Ming
> Sent: Monday, June 22, 2020 3:33 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Gao, Liming 
> Subject: [edk2-devel] [PATCH] Features/Intel/Debugging: Fix build error
> when use Xcode
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2822
> 
> When use Xcode, it will report following compile error:
>   duplicate symbol _mRscHandlerProtocol in:
> 
> So in the Features/Intel/Debugging/,
> change the global variable name in the following files
>   RuntimeDxeBeepStatusCodeHandlerLib.c
>   RuntimeDxePostCodeStatusCodeHandlerLib.c
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> Signed-off-by: Ming Tan 
> ---
>  .../RuntimeDxeBeepStatusCodeHandlerLib.c  | 20 +--
>  .../RuntimeDxePostCodeStatusCodeHandlerLib.c  | 20 +--
>  2 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git
> a/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCod
> eHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
> b/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCod
> eHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
> index 631e2eecae..0bdc3f4575 100644
> ---
> a/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCod
> eHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
> +++
> b/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCod
> eHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
> @@ -17,9 +17,9 @@
>  #include 
> 
>  #include 
> 
> 
> 
> -EFI_RSC_HANDLER_PROTOCOL  *mRscHandlerProtocol   = NULL;
> 
> -EFI_EVENT mExitBootServicesEvent = NULL;
> 
> -BOOLEAN   mRegistered= FALSE;
> 
> +EFI_RSC_HANDLER_PROTOCOL  *mBeepRscHandlerProtocol   = NULL;
> 
> +EFI_EVENT mBeepExitBootServicesEvent = NULL;
> 
> +BOOLEAN   mBeepRegistered= FALSE;
> 
> 
> 
>  /**
> 
>Convert status code value to the times of beep.
> 
> @@ -79,8 +79,8 @@ UnregisterBeepBootTimeHandlers (
>IN VOID *Context
> 
>)
> 
>  {
> 
> -  if (mRegistered) {
> 
> -mRscHandlerProtocol->Unregister (BeepStatusCodeReportWorker);
> 
> +  if (mBeepRegistered) {
> 
> +mBeepRscHandlerProtocol->Unregister (BeepStatusCodeReportWorker);
> 
>}
> 
>  }
> 
> 
> 
> @@ -105,13 +105,13 @@ RegisterBeepBootTimeHandlers (
>Status = gBS->LocateProtocol (
> 
>,
> 
>NULL,
> 
> -  (VOID **) 
> 
> +  (VOID **) 
> 
>);
> 
>ASSERT_EFI_ERROR (Status);
> 
> 
> 
> -  mRscHandlerProtocol->Register (BeepStatusCodeReportWorker,
> TPL_HIGH_LEVEL);
> 
> +  mBeepRscHandlerProtocol->Register (BeepStatusCodeReportWorker,
> TPL_HIGH_LEVEL);
> 
>ASSERT_EFI_ERROR (Status);
> 
> -  mRegistered = TRUE;
> 
> +  mBeepRegistered = TRUE;
> 
> 
> 
>Status = gBS->CreateEventEx (
> 
>EVT_NOTIFY_SIGNAL,
> 
> @@ -119,7 +119,7 @@ RegisterBeepBootTimeHandlers (
>UnregisterBeepBootTimeHandlers,
> 
>NULL,
> 
>,
> 
> -  
> 
> +  
> 
>);
> 
>ASSERT_EFI_ERROR (Status);
> 
>  }
> 
> @@ -154,7 +154,7 @@ RuntimeDxeBeepStatusCodeHandlerLibConstructor (
>Status = gBS->LocateProtocol (
> 
>,
> 
>NULL,
> 
> -  (VOID **) 
> 
> +  (VOID **) 
> 
>);
> 
> 
> 
>if (!EFI_ERROR (Status)) {
> 
> diff --git
> a/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeS
> tatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
> b/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeS
> tatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
> index 59b531fe7c..65fd555cc0 100644
> ---
> a/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeS
> tatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
> +++
> b/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeS
> tatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
> @@ -18,9 +18,9 @@
>  #include 
> 
>  #include 
> 
> 
> 
> -EFI_RSC_HANDLER_PROTOCOL  *mRscHandlerProtocol   = NULL;
> 
> -EFI_EVENT mExitBootServicesEvent = NULL;
> 
> -BOOLEAN   mRegisted  = FALSE;
> 
> +EFI_RSC_HANDLER_PROTOCOL  *mPostCodeRscHandlerProtocol   = NULL;
> 
> +EFI_EVENT mPostCodeExitBootServicesEvent = NULL;
> 
> +BOOLEAN   mPostCodeRegisted  = FALSE;
> 
> 
> 
>  /**
> 
>Convert status code value and write data to post code.
> 
> @@ -81,8 +81,8 @@ UnregisterPostCodeBootTimeHandlers (
>IN VOID *Context
> 
>)
> 
>  {
> 
> -  if (mRegisted) {
> 
> -mRscHandlerProtocol->Unregister (PostCodeStatusCodeReportWorker);
> 
> +  if 

[edk2-devel] [PATCH] Features/Intel/Debugging: Fix build error when use Xcode

2020-06-22 Thread Tan, Ming
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2822

When use Xcode, it will report following compile error:
  duplicate symbol _mRscHandlerProtocol in:

So in the Features/Intel/Debugging/,
change the global variable name in the following files
  RuntimeDxeBeepStatusCodeHandlerLib.c
  RuntimeDxePostCodeStatusCodeHandlerLib.c

Cc: Eric Dong 
Cc: Liming Gao 
Signed-off-by: Ming Tan 
---
 .../RuntimeDxeBeepStatusCodeHandlerLib.c  | 20 +--
 .../RuntimeDxePostCodeStatusCodeHandlerLib.c  | 20 +--
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git 
a/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCodeHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
 
b/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCodeHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
index 631e2eecae..0bdc3f4575 100644
--- 
a/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCodeHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
+++ 
b/Features/Intel/Debugging/BeepDebugFeaturePkg/Library/BeepStatusCodeHandlerLib/RuntimeDxeBeepStatusCodeHandlerLib.c
@@ -17,9 +17,9 @@
 #include 
 #include 
 
-EFI_RSC_HANDLER_PROTOCOL  *mRscHandlerProtocol   = NULL;
-EFI_EVENT mExitBootServicesEvent = NULL;
-BOOLEAN   mRegistered= FALSE;
+EFI_RSC_HANDLER_PROTOCOL  *mBeepRscHandlerProtocol   = NULL;
+EFI_EVENT mBeepExitBootServicesEvent = NULL;
+BOOLEAN   mBeepRegistered= FALSE;
 
 /**
   Convert status code value to the times of beep.
@@ -79,8 +79,8 @@ UnregisterBeepBootTimeHandlers (
   IN VOID *Context
   )
 {
-  if (mRegistered) {
-mRscHandlerProtocol->Unregister (BeepStatusCodeReportWorker);
+  if (mBeepRegistered) {
+mBeepRscHandlerProtocol->Unregister (BeepStatusCodeReportWorker);
   }
 }
 
@@ -105,13 +105,13 @@ RegisterBeepBootTimeHandlers (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  (VOID **) 
+  (VOID **) 
   );
   ASSERT_EFI_ERROR (Status);
 
-  mRscHandlerProtocol->Register (BeepStatusCodeReportWorker, TPL_HIGH_LEVEL);
+  mBeepRscHandlerProtocol->Register (BeepStatusCodeReportWorker, 
TPL_HIGH_LEVEL);
   ASSERT_EFI_ERROR (Status);
-  mRegistered = TRUE;
+  mBeepRegistered = TRUE;
 
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
@@ -119,7 +119,7 @@ RegisterBeepBootTimeHandlers (
   UnregisterBeepBootTimeHandlers,
   NULL,
   ,
-  
+  
   );
   ASSERT_EFI_ERROR (Status);
 }
@@ -154,7 +154,7 @@ RuntimeDxeBeepStatusCodeHandlerLibConstructor (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  (VOID **) 
+  (VOID **) 
   );
 
   if (!EFI_ERROR (Status)) {
diff --git 
a/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
 
b/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
index 59b531fe7c..65fd555cc0 100644
--- 
a/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
+++ 
b/Features/Intel/Debugging/PostCodeDebugFeaturePkg/Library/PostCodeStatusCodeHandlerLib/RuntimeDxePostCodeStatusCodeHandlerLib.c
@@ -18,9 +18,9 @@
 #include 
 #include 
 
-EFI_RSC_HANDLER_PROTOCOL  *mRscHandlerProtocol   = NULL;
-EFI_EVENT mExitBootServicesEvent = NULL;
-BOOLEAN   mRegisted  = FALSE;
+EFI_RSC_HANDLER_PROTOCOL  *mPostCodeRscHandlerProtocol   = NULL;
+EFI_EVENT mPostCodeExitBootServicesEvent = NULL;
+BOOLEAN   mPostCodeRegisted  = FALSE;
 
 /**
   Convert status code value and write data to post code.
@@ -81,8 +81,8 @@ UnregisterPostCodeBootTimeHandlers (
   IN VOID *Context
   )
 {
-  if (mRegisted) {
-mRscHandlerProtocol->Unregister (PostCodeStatusCodeReportWorker);
+  if (mPostCodeRegisted) {
+mPostCodeRscHandlerProtocol->Unregister (PostCodeStatusCodeReportWorker);
   }
 }
 
@@ -109,13 +109,13 @@ RegisterPostCodeBootTimeHandlers (
   Status = gBS->LocateProtocol (
   ,
   NULL,
-  (VOID **) 
+  (VOID **) 
   );
   ASSERT_EFI_ERROR (Status);
 
-  mRscHandlerProtocol->Register (PostCodeStatusCodeReportWorker, 
TPL_HIGH_LEVEL);
+  mPostCodeRscHandlerProtocol->Register (PostCodeStatusCodeReportWorker, 
TPL_HIGH_LEVEL);
   ASSERT_EFI_ERROR (Status);
-  mRegisted = TRUE;
+  mPostCodeRegisted = TRUE;
 
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
@@ -123,7 +123,7 @@ RegisterPostCodeBootTimeHandlers (
   

Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

2020-06-22 Thread Dandan Bi
Hi Brian,

Personally, I prefer to add the NULL class Library to StatusCodeHandler modules.

  1.  I think we should make the functionality of each module clear and 
separated. It may also be why we added ReportStatusCodeRouter and 
StatusCodeHandler modules in edk2 repo before.

ReportStatusCodeRouter modules are responsible for producing Status Code 
Protocol/PPI and Report Status Code Handler Protocol/PPI, and StatusCodeHandler 
modules are responsible for producing handlers (Handlers can be provided by 
NULL class Libraries in this RFC).

 So, that’s why I don’t want to add the NULL class Library to 
ReportStatusCodeRouter modules directly, which change the functionality scope 
of existing modules.



  1.  I agree that we have a lot of layers of indirection now, but what we may 
gain is the good modularity. And you also mentioned that one or more 
StatusCodeHandler Modules may be used. We also want to achieve that only the 
StatusCodeHandler modules in MdeModulePkg can be used after this separation, 
platform can only add its own handler Libs to meet its requirement.



  1.  As Andrew mentioned below, if add the libraries to 
ReportStatusCodeRouter, there will be some issue we need to fix, which seems 
also make the code logic a little tricky to me.



Thanks,
Dandan
From: Andrew Fish 
Sent: Saturday, June 20, 2020 2:04 AM
To: edk2-devel-groups-io ; brian.john...@hpe.com
Cc: Bi, Dandan ; r...@edk2.groups.io; Dong, Eric 
; Ni, Ray ; Wang, Jian J 
; Wu, Hao A ; Tan, Ming 

Subject: Re: [edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate 
NULL class libraries for Memory and serial handlers from 
MdeModulePkg/Universal/StatusCodeHandler modules




On Jun 19, 2020, at 10:29 AM, Brian J. Johnson 
mailto:brian.john...@hpe.com>> wrote:

On 6/18/20 2:01 AM, Dandan Bi wrote:
Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial 
handlers fromMdeModulePkg/Universal/StatusCodeHandler/…/ 
StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear 
and easy to maintain, 2) make platform flexible to choose any handler library 
they need, and it also can reduce image size since the unused handlers can be 
excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and 
SerialStatusCodeHandlerLib with different phase implementation into 
MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|--MemoryStausCodeHandlerLib
|--|-- PeiMemoryStausCodeHandlerLib.inf
|--|-- RuntimeDxeMemoryStatusCodeHandlerLib.inf
|--|-- SmmMemoryStausCodeHandlerLib.inf
|--SerialStatusCodeHandlerLib
|--|-- PeiSerialStatusCodeHandlerLib.inf
|--|-- RuntimeDxeSerialStatusCodeHandlerLib.inf
|--|-- SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to 
cover the new NULL class library to make sure this change doesn’t impact any 
platform.
After this separation, StatusCodeHandler module usage will like below, and it’s 
also very flexible for platform to cover more handler libraries to meet their 
requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
  
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
…
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
  {
  
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
…
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
  

NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
…
}


Thanks,
Dandan

Dandan,
We'll have a lot of layers of indirection  The ReportStatusCodeRouter 
modules will call one or more StatusCodeHandlerModules, and the standard 
StatusCodeHandler modules will call multiple StatusCodeHandlerLib libraries.
How about adding StatusCodeHandlerLib support directly to the 
ReportStatusCodeRouter modules?  Then platforms could omit the 
StatusCodeHandler modules if they're only using the open-source code.  That 
sounds like less overhead since fewer modules would be needed.


I think the need to execute from ROM makes this tricky.

It looks to me that it is easy to move from PCD to libs for the 
StatusCodeHandler since registration is basically `RscHandlerPpi->Register 
(SerialStatusCodeReportWorker);`. The issue I see is the ReportStatusCodeRouter 
publishes RscHandlerPpi after the PEIMs constructor