[edk2-devel] 回复: [Patch V2 0/3] Remove git reset and optimize

2021-11-23 Thread gaoliming
Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: Michael D Kinney 
> 发送时间: 2021年11月24日 0:31
> 收件人: devel@edk2.groups.io
> 抄送: Sean Brogan ; Bret Barkelew
> ; Liming Gao ;
> Michael Kubacki 
> 主题: [Patch V2 0/3] Remove git reset and optimize
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2986
> 
> New in V2
> --
> * Change temp directory path from Build/ecctemp to
>   Build/.pytool/Plugin/EccCheck to provide a unique
>   temp directory location for any .pytool Plugin.
> * Set working directory when ECC runs to temp directory
>   to guarantee all temp files created by EccCheck are
>   cleaned up.
> 
> * Use temp directory for all operations to prevent any
>   changed to git state.
> * Remove git reset operation that could corrupt staged
>   and local changes.
> * Improve performance by removing redundant directory scans
> * Improve performance and reduce log file sizes by using
>   --output option of git diff to a temp file instead of
>   using stdout.
> 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Liming Gao 
> Cc: Michael Kubacki 
> Signed-off-by: Michael D Kinney 
> 
> Michael D Kinney (3):
>   .pytool/Plugin/EccCheck: Remove RevertCode()
>   .pytool/Plugin/EccCheck: Remove temp directory on exception
>   .pytool/Plugin/EccCheck: Add performance optimizations
> 
>  .pytool/Plugin/EccCheck/EccCheck.py | 242 +++-
>  1 file changed, 169 insertions(+), 73 deletions(-)
> 
> --
> 2.32.0.windows.1







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




[edk2-devel] 回复: [Patch V2 1/1] .pytools/Plugin/LicenseCheck: Use temp directory for git diff output

2021-11-23 Thread gaoliming
Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: Michael D Kinney 
> 发送时间: 2021年11月24日 1:32
> 收件人: devel@edk2.groups.io
> 抄送: Sean Brogan ; Bret Barkelew
> ; Liming Gao ;
> Michael Kubacki 
> 主题: [Patch V2 1/1] .pytools/Plugin/LicenseCheck: Use temp directory for
git
> diff output
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3746
> 
> Use --output option in git diff command to remove code diffs
> from build log on stdout when LicenseCheck plugin is run.
> Instead, create a temp directory for the diff output file and
> remove the temp directory after the diff output is processed.
> 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Liming Gao 
> Cc: Michael Kubacki 
> Signed-off-by: Michael D Kinney 
> ---
>  .pytool/Plugin/LicenseCheck/LicenseCheck.py | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/.pytool/Plugin/LicenseCheck/LicenseCheck.py
> b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
> index 5733f7bf4ec0..7b998daf6f6b 100644
> --- a/.pytool/Plugin/LicenseCheck/LicenseCheck.py
> +++ b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
> @@ -5,6 +5,7 @@
>  ##
> 
>  import os
> +import shutil
>  import logging
>  import re
>  from io import StringIO
> @@ -61,12 +62,19 @@ class LicenseCheck(ICiBuildPlugin):
>  #   - Junit Logger
>  #   - output_stream the StringIO output stream from this plugin via
> logging
>  def RunBuildPlugin(self, packagename, Edk2pathObj, pkgconfig,
> environment, PLM, PLMHelper, tc, output_stream=None):
> -return_buffer = StringIO()
> -params = "diff --unified=0 origin/master HEAD"
> -RunCmd("git", params, outstream=return_buffer)
> -p = return_buffer.getvalue().strip()
> -patch = p.split("\n")
> -return_buffer.close()
> +# Create temp directory
> +temp_path = os.path.join(Edk2pathObj.WorkspacePath, 'Build',
> '.pytool', 'Plugin', 'LicenseCheck')
> +if not os.path.exists(temp_path):
> +os.makedirs(temp_path)
> +# Output file to use for git diff operations
> +temp_diff_output = os.path.join (temp_path, 'diff.txt')
> +params = "diff --output={} --unified=0 origin/master
> HEAD".format(temp_diff_output)
> +RunCmd("git", params)
> +with open(temp_diff_output) as file:
> +patch = file.read().strip().split("\n")
> +# Delete temp directory
> +if os.path.exists(temp_path):
> +shutil.rmtree(temp_path)
> 
>  ignore_files = []
>  if "IgnoreFiles" in pkgconfig:
> --
> 2.32.0.windows.1







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




回复: [edk2-devel] [Patch 1/1] EmulatorPkg/Win/Host: Update CC_FLAGS

2021-11-23 Thread gaoliming
Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Michael D
> Kinney
> 发送时间: 2021年11月24日 1:26
> 收件人: devel@edk2.groups.io
> 抄送: Andrew Fish ; Ray Ni ; Michael
> Kubacki 
> 主题: [edk2-devel] [Patch 1/1] EmulatorPkg/Win/Host: Update CC_FLAGS
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3747
> 
> * Remove deprecated option /Gm that generates a warning.
> * Remove /Zi and use '=' instead of '== to let DEBUG/RELEASE/NOOPT
>   profile from tools_def.txt enable debug information
> * Remove /Gs8192 option that is overriding the larger setting of
>   /GS32768 from tools_def.txt that generates a warning.
> 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Cc: Michael Kubacki 
> Signed-off-by: Michael D Kinney 
> ---
>  EmulatorPkg/Win/Host/WinHost.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/EmulatorPkg/Win/Host/WinHost.inf
> b/EmulatorPkg/Win/Host/WinHost.inf
> index 4d2ce19620a1..2030ac084702 100644
> --- a/EmulatorPkg/Win/Host/WinHost.inf
> +++ b/EmulatorPkg/Win/Host/WinHost.inf
> @@ -86,7 +86,7 @@ [Pcd]
> 
>  [BuildOptions]
>MSFT:*_*_*_DLINK_FLAGS==
> /out:"$(BIN_DIR)\$(BASE_NAME).exe" /base:0x1000
> /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
> -  MSFT:*_*_*_CC_FLAGS   == /nologo /W4 /WX /Gy /c /D
> UNICODE /Od /Oy- /FIAutoGen.h /EHs-c- /GF /Gs8192 /Zi /Gm /D
> _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE
> +  MSFT:*_*_*_CC_FLAGS= /nologo /W4 /WX /Gy /c /D
> UNICODE /Od /Oy- /FIAutoGen.h /EHs-c- /GF /D
> _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE
>MSFT:*_*_*_PP_FLAGS   == /nologo /E /TC /FIAutoGen.h
> 
>MSFT:*_VS2015_IA32_DLINK_FLAGS =
> /LIBPATH:"%VS2015_PREFIX%Lib" /LIBPATH:"%VS2015_PREFIX%VC\Lib"
> /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86"
> /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86"
> /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP
> /OPT:REF /DEBUG /MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib
> User32.lib Winmm.lib Advapi32.lib vcruntimed.lib ucrtd.lib
> --
> 2.32.0.windows.1
> 
> 
> 
> 
> 







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




回复: edk2-stable202111 Re: [edk2-devel] [PATCH] MdeModulePkg AtaAtapiPassThru: Skip the potential NULL pointer access

2021-11-23 Thread gaoliming
Leif:
  Thanks for your suggestion. I am OK to merge this patch into stable
tag20211.

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Leif Lindholm
> 发送时间: 2021年11月23日 21:19
> 收件人: Rebecca Cran ; gaolim...@byosoft.com.cn
> 抄送: devel@edk2.groups.io; Hao A Wu ; Ray Ni
> ; Andrew Fish ; Michael D Kinney
> 
> 主题: edk2-stable202111 Re: [edk2-devel] [PATCH] MdeModulePkg
> AtaAtapiPassThru: Skip the potential NULL pointer access
> 
> Since BZ3732 has been triggered by a standard build of a platform in
> edk2-platforms, I would request that this fix is brought into the
> upcoming stable tag.
> 
> SbsaQemu isn't a "real" platform, so I don't consider that in itself
> sufficient reason, but I feel the risk of it affecting other
> (including out-of-tree) platforms justifies it.
> 
> Best Regards,
> 
> Leif
> 
> On Tue, Nov 23, 2021 at 06:10:14 -0700, Rebecca Cran wrote:
> > Acked-by: Rebecca Cran 
> >
> >
> > I've confirmed that this patch fixes the exception I was seeing when
running
> > the DEBUG build of SbsaQemu.
> >
> >
> > --
> >
> > Rebecca Cran
> >
> >
> > On 11/15/21 7:53 PM, gaoliming wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3732
> > > Recent change c974257821208fc6191779d1ddea918499f165b8 exposes
> this potential issue.
> > >
> > > Signed-off-by: Liming Gao 
> > > Cc: Hao A Wu 
> > > Cc: Ray Ni 
> > > ---
> > >   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 7 +++
> > >   1 file changed, 7 insertions(+)
> > >
> > > diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> > > index 7626bac38d..bda900a161 100644
> > > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> > > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> > > @@ -885,6 +885,13 @@ AhciPrintStatusBlock (
> > > IN UINT32DebugLevel
> > > )
> > >   {
> > > +  //
> > > +  // Skip NULL pointer
> > > +  //
> > > +  if (AtaStatusBlock == NULL) {
> > > +return;
> > > +  }
> > > +
> > > //
> > > // Only print status and error since we have all of the rest
printed as
> > > // a part of command block print.
> 
> 
> 
> 





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




Re: [edk2-devel] [Patch 09/12] ShellPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Gao, Zhichao
Acked-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, November 24, 2021 5:21 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Gao, Zhichao ; Sean
> Brogan ; Bret Barkelew
> ; Liming Gao ;
> Michael Kubacki 
> Subject: [Patch 09/12] ShellPkg: Update YAML to ignore specific ECC
> files/errors
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749
> 
> Update package YAML files to ignore ECC errors that are already present.
> These issues must be fixed in the future, but should not block source code
> changes for these known issues.
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Liming Gao 
> Cc: Michael Kubacki 
> Signed-off-by: Michael D Kinney 
> ---
>  ShellPkg/ShellPkg.ci.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ShellPkg/ShellPkg.ci.yaml b/ShellPkg/ShellPkg.ci.yaml index
> 30894d44bc3a..e741402459e5 100644
> --- a/ShellPkg/ShellPkg.ci.yaml
> +++ b/ShellPkg/ShellPkg.ci.yaml
> @@ -15,6 +15,7 @@
>  ## "", ""
>  ## ]
>  "ExceptionList": [
> +"8001", "ShellCommandLineParse"
>  ],
>  ## Both file path and directory path are accepted.
>  "IgnoreFiles": [
> --
> 2.32.0.windows.1



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




[edk2-devel] Uncrustify Conversion Detailed Plan and Extended Hard Freeze

2021-11-23 Thread Michael D Kinney
Hello,

Michael Kubacki and I have prepared the patches required to apply the 
uncrustify changes and enable EDK II CI to check all submitted
patches have been run through uncrustify.

There are a couple minor updates expected over the next day.
New versions of this email will be sent with the latest links and
updates based on feedback from the community. 

We have verified through the CompareBuild GitHub Action that the
format changes performed by uncrustify have no functional changes.
All of the OBJ, LIB, DLL, EFI, FFS, FV, and FD files match 100%
across 70 VS2019/GCC5 builds of all package/platform DSC files in
the edk2 repo.

The hard freeze will be extended after the edk2-stable202111 tag until
all uncrustify related changes are committed.  We do not expect this 
to take more than a few days.  Do not push any PRs until the hard 
freeze is lifted.

The changes are broken up into 7 patch series/PRs.  The PRs are ordered
so they can be submitted using the normal submission process and EDK II
CI will pass for each one.  Details are listed below.

Uncrustify 73.0.3 for EDK II
=
* Sources: https://dev.azure.com/projectmu/_git/Uncrustify
* Documentation: 
https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme
* Download: 
https://dev.azure.com/projectmu/Uncrustify/_packaging?_a=package&feed=mu_uncrustify&package=mu-uncrustify-release&protocolType=NuGet&version=73.0.3

Installing Uncrustify
==
The Uncrustify tool is installed automatically when the Pytools
environment is used and the stuart* commands are run to complete the
environment setup.  Please see:

https://github.com/tianocore/edk2/tree/master/.pytool#running-ci-locally

Uncrustify can also be installed from the download page listed above 
or built from sources from the source link above.

The Documentation link provides instruction on how to run uncrustify from 
the command line or install as a Visual Studio Code plugin.  The main
uncrustify documentation also describes how to integrate with a few other
editors.

We have also discussed a client side githook.  That effort has not started.
Let us know if that is a feature you would find useful.

Developer impact for new code reviews
==
Once the uncrustify checker is active in EDK II CI, developers must 
make sure their patches are run through the uncrustify tool before 
sending the patches for review.

Developers must install and run uncrustify against changes files before 
sending patch review emails or submitting PR for EDK II CI.  If EDK II CI
detects and differences in soure formatting, then EDK II CI will fail
and the developer must run uncrustify and resubmit the patches.

Developer impact to patch series/PRs reviewed during edk2-stable201121 
soft/hard freeze
===
Developers must rebase their changes after the uncrustify source changes are
committed.  The branch with a preview of the uncrustify changes can be used
to start this rebase work.


https://github.com/mdkinney/edk2/tree/Bug_3737_3739_ApplyUncrustifyChanges_V5

Impacts to tracing history across the uncrusity changes
===
<>
<>

Order of PRs to apply during extended hard freeze
==
1) Update EmulatorPkg Win Host [BuildOptions] MSFT CC_FLAGS to not force debug 
information
   * https://bugzilla.tianocore.org/show_bug.cgi?id=3747
   * 
https://github.com/mdkinney/edk2/tree/Bug_3747_EmulatorPkg_WinHost_ReproducibleBuild
   * https://github.com/tianocore/edk2/pull/2215
   * Required for EmulatorPkg to pass CompareBuild for VS2019 IA32/X64 builds.

2) EccCheck should not revert staged and local changes
   * https://bugzilla.tianocore.org/show_bug.cgi?id=2986
   * https://github.com/mdkinney/edk2/tree/Bug_2986_EccCheckRemoveGitRevert_V2
   * https://github.com/tianocore/edk2/pull/2216
   * Required for EDK II CI to complete in a reasonable period of time when
 processing the 4000+ source file style changes made by uncrustify.
   * Also fixes critical bugs that can potentially corrupt git state when 
 EccCheck is run locally.

3) Update pytool LicenseCheck plugin to use temp directory for diff output file
   * https://bugzilla.tianocore.org/show_bug.cgi?id=3746
   * 
https://github.com/mdkinney/edk2/tree/Bug_3746_LicenseCheckUseDiffOutputFile_V2
   * https://github.com/tianocore/edk2/pull/2217
   * Required to reduce EDK II CI build times.

4) Update Package YAML to ignore specific ECC files/errors
   * https://bugzilla.tianocore.org/show_bug.cgi?id=3749
   * https://github.com/mdkinney/edk2/tree/Bug_3749_EccCheckIgnoreFilesErrors
   * https://github.com/tianocore/edk2/pull/2218
   * Required to pass EccCheck

5) Update max job time from 60 min to 120 minutes in .azurepipelines/templates
   * https://bugzilla.tianocore.

Re: [edk2-devel] [PATCH v3 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki
I just realized that I changed the plugin name in the patch but did not 
update the commit subject. Since I'm already planning to send a v4, I 
will update it to ".pytool/Plugin/UncrustifyCheck: Add Uncrustify CI 
plugin" at that time.


Thanks,
Michael

On 11/23/2021 10:38 PM, Michael Kubacki wrote:

From: Michael Kubacki 

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

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application host in this repository:

https://dev.azure.com/projectmu/Uncrustify/

Note that the Uncrustify application outputs the commit ID that the
application was built from when given the --version parameter.

This ID can be mapped to the version specified in the Uncrustify CI
plugin external dependency file (uncrustify_ext_dep.yaml) such as
73.0.3 by visiting the Uncrustify edk2 fork release pipeline page
which associates the NuGet package version with the commit ID it was
built from:

https://dev.azure.com/projectmu/Uncrustify/_build

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V4 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---

Notes:
 V3 changes:
 
 1. Renamed the CI plugin to "UncrustifyCheck" from "Uncrustify"

to follow similar naming conventions used in other plugins
that check files
 2. Added a clarifying paragraph to the beginning of the Uncrustify
CI plugin Readme.md file that the plugin is enabled by default
and test results can be ignored by enabling "AuditOnly" mode.
 3. Added instructions in the commit message on how to map the
version reported by the Uncrustify application (--version) to
the version specified in the CI plugin external dependency
YAML file.
 
 V2 changes:
 
 1. Changed plugin temp directory to Build/.pytool/Plugin/Uncrustify

 2. Added TCBZ REF in patch commit message

  .pytool/Plugin/Uncrustify/Readme.md   | 120 +
  .pytool/Plugin/Uncrustify/UncrustifyCheck.py  | 555 

  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  11 +
  .pytool/Readme.md |   4 +
  8 files changed, 1196 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..bb263bcc87d7
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,120 @@
+# UncrustifyCheck Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin is enabled by default. If a package would like to prevent the 
plugin from reporting errors, it can do
+so by enabling [`AuditOnly`](#auditonly) mode.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncrustify/uncrustify
+* Project Mu Uncrustify fork source code and documentation: 
https://dev.azure.com/projectmu/Uncrustify
+
+## Files Checked in a Package
+
+By default, this plugin will discover all files in the package with the 
following default paths:
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+From this list of files, any files ignored by Git or residing in a Git 
submodule will be removed. If Git is not
+found, submodules are not found, or ignored files are not found no changes are 
made to the list of discovered files.
+
+To control the paths checked in a given package, review the configuration 
options described in this file.
+
+## Configuration
+
+The plugin can be configured with a few op

[edk2-devel] [PATCH v3 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki
From: Michael Kubacki 

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

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application host in this repository:

https://dev.azure.com/projectmu/Uncrustify/

Note that the Uncrustify application outputs the commit ID that the
application was built from when given the --version parameter.

This ID can be mapped to the version specified in the Uncrustify CI
plugin external dependency file (uncrustify_ext_dep.yaml) such as
73.0.3 by visiting the Uncrustify edk2 fork release pipeline page
which associates the NuGet package version with the commit ID it was
built from:

https://dev.azure.com/projectmu/Uncrustify/_build

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V4 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---

Notes:
V3 changes:

1. Renamed the CI plugin to "UncrustifyCheck" from "Uncrustify"
   to follow similar naming conventions used in other plugins
   that check files
2. Added a clarifying paragraph to the beginning of the Uncrustify
   CI plugin Readme.md file that the plugin is enabled by default
   and test results can be ignored by enabling "AuditOnly" mode.
3. Added instructions in the commit message on how to map the
   version reported by the Uncrustify application (--version) to
   the version specified in the CI plugin external dependency
   YAML file.

V2 changes:

1. Changed plugin temp directory to Build/.pytool/Plugin/Uncrustify
2. Added TCBZ REF in patch commit message

 .pytool/Plugin/Uncrustify/Readme.md   | 120 +
 .pytool/Plugin/Uncrustify/UncrustifyCheck.py  | 555 

 .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
 .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
 .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
 .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
 .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  11 +
 .pytool/Readme.md |   4 +
 8 files changed, 1196 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..bb263bcc87d7
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,120 @@
+# UncrustifyCheck Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin is enabled by default. If a package would like to prevent the 
plugin from reporting errors, it can do
+so by enabling [`AuditOnly`](#auditonly) mode.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncrustify/uncrustify
+* Project Mu Uncrustify fork source code and documentation: 
https://dev.azure.com/projectmu/Uncrustify
+
+## Files Checked in a Package
+
+By default, this plugin will discover all files in the package with the 
following default paths:
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+From this list of files, any files ignored by Git or residing in a Git 
submodule will be removed. If Git is not
+found, submodules are not found, or ignored files are not found no changes are 
made to the list of discovered files.
+
+To control the paths checked in a given package, review the configuration 
options described in this file.
+
+## Configuration
+
+The plugin can be configured with a few optional configuration options.
+
+``` yaml
+  "UncrustifyCheck": {
+  "AdditionalIncludePaths": [], # Additional paths to check formatting 
(wildcards supported).
+  "AuditOnly": False,   # Don't fail the build if there are 
errors.  Just log them.
+  "ConfigFilePath": "", # Custom path to an Uncrustify

Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread Yao, Jiewen
My apology - fix typo: objection on the discussion => objective on the 
discussion.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Wednesday, November 24, 2021 11:16 AM
> To: j...@linux.ibm.com; devel@edk2.groups.io
> Cc: Gerd Hoffmann ; Xu, Min M ;
> Ard Biesheuvel ; Justen, Jordan L
> ; Brijesh Singh ; Erdem
> Aktas ; Tom Lendacky 
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
> 
> I think we are discussing under different context.
> 
> First, the term "isolation" shall be clarified.
> In my context, "isolation" means two domain cannot impact each other.
> The isolation is enforced by a 3rd higher privileged component. Examples: 
> Ring3
> apps are isolated by OS. TDs are isolated by TDX Module. That is why I say: 
> there
> is no isolation.
> 
> In your context, if one domain jumps to another domain and never jump back,
> then you call it "isolation".
> 
> 
> Second, in EDKII, we have similar concept - we call trust region (TR):
> 1) Recovery Trust Region (PEI)
> 2) Main Trust Region (DXE-before EndOfDxe)
> 3) MM Trust Region (SMM)
> 4) Boot Trust Region (DXE w/o CSM-after EndOfDxe)
> 5) Legacy Trust Region (DXE with CSM-after EndOfDxe)
> 6) OS Trust Region (OS Boot)
> 
> We use term "transition" to describe the domain jump. We don’t use term
> "isolation".
> We use "isolation" where two co-existed RT cannot tamper each other. For
> example, MM trust region and Boot Trust Region are isolated.
> Actually, the only isolation example we have in BIOS is x86 SMM or ARM
> TrustZone.
> 
> We have below security assumption:
> 1) What can be trusted? The later launched TR can trust the earlier TR. Here
> "trust" means "use data input without validation"
> For example:
> 1.1) Main TR can trust the input from Recovery TR.
> 1.2) MM RT can trust the input from Main TR.
> 
> 2) What cannot be trusted? Here "not trust" means "validate data input before
> use "
> For example:
> 2.1) MM RT cannot trust the input from Boot TR.
> 2.2) Recovery RT cannot trust the input from Boot TR.
> 
> However, TR just means a region definition to help us do security analysis.
> It is NOT related to any security exposure, severity, or exploitability.
> There is no conclusion that a bug in PEI is more or less exploitable than DXE 
> or
> SMM.
> 
> 
> Here, I have comment for the sentence below:
> 
> 1. " the PEI domain has very limited exposure, it's the DXE domain that has 
> full
> exposure "
> [Jiewen] I don’t understand how that is concluded, on " limited exposure ", " 
> full
> exposure ".
> 
> 2. "bugs in PEI code can't be used to exploit the system when it has 
> transitioned
> to the DXE domain."
> [Jiewen] I disagree. A bug in PEI code may already modify the HOB, while the
> HOB is an architecture data input for DXE.
> If DXE relies on some malicious data from PEI, DXE might be exploited later.
> 
> 3. " but it does mean that there are fewer exploitability classes in PEI than 
> DXE
> because the security domain is much less exposed."
> [Jiewen] I don’t understand how that is concluded, on  "fewer", "less".
> In history, there are security bugs in PEI and there are security bugs in 
> DXE. I
> won't say fewer or less.
> Also because we use *LOCK* mechanism, and some LOCKs are enforced in PEI
> phase.
> A bug in PEI might be more severe than a bug in DXE.
> 
> 
> 
> Hi James
> Sorry, I am a little lost now.
> To be honest, I am not sure what is objective on the discussion.
> Are you question the general threat model analysis on UEFI PI architecture?
> Or are you trying to persuade me we should include PEI in TDVF, because you
> think it is safer to add code in PEI ?
> Or something else?
> 
> Please enlighten me that.
> 
> 
> Thank you
> Yao, Jiewen
> 
> 
> > -Original Message-
> > From: James Bottomley 
> > Sent: Tuesday, November 23, 2021 11:38 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Gerd Hoffmann ; Xu, Min M ;
> > Ard Biesheuvel ; Justen, Jordan L
> > ; Brijesh Singh ; Erdem
> > Aktas ; Tom Lendacky
> 
> > Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm
> to
> > support Tdx
> >
> > On Tue, 2021-11-23 at 15:10 +, Yao, Jiewen wrote:
> > > I would say the PEI owns the system and all memory (including the
> > > DXE).
> > >
> > > A bug in PEI may override the loaded DXE memory or the whole system.
> >
> > That's not the correct way to analyse the security properties.  From
> > the security point of view this is a trapdoor system: once you go
> > through the door, you can't go back (the trapdoor being the jump from
> > PEI to DXE).  The trapdoor isolates the domains and allows you to
> > analyse the security properties of each separately.  It also allows
> > separation of exposure ... which is what we use in this case: the PEI
> > domain has very limited exposure, it's the DXE domain that has full
> > exposure but, because of the trapdoor, bugs in PEI code can't be used
> > to exploit the sys

[edk2-devel] [PATCH] uefi-sct/SctPkg:Enhance BBTestReadKeyStrokeExFunctionAutoTestCheckpoint1()

2021-11-23 Thread Gao Jie
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2386

Enhance BBTestReadKeyStrokeExFunctionAutoTestCheckpoint1()
to handle ReadKeyStrokeEx implementation which returns EFI_NOT_READY
but without touching KeyToggleState.

Signed-off-by: Barton Gao 
---
 .../BlackBoxTest/SimpleTextInputExBBTestFunction.c| 11 ++-
 .../BlackBoxTest/SimpleTextInputExBBTestFunction.c| 11 ++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
index 0398bc26..c1669959 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
@@ -1160,6 +1160,12 @@ BBTestReadKeyStrokeExFunctionAutoTestCheckpoint1 (
   ValidState[5] = EFI_TOGGLE_STATE_VALID | EFI_KEY_STATE_EXPOSED | 
EFI_NUM_LOCK_ACTIVE | EFI_CAPS_LOCK_ACTIVE;
   ValidState[6] = EFI_TOGGLE_STATE_VALID | EFI_KEY_STATE_EXPOSED | 
EFI_SCROLL_LOCK_ACTIVE |EFI_NUM_LOCK_ACTIVE | EFI_CAPS_LOCK_ACTIVE;
 
+  //
+  // Set all bits to one (invalid values) for both KeyShiftState and 
KeyToggleState
+  //
+  Key.KeyState.KeyShiftState = 0x;
+  Key.KeyState.KeyToggleState = 0xFF;
+
   //
   //Read next keystroke from the input device
   //
@@ -1171,7 +1177,10 @@ BBTestReadKeyStrokeExFunctionAutoTestCheckpoint1 (
 return Status;
   }
 
-  if ((Key.KeyState.KeyToggleState & EFI_TOGGLE_STATE_VALID) == 0) {
+  if (((Key.KeyState.KeyToggleState & EFI_TOGGLE_STATE_VALID) == 0) || 
(Key.KeyState.KeyShiftState == 0x) || (Key.KeyState.KeyToggleState == 
0xFF)) {
+//
+// Log the error here and return key states are not supported when high 
order bit of KeyToggleState is 0 or KeyState not touched
+//
 return EFI_UNSUPPORTED;
   }
 
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
index adbf3dcf..e20ed345 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestFunction.c
@@ -1160,6 +1160,12 @@ BBTestReadKeyStrokeExFunctionAutoTestCheckpoint1 (
   ValidState[5] = EFI_TOGGLE_STATE_VALID | EFI_KEY_STATE_EXPOSED | 
EFI_NUM_LOCK_ACTIVE | EFI_CAPS_LOCK_ACTIVE;
   ValidState[6] = EFI_TOGGLE_STATE_VALID | EFI_KEY_STATE_EXPOSED | 
EFI_SCROLL_LOCK_ACTIVE |EFI_NUM_LOCK_ACTIVE | EFI_CAPS_LOCK_ACTIVE;
 
+  //
+  // Set all bits to one (invalid values) for both KeyShiftState and 
KeyToggleState
+  //
+  Key.KeyState.KeyShiftState = 0x;
+  Key.KeyState.KeyToggleState = 0xFF;
+
   //
   //Read next keystroke from the input device
   //
@@ -1171,7 +1177,10 @@ BBTestReadKeyStrokeExFunctionAutoTestCheckpoint1 (
 return Status;
   }
 
-  if ((Key.KeyState.KeyToggleState & EFI_TOGGLE_STATE_VALID) == 0) {
+  if (((Key.KeyState.KeyToggleState & EFI_TOGGLE_STATE_VALID) == 0) || 
(Key.KeyState.KeyShiftState == 0x) || (Key.KeyState.KeyToggleState == 
0xFF)) {
+//
+// Log the error here and return key states are not supported when high 
order bit of KeyToggleState is 0 or KeyState not touched
+//
 return EFI_UNSUPPORTED;
   }
 
-- 
2.31.0.windows.1




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




Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread Yao, Jiewen
I think we are discussing under different context.

First, the term "isolation" shall be clarified.
In my context, "isolation" means two domain cannot impact each other.
The isolation is enforced by a 3rd higher privileged component. Examples: Ring3 
apps are isolated by OS. TDs are isolated by TDX Module. That is why I say: 
there is no isolation.

In your context, if one domain jumps to another domain and never jump back, 
then you call it "isolation".


Second, in EDKII, we have similar concept - we call trust region (TR):
1) Recovery Trust Region (PEI)
2) Main Trust Region (DXE-before EndOfDxe)
3) MM Trust Region (SMM)
4) Boot Trust Region (DXE w/o CSM-after EndOfDxe)
5) Legacy Trust Region (DXE with CSM-after EndOfDxe)
6) OS Trust Region (OS Boot)

We use term "transition" to describe the domain jump. We don’t use term 
"isolation".
We use "isolation" where two co-existed RT cannot tamper each other. For 
example, MM trust region and Boot Trust Region are isolated.
Actually, the only isolation example we have in BIOS is x86 SMM or ARM 
TrustZone.

We have below security assumption:
1) What can be trusted? The later launched TR can trust the earlier TR. Here 
"trust" means "use data input without validation"
For example:
1.1) Main TR can trust the input from Recovery TR.
1.2) MM RT can trust the input from Main TR.

2) What cannot be trusted? Here "not trust" means "validate data input before 
use "
For example:
2.1) MM RT cannot trust the input from Boot TR.
2.2) Recovery RT cannot trust the input from Boot TR.

However, TR just means a region definition to help us do security analysis.
It is NOT related to any security exposure, severity, or exploitability. 
There is no conclusion that a bug in PEI is more or less exploitable than DXE 
or SMM.


Here, I have comment for the sentence below:

1. " the PEI domain has very limited exposure, it's the DXE domain that has 
full exposure "
[Jiewen] I don’t understand how that is concluded, on " limited exposure ", " 
full exposure ". 

2. "bugs in PEI code can't be used to exploit the system when it has 
transitioned to the DXE domain."
[Jiewen] I disagree. A bug in PEI code may already modify the HOB, while the 
HOB is an architecture data input for DXE.
If DXE relies on some malicious data from PEI, DXE might be exploited later.

3. " but it does mean that there are fewer exploitability classes in PEI than 
DXE because the security domain is much less exposed."
[Jiewen] I don’t understand how that is concluded, on  "fewer", "less".
In history, there are security bugs in PEI and there are security bugs in DXE. 
I won't say fewer or less.
Also because we use *LOCK* mechanism, and some LOCKs are enforced in PEI phase.
A bug in PEI might be more severe than a bug in DXE.



Hi James
Sorry, I am a little lost now.
To be honest, I am not sure what is objection on the discussion.
Are you question the general threat model analysis on UEFI PI architecture?
Or are you trying to persuade me we should include PEI in TDVF, because you 
think it is safer to add code in PEI ?
Or something else?

Please enlighten me that.


Thank you
Yao, Jiewen


> -Original Message-
> From: James Bottomley 
> Sent: Tuesday, November 23, 2021 11:38 PM
> To: devel@edk2.groups.io; Yao, Jiewen 
> Cc: Gerd Hoffmann ; Xu, Min M ;
> Ard Biesheuvel ; Justen, Jordan L
> ; Brijesh Singh ; Erdem
> Aktas ; Tom Lendacky 
> Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to
> support Tdx
> 
> On Tue, 2021-11-23 at 15:10 +, Yao, Jiewen wrote:
> > I would say the PEI owns the system and all memory (including the
> > DXE).
> >
> > A bug in PEI may override the loaded DXE memory or the whole system.
> 
> That's not the correct way to analyse the security properties.  From
> the security point of view this is a trapdoor system: once you go
> through the door, you can't go back (the trapdoor being the jump from
> PEI to DXE).  The trapdoor isolates the domains and allows you to
> analyse the security properties of each separately.  It also allows
> separation of exposure ... which is what we use in this case: the PEI
> domain has very limited exposure, it's the DXE domain that has full
> exposure but, because of the trapdoor, bugs in PEI code can't be used
> to exploit the system when it has transitioned to the DXE domain.
> 
> > In history I did see PEI security issues.
> > Some security issue in PEI caused system compromised completely. You
> > even have no chance to run DXE.
> 
> The security domain analysis above doesn't mean no bug in PEI is ever
> exploitable but it does mean that there are fewer exploitability
> classes in PEI than DXE because the security domain is much less
> exposed.
> 
> James
> 



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

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - 11/23/2021 #cal-reminder

2021-11-23 Thread devel@edk2.groups.io Calendar
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1238680 
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20211124T021501Z
ORGANIZER;CN=Liming Gao:mailto:gaolim...@byosoft.com.cn
DTSTART:20211124T023000Z
DTEND:20211124T033000Z
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\
 n
 \n\nMicrosoft Teams meeting\n\n*Join on your computer or mobile a
 pp*\n\nClick here to join the meeting ( https://teams.microsoft.com/l/mee
 tup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40
 thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255
 d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d )\n\n*Jo
 in with a video conferencing device*\n\nte...@conf.intel.com\n\nVideo Con
 ference ID: 116 062 094 0\n\nAlternate VTC dialing instructions ( https:/
 /conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=te
 st_call )\n\n*Or call in (audio only)*\n\n+1 916-245-6934\,\,77463821# ( 
 tel:+19162456934\,\,77463821# ) United States\, Sacramento\n\nPhone Confe
 rence ID: 774 638 21#\n\nFind a local number ( https://dialin.teams.micro
 soft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN (
  https://mysettings.lync.com/pstnconferencing )\n\nLearn More ( https://a
 ka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/
 meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId
 =46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDh
 lNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US )
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2N
 jgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-
 1218-4db3-bfc9-3d4c5aa7669e%22%7d
SEQUENCE:1
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics


Re: [edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max pipeline job time to 2 hours

2021-11-23 Thread Michael Kubacki

Reviewed-by: Michael Kubacki 

On 11/23/2021 7:44 PM, Michael D Kinney wrote:

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

Large patches that modify a large number of files(e.g uncrustify)
take longer to process through CI checks such as ECC.  Increase
the max job time from 1 hour to 2 hours to accommodate larger patch
series.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
  .azurepipelines/templates/pr-gate-build-job.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index d5b16c127f58..244cffdbfaba 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -17,7 +17,7 @@ parameters:
  jobs:
  
  - job: Build_${{ parameters.tool_chain_tag }}

-
+  timeoutInMinutes: 120
#Use matrix to speed up the build process
strategy:
  matrix:




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




Re: [edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max pipeline job time to 2 hours

2021-11-23 Thread Michael Kubacki
I wouldn't expect it to extend past 1 hour that often either. An 
occasional audit sounds good though.


Do you think a BZ could be filed to track the ECC optimization work? I 
didn't see anything obvious with a quick search.


Thanks,
Michael

On 11/23/2021 7:54 PM, Kinney, Michael D wrote:

Hi Michael,

I would like to see some optimization work applied to the ECC tool to see if
we can reduce the time that tool requires.  If we find some easy improvements
that allow larger patch series to complete in 60 minutes, then I am in favor
of reducing back down to 60 minutes.

Unless we actually see jobs running more than 60 minutes or hitting the 120
minute timeout, I do not see this patch causing problems.  We can do an audit
of PRs once is a while to see what the job execution times are.

If we do want to reduce, it will have to be a separate patch after uncrustify
set of PRs is applied.

Mike


-Original Message-
From: Michael Kubacki 
Sent: Tuesday, November 23, 2021 4:49 PM
To: devel@edk2.groups.io; Kinney, Michael D 
Cc: Sean Brogan ; Bret Barkelew 
; Liming Gao
; Michael Kubacki 
Subject: Re: [edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max 
pipeline job time to 2 hours

Hi Mike,

Is the plan to keep it at a 2 hour limit indefinitely (not just for
these large series currently outstanding)?

Thanks,
Michael

On 11/23/2021 7:44 PM, Michael D Kinney wrote:

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

Large patches that modify a large number of files(e.g uncrustify)
take longer to process through CI checks such as ECC.  Increase
the max job time from 1 hour to 2 hours to accommodate larger patch
series.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
   .azurepipelines/templates/pr-gate-build-job.yml | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index d5b16c127f58..244cffdbfaba 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -17,7 +17,7 @@ parameters:
   jobs:

   - job: Build_${{ parameters.tool_chain_tag }}
-
+  timeoutInMinutes: 120
 #Use matrix to speed up the build process
 strategy:
   matrix:




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




Re: [edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max pipeline job time to 2 hours

2021-11-23 Thread Michael D Kinney
Hi Michael,

I would like to see some optimization work applied to the ECC tool to see if
we can reduce the time that tool requires.  If we find some easy improvements
that allow larger patch series to complete in 60 minutes, then I am in favor
of reducing back down to 60 minutes.

Unless we actually see jobs running more than 60 minutes or hitting the 120
minute timeout, I do not see this patch causing problems.  We can do an audit
of PRs once is a while to see what the job execution times are.

If we do want to reduce, it will have to be a separate patch after uncrustify
set of PRs is applied.

Mike

> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, November 23, 2021 4:49 PM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Sean Brogan ; Bret Barkelew 
> ; Liming Gao
> ; Michael Kubacki 
> Subject: Re: [edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max 
> pipeline job time to 2 hours
> 
> Hi Mike,
> 
> Is the plan to keep it at a 2 hour limit indefinitely (not just for
> these large series currently outstanding)?
> 
> Thanks,
> Michael
> 
> On 11/23/2021 7:44 PM, Michael D Kinney wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3750
> >
> > Large patches that modify a large number of files(e.g uncrustify)
> > take longer to process through CI checks such as ECC.  Increase
> > the max job time from 1 hour to 2 hours to accommodate larger patch
> > series.
> >
> > Cc: Sean Brogan 
> > Cc: Bret Barkelew 
> > Cc: Liming Gao 
> > Cc: Michael Kubacki 
> > Signed-off-by: Michael D Kinney 
> > ---
> >   .azurepipelines/templates/pr-gate-build-job.yml | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
> > b/.azurepipelines/templates/pr-gate-build-job.yml
> > index d5b16c127f58..244cffdbfaba 100644
> > --- a/.azurepipelines/templates/pr-gate-build-job.yml
> > +++ b/.azurepipelines/templates/pr-gate-build-job.yml
> > @@ -17,7 +17,7 @@ parameters:
> >   jobs:
> >
> >   - job: Build_${{ parameters.tool_chain_tag }}
> > -
> > +  timeoutInMinutes: 120
> > #Use matrix to speed up the build process
> > strategy:
> >   matrix:
> >


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




Re: [edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max pipeline job time to 2 hours

2021-11-23 Thread Michael Kubacki

Hi Mike,

Is the plan to keep it at a 2 hour limit indefinitely (not just for 
these large series currently outstanding)?


Thanks,
Michael

On 11/23/2021 7:44 PM, Michael D Kinney wrote:

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

Large patches that modify a large number of files(e.g uncrustify)
take longer to process through CI checks such as ECC.  Increase
the max job time from 1 hour to 2 hours to accommodate larger patch
series.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
  .azurepipelines/templates/pr-gate-build-job.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index d5b16c127f58..244cffdbfaba 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -17,7 +17,7 @@ parameters:
  jobs:
  
  - job: Build_${{ parameters.tool_chain_tag }}

-
+  timeoutInMinutes: 120
#Use matrix to speed up the build process
strategy:
  matrix:




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




[edk2-devel] [Patch 1/1] .azurepipelines/templates: Update max pipeline job time to 2 hours

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3750

Large patches that modify a large number of files(e.g uncrustify)
take longer to process through CI checks such as ECC.  Increase
the max job time from 1 hour to 2 hours to accommodate larger patch
series.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .azurepipelines/templates/pr-gate-build-job.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index d5b16c127f58..244cffdbfaba 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -17,7 +17,7 @@ parameters:
 jobs:
 
 - job: Build_${{ parameters.tool_chain_tag }}
-
+  timeoutInMinutes: 120
   #Use matrix to speed up the build process
   strategy:
 matrix:
-- 
2.32.0.windows.1



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




Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki

Sounds good. I'll include that in v3.

On 11/23/2021 6:53 PM, Kinney, Michael D wrote:

Hi Michael,

Thanks for the clarification.

It would be good to make it clear that UncrustifyCheck is by default enabled
for all packages and that the only way to disabled it is to add that section
to the package YAML files and set AuditOnly to True.

Probably best to add this clarification at the top of the Readme.md in
the .pytool/Plugin/UncrustifyCheck directory.

Thanks,

Mike


-Original Message-
From: Michael Kubacki 
Sent: Tuesday, November 23, 2021 3:17 PM
To: Kinney, Michael D ; devel@edk2.groups.io
Cc: Liming Gao ; Sean Brogan 
; Bret Barkelew

Subject: Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add 
Uncrustify plugin

Hi Mike,

I'm fine with changing the CI plugin name to "UncrustifyCheck". It does
only check files. I will make this change in a V3.

That section does not need to be present. It is just giving an example
of how to add the section and how to set the various config options
available.

Thanks,
Michael

On 11/23/2021 4:51 PM, Kinney, Michael D wrote:

Hi Michael,

In order to match some of the other naming conventions of plugins, should
this plugin be called "UncrustifyCheck".  It only checks if the sources
match the expected format.  It does not actually change the format of
any source files when either run locally or by EDK II CI.  Right?

Also, does the following section need to be added to every package YAML
file in the edk2 repository in order for the Uncrusitfy plugin to
be run by EDK II CI?  If so, should those YAML file updates be part
of this patch series or a different patch series?


+``` yaml
+  "Uncrustify": {
+  "AuditOnly": False,   # Don't fail the build if there are 
errors. Just log them.
+  "OutputFileDiffs": False  # Output chunks of formatting diffs in the 
test case log.
+# This can significantly slow down the 
plugin on very large packages.
+  "ConfigFilePath": "", # Custom path to an Uncrustify config 
file. Path is relative to the package.
+  "IgnoreStandardPaths": [],# Standard Plugin defined paths that 
should be ignored.
+  "AdditionalIncludePaths": []  # Additional paths to check formatting 
(wildcards supported).
+  }
+```


Thanks,

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, November 23, 2021 1:06 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Liming Gao 
; Sean Brogan
; Bret Barkelew 
Subject: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify 
plugin

From: Michael Kubacki 

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

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V3 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---

Notes:
  V2 changes:

  1. Changed plugin temp directory to
 Build/.pytool/Plugin/Uncrustify
  2. Added TCBZ REF in patch commit message

   .pytool/Plugin/Uncrustify/Readme.md   | 116 
   .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 

   .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
   .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
   .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
   .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
   .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
   .pytool/Readme.md |   4 +
   8 files changed, 1193 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..6fcb6e50472d
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,116 @@
+# Uncrustify Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid

confusion

+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, a

Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael D Kinney
Hi Michael,

Thanks for the clarification.

It would be good to make it clear that UncrustifyCheck is by default enabled
for all packages and that the only way to disabled it is to add that section
to the package YAML files and set AuditOnly to True.

Probably best to add this clarification at the top of the Readme.md in
the .pytool/Plugin/UncrustifyCheck directory.

Thanks,

Mike

> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, November 23, 2021 3:17 PM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Liming Gao ; Sean Brogan 
> ; Bret Barkelew
> 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add 
> Uncrustify plugin
> 
> Hi Mike,
> 
> I'm fine with changing the CI plugin name to "UncrustifyCheck". It does
> only check files. I will make this change in a V3.
> 
> That section does not need to be present. It is just giving an example
> of how to add the section and how to set the various config options
> available.
> 
> Thanks,
> Michael
> 
> On 11/23/2021 4:51 PM, Kinney, Michael D wrote:
> > Hi Michael,
> >
> > In order to match some of the other naming conventions of plugins, should
> > this plugin be called "UncrustifyCheck".  It only checks if the sources
> > match the expected format.  It does not actually change the format of
> > any source files when either run locally or by EDK II CI.  Right?
> >
> > Also, does the following section need to be added to every package YAML
> > file in the edk2 repository in order for the Uncrusitfy plugin to
> > be run by EDK II CI?  If so, should those YAML file updates be part
> > of this patch series or a different patch series?
> >
> >> +``` yaml
> >> +  "Uncrustify": {
> >> +  "AuditOnly": False,   # Don't fail the build if there are 
> >> errors. Just log them.
> >> +  "OutputFileDiffs": False  # Output chunks of formatting diffs 
> >> in the test case log.
> >> +# This can significantly slow down 
> >> the plugin on very large packages.
> >> +  "ConfigFilePath": "", # Custom path to an Uncrustify config 
> >> file. Path is relative to the package.
> >> +  "IgnoreStandardPaths": [],# Standard Plugin defined paths that 
> >> should be ignored.
> >> +  "AdditionalIncludePaths": []  # Additional paths to check 
> >> formatting (wildcards supported).
> >> +  }
> >> +```
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of Michael 
> >> Kubacki
> >> Sent: Tuesday, November 23, 2021 1:06 PM
> >> To: devel@edk2.groups.io
> >> Cc: Kinney, Michael D ; Liming Gao 
> >> ; Sean Brogan
> >> ; Bret Barkelew 
> >> Subject: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add 
> >> Uncrustify plugin
> >>
> >> From: Michael Kubacki 
> >>
> >> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3748
> >>
> >> Adds a new CI plugin for Uncrustify. This is used to check
> >> coding standard compliance of source code to the EDK II C Coding
> >> Standards Specification.
> >>
> >> An external dependency is added in the plugin directory to retrieve
> >> the Uncrustify executable. Currently, the executable is from an edk2
> >> fork of the application.
> >>
> >> The default Uncrustify configuration files are added in the plugin
> >> directory. Additional details are in the Readme.md file added in
> >> the Uncrustify plugin directory.
> >>
> >> Note: A V3 is planned that will fail the Uncrustify plugin results
> >> if a file or function template header is found in a formatted file.
> >> This will be additional functionality added in the plugin and will
> >> not change the way Uncrustify is invoked.
> >>
> >> Cc: Michael D Kinney 
> >> Cc: Liming Gao 
> >> Cc: Sean Brogan 
> >> Cc: Bret Barkelew 
> >> Signed-off-by: Michael Kubacki 
> >> ---
> >>
> >> Notes:
> >>  V2 changes:
> >>
> >>  1. Changed plugin temp directory to
> >> Build/.pytool/Plugin/Uncrustify
> >>  2. Added TCBZ REF in patch commit message
> >>
> >>   .pytool/Plugin/Uncrustify/Readme.md   | 116 
> >>   .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 
> >> 
> >>   .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
> >>   .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
> >>   .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
> >> 
> >>   .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
> >>   .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
> >>   .pytool/Readme.md |   4 +
> >>   8 files changed, 1193 insertions(+)
> >>
> >> diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
> >> b/.pytool/Plugin/Uncrustify/Readme.md
> >> new file mode 100644
> >> index ..6fcb6e50472d
> >> --- /dev/null
> >> +++ b/.pytool/Plugin/Uncrustify/Readme.md
> >> @@ -0,0 +1,116 @@
> >> +# Uncrustify Plugin
> >> +
> >> +This CiBuildPlugin scans all the files in a give

Re: [edk2-devel] [Patch 00/12] Update Package YAML to ignore specific ECC files/errors

2021-11-23 Thread Ard Biesheuvel
On Tue, 23 Nov 2021 at 22:21, Michael D Kinney
 wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749
>
> Update package YAML files to ignore ECC errors that are
> already present.  These issues must be fixed in the future,
> but should not block source code changes for these known
> issues.
>
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 

Where needed,

Acked-by: Ard Biesheuvel 

> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Cc: Guomin Jiang 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Cc: Zhiguang Liu 
> Cc: Qi Zhang 
> Cc: Rahul Kumar 
> Cc: Zhichao Gao 
> Cc: Supreeth Venkatesh 
> Cc: Guo Dong 
> Cc: Maurice Ma 
> Cc: Benjamin You 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Liming Gao 
> Cc: Michael Kubacki 
> Signed-off-by: Michael D Kinney 
>
> Michael D Kinney (12):
>   ArmPkg: Update YAML to ignore specific ECC files/errors
>   ArmPlatformPkg: Update YAML to ignore specific ECC files/errors
>   ArmVirtPkg: Update YAML to ignore specific ECC files/errors
>   CryptoPkg: Update YAML to ignore specific ECC files/errors
>   EmulatorPkg: Update YAML to ignore specific ECC files/errors
>   MdeModulePkg: Update YAML to ignore specific ECC files/errors
>   MdePkg: Update YAML to ignore specific ECC files/errors
>   SecurityPkg: Update YAML to ignore specific ECC files/errors
>   ShellPkg: Update YAML to ignore specific ECC files/errors
>   StandaloneMmPkg: Update YAML to ignore specific ECC files/errors
>   UefiPayloadPkg: Update YAML to ignore specific ECC files/errors
>   UnitTestFrameworkPkg: Update YAML to ignore specific ECC files/errors
>
>  ArmPkg/ArmPkg.ci.yaml |  5 ++-
>  ArmPlatformPkg/ArmPlatformPkg.ci.yaml |  3 +-
>  ArmVirtPkg/ArmVirtPkg.ci.yaml |  1 +
>  CryptoPkg/CryptoPkg.ci.yaml   | 10 --
>  EmulatorPkg/EmulatorPkg.ci.yaml   |  7 
>  MdeModulePkg/MdeModulePkg.ci.yaml |  9 ++---
>  MdePkg/MdePkg.ci.yaml | 34 ++-
>  SecurityPkg/SecurityPkg.ci.yaml   |  3 ++
>  ShellPkg/ShellPkg.ci.yaml |  1 +
>  StandaloneMmPkg/StandaloneMmPkg.ci.yaml   | 12 +++
>  UefiPayloadPkg/UefiPayloadPkg.ci.yaml |  6 
>  .../UnitTestFrameworkPkg.ci.yaml  |  5 ++-
>  12 files changed, 83 insertions(+), 13 deletions(-)
>
> --
> 2.32.0.windows.1
>


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




Re: [edk2-devel] [Patch V2 1/1] .pytools/Plugin/LicenseCheck: Use temp directory for git diff output

2021-11-23 Thread Michael Kubacki

Acked-by: Michael Kubacki 

On 11/23/2021 12:31 PM, Michael D Kinney wrote:

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

Use --output option in git diff command to remove code diffs
from build log on stdout when LicenseCheck plugin is run.
Instead, create a temp directory for the diff output file and
remove the temp directory after the diff output is processed.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
  .pytool/Plugin/LicenseCheck/LicenseCheck.py | 20 ++--
  1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/.pytool/Plugin/LicenseCheck/LicenseCheck.py 
b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
index 5733f7bf4ec0..7b998daf6f6b 100644
--- a/.pytool/Plugin/LicenseCheck/LicenseCheck.py
+++ b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
@@ -5,6 +5,7 @@
  ##
  
  import os

+import shutil
  import logging
  import re
  from io import StringIO
@@ -61,12 +62,19 @@ class LicenseCheck(ICiBuildPlugin):
  #   - Junit Logger
  #   - output_stream the StringIO output stream from this plugin via 
logging
  def RunBuildPlugin(self, packagename, Edk2pathObj, pkgconfig, 
environment, PLM, PLMHelper, tc, output_stream=None):
-return_buffer = StringIO()
-params = "diff --unified=0 origin/master HEAD"
-RunCmd("git", params, outstream=return_buffer)
-p = return_buffer.getvalue().strip()
-patch = p.split("\n")
-return_buffer.close()
+# Create temp directory
+temp_path = os.path.join(Edk2pathObj.WorkspacePath, 'Build', 
'.pytool', 'Plugin', 'LicenseCheck')
+if not os.path.exists(temp_path):
+os.makedirs(temp_path)
+# Output file to use for git diff operations
+temp_diff_output = os.path.join (temp_path, 'diff.txt')
+params = "diff --output={} --unified=0 origin/master 
HEAD".format(temp_diff_output)
+RunCmd("git", params)
+with open(temp_diff_output) as file:
+patch = file.read().strip().split("\n")
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
  
  ignore_files = []

  if "IgnoreFiles" in pkgconfig:




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




Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki

Hi Mike,

I'm fine with changing the CI plugin name to "UncrustifyCheck". It does 
only check files. I will make this change in a V3.


That section does not need to be present. It is just giving an example 
of how to add the section and how to set the various config options 
available.


Thanks,
Michael

On 11/23/2021 4:51 PM, Kinney, Michael D wrote:

Hi Michael,

In order to match some of the other naming conventions of plugins, should
this plugin be called "UncrustifyCheck".  It only checks if the sources
match the expected format.  It does not actually change the format of
any source files when either run locally or by EDK II CI.  Right?

Also, does the following section need to be added to every package YAML
file in the edk2 repository in order for the Uncrusitfy plugin to
be run by EDK II CI?  If so, should those YAML file updates be part
of this patch series or a different patch series?


+``` yaml
+  "Uncrustify": {
+  "AuditOnly": False,   # Don't fail the build if there are 
errors. Just log them.
+  "OutputFileDiffs": False  # Output chunks of formatting diffs in the 
test case log.
+# This can significantly slow down the 
plugin on very large packages.
+  "ConfigFilePath": "", # Custom path to an Uncrustify config 
file. Path is relative to the package.
+  "IgnoreStandardPaths": [],# Standard Plugin defined paths that 
should be ignored.
+  "AdditionalIncludePaths": []  # Additional paths to check formatting 
(wildcards supported).
+  }
+```


Thanks,

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, November 23, 2021 1:06 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Liming Gao 
; Sean Brogan
; Bret Barkelew 
Subject: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify 
plugin

From: Michael Kubacki 

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

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V3 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---

Notes:
 V2 changes:

 1. Changed plugin temp directory to
Build/.pytool/Plugin/Uncrustify
 2. Added TCBZ REF in patch commit message

  .pytool/Plugin/Uncrustify/Readme.md   | 116 
  .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 

  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
  .pytool/Readme.md |   4 +
  8 files changed, 1193 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..6fcb6e50472d
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,116 @@
+# Uncrustify Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncrustify/uncrustify
+* Project Mu Uncrustify fork source code and documentation: 
https://dev.azure.com/projectmu/Uncrustify
+
+## Files Checked in a Package
+
+By default, this plugin will discover all files in the package with the 
following default paths:
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+From this list of files, any files ignored by Git or residing in a Git 
submodule will be removed. If Git is not
+found, submodules are not found, or ignored 

Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki

Hi Mike,

The simplest way to stay up-to-date is to let the stuart_update command 
check that the local version matches the version specified in 
"uncrustify_ext_dep.yaml".


The version "73.0" is based on the upstream tag of Uncrustify:
https://github.com/uncrustify/uncrustify/tags

Each release from the fork is assigned an incrementing patch number, in 
this case it is "3". The release pipeline in the Project Mu repo 
associates a given build version such as "73.0.3" with the commit it was 
built from:

https://dev.azure.com/projectmu/Uncrustify/_build/results?buildId=12645&view=results

The "uncrustify.exe --version" command is implemented as-is from the 
upstream which outputs the commit ID.



I'm happy to clarify this in the commit message or other ways that might 
be helpful.


Thanks,
Michael

On 11/23/2021 4:43 PM, Michael D Kinney wrote:

Hi Michael,

When I download and install uncrustify from the nuget feed referenced in this 
patch,
I see the following when I check the version of the uncrustify tool:


uncrustify.exe --version


Uncrustify-c82ee034

But the source link and version in the deps file says 73.0.3


+  "source": 
"https://pkgs.dev.azure.com/projectmu/Uncrustify/_packaging/mu_uncrustify/nuget/v3/index.json";,
+  "version": "73.0.3",


How do developers know that they have installed the correct version of
uncrustify and verify it is the right version.

Also, since this is a fork of uncrustify, what is the relationship between
version numbers of the official release of uncrustify and the release
from this fork that is required for EDK II work?

Thanks,

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, November 23, 2021 1:06 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Liming Gao 
; Sean Brogan
; Bret Barkelew 
Subject: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify 
plugin

From: Michael Kubacki 

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

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V3 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---

Notes:
 V2 changes:

 1. Changed plugin temp directory to
Build/.pytool/Plugin/Uncrustify
 2. Added TCBZ REF in patch commit message

  .pytool/Plugin/Uncrustify/Readme.md   | 116 
  .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 

  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
  .pytool/Readme.md |   4 +
  8 files changed, 1193 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..6fcb6e50472d
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,116 @@
+# Uncrustify Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncrustify/uncrustify
+* Project Mu Uncrustify fork source code and documentation: 
https://dev.azure.com/projectmu/Uncrustify
+
+## Files Checked in a Package
+
+By default, this plugin will discover all files in the package with the 
following default paths:
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+From this list of files, any files ignored by Git or residing in a Git 
submodule will be removed. If Git is not
+found, submo

Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael D Kinney
Hi Michael,

In order to match some of the other naming conventions of plugins, should
this plugin be called "UncrustifyCheck".  It only checks if the sources
match the expected format.  It does not actually change the format of 
any source files when either run locally or by EDK II CI.  Right?

Also, does the following section need to be added to every package YAML
file in the edk2 repository in order for the Uncrusitfy plugin to
be run by EDK II CI?  If so, should those YAML file updates be part
of this patch series or a different patch series?

> +``` yaml
> +  "Uncrustify": {
> +  "AuditOnly": False,   # Don't fail the build if there are 
> errors. Just log them.
> +  "OutputFileDiffs": False  # Output chunks of formatting diffs in 
> the test case log.
> +# This can significantly slow down the 
> plugin on very large packages.
> +  "ConfigFilePath": "", # Custom path to an Uncrustify config 
> file. Path is relative to the package.
> +  "IgnoreStandardPaths": [],# Standard Plugin defined paths that 
> should be ignored.
> +  "AdditionalIncludePaths": []  # Additional paths to check formatting 
> (wildcards supported).
> +  }
> +```

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
> Sent: Tuesday, November 23, 2021 1:06 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liming Gao 
> ; Sean Brogan
> ; Bret Barkelew 
> Subject: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add 
> Uncrustify plugin
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3748
> 
> Adds a new CI plugin for Uncrustify. This is used to check
> coding standard compliance of source code to the EDK II C Coding
> Standards Specification.
> 
> An external dependency is added in the plugin directory to retrieve
> the Uncrustify executable. Currently, the executable is from an edk2
> fork of the application.
> 
> The default Uncrustify configuration files are added in the plugin
> directory. Additional details are in the Readme.md file added in
> the Uncrustify plugin directory.
> 
> Note: A V3 is planned that will fail the Uncrustify plugin results
> if a file or function template header is found in a formatted file.
> This will be additional functionality added in the plugin and will
> not change the way Uncrustify is invoked.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> V2 changes:
> 
> 1. Changed plugin temp directory to
>Build/.pytool/Plugin/Uncrustify
> 2. Added TCBZ REF in patch commit message
> 
>  .pytool/Plugin/Uncrustify/Readme.md   | 116 
>  .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 
> 
>  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
>  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
>  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
>  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
>  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
>  .pytool/Readme.md |   4 +
>  8 files changed, 1193 insertions(+)
> 
> diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
> b/.pytool/Plugin/Uncrustify/Readme.md
> new file mode 100644
> index ..6fcb6e50472d
> --- /dev/null
> +++ b/.pytool/Plugin/Uncrustify/Readme.md
> @@ -0,0 +1,116 @@
> +# Uncrustify Plugin
> +
> +This CiBuildPlugin scans all the files in a given package and checks for 
> coding standard compliance issues.
> +
> +This plugin requires the directory containing the Uncrustify executable that 
> should be used for this plugin to
> +be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
> unique variable name is used to avoid confusion
> +with other paths to Uncrustify which might not be the expected build for use 
> by this plugin.
> +
> +By default, an Uncrustify configuration file named "uncrustify.cfg" located 
> in the same directory as the plugin is
> +used. The value can be overridden to a package-specific path with the 
> `ConfigFilePath` configuration file option.
> +
> +* Uncrustify source code and documentation: 
> https://github.com/uncrustify/uncrustify
> +* Project Mu Uncrustify fork source code and documentation: 
> https://dev.azure.com/projectmu/Uncrustify
> +
> +## Files Checked in a Package
> +
> +By default, this plugin will discover all files in the package with the 
> following default paths:
> +
> +```python
> +[
> +# C source
> +"*.c",
> +"*.h"
> +]
> +```
> +
> +From this list of files, any files ignored by Git or residing in a Git 
> submodule will be removed. If Git is not
> +found, submodules are not found, or ignored files are not found no changes 
> are made to the list of discovered files.
> +
> +To control the paths checked in a given package, review

Re: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael D Kinney
Hi Michael,

When I download and install uncrustify from the nuget feed referenced in this 
patch,
I see the following when I check the version of the uncrustify tool:

>uncrustify.exe --version

Uncrustify-c82ee034

But the source link and version in the deps file says 73.0.3

> +  "source": 
> "https://pkgs.dev.azure.com/projectmu/Uncrustify/_packaging/mu_uncrustify/nuget/v3/index.json";,
> +  "version": "73.0.3",

How do developers know that they have installed the correct version of 
uncrustify and verify it is the right version.

Also, since this is a fork of uncrustify, what is the relationship between
version numbers of the official release of uncrustify and the release
from this fork that is required for EDK II work?

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
> Sent: Tuesday, November 23, 2021 1:06 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liming Gao 
> ; Sean Brogan
> ; Bret Barkelew 
> Subject: [edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add 
> Uncrustify plugin
> 
> From: Michael Kubacki 
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3748
> 
> Adds a new CI plugin for Uncrustify. This is used to check
> coding standard compliance of source code to the EDK II C Coding
> Standards Specification.
> 
> An external dependency is added in the plugin directory to retrieve
> the Uncrustify executable. Currently, the executable is from an edk2
> fork of the application.
> 
> The default Uncrustify configuration files are added in the plugin
> directory. Additional details are in the Readme.md file added in
> the Uncrustify plugin directory.
> 
> Note: A V3 is planned that will fail the Uncrustify plugin results
> if a file or function template header is found in a formatted file.
> This will be additional functionality added in the plugin and will
> not change the way Uncrustify is invoked.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Signed-off-by: Michael Kubacki 
> ---
> 
> Notes:
> V2 changes:
> 
> 1. Changed plugin temp directory to
>Build/.pytool/Plugin/Uncrustify
> 2. Added TCBZ REF in patch commit message
> 
>  .pytool/Plugin/Uncrustify/Readme.md   | 116 
>  .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 
> 
>  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
>  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
>  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
>  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
>  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
>  .pytool/Readme.md |   4 +
>  8 files changed, 1193 insertions(+)
> 
> diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
> b/.pytool/Plugin/Uncrustify/Readme.md
> new file mode 100644
> index ..6fcb6e50472d
> --- /dev/null
> +++ b/.pytool/Plugin/Uncrustify/Readme.md
> @@ -0,0 +1,116 @@
> +# Uncrustify Plugin
> +
> +This CiBuildPlugin scans all the files in a given package and checks for 
> coding standard compliance issues.
> +
> +This plugin requires the directory containing the Uncrustify executable that 
> should be used for this plugin to
> +be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
> unique variable name is used to avoid confusion
> +with other paths to Uncrustify which might not be the expected build for use 
> by this plugin.
> +
> +By default, an Uncrustify configuration file named "uncrustify.cfg" located 
> in the same directory as the plugin is
> +used. The value can be overridden to a package-specific path with the 
> `ConfigFilePath` configuration file option.
> +
> +* Uncrustify source code and documentation: 
> https://github.com/uncrustify/uncrustify
> +* Project Mu Uncrustify fork source code and documentation: 
> https://dev.azure.com/projectmu/Uncrustify
> +
> +## Files Checked in a Package
> +
> +By default, this plugin will discover all files in the package with the 
> following default paths:
> +
> +```python
> +[
> +# C source
> +"*.c",
> +"*.h"
> +]
> +```
> +
> +From this list of files, any files ignored by Git or residing in a Git 
> submodule will be removed. If Git is not
> +found, submodules are not found, or ignored files are not found no changes 
> are made to the list of discovered files.
> +
> +To control the paths checked in a given package, review the configuration 
> options described in this file.
> +
> +## Configuration
> +
> +The plugin can be configured with a few optional configuration options.
> +
> +``` yaml
> +  "Uncrustify": {
> +  "AuditOnly": False,   # Don't fail the build if there are 
> errors. Just log them.
> +  "OutputFileDiffs": False  # Output chunks of formatting diffs in 
> the test case log.
> +# This can significantly slow down the 
> plugin on very large pac

[edk2-devel] [Patch 08/12] SecurityPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Qi Zhang 
Cc: Rahul Kumar 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 SecurityPkg/SecurityPkg.ci.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.ci.yaml b/SecurityPkg/SecurityPkg.ci.yaml
index d7b9e1f4e239..791214239899 100644
--- a/SecurityPkg/SecurityPkg.ci.yaml
+++ b/SecurityPkg/SecurityPkg.ci.yaml
@@ -18,6 +18,9 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
+"Library/TcgStorageCoreLib/TcgStorageUtil.c",
+"Library/TcgStorageCoreLib/TcgStorageCore.c",
+"Library/Tpm2CommandLib/Tpm2NVStorage.c"
 ]
 },
 "CompilerPlugin": {
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 11/12] UefiPayloadPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 UefiPayloadPkg/UefiPayloadPkg.ci.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.ci.yaml 
b/UefiPayloadPkg/UefiPayloadPkg.ci.yaml
index 35e6fb3540d1..93f4d3603db9 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.ci.yaml
+++ b/UefiPayloadPkg/UefiPayloadPkg.ci.yaml
@@ -18,6 +18,12 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
+"Include/Coreboot.h",
+"Library/CbParseLib/CbParseLib.c",
+"Library/CbParseLib/CbParseLib.c",
+"PayloadLoaderPeim/ElfLib/ElfCommon.h",
+"PayloadLoaderPeim/ElfLib/Elf32.h",
+"PayloadLoaderPeim/ElfLib/Elf64.h"
 ]
 },
 ## options defined .pytool/Plugin/CompilerPlugin
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 12/12] UnitTestFrameworkPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml 
b/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
index 9e9ffc1af113..1b247a831593 100644
--- a/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
+++ b/UnitTestFrameworkPkg/UnitTestFrameworkPkg.ci.yaml
@@ -15,10 +15,13 @@
 ## "", ""
 ## ]
 "ExceptionList": [
+"9005", "@MRT",
+"7007", "_UNIT_TEST_FAILURE_TYPE_STRING"
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
-"Library/CmockaLib/cmocka"
+"Library/CmockaLib/cmocka",
+"Library/UnitTestLib/RunTestsCmocka.c"
 ]
 },
 ## options defined .pytool/Plugin/CompilerPlugin
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 09/12] ShellPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 ShellPkg/ShellPkg.ci.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ShellPkg/ShellPkg.ci.yaml b/ShellPkg/ShellPkg.ci.yaml
index 30894d44bc3a..e741402459e5 100644
--- a/ShellPkg/ShellPkg.ci.yaml
+++ b/ShellPkg/ShellPkg.ci.yaml
@@ -15,6 +15,7 @@
 ## "", ""
 ## ]
 "ExceptionList": [
+"8001", "ShellCommandLineParse"
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 10/12] StandaloneMmPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Jiewen Yao 
Cc: Supreeth Venkatesh 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 StandaloneMmPkg/StandaloneMmPkg.ci.yaml | 12 
 1 file changed, 12 insertions(+)

diff --git a/StandaloneMmPkg/StandaloneMmPkg.ci.yaml 
b/StandaloneMmPkg/StandaloneMmPkg.ci.yaml
index 06bef683cdaf..4777532a7ede 100644
--- a/StandaloneMmPkg/StandaloneMmPkg.ci.yaml
+++ b/StandaloneMmPkg/StandaloneMmPkg.ci.yaml
@@ -5,6 +5,18 @@
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 {
+"EccCheck": {
+## Exception sample looks like below:
+## "ExceptionList": [
+## "", ""
+## ]
+"ExceptionList": [
+"4002", "HobConstructor"
+],
+## Both file path and directory path are accepted.
+"IgnoreFiles": [
+]
+},
 ## options defined .pytool/Plugin/CompilerPlugin
 "CompilerPlugin": {
 "DscPath": "StandaloneMmPkg.dsc"
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 06/12] MdeModulePkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/MdeModulePkg.ci.yaml | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.ci.yaml 
b/MdeModulePkg/MdeModulePkg.ci.yaml
index b8d15a3e952e..f69989087b4c 100644
--- a/MdeModulePkg/MdeModulePkg.ci.yaml
+++ b/MdeModulePkg/MdeModulePkg.ci.yaml
@@ -23,12 +23,9 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
-"Library/BrotliCustomDecompressLib/brotli",
-"Universal/RegularExpressionDxe/oniguruma",
-"Library/LzmaCustomDecompressLib/Sdk/DOC",
-"Library/LzmaCustomDecompressLib/Sdk/C",
-"Universal/RegularExpressionDxe/OnigurumaUefiPort.h",
-"Universal/RegularExpressionDxe/OnigurumaUefiPort.c"
+"Library/LzmaCustomDecompressLib",
+"Library/BrotliCustomDecompressLib",
+"Universal/RegularExpressionDxe"
 ]
 },
 ## options defined ci/Plugin/CompilerPlugin
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 07/12] MdePkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 MdePkg/MdePkg.ci.yaml | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/MdePkg/MdePkg.ci.yaml b/MdePkg/MdePkg.ci.yaml
index 3ea8eec33152..054233ebc7bd 100644
--- a/MdePkg/MdePkg.ci.yaml
+++ b/MdePkg/MdePkg.ci.yaml
@@ -17,10 +17,42 @@
 ## "", ""
 ## ]
 "ExceptionList": [
+"9005", "@VDD",
+"8005", "gST",
+"8005", "gBS",
+"8005", "gDS",
+"8005", "gDS",
+"8002", "va_list",
+"8005", "EFI_BLUETOOTH_LE_SCAN_CALLBACK_INFORMATION.RSSI",
+"8005", "void",
+"8005", "va_list.__ap",
+"8005", "__stack_chk_guard",
+"8001", "MSG_IPv6_DP",
+"8001", "MSG_IPv4_DP",
+"8001", "DEFAULT_ToS",
+"8001", "EFI_SERIAL_IO_PROTOCOL_REVISION1p1",
+"8001", "EFI_ABS_AltActive",
+"8001", "EFI_ABSP_SupportsAltActive",
+"8001", "_ReadWriteBarrier",
+"8001", "__va_copy",
+"8003", "__va_copy",
+"7007", "_EFI_LEGACY_SPI_CONTROLLER_PROTOCOL",
+"7007", "_EFI_LEGACY_SPI_FLASH_PROTOCOL",
+"7007", "_EFI_SPI_NOR_FLASH_PROTOCOL",
+"7007", "_EFI_SPI_HC_PROTOCOL",
+"8002", "aligned (",
+"4002", "_ReturnAddress"
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
-"Include/IndustryStandard/Acpi64.h"
+"Include/IndustryStandard/Acpi64.h",
+"Include/IndustryStandard/Tpm12.h",
+"Include/IndustryStandard/Tpm20.h",
+"Include/IndustryStandard/IoRemappingTable.h",
+"Include/IndustryStandard/UefiTcgPlatform.h",
+"Include/Library/PcdLib.h",
+"Include/Library/SafeIntLib.h",
+"Test/UnitTest/Library/BaseSafeIntLib/TestBaseSafeIntLib.c"
 ]
 },
 ## options defined ci/Plugin/CompilerPlugin
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 04/12] CryptoPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Cc: Guomin Jiang 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 CryptoPkg/CryptoPkg.ci.yaml | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/CryptoPkg/CryptoPkg.ci.yaml b/CryptoPkg/CryptoPkg.ci.yaml
index 1448299073de..eeb388ae71c5 100644
--- a/CryptoPkg/CryptoPkg.ci.yaml
+++ b/CryptoPkg/CryptoPkg.ci.yaml
@@ -19,6 +19,9 @@
 ## "", ""
 ## ]
 "ExceptionList": [
+"8001", "IsLeap",
+"8001", "OBJ_get0_data",
+"8001", "OBJ_length"
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
@@ -26,14 +29,15 @@
 # The unit testing folder is not to be checked
 "Test/UnitTest",
 # This has OpenSSL interfaces that aren't UEFI spec compliant
-"Library/BaseCryptLib/SysCall/UnitTestHostCrtWrapper.c",
+"Library/BaseCryptLib/SysCall",
 # This has OpenSSL interfaces that aren't UEFI spec compliant
 "Library/OpensslLib/rand_pool.c",
 # This has OpenSSL interfaces that aren't UEFI spec compliant
 "Library/Include/CrtLibSupport.h",
 # These directories contain auto-generated OpenSSL content
-"Library/OpensslLib/X64",
-"Library/OpensslLib/X64Gcc"
+"Library/OpensslLib",
+"Library/IntrinsicLib",
+"Library/BaseCryptLib/Pk/CryptPkcs7VerifyBase.c"
 ]
 },
 "CompilerPlugin": {
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 03/12] ArmVirtPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Gerd Hoffmann 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 ArmVirtPkg/ArmVirtPkg.ci.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ArmVirtPkg/ArmVirtPkg.ci.yaml b/ArmVirtPkg/ArmVirtPkg.ci.yaml
index f80500ab53b0..67b0e9594f3e 100644
--- a/ArmVirtPkg/ArmVirtPkg.ci.yaml
+++ b/ArmVirtPkg/ArmVirtPkg.ci.yaml
@@ -24,6 +24,7 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
+"Library/PlatformBootManagerLib/PlatformBm.c"
 ]
 },
 ## options defined .pytool/Plugin/CompilerPlugin
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 05/12] EmulatorPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 EmulatorPkg/EmulatorPkg.ci.yaml | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/EmulatorPkg/EmulatorPkg.ci.yaml b/EmulatorPkg/EmulatorPkg.ci.yaml
index 97fdef17abf4..338d5fc2d381 100644
--- a/EmulatorPkg/EmulatorPkg.ci.yaml
+++ b/EmulatorPkg/EmulatorPkg.ci.yaml
@@ -22,6 +22,13 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
+"EmuBlockIoDxe/EmuBlockIo.c",
+"EmuGopDxe/GopInput.c",
+"EmuSnpDxe/EmuSnpDxe.c",
+"EmuSimpleFileSystemDxe/EmuSimpleFileSystem.c",
+"FvbServicesRuntimeDxe/FWBlockService.c",
+"Win/Host/WinFileSystem.c",
+"Win/Host/WinInclude.h"
 ]
 },
 ## options defined .pytool/Plugin/CompilerPlugin
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 01/12] ArmPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 ArmPkg/ArmPkg.ci.yaml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/ArmPkg.ci.yaml b/ArmPkg/ArmPkg.ci.yaml
index a0d6a75fe881..b7e07aaef675 100644
--- a/ArmPkg/ArmPkg.ci.yaml
+++ b/ArmPkg/ArmPkg.ci.yaml
@@ -19,7 +19,10 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
-"Library/ArmSoftFloatLib/berkeley-softfloat-3"
+"Library/ArmSoftFloatLib/berkeley-softfloat-3",
+"Library/ArmSoftFloatLib/ArmSoftFloatLib.c",
+"Library/CompilerIntrinsicsLib",
+"Universal/Smbios/SmbiosMiscDxe"
 ]
 },
 
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 02/12] ArmPlatformPkg: Update YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 ArmPlatformPkg/ArmPlatformPkg.ci.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.ci.yaml 
b/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
index 3dbbcc673bf0..03632e74df73 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
+++ b/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
@@ -19,7 +19,8 @@
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
-"Scripts/Ds5/"
+"Scripts/Ds5/",
+"Drivers/PL061GpioDxe/PL061Gpio.c"
 ]
 },
 
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 00/12] Update Package YAML to ignore specific ECC files/errors

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3749

Update package YAML files to ignore ECC errors that are
already present.  These issues must be fixed in the future,
but should not block source code changes for these known
issues.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Sami Mujawar 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Cc: Guomin Jiang 
Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Zhiguang Liu 
Cc: Qi Zhang 
Cc: Rahul Kumar 
Cc: Zhichao Gao 
Cc: Supreeth Venkatesh 
Cc: Guo Dong 
Cc: Maurice Ma 
Cc: Benjamin You 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 

Michael D Kinney (12):
  ArmPkg: Update YAML to ignore specific ECC files/errors
  ArmPlatformPkg: Update YAML to ignore specific ECC files/errors
  ArmVirtPkg: Update YAML to ignore specific ECC files/errors
  CryptoPkg: Update YAML to ignore specific ECC files/errors
  EmulatorPkg: Update YAML to ignore specific ECC files/errors
  MdeModulePkg: Update YAML to ignore specific ECC files/errors
  MdePkg: Update YAML to ignore specific ECC files/errors
  SecurityPkg: Update YAML to ignore specific ECC files/errors
  ShellPkg: Update YAML to ignore specific ECC files/errors
  StandaloneMmPkg: Update YAML to ignore specific ECC files/errors
  UefiPayloadPkg: Update YAML to ignore specific ECC files/errors
  UnitTestFrameworkPkg: Update YAML to ignore specific ECC files/errors

 ArmPkg/ArmPkg.ci.yaml |  5 ++-
 ArmPlatformPkg/ArmPlatformPkg.ci.yaml |  3 +-
 ArmVirtPkg/ArmVirtPkg.ci.yaml |  1 +
 CryptoPkg/CryptoPkg.ci.yaml   | 10 --
 EmulatorPkg/EmulatorPkg.ci.yaml   |  7 
 MdeModulePkg/MdeModulePkg.ci.yaml |  9 ++---
 MdePkg/MdePkg.ci.yaml | 34 ++-
 SecurityPkg/SecurityPkg.ci.yaml   |  3 ++
 ShellPkg/ShellPkg.ci.yaml |  1 +
 StandaloneMmPkg/StandaloneMmPkg.ci.yaml   | 12 +++
 UefiPayloadPkg/UefiPayloadPkg.ci.yaml |  6 
 .../UnitTestFrameworkPkg.ci.yaml  |  5 ++-
 12 files changed, 83 insertions(+), 13 deletions(-)

-- 
2.32.0.windows.1



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




[edk2-devel] [PATCH v2 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki
From: Michael Kubacki 

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

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V3 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---

Notes:
V2 changes:

1. Changed plugin temp directory to
   Build/.pytool/Plugin/Uncrustify
2. Added TCBZ REF in patch commit message

 .pytool/Plugin/Uncrustify/Readme.md   | 116 
 .pytool/Plugin/Uncrustify/Uncrustify.py   | 555 

 .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
 .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
 .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
 .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
 .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
 .pytool/Readme.md |   4 +
 8 files changed, 1193 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..6fcb6e50472d
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,116 @@
+# Uncrustify Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncrustify/uncrustify
+* Project Mu Uncrustify fork source code and documentation: 
https://dev.azure.com/projectmu/Uncrustify
+
+## Files Checked in a Package
+
+By default, this plugin will discover all files in the package with the 
following default paths:
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+From this list of files, any files ignored by Git or residing in a Git 
submodule will be removed. If Git is not
+found, submodules are not found, or ignored files are not found no changes are 
made to the list of discovered files.
+
+To control the paths checked in a given package, review the configuration 
options described in this file.
+
+## Configuration
+
+The plugin can be configured with a few optional configuration options.
+
+``` yaml
+  "Uncrustify": {
+  "AuditOnly": False,   # Don't fail the build if there are 
errors. Just log them.
+  "OutputFileDiffs": False  # Output chunks of formatting diffs in the 
test case log.
+# This can significantly slow down the 
plugin on very large packages.
+  "ConfigFilePath": "", # Custom path to an Uncrustify config 
file. Path is relative to the package.
+  "IgnoreStandardPaths": [],# Standard Plugin defined paths that 
should be ignored.
+  "AdditionalIncludePaths": []  # Additional paths to check formatting 
(wildcards supported).
+  }
+```
+
+### `AdditionalIncludePaths`
+
+A package configuration file can specify any additional paths to be included 
with this option.
+
+At this time, it is recommended all files run against the plugin be written in 
the C or C++ language.
+
+### `AuditOnly`
+
+`Boolean` - Default is `False`.
+
+If `True`, run the test in an "audit only mode" which will log all errors but 
instead of failing the build, it will set
+the test as skipped. This allows visibility into the failures without breaking 
the build.
+
+### `ConfigFilePath`
+
+`String` - Default is `"uncrustify.cfg"`
+
+When specified in the config file, this is a package relative path to the 
Uncrustify configuration file.
+
+### `IgnoreStandardPaths`
+
+This plugin by default will check the below standard paths. A package 
configuration file can specify any of these paths
+to be ignored.
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+### `OutputFileDiffs`
+
+`Boolean` - Default is `False`

Re: [edk2-devel] [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki

Response below.

On 11/23/2021 3:19 PM, Kinney, Michael D wrote:

Hi Michael,

Comments below.

Mike


-Original Message-
From: Michael Kubacki 
Sent: Tuesday, November 23, 2021 12:07 PM
To: Kinney, Michael D ; devel@edk2.groups.io
Cc: Liming Gao ; Sean Brogan 
; Bret Barkelew

Subject: Re: [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

I'll file a BZ and add it.

I don't see a difference comparing my template file contents against the
corresponding files in the branch you linked. Am I missing something?


You are correct.  Please ignore.

I saw reference to Project Mu, but that is in the
.pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml file, which is correct
because that is where the fork of uncrustify tool with EDK II extensions
is hosted.



I saw the temp file directory change recently added to those plugin
patches. My concern is that .pytool/ is tracked by git and Build/ is not.


My suggestion is to use Build/.pytool/Plugin/ as a temp
directory that is in Build output directory that is ignored by .gitignore.

Okay, I missed this is relative to the Build directory. I can make that 
change.


In the unlikely case the temp file removal fails (for whatever reason),
the git workspace does not pick up the left over files.

Given the plugin is storing temp files in a "UncrustifyPlugin" directory
in each package's build directory, I don't anticipate conflicts (unless
the user has intentionally tried to do so). I've also taken time to
improve temp directory removal robustness in ways I haven't seen in
other plugins including doing so for cases like keyboard interrupts and
attempting multiple times for sporadic issues that might occur during
removal (that we've very rarely observed across many CI instances).

Technically, since .pytool/ is tracked, the user could also have local
changes there that conflict with what the plugin produces as temporary
output.

So I didn't see a strong practical benefit to changing it from
Build/{PackageName}/UncrustifyPlugin. Is there a benefit/issue I missed?


I have seen a difference between CRTL-C and CRTL-BREAK.  CRTL-C is caught
by Python exception processing so the temp dir can be removed.  CRTL-BREAK
or other OS specific actions to kill a process bypasses the Python exception
handling and the temp dir will not be removed.

I recommend moving all temp dirs/files into locations that are guaranteed
to never be seen as untracked files by git.



Thanks,
Michael

On 11/23/2021 2:20 PM, Kinney, Michael D wrote:

Hi Michael,

Have you opened a BZ for this feature?  Can you do that and add REF: to the 
commit message?

Also, the template files for uncrustify need to be updated to match the contents
from the EDK II C Coding Standard.  Pease see the file and function header 
templates
in this location:

  
https://github.com/mdkinney/edk2/tree/Bug_3737_ApplyUncrustifyChanges_V4/.uncrustify

I also see you use a temp directory in Build output:


+self._working_dir = os.path.join(
+self._abs_workspace_path, "Build", self._package_name, 
"UncrustifyPlugin")


In the EccCheck and LicenseCheck patches I sent earlier today, I decided to put 
all
temp directories associated with pytools Plugins in the path:

  Build/.pytool/Plugin/

This provide a unique path for temp files associated with Plugins that matches
the source path to the Plugin so plugins will never use the same temp dir path
and each plugin can safely clean up its own temp directory.

Thanks,

Mike


-Original Message-
From: mikub...@linux.microsoft.com 
Sent: Tuesday, November 23, 2021 8:54 AM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Liming Gao 
; Sean Brogan
; Bret Barkelew 
Subject: [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

From: Michael Kubacki 

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V2 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---
   .pytool/Plugin/Uncrustify/Readme.md   | 116 
   .pytool/Plugin/Uncrustify/Uncrustify.py   | 556 

   .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
   .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
   .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
   .pyto

Re: [edk2-devel] [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael D Kinney
Hi Michael,

Comments below.

Mike

> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, November 23, 2021 12:07 PM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Liming Gao ; Sean Brogan 
> ; Bret Barkelew
> 
> Subject: Re: [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin
> 
> I'll file a BZ and add it.
> 
> I don't see a difference comparing my template file contents against the
> corresponding files in the branch you linked. Am I missing something?

You are correct.  Please ignore.

I saw reference to Project Mu, but that is in the 
.pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml file, which is correct
because that is where the fork of uncrustify tool with EDK II extensions
is hosted.

> 
> I saw the temp file directory change recently added to those plugin
> patches. My concern is that .pytool/ is tracked by git and Build/ is not.

My suggestion is to use Build/.pytool/Plugin/ as a temp
directory that is in Build output directory that is ignored by .gitignore.

> 
> In the unlikely case the temp file removal fails (for whatever reason),
> the git workspace does not pick up the left over files.
> 
> Given the plugin is storing temp files in a "UncrustifyPlugin" directory
> in each package's build directory, I don't anticipate conflicts (unless
> the user has intentionally tried to do so). I've also taken time to
> improve temp directory removal robustness in ways I haven't seen in
> other plugins including doing so for cases like keyboard interrupts and
> attempting multiple times for sporadic issues that might occur during
> removal (that we've very rarely observed across many CI instances).
> 
> Technically, since .pytool/ is tracked, the user could also have local
> changes there that conflict with what the plugin produces as temporary
> output.
> 
> So I didn't see a strong practical benefit to changing it from
> Build/{PackageName}/UncrustifyPlugin. Is there a benefit/issue I missed?

I have seen a difference between CRTL-C and CRTL-BREAK.  CRTL-C is caught
by Python exception processing so the temp dir can be removed.  CRTL-BREAK
or other OS specific actions to kill a process bypasses the Python exception
handling and the temp dir will not be removed.

I recommend moving all temp dirs/files into locations that are guaranteed
to never be seen as untracked files by git.

> 
> Thanks,
> Michael
> 
> On 11/23/2021 2:20 PM, Kinney, Michael D wrote:
> > Hi Michael,
> >
> > Have you opened a BZ for this feature?  Can you do that and add REF: to the 
> > commit message?
> >
> > Also, the template files for uncrustify need to be updated to match the 
> > contents
> > from the EDK II C Coding Standard.  Pease see the file and function header 
> > templates
> > in this location:
> >
> >  
> > https://github.com/mdkinney/edk2/tree/Bug_3737_ApplyUncrustifyChanges_V4/.uncrustify
> >
> > I also see you use a temp directory in Build output:
> >
> >> +self._working_dir = os.path.join(
> >> +self._abs_workspace_path, "Build", self._package_name, 
> >> "UncrustifyPlugin")
> >
> > In the EccCheck and LicenseCheck patches I sent earlier today, I decided to 
> > put all
> > temp directories associated with pytools Plugins in the path:
> >
> >  Build/.pytool/Plugin/
> >
> > This provide a unique path for temp files associated with Plugins that 
> > matches
> > the source path to the Plugin so plugins will never use the same temp dir 
> > path
> > and each plugin can safely clean up its own temp directory.
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: mikub...@linux.microsoft.com 
> >> Sent: Tuesday, November 23, 2021 8:54 AM
> >> To: devel@edk2.groups.io
> >> Cc: Kinney, Michael D ; Liming Gao 
> >> ; Sean Brogan
> >> ; Bret Barkelew 
> >> Subject: [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin
> >>
> >> From: Michael Kubacki 
> >>
> >> Adds a new CI plugin for Uncrustify. This is used to check
> >> coding standard compliance of source code to the EDK II C Coding
> >> Standards Specification.
> >>
> >> An external dependency is added in the plugin directory to retrieve
> >> the Uncrustify executable. Currently, the executable is from an edk2
> >> fork of the application.
> >>
> >> The default Uncrustify configuration files are added in the plugin
> >> directory. Additional details are in the Readme.md file added in
> >> the Uncrustify plugin directory.
> >>
> >> Note: A V2 is planned that will fail the Uncrustify plugin results
> >> if a file or function template header is found in a formatted file.
> >> This will be additional functionality added in the plugin and will
> >> not change the way Uncrustify is invoked.
> >>
> >> Cc: Michael D Kinney 
> >> Cc: Liming Gao 
> >> Cc: Sean Brogan 
> >> Cc: Bret Barkelew 
> >> Signed-off-by: Michael Kubacki 
> >> ---
> >>   .pytool/Plugin/Uncrustify/Readme.md   | 116 
> >>   .pytool/Plugin/Uncrustify/Uncrustify.py   | 556 
> >> +

Re: [edk2-devel] [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki

I'll file a BZ and add it.

I don't see a difference comparing my template file contents against the 
corresponding files in the branch you linked. Am I missing something?


I saw the temp file directory change recently added to those plugin 
patches. My concern is that .pytool/ is tracked by git and Build/ is not.


In the unlikely case the temp file removal fails (for whatever reason), 
the git workspace does not pick up the left over files.


Given the plugin is storing temp files in a "UncrustifyPlugin" directory 
in each package's build directory, I don't anticipate conflicts (unless 
the user has intentionally tried to do so). I've also taken time to 
improve temp directory removal robustness in ways I haven't seen in 
other plugins including doing so for cases like keyboard interrupts and 
attempting multiple times for sporadic issues that might occur during 
removal (that we've very rarely observed across many CI instances).


Technically, since .pytool/ is tracked, the user could also have local 
changes there that conflict with what the plugin produces as temporary 
output.


So I didn't see a strong practical benefit to changing it from 
Build/{PackageName}/UncrustifyPlugin. Is there a benefit/issue I missed?


Thanks,
Michael

On 11/23/2021 2:20 PM, Kinney, Michael D wrote:

Hi Michael,

Have you opened a BZ for this feature?  Can you do that and add REF: to the 
commit message?

Also, the template files for uncrustify need to be updated to match the contents
from the EDK II C Coding Standard.  Pease see the file and function header 
templates
in this location:

 
https://github.com/mdkinney/edk2/tree/Bug_3737_ApplyUncrustifyChanges_V4/.uncrustify

I also see you use a temp directory in Build output:


+self._working_dir = os.path.join(
+self._abs_workspace_path, "Build", self._package_name, 
"UncrustifyPlugin")


In the EccCheck and LicenseCheck patches I sent earlier today, I decided to put 
all
temp directories associated with pytools Plugins in the path:

 Build/.pytool/Plugin/

This provide a unique path for temp files associated with Plugins that matches
the source path to the Plugin so plugins will never use the same temp dir path
and each plugin can safely clean up its own temp directory.

Thanks,

Mike


-Original Message-
From: mikub...@linux.microsoft.com 
Sent: Tuesday, November 23, 2021 8:54 AM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Liming Gao 
; Sean Brogan
; Bret Barkelew 
Subject: [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

From: Michael Kubacki 

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V2 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---
  .pytool/Plugin/Uncrustify/Readme.md   | 116 
  .pytool/Plugin/Uncrustify/Uncrustify.py   | 556 

  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
  .pytool/Readme.md |   4 +
  8 files changed, 1194 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..46586d81c68c
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,116 @@
+# Uncrustify Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncr

Re: [edk2-devel] [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael D Kinney
Hi Michael,

Have you opened a BZ for this feature?  Can you do that and add REF: to the 
commit message?

Also, the template files for uncrustify need to be updated to match the contents
from the EDK II C Coding Standard.  Pease see the file and function header 
templates
in this location:


https://github.com/mdkinney/edk2/tree/Bug_3737_ApplyUncrustifyChanges_V4/.uncrustify

I also see you use a temp directory in Build output:

> +self._working_dir = os.path.join(
> +self._abs_workspace_path, "Build", self._package_name, 
> "UncrustifyPlugin")

In the EccCheck and LicenseCheck patches I sent earlier today, I decided to put 
all
temp directories associated with pytools Plugins in the path:

Build/.pytool/Plugin/

This provide a unique path for temp files associated with Plugins that matches
the source path to the Plugin so plugins will never use the same temp dir path
and each plugin can safely clean up its own temp directory.

Thanks,

Mike

> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Tuesday, November 23, 2021 8:54 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Liming Gao 
> ; Sean Brogan
> ; Bret Barkelew 
> Subject: [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin
> 
> From: Michael Kubacki 
> 
> Adds a new CI plugin for Uncrustify. This is used to check
> coding standard compliance of source code to the EDK II C Coding
> Standards Specification.
> 
> An external dependency is added in the plugin directory to retrieve
> the Uncrustify executable. Currently, the executable is from an edk2
> fork of the application.
> 
> The default Uncrustify configuration files are added in the plugin
> directory. Additional details are in the Readme.md file added in
> the Uncrustify plugin directory.
> 
> Note: A V2 is planned that will fail the Uncrustify plugin results
> if a file or function template header is found in a formatted file.
> This will be additional functionality added in the plugin and will
> not change the way Uncrustify is invoked.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Signed-off-by: Michael Kubacki 
> ---
>  .pytool/Plugin/Uncrustify/Readme.md   | 116 
>  .pytool/Plugin/Uncrustify/Uncrustify.py   | 556 
> 
>  .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
>  .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
>  .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
>  .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
>  .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
>  .pytool/Readme.md |   4 +
>  8 files changed, 1194 insertions(+)
> 
> diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
> b/.pytool/Plugin/Uncrustify/Readme.md
> new file mode 100644
> index ..46586d81c68c
> --- /dev/null
> +++ b/.pytool/Plugin/Uncrustify/Readme.md
> @@ -0,0 +1,116 @@
> +# Uncrustify Plugin
> +
> +This CiBuildPlugin scans all the files in a given package and checks for 
> coding standard compliance issues.
> +
> +This plugin requires the directory containing the Uncrustify executable that 
> should be used for this plugin to
> +be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
> unique variable name is used to avoid confusion
> +with other paths to Uncrustify which might not be the expected build for use 
> by this plugin.
> +
> +By default, an Uncrustify configuration file named "uncrustify.cfg" located 
> in the same directory as the plugin is
> +used. The value can be overridden to a package-specific path with the 
> `ConfigFilePath` configuration file option.
> +
> +* Uncrustify source code and documentation: 
> https://github.com/uncrustify/uncrustify
> +* Project Mu Uncrustify fork source code and documentation: 
> https://dev.azure.com/projectmu/Uncrustify
> +
> +## Files Checked in a Package
> +
> +By default, this plugin will discover all files in the package with the 
> following default paths:
> +
> +```python
> +[
> +# C source
> +"*.c",
> +"*.h"
> +]
> +```
> +
> +From this list of files, any files ignored by Git or residing in a Git 
> submodule will be removed. If Git is not
> +found, submodules are not found, or ignored files are not found no changes 
> are made to the list of discovered files.
> +
> +To control the paths checked in a given package, review the configuration 
> options described in this file.
> +
> +## Configuration
> +
> +The plugin can be configured with a few optional configuration options.
> +
> +``` yaml
> +  "Uncrustify": {
> +  "AuditOnly": False,   # Don't fail the build if there are 
> errors. Just log them.
> +  "OutputFileDiffs": False  # Output chunks of formatting diffs in 
> the test case log.
> +# This can significantly slow down the 
> plugin on very large packages.
> +  "ConfigFilePat

Re: [edk2-devel] [Patch 1/1] EmulatorPkg/Win/Host: Update CC_FLAGS

2021-11-23 Thread Michael Kubacki

Reviewed-by: Michael Kubacki 

On 11/23/2021 12:25 PM, Michael D Kinney wrote:

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

* Remove deprecated option /Gm that generates a warning.
* Remove /Zi and use '=' instead of '== to let DEBUG/RELEASE/NOOPT
   profile from tools_def.txt enable debug information
* Remove /Gs8192 option that is overriding the larger setting of
   /GS32768 from tools_def.txt that generates a warning.

Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
  EmulatorPkg/Win/Host/WinHost.inf | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.inf b/EmulatorPkg/Win/Host/WinHost.inf
index 4d2ce19620a1..2030ac084702 100644
--- a/EmulatorPkg/Win/Host/WinHost.inf
+++ b/EmulatorPkg/Win/Host/WinHost.inf
@@ -86,7 +86,7 @@ [Pcd]
  
  [BuildOptions]

MSFT:*_*_*_DLINK_FLAGS== /out:"$(BIN_DIR)\$(BASE_NAME).exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
-  MSFT:*_*_*_CC_FLAGS   == /nologo /W4 /WX /Gy /c /D UNICODE /Od 
/Oy- /FIAutoGen.h /EHs-c- /GF /Gs8192 /Zi /Gm /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
+  MSFT:*_*_*_CC_FLAGS= /nologo /W4 /WX /Gy /c /D UNICODE /Od 
/Oy- /FIAutoGen.h /EHs-c- /GF /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
MSFT:*_*_*_PP_FLAGS   == /nologo /E /TC /FIAutoGen.h
  
MSFT:*_VS2015_IA32_DLINK_FLAGS = /LIBPATH:"%VS2015_PREFIX%Lib" /LIBPATH:"%VS2015_PREFIX%VC\Lib" /LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" /LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO /SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG /MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib Advapi32.lib vcruntimed.lib ucrtd.lib





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




[edk2-devel] [Patch V2 1/1] .pytools/Plugin/LicenseCheck: Use temp directory for git diff output

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3746

Use --output option in git diff command to remove code diffs
from build log on stdout when LicenseCheck plugin is run.
Instead, create a temp directory for the diff output file and
remove the temp directory after the diff output is processed.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .pytool/Plugin/LicenseCheck/LicenseCheck.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/.pytool/Plugin/LicenseCheck/LicenseCheck.py 
b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
index 5733f7bf4ec0..7b998daf6f6b 100644
--- a/.pytool/Plugin/LicenseCheck/LicenseCheck.py
+++ b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
@@ -5,6 +5,7 @@
 ##
 
 import os
+import shutil
 import logging
 import re
 from io import StringIO
@@ -61,12 +62,19 @@ class LicenseCheck(ICiBuildPlugin):
 #   - Junit Logger
 #   - output_stream the StringIO output stream from this plugin via logging
 def RunBuildPlugin(self, packagename, Edk2pathObj, pkgconfig, environment, 
PLM, PLMHelper, tc, output_stream=None):
-return_buffer = StringIO()
-params = "diff --unified=0 origin/master HEAD"
-RunCmd("git", params, outstream=return_buffer)
-p = return_buffer.getvalue().strip()
-patch = p.split("\n")
-return_buffer.close()
+# Create temp directory
+temp_path = os.path.join(Edk2pathObj.WorkspacePath, 'Build', 
'.pytool', 'Plugin', 'LicenseCheck')
+if not os.path.exists(temp_path):
+os.makedirs(temp_path)
+# Output file to use for git diff operations
+temp_diff_output = os.path.join (temp_path, 'diff.txt')
+params = "diff --output={} --unified=0 origin/master 
HEAD".format(temp_diff_output)
+RunCmd("git", params)
+with open(temp_diff_output) as file:
+patch = file.read().strip().split("\n")
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
 
 ignore_files = []
 if "IgnoreFiles" in pkgconfig:
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch V2 1/1] .pytools/Plugin/LicenseCheck: Use temp directory for git diff output

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3746

Use --output option in git diff command to remove code diffs
from build log on stdout when LicenseCheck plugin is run.
Instead, create a temp directory for the diff output file and
remove the temp directory after the diff output is processed.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .pytool/Plugin/LicenseCheck/LicenseCheck.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/.pytool/Plugin/LicenseCheck/LicenseCheck.py 
b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
index 5733f7bf4ec0..7b998daf6f6b 100644
--- a/.pytool/Plugin/LicenseCheck/LicenseCheck.py
+++ b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
@@ -5,6 +5,7 @@
 ##
 
 import os
+import shutil
 import logging
 import re
 from io import StringIO
@@ -61,12 +62,19 @@ class LicenseCheck(ICiBuildPlugin):
 #   - Junit Logger
 #   - output_stream the StringIO output stream from this plugin via logging
 def RunBuildPlugin(self, packagename, Edk2pathObj, pkgconfig, environment, 
PLM, PLMHelper, tc, output_stream=None):
-return_buffer = StringIO()
-params = "diff --unified=0 origin/master HEAD"
-RunCmd("git", params, outstream=return_buffer)
-p = return_buffer.getvalue().strip()
-patch = p.split("\n")
-return_buffer.close()
+# Create temp directory
+temp_path = os.path.join(Edk2pathObj.WorkspacePath, 'Build', 
'.pytool', 'Plugin', 'LicenseCheck')
+if not os.path.exists(temp_path):
+os.makedirs(temp_path)
+# Output file to use for git diff operations
+temp_diff_output = os.path.join (temp_path, 'diff.txt')
+params = "diff --output={} --unified=0 origin/master 
HEAD".format(temp_diff_output)
+RunCmd("git", params)
+with open(temp_diff_output) as file:
+patch = file.read().strip().split("\n")
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
 
 ignore_files = []
 if "IgnoreFiles" in pkgconfig:
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 1/1] EmulatorPkg/Win/Host: Update CC_FLAGS

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3747

* Remove deprecated option /Gm that generates a warning.
* Remove /Zi and use '=' instead of '== to let DEBUG/RELEASE/NOOPT
  profile from tools_def.txt enable debug information
* Remove /Gs8192 option that is overriding the larger setting of
  /GS32768 from tools_def.txt that generates a warning.

Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 EmulatorPkg/Win/Host/WinHost.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.inf b/EmulatorPkg/Win/Host/WinHost.inf
index 4d2ce19620a1..2030ac084702 100644
--- a/EmulatorPkg/Win/Host/WinHost.inf
+++ b/EmulatorPkg/Win/Host/WinHost.inf
@@ -86,7 +86,7 @@ [Pcd]
 
 [BuildOptions]
   MSFT:*_*_*_DLINK_FLAGS== /out:"$(BIN_DIR)\$(BASE_NAME).exe" 
/base:0x1000 /pdb:"$(BIN_DIR)\$(BASE_NAME).pdb"
-  MSFT:*_*_*_CC_FLAGS   == /nologo /W4 /WX /Gy /c /D UNICODE /Od 
/Oy- /FIAutoGen.h /EHs-c- /GF /Gs8192 /Zi /Gm /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
+  MSFT:*_*_*_CC_FLAGS= /nologo /W4 /WX /Gy /c /D UNICODE /Od 
/Oy- /FIAutoGen.h /EHs-c- /GF /D _CRT_SECURE_NO_WARNINGS /D 
_CRT_SECURE_NO_DEPRECATE
   MSFT:*_*_*_PP_FLAGS   == /nologo /E /TC /FIAutoGen.h
 
   MSFT:*_VS2015_IA32_DLINK_FLAGS = /LIBPATH:"%VS2015_PREFIX%Lib" 
/LIBPATH:"%VS2015_PREFIX%VC\Lib" 
/LIBPATH:"%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x86" 
/LIBPATH:"%WindowsSdkDir%lib\%WindowsSDKLibVersion%\um\x86" /NOLOGO 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB /IGNORE:4086 /MAP /OPT:REF /DEBUG 
/MACHINE:I386 /LTCG Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib 
Advapi32.lib vcruntimed.lib ucrtd.lib
-- 
2.32.0.windows.1



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




[edk2-devel] [Patch 1/1] .pytools/Plugin/LicenseCheck: Use temp directory for git diff output

2021-11-23 Thread Michael D Kinney
Use --output option in git diff command to remove code diffs
from build log on stdout when LicenseCheck plugin is run.
Instead, create a temp directory for the diff output file and
remove the temp directory after the diff output is processed.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .pytool/Plugin/LicenseCheck/LicenseCheck.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/.pytool/Plugin/LicenseCheck/LicenseCheck.py 
b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
index 5733f7bf4ec0..7b998daf6f6b 100644
--- a/.pytool/Plugin/LicenseCheck/LicenseCheck.py
+++ b/.pytool/Plugin/LicenseCheck/LicenseCheck.py
@@ -5,6 +5,7 @@
 ##
 
 import os
+import shutil
 import logging
 import re
 from io import StringIO
@@ -61,12 +62,19 @@ class LicenseCheck(ICiBuildPlugin):
 #   - Junit Logger
 #   - output_stream the StringIO output stream from this plugin via logging
 def RunBuildPlugin(self, packagename, Edk2pathObj, pkgconfig, environment, 
PLM, PLMHelper, tc, output_stream=None):
-return_buffer = StringIO()
-params = "diff --unified=0 origin/master HEAD"
-RunCmd("git", params, outstream=return_buffer)
-p = return_buffer.getvalue().strip()
-patch = p.split("\n")
-return_buffer.close()
+# Create temp directory
+temp_path = os.path.join(Edk2pathObj.WorkspacePath, 'Build', 
'.pytool', 'Plugin', 'LicenseCheck')
+if not os.path.exists(temp_path):
+os.makedirs(temp_path)
+# Output file to use for git diff operations
+temp_diff_output = os.path.join (temp_path, 'diff.txt')
+params = "diff --output={} --unified=0 origin/master 
HEAD".format(temp_diff_output)
+RunCmd("git", params)
+with open(temp_diff_output) as file:
+patch = file.read().strip().split("\n")
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
 
 ignore_files = []
 if "IgnoreFiles" in pkgconfig:
-- 
2.32.0.windows.1



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




[edk2-devel] [PATCH v3 14/15] DynamicTablesPkg: Add FdtHwInfoParser library

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.

FdtHwInfoParser library is an instance of a HwInfoParser
that parses a Device Tree and populates the Configuration
Manager Platform information repository.

FdtHwInfoParser library is aimed at providing a solution
for generating ACPI tables for Guest Partitions launched
by virtual machine managers (VMMs). One such use case is
Kvmtool where the Device Tree for the Guest is passed on
to the firmware by Kvmtool. The Configuration Manager for
Kvmtool firmware shall invoke the FdtHwInfoParser to parse
the Device Tree to populate the hardware information in
the Platform Info Repository. The Kvmtool Configuration
Manager can the process this information to generate the
required ACPI tables for the Guest VM.

This approach also scales well if the number of CPUs or
if the hardware configuration of the Guest partition is
varied.

FdtHwInfoParser thereby introduces 'Dynamic Tables for
Virtual Machines'.

Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=3741
Signed-off-by: Pierre Gondois 
---
 DynamicTablesPkg/DynamicTablesPkg.dsc |   3 +-
 .../FdtHwInfoParserLib/FdtHwInfoParser.c  | 190 ++
 .../FdtHwInfoParserLib/FdtHwInfoParser.h  |  63 ++
 .../FdtHwInfoParserInclude.h  |  17 ++
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf |  56 ++
 5 files changed, 328 insertions(+), 1 deletion(-)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf

diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc 
b/DynamicTablesPkg/DynamicTablesPkg.dsc
index e1439a130143..a2a1b8d004d2 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dsc
+++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
@@ -2,7 +2,7 @@
 #  Dsc file for Dynamic Tables Framework.
 #
 #  Copyright (c) 2019, Linaro Limited. All rights reserved.
-#  Copyright (c) 2019 - 2020, Arm Limited. All rights reserved.
+#  Copyright (c) 2019 - 2021, Arm Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -43,6 +43,7 @@ [Components.common]
   DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
   
DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
   DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
+  DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
 
 [BuildOptions]
   *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.c
new file mode 100644
index ..4c9611194421
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.c
@@ -0,0 +1,190 @@
+/** @file
+  Flattened Device Tree parser library for KvmTool.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "FdtHwInfoParser.h"
+#include "BootArch/ArmBootArchParser.h"
+#include "GenericTimer/ArmGenericTimerParser.h"
+#include "Gic/ArmGicDispatcher.h"
+#include "Pci/ArmPciConfigSpaceParser.h"
+#include "Serial/ArmSerialPortParser.h"
+
+/** Ordered table of parsers/dispatchers.
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+*/
+STATIC CONST FDT_HW_INFO_PARSER_FUNC HwInfoParserTable[] = {
+  ArmBootArchInfoParser,
+  ArmGenericTimerInfoParser,
+  ArmGicDispatcher,
+  ArmPciConfigInfoParser,
+  SerialPortDispatcher
+};
+
+/** Main dispatcher: sequentially call the parsers/dispatchers
+of the HwInfoParserTable.
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+
+  @param [in]  FdtParserHandle A handle to the parser instance.
+  @param [in]  FdtBranch   When searching for DT node name, restrict
+   the search to this Device Tree branch.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Inval

[edk2-devel] [PATCH v3 15/15] DynamicTablesPkg: Handle 16550_WITH_GAS id

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

Handle the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
id when generating an AML description of a serial port. The same
_HID/_CID as the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550
are generated.

Signed-off-by: Pierre Gondois 
---

Notes:
v2:
 - New patch. [Pierre]

 .../Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c   | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git 
a/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
 
b/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
index 79e1fabc9223..85c7293bb4a6 100644
--- 
a/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
+++ 
b/DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.c
@@ -83,7 +83,9 @@ ValidateSerialPortInfo (
 (SerialPortInfo->PortSubtype !=
  EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_DCC) &&
 (SerialPortInfo->PortSubtype !=
- EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550)) {
+ EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550) &&
+(SerialPortInfo->PortSubtype !=
+ EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS)) {
   DEBUG ((
 DEBUG_ERROR,
 "ERROR: UART port subtype is invalid."
@@ -143,6 +145,7 @@ FixupIds (
   // Get the _CID and _HID value to write.
   switch (SerialPortInfo->PortSubtype) {
 case EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550:
+case EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS:
 {
   // If there is a non-BSA compliant HID, use that.
   NonBsaHid = (CONST CHAR8*)PcdGetPtr (PcdNonBsaCompliant16550SerialHid);
-- 
2.25.1



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




[edk2-devel] [PATCH v3 12/15] DynamicTablesPkg: FdtHwInfoParser: Add GIC dispatcher

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The GIC Dispatcher is the top-level component that is responsible
for invoking the respective parsers for GICC, GICD, GIC MSI Frame,
GIC ITS and the GICR.

Signed-off-by: Pierre Gondois 
---
 .../FdtHwInfoParserLib/Gic/ArmGicDispatcher.c | 212 ++
 .../FdtHwInfoParserLib/Gic/ArmGicDispatcher.h |  72 ++
 2 files changed, 284 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDispatcher.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDispatcher.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDispatcher.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDispatcher.c
new file mode 100644
index ..3e5d7fb0cba6
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDispatcher.c
@@ -0,0 +1,212 @@
+/** @file
+  Arm Gic dispatcher.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+  - 
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+**/
+
+#include "FdtHwInfoParser.h"
+#include "Gic/ArmGicCParser.h"
+#include "Gic/ArmGicDispatcher.h"
+#include "Gic/ArmGicDParser.h"
+#include "Gic/ArmGicItsParser.h"
+#include "Gic/ArmGicMsiFrameParser.h"
+#include "Gic/ArmGicRParser.h"
+
+/** List of "compatible" property values for GicV2 interrupt nodes.
+
+  Any other "compatible" value is not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR GicV2CompatibleStr[] = {
+  {"arm,cortex-a15-gic"}
+};
+
+/** COMPATIBILITY_INFO structure for the GICv2.
+*/
+CONST COMPATIBILITY_INFO GicV2CompatibleInfo = {
+  ARRAY_SIZE (GicV2CompatibleStr),
+  GicV2CompatibleStr
+};
+
+/** List of "compatible" property values for GicV3 interrupt nodes.
+
+  Any other "compatible" value is not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR GicV3CompatibleStr[] = {
+  {"arm,gic-v3"}
+};
+
+/** COMPATIBILITY_INFO structure for the GICv3.
+*/
+CONST COMPATIBILITY_INFO GicV3CompatibleInfo = {
+  ARRAY_SIZE (GicV3CompatibleStr),
+  GicV3CompatibleStr
+};
+
+/** Get the Gic version of am interrupt-controller node.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree (Fdt).
+  @param [in]  IntcNode Interrupt-controller node.
+  @param [out] GicVersion   If success, contains the Gic version of the
+interrupt-controller node.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_UNSUPPORTED Unsupported.
+**/
+EFI_STATUS
+EFIAPI
+GetGicVersion (
+  IN  CONST VOID* Fdt,
+  ININT32 IntcNode,
+  OUT   UINT32  * GicVersion
+  )
+{
+  if ((Fdt == NULL) ||
+  (GicVersion == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (FdtNodeIsCompatible (Fdt, IntcNode, &GicV2CompatibleInfo)) {
+*GicVersion = 2;
+  } else if (FdtNodeIsCompatible (Fdt, IntcNode, &GicV3CompatibleInfo)) {
+*GicVersion = 3;
+  } else {
+// Unsupported Gic version.
+ASSERT (0);
+return EFI_UNSUPPORTED;
+  }
+
+  return EFI_SUCCESS;
+}
+
+/** Gic dispatcher.
+
+  This disptacher populates the following structures:
+   - CM_ARM_GICC_INFO
+   - CM_ARM_GICD_INFO
+   - CM_ARM_GIC_MSI_FRAME_INFO
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+
+  @param [in]  FdtParserHandle A handle to the parser instance.
+  @param [in]  FdtBranch   When searching for DT node name, restrict
+   the search to this Device Tree branch.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_NOT_FOUND   Not found.
+  @retval EFI_UNSUPPORTED Unsupported.
+**/
+EFI_STATUS
+EFIAPI
+ArmGicDispatcher (
+  IN  CONST FDT_HW_INFO_PARSER_HANDLE FdtParserHandle,
+  ININT32 FdtBranch
+  )
+{
+  EFI_STATUSStatus;
+  INT32 CpusNode;
+  INT32 IntcNode;
+  UINT32GicVersion;
+  VOID* Fdt;
+
+  if (FdtParserHandle == NULL) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Fdt = FdtParserHandle->Fdt;
+
+  // The "cpus" node resides at the the root of the DT. Fetch it.
+  CpusNode = fdt_path_offset (Fdt, "/cpus");
+  if (CpusNode < 0) {
+return EFI_NOT_FOUND;
+  }
+
+  // Get the interrupt-controller node associated to the "cpus" node.
+  Status = FdtGetIntcParentNode (Fdt, CpusNode, &IntcNode);
+  if (E

[edk2-devel] [PATCH v3 13/15] DynamicTablesPkg: FdtHwInfoParser: Add PCI config parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

On platforms that implement PCIe, the PCIe configuration space
information must be described to a standards-based operating
system in the Memory mapped configuration space base address
Description (MCFG) table.

The PCIe information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/pci/
  host-generic-pci.yaml

The FdtHwInfoParser implements a PCI configuration space Parser
that parses the platform Device Tree to create
CM_ARM_PCI_CONFIG_SPACE_INFO objects which are encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.

The platform Configuration Manager can then utilise this
information when generating the MCFG table.

Signed-off-by: Pierre Gondois 
---

Notes:
v2:
- Handle absence of Pci legacy interrupts in Pci parser. [Pierre]

 .../Pci/ArmPciConfigSpaceParser.c | 797 ++
 .../Pci/ArmPciConfigSpaceParser.h | 142 
 2 files changed, 939 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.h

diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c
new file mode 100644
index ..94b2721caaa9
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c
@@ -0,0 +1,797 @@
+/** @file
+  Arm PCI Configuration Space Parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
+  - PCI Firmware Specification - Revision 3.0
+  - Open Firmware Recommended Practice: Interrupt Mapping, Version 0.9
+  - Devicetree Specification Release v0.3
+  - linux kernel code
+**/
+
+#include "CmObjectDescUtility.h"
+#include 
+
+#include "FdtHwInfoParser.h"
+#include "Pci/ArmPciConfigSpaceParser.h"
+#include "Gic/ArmGicDispatcher.h"
+
+/** List of "compatible" property values for host PCIe bridges nodes.
+
+  Any other "compatible" value is not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR PciCompatibleStr[] = {
+  {"pci-host-ecam-generic"}
+};
+
+/** COMPATIBILITY_INFO structure for the PCIe.
+*/
+STATIC CONST COMPATIBILITY_INFO PciCompatibleInfo = {
+  ARRAY_SIZE (PciCompatibleStr),
+  PciCompatibleStr
+};
+
+/** Get the Segment group (also called: Domain Id) of a host-pci node.
+
+  kernel/Documentation/devicetree/bindings/pci/pci.txt:
+  "It is required to either not set this property at all or set it for all
+  host bridges in the system"
+
+  The function checks the "linux,pci-domain" property of the host-pci node.
+  Either all host-pci nodes must have this property, or none of them. If the
+  property is available, read it. Otherwise dynamically assign the Ids.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree (Fdt).
+  @param [in]  HostPciNode  Offset of a host-pci node.
+  @param [out] SegGroup Segment group assigned to the host-pci controller.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+GetPciSegGroup (
+  IN  CONST VOID   * Fdt,
+  ININT32HostPciNode,
+  OUT   INT32  * SegGroup
+  )
+{
+  CONST UINT8   * Data;
+  INT32   DataSize;
+  STATIC INT32LocalSegGroup = 0;
+
+  if ((Fdt == NULL) ||
+  (SegGroup == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Data = fdt_getprop (Fdt, HostPciNode, "linux,pci-domain", &DataSize);
+  if ((Data == NULL) || (DataSize < 0)) {
+// Did not find property, assign the DomainIds ourselves.
+if (LocalSegGroup < 0) {
+  // "linux,pci-domain" property was defined for another node.
+  ASSERT (0);
+  return EFI_ABORTED;
+}
+
+*SegGroup = LocalSegGroup++;
+return EFI_SUCCESS;
+  }
+
+  if ((DataSize > sizeof (UINT32))  ||
+  (LocalSegGroup > 0)) {
+// Property on more than 1 cell or
+// "linux,pci-domain" property was not defined for a node.
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  // If one node has the "linux,pci-domain" property, then all the host-pci
+  // nodes must have it.
+  LocalSegGroup = -1;
+
+  *SegGroup = fdt32_to_cpu (*(UINT32*)Data);
+  return EFI_SUCCESS;
+}
+
+/** Parse the bus-range controlled by this host-pci node.
+
+  @param [in]   Fdt   Pointer to a Flattened Device Tree (Fdt).
+  @param [in]   HostPciNode   Offset of a host-pci node.
+  @param [in, out]  PciInfo   PCI_PARSER_TABLE structure storing
+  information about the current host-pci.
+
+  @retval EFI_SUCCESS  

[edk2-devel] [PATCH v3 11/15] DynamicTablesPkg: FdtHwInfoParser: Add GICR parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The GIC Redistributor (GICR) structure is part of the Multiple
APIC Description Table (MADT) that enables the discovery of
GIC Redistributor base addresses by providing the Physical Base
Address of a page range containing the GIC Redistributors. More
than one GICR Structure may be presented in the MADT. The GICR
structures should only be used when describing GIC version 3 or
higher.

The GIC Redistributor information is described in the platform
Device Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC Redistributor Parser that
parses the platform Device Tree to create CM_ARM_GIC_REDIST_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT table.

Signed-off-by: Pierre Gondois 
---
 .../FdtHwInfoParserLib/Gic/ArmGicRParser.c| 235 ++
 .../FdtHwInfoParserLib/Gic/ArmGicRParser.h|  47 
 2 files changed, 282 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicRParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicRParser.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicRParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicRParser.c
new file mode 100644
index ..4d89a8c848fe
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicRParser.c
@@ -0,0 +1,235 @@
+/** @file
+  Arm Gic Redistributor Parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - 
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+**/
+
+#include "CmObjectDescUtility.h"
+#include "FdtHwInfoParser.h"
+#include "Gic/ArmGicDispatcher.h"
+#include "Gic/ArmGicRParser.h"
+
+/** Parse a Gic compatible interrupt-controller node,
+extracting GicR information.
+
+  This parser is valid for Gic v3 and higher.
+
+  @param [in]  FdtParserHandle  A handle to the parser instance.
+  @param [in]  GicIntcNode  Offset of a Gic compatible
+interrupt-controller node.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+GicRIntcNodeParser (
+  IN  CONST FDT_HW_INFO_PARSER_HANDLE   FdtParserHandle,
+  ININT32   GicIntcNode
+  )
+{
+  EFI_STATUSStatus;
+  UINT32Index;
+  UINT32RedistReg;
+  UINT32RegSize;
+  INT32 AddressCells;
+  INT32 SizeCells;
+  CONST UINT8 * Data;
+  INT32 DataSize;
+  CM_ARM_GIC_REDIST_INFOGicRInfo;
+  VOID* Fdt;
+
+  if (FdtParserHandle == NULL) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Fdt = FdtParserHandle->Fdt;
+
+  Status = FdtGetParentAddressInfo (
+ Fdt,
+ GicIntcNode,
+ &AddressCells,
+ &SizeCells
+ );
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+return Status;
+  }
+
+  // Don't support more than 64 bits and less than 32 bits addresses.
+  if ((AddressCells < 1)  ||
+  (AddressCells > 2)  ||
+  (SizeCells < 1) ||
+  (SizeCells > 2)) {
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  // The "#redistributor-regions" property is optional.
+  // It indicates the number of GicR.
+  Data = fdt_getprop (Fdt, GicIntcNode, "#redistributor-regions", &DataSize);
+  if ((Data != NULL) && (DataSize == sizeof (UINT32))) {
+// If available, must be on one cell.
+RedistReg = fdt32_to_cpu (*(UINT32*)Data);
+  } else {
+// The DT Spec says GicR is mandatory so we will
+// always have one.
+RedistReg = 1;
+  }
+
+  /*
+Ref: linux/blob/master/Documentation/devicetree/bindings/
+ interrupt-controller/arm%2Cgic-v3.yaml
+
+reg:
+description: |
+  Specifies base physical address(s) and size of the GIC
+  registers, in the following order:
+  - GIC Distributor interface (GICD)
+  - GIC Redistributors (GICR), one range per redistributor region
+  - GIC CPU interface (GICC)
+  - GIC Hypervisor interface (GICH)
+  - GIC Virtual CPU interface (GICV)
+  GICC, GICH and GICV are optional.
+minItems: 2
+maxItems: 4096
+
+Example:
+  interrupt-controller@2c01 {
+compatible = "arm,gic-v3";
+#interrupt-cells = <4>;
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+interrupt-controller;
+redistributor-stride = <0x0 0x4>;  // 256kB stride
+  

[edk2-devel] [PATCH v3 10/15] DynamicTablesPkg: FdtHwInfoParser: Add ITS parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

Arm GIC v3/v4 optionally includes support for GIC Interrupt
Translation Service (ITS). The GIC ITS Structure is part of
the Multiple APIC Description Table (MADT) that describes
the GIC Interrupt Translation service to the OS.

The GIC Interrupt Translation Service information is described
in the platform Device Tree, the bindings for which can be
found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC ITS Parser that parses the
platform Device Tree to create CM_ARM_GIC_ITS_INFO objects which
are encapsulated in a Configuration Manager descriptor object and
added to the platform information repository.

The platform Configuration Manager can then utilise this information
when generating the MADT table.

Signed-off-by: Pierre Gondois 
---
 .../FdtHwInfoParserLib/Gic/ArmGicItsParser.c  | 215 ++
 .../FdtHwInfoParserLib/Gic/ArmGicItsParser.h  |  48 
 2 files changed, 263 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicItsParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicItsParser.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicItsParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicItsParser.c
new file mode 100644
index ..faaa0df1d9be
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicItsParser.c
@@ -0,0 +1,215 @@
+/** @file
+  Arm Gic Interrupt Translation Service Parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - 
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+**/
+
+#include "CmObjectDescUtility.h"
+#include "FdtHwInfoParser.h"
+#include "Gic/ArmGicDispatcher.h"
+#include "Gic/ArmGicItsParser.h"
+
+/** Parse a Gic compatible interrupt-controller node,
+extracting GicIts information.
+
+  This parser is valid for Gic v3 and higher.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree (Fdt).
+  @param [in]  GicIntcNode  Offset of a Gic compatible
+interrupt-controller node.
+  @param [in]  GicItsId Id for the Gic ITS node.
+  @param [in]  GicItsInfo   The CM_ARM_GIC_ITS_INFO to populate.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+GicItsIntcNodeParser (
+  IN  CONST VOID* Fdt,
+  IN  INT32   GicIntcNode,
+  IN  UINT32  GicItsId,
+  IN  CM_ARM_GIC_ITS_INFO   * GicItsInfo
+  )
+{
+  EFI_STATUSStatus;
+  INT32 AddressCells;
+  CONST UINT8 * Data;
+  INT32 DataSize;
+
+  if ((Fdt == NULL) ||
+  (GicItsInfo == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Status = FdtGetParentAddressInfo (Fdt, GicIntcNode, &AddressCells, NULL);
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+return Status;
+  }
+
+  // Don't support more than 64 bits and less than 32 bits addresses.
+  if ((AddressCells < 1)  ||
+  (AddressCells > 2)) {
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  Data = fdt_getprop (Fdt, GicIntcNode, "reg", &DataSize);
+  if ((Data == NULL) || (DataSize < (INT32)(AddressCells * sizeof (UINT32 {
+// If error or not enough space.
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  if (AddressCells == 2) {
+GicItsInfo->PhysicalBaseAddress = fdt64_to_cpu (*(UINT64*)Data);
+  } else {
+GicItsInfo->PhysicalBaseAddress = fdt32_to_cpu (*(UINT32*)Data);
+  }
+
+  // Gic Its Id
+  GicItsInfo->GicItsId = GicItsId;
+
+  // {default = 0}
+  GicItsInfo->ProximityDomain = 0;
+  return Status;
+}
+
+/** CM_ARM_GIC_ITS_INFO parser function.
+
+  This parser expects FdtBranch to be a Gic interrupt-controller node.
+  Gic version must be v3 or higher.
+  typedef struct CmArmGicItsInfo {
+UINT32  GicItsId; // {Populated}
+UINT64  PhysicalBaseAddress;  // {Populated}
+UINT32  ProximityDomain;  // {default = 0}
+  } CM_ARM_GIC_ITS_INFO;
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+
+  @param [in]  FdtParserHandle A handle to the parser instance.
+  @param [in]  FdtBranch   When searching for DT node name, restrict
+   the search to this Device Tree branch.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED

[edk2-devel] [PATCH v3 09/15] DynamicTablesPkg: FdtHwInfoParser: Add MSI Frame parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

Arm GIC version 2 systems that support Message Signalled Interrupts
implement GICv2m MSI frame(s). Each GICv2m MSI frame consists of a
4k page which includes registers to generate message signalled
interrupts to an associated GIC distributor. The frame also includes
registers to discover the set of distributor lines which may be
signalled by MSIs from that frame. A system may have multiple MSI
frames, and separate frames may be defined for secure and non-secure
access.

A MSI Frame structure is part of the Multiple APIC Description Table
(MADT) and must only be used to describe non-secure MSI frames.

The MSI Frame information is described in the platform Device Tree,
the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a MSI Frame Parser that parses
the platform Device Tree to create CM_ARM_GIC_MSI_FRAME_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT table.

Signed-off-by: Pierre Gondois 
---
 .../Gic/ArmGicMsiFrameParser.c| 214 ++
 .../Gic/ArmGicMsiFrameParser.h|  50 
 2 files changed, 264 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicMsiFrameParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicMsiFrameParser.h

diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicMsiFrameParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicMsiFrameParser.c
new file mode 100644
index ..9e6715f69ce7
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicMsiFrameParser.c
@@ -0,0 +1,214 @@
+/** @file
+  Arm Gic Msi frame Parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+  - 
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+**/
+
+#include "CmObjectDescUtility.h"
+#include "FdtHwInfoParser.h"
+#include "Gic/ArmGicDispatcher.h"
+#include "Gic/ArmGicMsiFrameParser.h"
+
+/** List of "compatible" property values for Msi-frame nodes.
+
+  Any other "compatible" value is not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR MsiFrameCompatibleStr[] = {
+  {"arm,gic-v2m-frame"}
+};
+
+/** COMPATIBILITY_INFO structure for the MSI frame.
+*/
+STATIC CONST COMPATIBILITY_INFO MsiFrameCompatibleInfo = {
+  ARRAY_SIZE (MsiFrameCompatibleStr),
+  MsiFrameCompatibleStr
+};
+
+/** Parse a Msi frame node.
+
+  @param [in]  FdtPointer to a Flattened Device Tree (Fdt).
+  @param [in]  MsiFrameNode   Offset of a Msi frame node.
+  @param [in]  MsiFrameId Frame ID.
+  @param [out] MsiFrameInfo   The CM_ARM_GIC_MSI_FRAME_INFO to populate.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+MsiFrameNodeParser (
+  IN  CONST VOID  * Fdt,
+  IN  INT32 MsiFrameNode,
+  IN  UINT32MsiFrameId,
+  OUT CM_ARM_GIC_MSI_FRAME_INFO   * MsiFrameInfo
+  )
+{
+  EFI_STATUSStatus;
+  INT32 AddressCells;
+  CONST UINT8 * Data;
+  INT32 DataSize;
+
+  if ((Fdt == NULL) ||
+  (MsiFrameInfo == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Status = FdtGetParentAddressInfo (Fdt, MsiFrameNode, &AddressCells, NULL);
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+return Status;
+  }
+
+  // Don't support more than 64 bits and less than 32 bits addresses.
+  if ((AddressCells < 1)  ||
+  (AddressCells > 2)) {
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  Data = fdt_getprop (Fdt, MsiFrameNode, "reg", &DataSize);
+  if ((Data == NULL) || (DataSize < (INT32)(AddressCells * sizeof (UINT32 {
+// If error or not enough space.
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  if (AddressCells == 2) {
+MsiFrameInfo->PhysicalBaseAddress = fdt64_to_cpu (*(UINT64*)Data);
+  } else {
+MsiFrameInfo->PhysicalBaseAddress = fdt32_to_cpu (*(UINT32*)Data);
+  }
+
+  MsiFrameInfo->GicMsiFrameId = MsiFrameId;
+
+  return EFI_SUCCESS;
+}
+
+/** CM_ARM_GIC_MSI_FRAME_INFO parser function.
+
+  The following structure is populated:
+  typedef struct CmArmGicMsiFrameInfo {
+UINT32  GicMsiFrameId;// {Populated}
+UINT64  PhysicalBaseAddress;  // {Populated}
+UINT32  Flags;// {default = 0}
+UINT16  SPICount;
+UINT16  SPIBase;
+  } CM_ARM_

[edk2-devel] [PATCH v3 08/15] DynamicTablesPkg: FdtHwInfoParser: Add GICD parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

On ARM-based systems the Generic Interrupt Controller (GIC)
manages interrupts on the system. Each interrupt is identified
in the GIC by an interrupt identifier (INTID). ACPI GSIVs map
one to one to GIC INTIDs for peripheral interrupts, whether
shared (SPI) or private (PPI). The GIC distributor provides
the routing configuration for the interrupts.

The GIC Distributor (GICD) structure is part of the Multiple
APIC Description Table (MADT) that describes the GIC
distributor to the OS. The MADT table is a mandatory table
required for booting a standards-based operating system.

The GIC Distributor information is described in the platform
Device Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC Distributor Parser that
parses the platform Device Tree to create CM_ARM_GICD_INFO
object which is encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT table.

Signed-off-by: Pierre Gondois 
---
 .../FdtHwInfoParserLib/Gic/ArmGicDParser.c| 169 ++
 .../FdtHwInfoParserLib/Gic/ArmGicDParser.h|  50 ++
 2 files changed, 219 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDParser.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDParser.c
new file mode 100644
index ..b58729ac8a19
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicDParser.c
@@ -0,0 +1,169 @@
+/** @file
+  Arm Gic Distributor Parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+  - 
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+**/
+
+#include "CmObjectDescUtility.h"
+#include "FdtHwInfoParser.h"
+#include "Gic/ArmGicDispatcher.h"
+#include "Gic/ArmGicDParser.h"
+
+/** Parse a Gic compatible interrupt-controller node,
+extracting GicD information.
+
+  This parser is valid for Gic v2 and v3.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree (Fdt).
+  @param [in]  GicIntcNode  Offset of a Gic compatible
+interrupt-controller node.
+  @param [in]  GicDInfo The CM_ARM_GICD_INFO to populate.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+GicDIntcNodeParser (
+  IN  CONST VOID* Fdt,
+  IN  INT32   GicIntcNode,
+  IN  CM_ARM_GICD_INFO  * GicDInfo
+  )
+{
+  EFI_STATUSStatus;
+  INT32 AddressCells;
+  CONST UINT8 * Data;
+  INT32 DataSize;
+
+  if ((Fdt == NULL) ||
+  (GicDInfo == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Status = FdtGetParentAddressInfo (Fdt, GicIntcNode, &AddressCells, NULL);
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+return Status;
+  }
+
+  // Don't support more than 64 bits and less than 32 bits addresses.
+  if ((AddressCells < 1)  ||
+  (AddressCells > 2)) {
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  Data = fdt_getprop (Fdt, GicIntcNode, "reg", &DataSize);
+  if ((Data == NULL) || (DataSize < (INT32)(AddressCells * sizeof (UINT32 {
+// If error or not enough space.
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  if (AddressCells == 2) {
+GicDInfo->PhysicalBaseAddress = fdt64_to_cpu (*(UINT64*)Data);
+  } else {
+GicDInfo->PhysicalBaseAddress = fdt32_to_cpu (*(UINT32*)Data);
+  }
+
+  return Status;
+}
+
+/** CM_ARM_GICD_INFO parser function.
+
+  This parser expects FdtBranch to be a Gic interrupt-controller node.
+  At most one CmObj is created.
+  The following structure is populated:
+  typedef struct CmArmGicDInfo {
+UINT64  PhysicalBaseAddress;  // {Populated}
+UINT32  SystemVectorBase;
+UINT8   GicVersion;   // {Populated}
+  } CM_ARM_GICD_INFO;
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+
+  @param [in]  FdtParserHandle A handle to the parser instance.
+  @param [in]  FdtBranch   When searching for DT node name, restrict

[edk2-devel] [PATCH v3 06/15] DynamicTablesPkg: FdtHwInfoParser: Add Serial port parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The Microsoft Debug Port Table 2 (DBG2), the Serial Port Console
Redirector (SPCR) table are mandatory tables required for booting
a standards-based operating system. The DBG2 table is used by the
OS debugger while the SPCR table is used to configure the serial
terminal. Additionally, the serial ports available on a platform
for generic use also need to be described in DSDT/SSDT for an OS
to be able to use the serial ports.

The Arm Base System Architecture 1.0 specification a lists of
supported serial port hardware for Arm Platforms. This list
includes the following serial port UARTs:
 - SBSA/Generic UART
 - a fully 16550 compatible UART.
Along, with these the PL011 UART is the most commonly used serial
port hardware on Arm platforms.

The serial port hardware information is described in the platform
Device Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/serial/serial.yaml
 - linux/Documentation/devicetree/bindings/serial/8250.txt
 - linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
 - linux/Documentation/devicetree/bindings/serial/pl011.yaml

The FdtHwInfoParser implements a Serial Port Parser that parses
the platform Device Tree to create CM_ARM_SERIAL_PORT_INFO objects
with the following IDs:
 - EArmObjSerialConsolePortInfo (for use by SPCR)
 - EArmObjSerialDebugPortInfo (for use by DBG2)
 - EArmObjSerialPortInfo (for use as generic Serial Ports)

The Serial Port for use by SPCR is selected by parsing the Device
Tree for the '/chosen' node with the 'stdout-path' property. The
next Serial Port is selected for use as the Debug Serial Port and
the remaining serial ports are used as generic serial ports.

The CM_ARM_SERIAL_PORT_INFO objects are encapsulated in Configuration
Manager descriptor objects with the respective IDs and are added to
the platform information repository.

The platform Configuration Manager can then utilise this information
when generating the DBG2, SPCR and the SSDT serial port tables.

Signed-off-by: Pierre Gondois 
---

Notes:
v2:
- Add pl011 compatible string in serial port parser. [Sami]
- Use 16550_with_GAS ID when 16550 is detected in serial
  port parser. [Sami]
v3:
- Remove trailing whitespace. [Pierre]

 .../Serial/ArmSerialPortParser.c  | 620 ++
 .../Serial/ArmSerialPortParser.h  |  47 ++
 2 files changed, 667 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.h

diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c
new file mode 100644
index ..b05b04da41a6
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c
@@ -0,0 +1,620 @@
+/** @file
+  Arm Serial Port Parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/serial/serial.yaml
+  - linux/Documentation/devicetree/bindings/serial/8250.txt
+  - linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
+  - linux/Documentation/devicetree/bindings/serial/pl011.yaml
+**/
+
+#include 
+
+#include "CmObjectDescUtility.h"
+#include "FdtHwInfoParser.h"
+#include "Serial/ArmSerialPortParser.h"
+
+/** List of "compatible" property values for serial port nodes.
+
+  Any other "compatible" value is not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR SerialCompatibleStr[] = {
+  {"ns16550a"},
+  {"arm,sbsa-uart"},
+  {"arm,pl011"}
+};
+
+/** COMPATIBILITY_INFO structure for the SerialCompatible.
+*/
+CONST COMPATIBILITY_INFO SerialCompatibleInfo = {
+  ARRAY_SIZE (SerialCompatibleStr),
+  SerialCompatibleStr
+};
+
+/** 16550 UART compatible strings.
+
+  Any string of this list must be part of SerialCompatible.
+*/
+STATIC CONST COMPATIBILITY_STR Serial16550CompatibleStr[] = {
+  {"ns16550a"}
+};
+
+/** COMPATIBILITY_INFO structure for the Serial16550Compatible.
+*/
+CONST COMPATIBILITY_INFO Serial16550CompatibleInfo = {
+  ARRAY_SIZE (Serial16550CompatibleStr),
+  Serial16550CompatibleStr
+};
+
+/** SBSA UART compatible strings.
+
+  Include PL011 as SBSA uart is a subset of PL011.
+
+  Any string of this list must be part of SerialCompatible.
+*/
+STATIC CONST COMPATIBILITY_STR SerialSbsaCompatibleStr[] = {
+  {"arm,sbsa-uart"},
+  {"arm,pl011"}
+};
+
+/** COMPATIBILITY_INFO structure for the SerialSbsaCompatible.
+*/
+CONST COMPATIBILITY_INFO SerialSbsaCompatibleInfo = {
+  ARRAY_SIZE (SerialSbsaCompatibleStr),
+  SerialSbsaCompatibleStr
+};
+
+/** Parse a serial port node.
+
+  @param [in]  Fdt   Pointer to a Flattened Device Tree (Fdt).
+  @param [in]  SerialPortNodeOffset of a serial-port node.
+  @param [in]  SerialPortInf

[edk2-devel] [PATCH v3 07/15] DynamicTablesPkg: FdtHwInfoParser: Add GICC parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The GIC CPU Interface (GICC) structure is part of the Multiple
APIC Description Table (MADT) that describes the interrupt model
for the platform. The MADT table is a mandatory table required
for booting a standards-based operating system.

Arm requires the GIC interrupt model, in which the logical
processors are required to have a Processor Device object in
the DSDT, and must convey each processor's GIC information to
the OS using the GICC structure.

The CPU and GIC information is described in the platform Device
Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/arm/cpus.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC CPU Interface Parser that
parses the platform Device Tree to create CM_ARM_GICC_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT and the SSDT CPU
information tables.

Signed-off-by: Pierre Gondois 
---

Notes:
v2:
- Handle Affinity3 field in GicC parser. [Sami]
v3:
- Populate the 64 bits of the MPIDR field of the GicC CmObj.
  [Sami]

 .../FdtHwInfoParserLib/Gic/ArmGicCParser.c| 769 ++
 .../FdtHwInfoParserLib/Gic/ArmGicCParser.h|  67 ++
 2 files changed, 836 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicCParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicCParser.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicCParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicCParser.c
new file mode 100644
index ..7c221697975b
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Gic/ArmGicCParser.c
@@ -0,0 +1,769 @@
+/** @file
+  Arm Gic cpu parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/arm/cpus.yaml
+  - linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+  - 
linux/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+**/
+
+#include "FdtHwInfoParser.h"
+#include "CmObjectDescUtility.h"
+#include "Gic/ArmGicCParser.h"
+#include "Gic/ArmGicDispatcher.h"
+
+/** List of "compatible" property values for CPU nodes.
+
+  Any other "compatible" value is not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR CpuCompatibleStr[] = {
+  {"arm,arm-v7"},
+  {"arm,arm-v8"},
+  {"arm,cortex-a15"},
+  {"arm,cortex-a7"},
+  {"arm,cortex-a57"}
+};
+
+/** COMPATIBILITY_INFO structure for CPU nodes.
+*/
+STATIC CONST COMPATIBILITY_INFO CpuCompatibleInfo = {
+  ARRAY_SIZE (CpuCompatibleStr),
+  CpuCompatibleStr
+};
+
+/** Parse a "cpu" node.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree (Fdt).
+  @param [in]  CpuNode  Offset of a cpu node.
+  @param [in]  GicVersion   Version of the GIC.
+  @param [in]  AddressCells Number of address cells used for the reg
+property.
+  @param [out] GicCInfo CM_ARM_GICC_INFO structure to populate.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_UNSUPPORTED Unsupported.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+CpuNodeParser (
+  IN  CONST VOID  * Fdt,
+  ININT32   CpuNode,
+  INUINT32  GicVersion,
+  INUINT32  AddressCells,
+  OUT   CM_ARM_GICC_INFO  * GicCInfo
+)
+{
+  CONST UINT8   * Data;
+  INT32   DataSize;
+  UINT32  ProcUid;
+  UINT64  MpIdr;
+  UINT64  CheckAffMask;
+
+  MpIdr = 0;
+  CheckAffMask = ARM_CORE_AFF0 | ARM_CORE_AFF1 | ARM_CORE_AFF2;
+
+  if (GicCInfo == NULL) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Data = fdt_getprop (Fdt, CpuNode, "reg", &DataSize);
+  if ((Data == NULL)  ||
+  ((DataSize != sizeof (UINT32))  &&
+   (DataSize != sizeof (UINT64 {
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  /* If cpus node's #address-cells property is set to 2
+ The first reg cell bits [7:0] must be set to
+ bits [39:32] of MPIDR_EL1.
+ The second reg cell bits [23:0] must be set to
+ bits [23:0] of MPIDR_EL1.
+   */
+  if (AddressCells == 2) {
+MpIdr = fdt64_to_cpu (*((UINT64*)Data));
+CheckAffMask |= ARM_CORE_AFF3;
+  } else {
+MpIdr = fdt32_to_cpu (*((UINT32*)Data));
+  }
+
+  if ((MpIdr & ~CheckAffMask) != 0) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  // To fit the Affinity [0-3] a 32bits value

[edk2-devel] [PATCH v3 05/15] DynamicTablesPkg: FdtHwInfoParser: Generic Timer Parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The Generic Timer Description Table (GTDT) is a mandatory table
required for booting a standards-based operating system. It
provides an OSPM with information about a system's Generic Timer
configuration. The Generic Timer (GT) is a standard timer interface
implemented on ARM processor-based systems. The GTDT provides OSPM
with information about a system's GT interrupt configurations, for
both per-processor timers, and platform (memory-mapped) timers.

The Generic Timer information is described in the platform Device
Tree. The Device Tree bindings for the Generic timers can be found
at:
 - linux/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml

The FdtHwInfoParser implements a Generic Timer Parser that parses
the platform Device Tree to create a CM_ARM_GENERIC_TIMER_INFO
object. The CM_ARM_GENERIC_TIMER_INFO object is encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.

The platform Configuration Manager can then utilise this information
when generating the GTDT table.

Note: The Generic Timer Parser currently does not support parsing
of memory-mapped platform timers.

Signed-off-by: Pierre Gondois 
---
 .../GenericTimer/ArmGenericTimerParser.c  | 254 ++
 .../GenericTimer/ArmGenericTimerParser.h  |  66 +
 2 files changed, 320 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.h

diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.c
 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.c
new file mode 100644
index ..e7095396a5a8
--- /dev/null
+++ 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.c
@@ -0,0 +1,254 @@
+/** @file
+  Arm generic timer parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+**/
+
+#include "FdtHwInfoParser.h"
+#include "CmObjectDescUtility.h"
+#include "GenericTimer/ArmGenericTimerParser.h"
+#include "Gic/ArmGicDispatcher.h"
+
+/** List of "compatible" property values for timer nodes.
+
+  Other "compatible" values are not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR TimerCompatibleStr[] = {
+  {"arm,armv7-timer"},
+  {"arm,armv8-timer"}
+};
+
+/** Timer compatiblity information.
+*/
+STATIC CONST COMPATIBILITY_INFO TimerCompatibleInfo = {
+  ARRAY_SIZE (TimerCompatibleStr),
+  TimerCompatibleStr
+};
+
+/** Parse a timer node.
+
+  @param [in]  FdtPointer to a Flattened Device Tree (Fdt).
+  @param [in]  TimerNode  Offset of a timer node.
+  @param [in]  GenericTimerInfo   The CM_ARM_BOOT_ARCH_INFO to populate.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+TimerNodeParser (
+  IN  CONST VOID  * Fdt,
+  ININT32   TimerNode,
+  INCM_ARM_GENERIC_TIMER_INFO * GenericTimerInfo
+  )
+{
+  EFI_STATUS  Status;
+  CONST UINT32  * Data;
+  INT32   IntcNode;
+  UINT32  GicVersion;
+  INT32   DataSize;
+  INT32   IntCells;
+  BOOLEAN AlwaysOnTimer;
+
+  if ((Fdt == NULL) ||
+  (GenericTimerInfo == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Data = fdt_getprop (Fdt, TimerNode, "always-on", &DataSize);
+  if ((Data == NULL) || (DataSize < 0)) {
+AlwaysOnTimer = FALSE;
+  } else {
+AlwaysOnTimer = TRUE;
+  }
+
+  // Get the associated interrupt-controller.
+  Status = FdtGetIntcParentNode (Fdt, TimerNode, &IntcNode);
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+return Status;
+  }
+
+  // Check that the interrupt-controller node is a Gic.
+  Status = GetGicVersion (Fdt, IntcNode, &GicVersion);
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+return Status;
+  }
+
+  // Get the number of cells used to encode an interrupt.
+  Status = FdtGetInterruptCellsInfo (Fdt, IntcNode, &IntCells);
+  if (EFI_ERROR (Status)) {
+ASSERT (0);
+if (Status == EFI_NOT_FOUND) {
+  // Should have found the node.
+  Status = EFI_ABORTED;
+}
+return Status;
+  }
+
+  Data = fdt_getprop (Fdt, TimerNode, "interrupts", &DataSize);
+  if ((Data == NULL) ||
+  (DataSize != (FdtMaxTimerItem * IntCells * sizeof (UINT32 {
+// If error or not FdtMaxTimerItem interrupts.
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  GenericTimerInfo->SecurePL1TimerGSIV =
+FdtGetInterruptId (&Data[FdtSecureTimerIrq * IntCells]);
+  GenericTimerInfo->SecurePL1TimerFlags =
+FdtGetInterruptFlags (&Data[FdtSe

[edk2-devel] [PATCH v3 04/15] DynamicTablesPkg: FdtHwInfoParser: Add Boot Arch parser

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The Fixed ACPI Description Table (FADT) is a mandatory table
required for booting a standards-based operating system. The
FADT table has an 'ARM Boot Architecture Flags' field that is
used by an OS at boot time to determine the code path during
boot. This field is used to specify if the platform complies
with the PSCI specification. It is also used to describe the
conduit (SMC/HVC) to be used for PSCI.

The PSCI compliance information for a platform is described
in the platform Device Tree, the bindings for which can be
found at:
 - linux/Documentation/devicetree/bindings/arm/psci.yaml

The FdtHwInfoParser implements a Boot Arch Parser that parses
the platform Device Tree to create a CM_ARM_BOOT_ARCH_INFO
object. The CM_ARM_BOOT_ARCH_INFO object is encapsulated in
a Configuration Manager descriptor object and added to the
platform information repository.

The platform Configuration Manager can then utilise this
information when generating the FADT table.

Signed-off-by: Pierre Gondois 
---
 .../BootArch/ArmBootArchParser.c  | 159 ++
 .../BootArch/ArmBootArchParser.h  |  45 +
 2 files changed, 204 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.h

diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.c
new file mode 100644
index ..5040e50eb16a
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.c
@@ -0,0 +1,159 @@
+/** @file
+  Arm boot architecture parser.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - linux/Documentation/devicetree/bindings/arm/psci.yaml
+**/
+
+#include "FdtHwInfoParser.h"
+#include "CmObjectDescUtility.h"
+#include "BootArch/ArmBootArchParser.h"
+
+/** List of "compatible" property values for Psci nodes.
+
+  Other "compatible" values are not supported by this module.
+*/
+STATIC CONST COMPATIBILITY_STR PsciCompatibleStr[] = {
+  {"arm,psci-0.2"},
+  {"arm,psci"}
+};
+
+/** COMPATIBILITY_INFO structure for the PsciCompatibleInfo.
+*/
+STATIC CONST COMPATIBILITY_INFO PsciCompatibleInfo = {
+  ARRAY_SIZE (PsciCompatibleStr),
+  PsciCompatibleStr
+};
+
+/** List of PSCI method strings.
+*/
+STATIC CONST CHAR8  *PsciMethod[] = {
+  "smc",
+  "hvc"
+};
+
+/** Parse a Psci node.
+
+  @param [in]  FdtPointer to a Flattened Device Tree (Fdt).
+  @param [in]  PsciNode   Offset of a Psci node.
+  @param [in]  BootArchInfo   The CM_ARM_BOOT_ARCH_INFO to populate.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+PsciNodeParser (
+  IN  CONST VOID* Fdt,
+  ININT32 PsciNode,
+  INCM_ARM_BOOT_ARCH_INFO   * BootArchInfo
+  )
+{
+  CONST VOID* Data;
+  INT32   DataSize;
+
+  if ((Fdt == NULL) ||
+  (BootArchInfo == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  // Default to parking protocol
+  BootArchInfo->BootArchFlags = 0;
+
+  Data = fdt_getprop (Fdt, PsciNode, "method", &DataSize);
+  if ((Data == NULL) || (DataSize < 0)) {
+ASSERT (0);
+return EFI_ABORTED;
+  }
+
+  // Check PSCI conduit.
+  if (AsciiStrnCmp (Data, PsciMethod[0], DataSize) == 0) {
+BootArchInfo->BootArchFlags = EFI_ACPI_6_3_ARM_PSCI_COMPLIANT;
+
+  } else if (AsciiStrnCmp (Data, PsciMethod[1], DataSize) == 0) {
+BootArchInfo->BootArchFlags = (EFI_ACPI_6_3_ARM_PSCI_COMPLIANT |
+   EFI_ACPI_6_3_ARM_PSCI_USE_HVC);
+  }
+
+  return EFI_SUCCESS;
+}
+
+/** CM_ARM_BOOT_ARCH_INFO parser function.
+
+  The following structure is populated:
+  typedef struct CmArmBootArchInfo {
+UINT16  BootArchFlags;// {Populated}
+  } CM_ARM_BOOT_ARCH_INFO;
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+
+  @param [in]  FdtParserHandle A handle to the parser instance.
+  @param [in]  FdtBranch   When searching for DT node name, restrict
+   the search to this Device Tree branch.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_NOT_FOUND   Not found.
+  @retval EFI_UNSUPPORTED  

[edk2-devel] [PATCH v3 03/15] DynamicTablesPkg: FdtHwInfoParser: Add FDT utility functions

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration Manager
objects.

Therefore, add a set of helper functions to simplify parsing of
the platform Device Tree.

Signed-off-by: Pierre Gondois 
---
 .../Library/FdtHwInfoParserLib/FdtUtility.c   | 907 ++
 .../Library/FdtHwInfoParserLib/FdtUtility.h   | 458 +
 2 files changed, 1365 insertions(+)
 create mode 100644 DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
 create mode 100644 DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
new file mode 100644
index ..3a88fda46127
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
@@ -0,0 +1,907 @@
+/** @file
+  Flattened device tree utility.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - Device tree Specification - Release v0.3
+  - linux/Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic.yaml
+  - 
linux//Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic.yaml
+**/
+
+#include 
+#include "FdtUtility.h"
+
+/** Get the interrupt Id of an interrupt described in a fdt.
+
+  Data must describe a GIC interrupt. A GIC interrupt is on at least
+  3 UINT32 cells.
+  This function DOES NOT SUPPORT extended SPI range and extended PPI range.
+
+  @param [in]  Data   Pointer to the first cell of an "interrupts" property.
+
+  @retval  The interrupt id.
+**/
+UINT32
+EFIAPI
+FdtGetInterruptId (
+  UINT32 CONST  * Data
+  )
+{
+  UINT32  IrqType;
+  UINT32  IrqId;
+
+  ASSERT (Data != NULL);
+
+  IrqType = fdt32_to_cpu (Data[IRQ_TYPE_OFFSET]);
+  IrqId = fdt32_to_cpu (Data[IRQ_NUMBER_OFFSET]);
+
+  switch (IrqType) {
+  case DT_SPI_IRQ:
+IrqId += SPI_OFFSET;
+break;
+
+  case DT_PPI_IRQ:
+IrqId += PPI_OFFSET;
+break;
+
+  default:
+ASSERT (0);
+IrqId = 0;
+  }
+
+  return IrqId;
+}
+
+/** Get the ACPI interrupt flags of an interrupt described in a fdt.
+
+  Data must describe a GIC interrupt. A GIC interrupt is on at least
+  3 UINT32 cells.
+
+  PPI interrupt cpu mask on bits [15:8] are ignored.
+
+  @param [in]  Data   Pointer to the first cell of an "interrupts" property.
+
+  @retval  The interrupt flags (for ACPI).
+**/
+UINT32
+EFIAPI
+FdtGetInterruptFlags (
+  UINT32 CONST  * Data
+  )
+{
+  UINT32  IrqFlags;
+  UINT32  AcpiIrqFlags;
+
+  ASSERT (Data != NULL);
+
+  IrqFlags = fdt32_to_cpu (Data[IRQ_FLAGS_OFFSET]);
+
+  AcpiIrqFlags = DT_IRQ_IS_EDGE_TRIGGERED (IrqFlags) ? BIT0 : 0;
+  AcpiIrqFlags |= DT_IRQ_IS_ACTIVE_LOW (IrqFlags) ? BIT1 : 0;
+
+  return AcpiIrqFlags;
+}
+
+/** Check whether a node has the input name.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree.
+  @param [in]  Node Offset of the node to check the name.
+  @param [in]  SearchName   Node name to search.
+This is a NULL terminated string.
+
+  @retval TrueThe node has the input name.
+  @retval FALSE   Otherwise, or error.
+**/
+STATIC
+BOOLEAN
+EFIAPI
+FdtNodeHasName (
+  IN  CONST VOID  * Fdt,
+  ININT32   Node,
+  IN  CONST VOID  * SearchName
+  )
+{
+  CONST CHAR8   * NodeName;
+  UINT32  Length;
+
+  if ((Fdt == NULL) ||
+  (SearchName == NULL)) {
+ASSERT (0);
+return FALSE;
+  }
+
+  // Always compare the whole string. Don't stop at the "@" char.
+  Length = (UINT32)AsciiStrLen (SearchName);
+
+  // Get the address of the node name.
+  NodeName = fdt_offset_ptr (Fdt, Node + FDT_TAGSIZE, Length + 1);
+  if (NodeName == NULL) {
+return FALSE;
+  }
+
+  // SearchName must be longer than the node name.
+  if (Length > AsciiStrLen (NodeName)) {
+return FALSE;
+  }
+
+  if (AsciiStrnCmp (NodeName, SearchName, Length) != 0) {
+return FALSE;
+  }
+
+  // The name matches perfectly, or
+  // the node name is XXX@addr and the XXX matches.
+  if ((NodeName[Length] == '\0') ||
+  (NodeName[Length] == '@')) {
+return TRUE;
+  }
+
+  return FALSE;
+}
+
+/** Iterate through the list of strings in the Context,
+and check whether at least one string is matching the
+"compatible" property of the node.
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree.
+  @param [in]  Node Offset of the node to operate the check on.
+  @param [in]  CompatInfo   COMPATIBILITY_INFO containing the list of 
compatible
+strings to compare with the "compatible" property
+of the node.
+
+  @retval TRUEAt least one string matched, the node is compatible.
+  @retval FALSE   Otherwise, or error.
+**/
+BOOLEAN
+EFIAPI
+FdtNodeIsCompatible (
+  IN  CONST VOID* Fdt,
+  ININT32 Node,
+  IN  CONST VOID* CompatInfo
+  )

[edk2-devel] [PATCH v3 01/15] DynamicTablesPkg: Definition for HwInfoParser interface

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.

The Configuration Manager can then utilise this information
to generate ACPI tables for the platform.

Therefore, define an interface for the HwInfoParser library
class.

Signed-off-by: Pierre Gondois 
Co-authored-by: Sami Mujawar 
---
 DynamicTablesPkg/DynamicTablesPkg.dec |  3 +
 .../Include/Library/HwInfoParserLib.h | 99 +++
 2 files changed, 102 insertions(+)
 create mode 100644 DynamicTablesPkg/Include/Library/HwInfoParserLib.h

diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec 
b/DynamicTablesPkg/DynamicTablesPkg.dec
index 9996bdf6f520..80a61dd2dbac 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dec
+++ b/DynamicTablesPkg/DynamicTablesPkg.dec
@@ -24,6 +24,9 @@ [LibraryClasses]
   ##  @libraryclass  Defines a set of APIs for Dynamic AML generation.
   AmlLib|Include/Library/AmlLib/AmlLib.h
 
+  ##  @libraryclass  Defines a set of APIs to a hardware information parser.
+  HwInfoParserLib|Include/Library/HwInfoParserLib.h
+
   ##  @libraryclass  Defines a set of methods for fixing up a SSDT Serial Port.
   SsdtSerialPortFixupLib|Include/Library/SsdtSerialPortFixupLib.h
 
diff --git a/DynamicTablesPkg/Include/Library/HwInfoParserLib.h 
b/DynamicTablesPkg/Include/Library/HwInfoParserLib.h
new file mode 100644
index ..472fbefcc6b5
--- /dev/null
+++ b/DynamicTablesPkg/Include/Library/HwInfoParserLib.h
@@ -0,0 +1,99 @@
+/** @file
+  Hardware information parser library.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef HW_INFO_PARSER_LIB_H_
+#define HW_INFO_PARSER_LIB_H_
+
+#include 
+
+/** A handle to the HwInfoParser instance.
+*/
+typedef VOID * HW_INFO_PARSER_HANDLE;
+
+/** Function pointer called by the parser to add information.
+
+  Callback function that the parser can use to add new
+  CmObj. This function must copy the CmObj data and not rely on
+  the parser preserving the CmObj memory.
+  This function is responsible of the Token allocation.
+
+  @param  [in]  ParserHandle  A handle to the parser instance.
+  @param  [in]  Context   A pointer to the caller's context provided in
+  HwInfoParserInit ().
+  @param  [in]  CmObjDesc CM_OBJ_DESCRIPTOR containing the CmObj(s) to add.
+  @param  [out] Token If provided and success, contain the token
+  generated for the CmObj.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+typedef
+EFI_STATUS
+(EFIAPI * HW_INFO_ADD_OBJECT) (
+  INHW_INFO_PARSER_HANDLE   ParserHandle,
+  INVOID  * Context,
+  IN  CONST CM_OBJ_DESCRIPTOR * CmObjDesc,
+  OUT   CM_OBJECT_TOKEN   * Token OPTIONAL
+  );
+
+/** Initialise the HwInfoParser.
+
+  The HwInfoParser shall use the information provided by the HwDataSource
+  to initialise the internal state of the parser or to index the data. This
+  internal state shall be linked to the ParserHandle using an implementation
+  defined mechanism.
+
+  @param [in]   HwDataSourcePointer to the blob containing the hardware
+information. It can be a pointer to a Device
+Tree, an XML file, etc. or any other data
+structure defined by the HwInfoParser.
+  @param [in]   Context A pointer to the caller's context.
+  @param [in]   HwInfoAdd   Function pointer called by the parser when
+adding information.
+  @param [out]  ParserHandleA handle to the parser instance.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+HwInfoParserInit (
+  INVOID  * HwDataSource,
+  INVOID  * Context,
+  INHW_INFO_ADD_OBJECT  HwInfoAdd,
+  OUT   HW_INFO_PARSER_HANDLE * ParserHandle
+  );
+
+/** Parse the data provided by the HwDataSource.
+
+  @param [in]  ParserHandleA handle to the parser instance.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_OUT_OF_RESOURCESAn allocation has failed.
+**/
+EFI_STATUS
+EFIAPI
+HwInfoParse (
+  IN  HW_INFO_PARSER_HANDLE  ParserHandle
+  );
+
+/** Cleanup any internal state and resources that were allocated
+by the the HwInfoParser.
+
+  @param [in]  ParserHandleA handle to the parser instance.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+HwInf

[edk2-devel] [PATCH v3 02/15] DynamicTablesPkg: FdtHwInfoParser: CM Object descriptor helper

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

FdtHwInfoParserLib is an instance of the HwInfoParser. The
FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration
Manager objects that describe the platform hardware.
These Configuration Manager objects are encapsulated in
Configuration Manager Object Descriptors.

Therefore, add helper functions to create and free the
Configuration Manager Object descriptors.

Signed-off-by: Pierre Gondois 
---
 .../FdtHwInfoParserLib/CmObjectDescUtility.c  | 302 ++
 .../FdtHwInfoParserLib/CmObjectDescUtility.h  | 131 
 2 files changed, 433 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.h

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.c
new file mode 100644
index ..d54256df8e83
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.c
@@ -0,0 +1,302 @@
+/** @file
+  Configuration manager Object Descriptor Utility.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+
+#include "CmObjectDescUtility.h"
+
+/** Create a CM_OBJ_DESCRIPTOR.
+
+  @param [in]  ObjectId   CM_OBJECT_ID of the node.
+  @param [in]  Count  Number of CmObj stored in the
+  data field.
+  @param [in]  Data   Pointer to one or more CmObj objects.
+  The content of this Data buffer is copied.
+  @param [in]  Size   Size of the Data buffer.
+  @param [out] NewCmObjDesc   The created CM_OBJ_DESCRIPTOR.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_OUT_OF_RESOURCESAn allocation has failed.
+**/
+EFI_STATUS
+EFIAPI
+CreateCmObjDesc (
+  IN  CM_OBJECT_ID  ObjectId,
+  IN  UINT32Count,
+  IN  VOID* Data,
+  IN  UINT32Size,
+  OUT CM_OBJ_DESCRIPTOR  ** NewCmObjDesc
+  )
+{
+  CM_OBJ_DESCRIPTOR   * CmObjDesc;
+  VOID* DataBuffer;
+
+  if ((Count == 0)  ||
+  (Data == NULL)||
+  (Size == 0)   ||
+  (NewCmObjDesc == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  CmObjDesc = AllocateZeroPool (sizeof (CM_OBJ_DESCRIPTOR));
+  if (CmObjDesc == NULL) {
+ASSERT (0);
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  DataBuffer = AllocateCopyPool (Size, Data);
+  if (DataBuffer == NULL) {
+FreePool (CmObjDesc);
+ASSERT (0);
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  CmObjDesc->ObjectId = ObjectId;
+  CmObjDesc->Count = Count;
+  CmObjDesc->Data = DataBuffer;
+  CmObjDesc->Size = Size;
+
+  *NewCmObjDesc = CmObjDesc;
+
+  return EFI_SUCCESS;
+}
+
+/** Free resources allocated for the CM_OBJ_DESCRIPTOR.
+
+  @param [in] CmObjDesc   Pointer to the CM_OBJ_DESCRIPTOR.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+FreeCmObjDesc (
+  IN CM_OBJ_DESCRIPTOR  * CmObjDesc
+  )
+{
+  if (CmObjDesc == NULL) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (CmObjDesc->Data != NULL) {
+FreePool (CmObjDesc->Data);
+  }
+
+  FreePool (CmObjDesc);
+  return EFI_SUCCESS;
+}
+
+/** Add a single CmObj to the Configuration Manager.
+
+  @param  [in]  FdtParserHandle   A handle to the parser instance.
+  @param  [in]  ObjectId  CmObj ObjectId.
+  @param  [in]  Data  CmObj Data.
+  @param  [in]  Size  CmObj Size.
+  @param  [out] Token If provided and success,
+  token generated for this CmObj.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+AddSingleCmObj (
+  IN  CONST FDT_HW_INFO_PARSER_HANDLE   FdtParserHandle,
+  INCM_OBJECT_IDObjectId,
+  INVOID*Data,
+  INUINT32  Size,
+  OUT   CM_OBJECT_TOKEN *TokenOPTIONAL
+  )
+{
+  EFI_STATUS  Status;
+  CM_OBJ_DESCRIPTOR   CmObjDesc;
+
+  if ((FdtParserHandle == NULL) ||
+  (FdtParserHandle->HwInfoAdd == NULL)  ||
+  (Data == NULL)||
+  (Size == 0)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  CmObjDesc.ObjectId = ObjectId;
+  CmObjDesc.Count = 1;
+  CmObjDesc.Data = Data;
+  CmObjDesc.Size = Size;
+
+  // Add the CmObj.
+  // Don't ask for a token.
+  Status = FdtParserHandle->HwInfoAdd (
+  FdtParserHandle,
+  FdtParserHandle->Context,
+ 

[edk2-devel] [PATCH v3 00/15] Implement a FdtHwInfoParserLib

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

v3:
- Populate the 64 bits of the MPIDR field of the GicC CmObj.
[Sami]
- Fix typos. [Sami]
v2:
- Handle absence of Pci legacy interrupts in Pci parser. [Pierre]
- Handle Affinity3 field in GicC parser. [Sami]
- Add pl011 compatible string in serial port parser. [Sami]
- Use 16550_with_GAS ID when 16550 is detected in serial
 port parser. [Sami]
- Use ASSERT_EFI_ERROR when possible. [Sami]
- Fix typos and add comments. [Pierre]

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

The generic HwInfoParserLib provides an interface to parse hardware
information stored in certain a data type (e.g.: xml, device tree,
...) and generate objects that can be used by the DynamicTablesPkg
framework to generate another hardware description (e.g.:
SMBIOS tables, ACPI tables, ...).

This patch-set also implements a FdtHwInfoParserLib, parsing
hardware information stored in a device tree. The objects
generated by the library have been used ACPI tables.

The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1787_Implement_FdtHwInfoParser_v3

Pierre Gondois (15):
  DynamicTablesPkg: Definition for HwInfoParser interface
  DynamicTablesPkg: FdtHwInfoParser: CM Object descriptor helper
  DynamicTablesPkg: FdtHwInfoParser: Add FDT utility functions
  DynamicTablesPkg: FdtHwInfoParser: Add Boot Arch parser
  DynamicTablesPkg: FdtHwInfoParser: Generic Timer Parser
  DynamicTablesPkg: FdtHwInfoParser: Add Serial port parser
  DynamicTablesPkg: FdtHwInfoParser: Add GICC parser
  DynamicTablesPkg: FdtHwInfoParser: Add GICD parser
  DynamicTablesPkg: FdtHwInfoParser: Add MSI Frame parser
  DynamicTablesPkg: FdtHwInfoParser: Add ITS parser
  DynamicTablesPkg: FdtHwInfoParser: Add GICR parser
  DynamicTablesPkg: FdtHwInfoParser: Add GIC dispatcher
  DynamicTablesPkg: FdtHwInfoParser: Add PCI config parser
  DynamicTablesPkg: Add FdtHwInfoParser library
  DynamicTablesPkg: Handle 16550_WITH_GAS id

 DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
 DynamicTablesPkg/DynamicTablesPkg.dsc |   3 +-
 .../Include/Library/HwInfoParserLib.h |  99 ++
 .../SsdtSerialPortFixupLib.c  |   5 +-
 .../BootArch/ArmBootArchParser.c  | 159 +++
 .../BootArch/ArmBootArchParser.h  |  45 +
 .../FdtHwInfoParserLib/CmObjectDescUtility.c  | 302 ++
 .../FdtHwInfoParserLib/CmObjectDescUtility.h  | 131 +++
 .../FdtHwInfoParserLib/FdtHwInfoParser.c  | 190 
 .../FdtHwInfoParserLib/FdtHwInfoParser.h  |  63 ++
 .../FdtHwInfoParserInclude.h  |  17 +
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf |  56 ++
 .../Library/FdtHwInfoParserLib/FdtUtility.c   | 907 ++
 .../Library/FdtHwInfoParserLib/FdtUtility.h   | 458 +
 .../GenericTimer/ArmGenericTimerParser.c  | 254 +
 .../GenericTimer/ArmGenericTimerParser.h  |  66 ++
 .../FdtHwInfoParserLib/Gic/ArmGicCParser.c| 769 +++
 .../FdtHwInfoParserLib/Gic/ArmGicCParser.h|  67 ++
 .../FdtHwInfoParserLib/Gic/ArmGicDParser.c| 169 
 .../FdtHwInfoParserLib/Gic/ArmGicDParser.h|  50 +
 .../FdtHwInfoParserLib/Gic/ArmGicDispatcher.c | 212 
 .../FdtHwInfoParserLib/Gic/ArmGicDispatcher.h |  72 ++
 .../FdtHwInfoParserLib/Gic/ArmGicItsParser.c  | 215 +
 .../FdtHwInfoParserLib/Gic/ArmGicItsParser.h  |  48 +
 .../Gic/ArmGicMsiFrameParser.c| 214 +
 .../Gic/ArmGicMsiFrameParser.h|  50 +
 .../FdtHwInfoParserLib/Gic/ArmGicRParser.c| 235 +
 .../FdtHwInfoParserLib/Gic/ArmGicRParser.h|  47 +
 .../Pci/ArmPciConfigSpaceParser.c | 797 +++
 .../Pci/ArmPciConfigSpaceParser.h | 142 +++
 .../Serial/ArmSerialPortParser.c  | 620 
 .../Serial/ArmSerialPortParser.h  |  47 +
 32 files changed, 6510 insertions(+), 2 deletions(-)
 create mode 100644 DynamicTablesPkg/Include/Library/HwInfoParserLib.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/CmObjectDescUtility.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
 create mode 100644 DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
 create mode 100644 DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.h
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.c
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTim

[edk2-devel] [PATCH v1 1/1] .pytool/Plugin/Uncrustify: Add Uncrustify plugin

2021-11-23 Thread Michael Kubacki
From: Michael Kubacki 

Adds a new CI plugin for Uncrustify. This is used to check
coding standard compliance of source code to the EDK II C Coding
Standards Specification.

An external dependency is added in the plugin directory to retrieve
the Uncrustify executable. Currently, the executable is from an edk2
fork of the application.

The default Uncrustify configuration files are added in the plugin
directory. Additional details are in the Readme.md file added in
the Uncrustify plugin directory.

Note: A V2 is planned that will fail the Uncrustify plugin results
if a file or function template header is found in a formatted file.
This will be additional functionality added in the plugin and will
not change the way Uncrustify is invoked.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Bret Barkelew 
Signed-off-by: Michael Kubacki 
---
 .pytool/Plugin/Uncrustify/Readme.md   | 116 
 .pytool/Plugin/Uncrustify/Uncrustify.py   | 556 

 .pytool/Plugin/Uncrustify/default_file_header.txt |   9 +
 .pytool/Plugin/Uncrustify/default_function_header.txt |  15 +
 .pytool/Plugin/Uncrustify/uncrustify.cfg  | 466 
 .pytool/Plugin/Uncrustify/uncrustify_ext_dep.yaml |  16 +
 .pytool/Plugin/Uncrustify/uncrustify_plug_in.yaml |  12 +
 .pytool/Readme.md |   4 +
 8 files changed, 1194 insertions(+)

diff --git a/.pytool/Plugin/Uncrustify/Readme.md 
b/.pytool/Plugin/Uncrustify/Readme.md
new file mode 100644
index ..46586d81c68c
--- /dev/null
+++ b/.pytool/Plugin/Uncrustify/Readme.md
@@ -0,0 +1,116 @@
+# Uncrustify Plugin
+
+This CiBuildPlugin scans all the files in a given package and checks for 
coding standard compliance issues.
+
+This plugin requires the directory containing the Uncrustify executable that 
should be used for this plugin to
+be specified in an environment variable named `UNCRUSTIFY_CI_PATH`. This 
unique variable name is used to avoid confusion
+with other paths to Uncrustify which might not be the expected build for use 
by this plugin.
+
+By default, an Uncrustify configuration file named "uncrustify.cfg" located in 
the same directory as the plugin is
+used. The value can be overridden to a package-specific path with the 
`ConfigFilePath` configuration file option.
+
+* Uncrustify source code and documentation: 
https://github.com/uncrustify/uncrustify
+* Project Mu Uncrustify fork source code and documentation: 
https://dev.azure.com/projectmu/Uncrustify
+
+## Files Checked in a Package
+
+By default, this plugin will discover all files in the package with the 
following default paths:
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+From this list of files, any files ignored by Git or residing in a Git 
submodule will be removed. If Git is not
+found, submodules are not found, or ignored files are not found no changes are 
made to the list of discovered files.
+
+To control the paths checked in a given package, review the configuration 
options described in this file.
+
+## Configuration
+
+The plugin can be configured with a few optional configuration options.
+
+``` yaml
+  "Uncrustify": {
+  "AuditOnly": False,   # Don't fail the build if there are 
errors. Just log them.
+  "OutputFileDiffs": False  # Output chunks of formatting diffs in the 
test case log.
+# This can significantly slow down the 
plugin on very large packages.
+  "ConfigFilePath": "", # Custom path to an Uncrustify config 
file. Path is relative to the package.
+  "IgnoreStandardPaths": [],# Standard Plugin defined paths that 
should be ignored.
+  "AdditionalIncludePaths": []  # Additional paths to check formatting 
(wildcards supported).
+  }
+```
+
+### `AdditionalIncludePaths`
+
+A package configuration file can specify any additional paths to be included 
with this option.
+
+At this time, it is recommended all files run against the plugin be written in 
the C or C++ language.
+
+### `AuditOnly`
+
+`Boolean` - Default is `False`.
+
+If `True`, run the test in an "audit only mode" which will log all errors but 
instead of failing the build, it will set
+the test as skipped. This allows visibility into the failures without breaking 
the build.
+
+### `ConfigFilePath`
+
+`String` - Default is `"uncrustify.cfg"`
+
+When specified in the config file, this is a package relative path to the 
Uncrustify configuration file.
+
+### `IgnoreStandardPaths`
+
+This plugin by default will check the below standard paths. A package 
configuration file can specify any of these paths
+to be ignored.
+
+```python
+[
+# C source
+"*.c",
+"*.h"
+]
+```
+
+### `OutputFileDiffs`
+
+`Boolean` - Default is `False`.
+
+If `True`, output diffs of formatting changes into the test case log. This is 
helpful to exactly understand what changes
+need to be made to the source code in order to fix a coding standard 
compliance iss

[edk2-devel] [Patch V2 3/3] .pytool/Plugin/EccCheck: Add performance optimizations

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2986

Improve the performance of EccCheck by using a temp file
instead of stdout to capture the results of the git diff
commands. If a large patch set is passed into EccCheck,
using stdout could be slow and also added the large diff
content to the build log that is redundant information.

A second performance improvement is to filter the
modified directories to remove duplicate directories.
Complex libraries and modules that have subdirectories
with sources would be scanned twice if there were source
changes in both the main directory and subdirectories.
Filter out the subdirectories from the modified directory
list when this case is detected.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .pytool/Plugin/EccCheck/EccCheck.py | 121 +---
 1 file changed, 94 insertions(+), 27 deletions(-)

diff --git a/.pytool/Plugin/EccCheck/EccCheck.py 
b/.pytool/Plugin/EccCheck/EccCheck.py
index de766d984f7c..4fbc67765fdf 100644
--- a/.pytool/Plugin/EccCheck/EccCheck.py
+++ b/.pytool/Plugin/EccCheck/EccCheck.py
@@ -30,7 +30,6 @@ class EccCheck(ICiBuildPlugin):
 },
 """
 
-ReModifyFile = re.compile(r'[B-Q,S-Z]+[\d]*\t(.*)')
 FindModifyFile = re.compile(r'\+\+\+ b\/(.*)')
 LineScopePattern = (r'@@ -\d*\,*\d* \+\d*\,*\d* @@.*')
 LineNumRange = re.compile(r'@@ -\d*\,*\d* \+(\d*)\,*(\d*) @@.*')
@@ -87,10 +86,12 @@ class EccCheck(ICiBuildPlugin):
   os.path.join(basetools_path, "Source", "Python", "Ecc", 
"exception.xml"),
   os.path.join(temp_path, "exception.xml")
   )
+# Output file to use for git diff operations
+temp_diff_output = os.path.join (temp_path, 'diff.txt')
 
 self.ApplyConfig(pkgconfig, temp_path, packagename)
-modify_dir_list = self.GetModifyDir(packagename)
-patch = self.GetDiff(packagename)
+modify_dir_list = self.GetModifyDir(packagename, temp_diff_output)
+patch = self.GetDiff(packagename, temp_diff_output)
 ecc_diff_range = self.GetDiffRange(patch, packagename, temp_path)
 #
 # Use temp_path as working directory when running ECC tool
@@ -129,37 +130,103 @@ class EccCheck(ICiBuildPlugin):
 raise
 return 1
 
-def GetDiff(self, pkg: str) -> List[str]:
-return_buffer = StringIO()
-params = "diff --unified=0 origin/master HEAD"
-RunCmd("git", params, outstream=return_buffer)
-p = return_buffer.getvalue().strip()
-patch = p.split("\n")
-return_buffer.close()
-
+def GetDiff(self, pkg: str, temp_diff_output: str) -> List[str]:
+patch = []
+#
+# Generate unified diff between origin/master and HEAD.
+#
+params = "diff --output={} --unified=0 origin/master 
HEAD".format(temp_diff_output)
+RunCmd("git", params)
+with open(temp_diff_output) as file:
+patch = file.read().strip().split('\n')
 return patch
 
-def GetModifyDir(self, pkg: str) -> List[str]:
-return_buffer = StringIO()
-params = "diff --name-status" + ' HEAD' + ' origin/master'
-RunCmd("git", params, outstream=return_buffer)
-p1 = return_buffer.getvalue().strip()
-dir_list = p1.split("\n")
-return_buffer.close()
+def GetModifyDir(self, pkg: str, temp_diff_output: str) -> List[str]:
+#
+# Generate diff between origin/master and HEAD using --diff-filter to
+# exclude deleted and renamed files that do not need to be scanned by
+# ECC.  Also use --name-status to only generate the names of the files
+# with differences.  The output format of this git diff command is a
+# list of files with the change status and the filename.  The filename
+# is always at the end of the line.  Examples:
+#
+#   M   MdeModulePkg/Application/CapsuleApp/CapsuleApp.h
+#   M   MdeModulePkg/Application/UiApp/FrontPage.h
+#
+params = "diff --output={} --diff-filter=dr --name-status 
origin/master HEAD".format(temp_diff_output)
+RunCmd("git", params)
+dir_list = []
+with open(temp_diff_output) as file:
+dir_list = file.read().strip().split('\n')
+
 modify_dir_list = []
 for modify_dir in dir_list:
-file_path = self.ReModifyFile.findall(modify_dir)
-if file_path:
-file_dir = os.path.dirname(file_path[0])
-else:
+#
+# Parse file name from the end of the line
+#
+file_path = modify_dir.strip().split()
+#
+# Skip lines that do not have at least 2 elements (status and file 
name)
+#
+if len(file_path) < 2:
 continue
-if pkg in file_dir and file_d

[edk2-devel] [Patch V2 2/3] .pytool/Plugin/EccCheck: Remove temp directory on exception

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2986

Add try/except to RunBuildPlugin() to remove temporary
directory if a KeyboardInterrupt exception or an unexpected
exception is detected.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .pytool/Plugin/EccCheck/EccCheck.py | 78 +
 1 file changed, 47 insertions(+), 31 deletions(-)

diff --git a/.pytool/Plugin/EccCheck/EccCheck.py 
b/.pytool/Plugin/EccCheck/EccCheck.py
index c4c2af1bf6e4..de766d984f7c 100644
--- a/.pytool/Plugin/EccCheck/EccCheck.py
+++ b/.pytool/Plugin/EccCheck/EccCheck.py
@@ -72,45 +72,61 @@ class EccCheck(ICiBuildPlugin):
 
 # Create temp directory
 temp_path = os.path.join(workspace_path, 'Build', '.pytool', 'Plugin', 
'EccCheck')
-# Delete temp directory
-if os.path.exists(temp_path):
-shutil.rmtree(temp_path)
-# Copy package being scanned to temp_path
-shutil.copytree (
-  os.path.join(workspace_path, packagename),
-  os.path.join(temp_path, packagename),
-  symlinks=True
-  )
-# Copy exception.xml to temp_path
-shutil.copyfile (
-  os.path.join(basetools_path, "Source", "Python", "Ecc", 
"exception.xml"),
-  os.path.join(temp_path, "exception.xml")
-  )
+try:
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
+# Copy package being scanned to temp_path
+shutil.copytree (
+  os.path.join(workspace_path, packagename),
+  os.path.join(temp_path, packagename),
+  symlinks=True
+  )
+# Copy exception.xml to temp_path
+shutil.copyfile (
+  os.path.join(basetools_path, "Source", "Python", "Ecc", 
"exception.xml"),
+  os.path.join(temp_path, "exception.xml")
+  )
 
-self.ApplyConfig(pkgconfig, temp_path, packagename)
-modify_dir_list = self.GetModifyDir(packagename)
-patch = self.GetDiff(packagename)
-ecc_diff_range = self.GetDiffRange(patch, packagename, temp_path)
-#
-# Use temp_path as working directory when running ECC tool
-#
-self.GenerateEccReport(modify_dir_list, ecc_diff_range, temp_path, 
basetools_path)
-ecc_log = os.path.join(temp_path, "Ecc.log")
-if self.ECC_PASS:
+self.ApplyConfig(pkgconfig, temp_path, packagename)
+modify_dir_list = self.GetModifyDir(packagename)
+patch = self.GetDiff(packagename)
+ecc_diff_range = self.GetDiffRange(patch, packagename, temp_path)
+#
+# Use temp_path as working directory when running ECC tool
+#
+self.GenerateEccReport(modify_dir_list, ecc_diff_range, temp_path, 
basetools_path)
+ecc_log = os.path.join(temp_path, "Ecc.log")
+if self.ECC_PASS:
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
+tc.SetSuccess()
+return 0
+else:
+with open(ecc_log, encoding='utf8') as output:
+ecc_output = output.readlines()
+for line in ecc_output:
+logging.error(line.strip())
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
+tc.SetFailed("EccCheck failed for {0}".format(packagename), 
"CHECK FAILED")
+return 1
+except KeyboardInterrupt:
+# If EccCheck is interrupted by keybard interrupt, then return 
failure
 # Delete temp directory
 if os.path.exists(temp_path):
 shutil.rmtree(temp_path)
-tc.SetSuccess()
-return 0
+tc.SetFailed("EccCheck interrupted for {0}".format(packagename), 
"CHECK FAILED")
+return 1
 else:
-with open(ecc_log, encoding='utf8') as output:
-ecc_output = output.readlines()
-for line in ecc_output:
-logging.error(line.strip())
+# If EccCheck fails for any other exception type, raise the 
exception
 # Delete temp directory
 if os.path.exists(temp_path):
 shutil.rmtree(temp_path)
-tc.SetFailed("EccCheck failed for {0}".format(packagename), "CHECK 
FAILED")
+tc.SetFailed("EccCheck exception for {0}".format(packagename), 
"CHECK FAILED")
+raise
 return 1
 
 def GetDiff(self, pkg: str) -> List[str]:
-- 
2.32.0.windows.1



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

[edk2-devel] [Patch V2 0/3] Remove git reset and optimize

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2986

New in V2
--
* Change temp directory path from Build/ecctemp to
  Build/.pytool/Plugin/EccCheck to provide a unique
  temp directory location for any .pytool Plugin.
* Set working directory when ECC runs to temp directory
  to guarantee all temp files created by EccCheck are
  cleaned up.

* Use temp directory for all operations to prevent any
  changed to git state.
* Remove git reset operation that could corrupt staged
  and local changes.
* Improve performance by removing redundant directory scans
* Improve performance and reduce log file sizes by using
  --output option of git diff to a temp file instead of
  using stdout.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 

Michael D Kinney (3):
  .pytool/Plugin/EccCheck: Remove RevertCode()
  .pytool/Plugin/EccCheck: Remove temp directory on exception
  .pytool/Plugin/EccCheck: Add performance optimizations

 .pytool/Plugin/EccCheck/EccCheck.py | 242 +++-
 1 file changed, 169 insertions(+), 73 deletions(-)

-- 
2.32.0.windows.1



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




[edk2-devel] [Patch V2 1/3] .pytool/Plugin/EccCheck: Remove RevertCode()

2021-11-23 Thread Michael D Kinney
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2986

The RevertCode() method uses git reset which can remove
local changes. Instead of modifying the local files, a
copy of the package passed into the EccCheck tool is
copied to a temp directory in Build/ecctemp.  This same
temp directory is also used for exception.xml. The working
directory used by ECC is also set to this same temp
directory. The combination of these changes eliminates
operations that that modified the git state.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Liming Gao 
Cc: Michael Kubacki 
Signed-off-by: Michael D Kinney 
---
 .pytool/Plugin/EccCheck/EccCheck.py | 93 -
 1 file changed, 53 insertions(+), 40 deletions(-)

diff --git a/.pytool/Plugin/EccCheck/EccCheck.py 
b/.pytool/Plugin/EccCheck/EccCheck.py
index 2d0612269b2e..c4c2af1bf6e4 100644
--- a/.pytool/Plugin/EccCheck/EccCheck.py
+++ b/.pytool/Plugin/EccCheck/EccCheck.py
@@ -69,32 +69,50 @@ class EccCheck(ICiBuildPlugin):
 env.set_shell_var('WORKSPACE', workspace_path)
 env.set_shell_var('PACKAGES_PATH', 
os.pathsep.join(Edk2pathObj.PackagePathList))
 self.ECC_PASS = True
-self.ApplyConfig(pkgconfig, workspace_path, basetools_path, 
packagename)
+
+# Create temp directory
+temp_path = os.path.join(workspace_path, 'Build', '.pytool', 'Plugin', 
'EccCheck')
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
+# Copy package being scanned to temp_path
+shutil.copytree (
+  os.path.join(workspace_path, packagename),
+  os.path.join(temp_path, packagename),
+  symlinks=True
+  )
+# Copy exception.xml to temp_path
+shutil.copyfile (
+  os.path.join(basetools_path, "Source", "Python", "Ecc", 
"exception.xml"),
+  os.path.join(temp_path, "exception.xml")
+  )
+
+self.ApplyConfig(pkgconfig, temp_path, packagename)
 modify_dir_list = self.GetModifyDir(packagename)
 patch = self.GetDiff(packagename)
-ecc_diff_range = self.GetDiffRange(patch, packagename, workspace_path)
-self.GenerateEccReport(modify_dir_list, ecc_diff_range, 
workspace_path, basetools_path)
-ecc_log = os.path.join(workspace_path, "Ecc.log")
-self.RevertCode()
+ecc_diff_range = self.GetDiffRange(patch, packagename, temp_path)
+#
+# Use temp_path as working directory when running ECC tool
+#
+self.GenerateEccReport(modify_dir_list, ecc_diff_range, temp_path, 
basetools_path)
+ecc_log = os.path.join(temp_path, "Ecc.log")
 if self.ECC_PASS:
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
 tc.SetSuccess()
-self.RemoveFile(ecc_log)
 return 0
 else:
 with open(ecc_log, encoding='utf8') as output:
 ecc_output = output.readlines()
 for line in ecc_output:
 logging.error(line.strip())
-self.RemoveFile(ecc_log)
-tc.SetFailed("EccCheck failed for {0}".format(packagename), "Ecc 
detected issues")
+# Delete temp directory
+if os.path.exists(temp_path):
+shutil.rmtree(temp_path)
+tc.SetFailed("EccCheck failed for {0}".format(packagename), "CHECK 
FAILED")
 return 1
 
-def RevertCode(self) -> None:
-submoudle_params = "submodule update --init"
-RunCmd("git", submoudle_params)
-reset_params = "reset HEAD --hard"
-RunCmd("git", reset_params)
-
 def GetDiff(self, pkg: str) -> List[str]:
 return_buffer = StringIO()
 params = "diff --unified=0 origin/master HEAD"
@@ -105,11 +123,6 @@ class EccCheck(ICiBuildPlugin):
 
 return patch
 
-def RemoveFile(self, file: str) -> None:
-if os.path.exists(file):
-os.remove(file)
-return
-
 def GetModifyDir(self, pkg: str) -> List[str]:
 return_buffer = StringIO()
 params = "diff --name-status" + ' HEAD' + ' origin/master'
@@ -132,14 +145,14 @@ class EccCheck(ICiBuildPlugin):
 modify_dir_list = list(set(modify_dir_list))
 return modify_dir_list
 
-def GetDiffRange(self, patch_diff: List[str], pkg: str, workingdir: str) 
-> Dict[str, List[Tuple[int, int]]]:
+def GetDiffRange(self, patch_diff: List[str], pkg: str, temp_path: str) -> 
Dict[str, List[Tuple[int, int]]]:
 IsDelete = True
 StartCheck = False
 range_directory: Dict[str, List[Tuple[int, int]]] = {}
 for line in patch_diff:
 modify_file = self.FindModifyFile.findall(line)
 if modify_file and pkg in modify_file[0] and not StartCheck and 
os.path.isfile(modify_file[0]):
-modify_file_comment_dic = self.GetCommentRange(modify_file[0], 
workingdir)
+

Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread James Bottomley
On Tue, 2021-11-23 at 15:10 +, Yao, Jiewen wrote:
> I would say the PEI owns the system and all memory (including the
> DXE). 
> 
> A bug in PEI may override the loaded DXE memory or the whole system.

That's not the correct way to analyse the security properties.  From
the security point of view this is a trapdoor system: once you go
through the door, you can't go back (the trapdoor being the jump from
PEI to DXE).  The trapdoor isolates the domains and allows you to
analyse the security properties of each separately.  It also allows
separation of exposure ... which is what we use in this case: the PEI
domain has very limited exposure, it's the DXE domain that has full
exposure but, because of the trapdoor, bugs in PEI code can't be used
to exploit the system when it has transitioned to the DXE domain.

> In history I did see PEI security issues. 
> Some security issue in PEI caused system compromised completely. You
> even have no chance to run DXE. 

The security domain analysis above doesn't mean no bug in PEI is ever
exploitable but it does mean that there are fewer exploitability
classes in PEI than DXE because the security domain is much less
exposed.

James




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




Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread Yao, Jiewen
I would say the PEI owns the system and all memory (including the DXE). 

A bug in PEI may override the loaded DXE memory or the whole system.

In history I did see PEI security issues. 
Some security issue in PEI caused system compromised completely. You even have 
no chance to run DXE. 

thank you!
Yao, Jiewen


> 在 2021年11月23日,下午10:52,James Bottomley  写道:
> 
> On Tue, 2021-11-23 at 14:36 +, Yao, Jiewen wrote:
>>> This strict isolation between DXE and PEI means that once we're in
>>> DXE, any bugs in PEI can't be exploited to attack the DXE
>>> environment.  
>> 
>> [jiewen] I would disagree the statement above. 
>> There is not strict isolation. Actually no isolation at all.
>> The DXE is loaded by PEI. 
> 
> Not in OVMF ... DXE and PEI are actually loaded by SEC.  PEI eventually
> jumps to execute DXE but that's after all its own tasks are completed.
> 
>> A bug in PEI has global impact and it can definitely be used to
>> attack the DXE.
> 
> Only if it can be exploited.  Moving things to PEI is mitigating the
> exploitability not the bugs.  The point about exploitability and PEI is
> that it doesn't read any config files, it can't execute any EFI
> binaries and it has no Human Interface modules so can't be influenced
> even by a physically present attacker.  No ability to influence is what
> removes the ability to exploit.
> 
> James
> 
> 


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




Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread James Bottomley
On Tue, 2021-11-23 at 14:36 +, Yao, Jiewen wrote:
> > This strict isolation between DXE and PEI means that once we're in
> > DXE, any bugs in PEI can't be exploited to attack the DXE
> > environment.  
> 
> [jiewen] I would disagree the statement above. 
> There is not strict isolation. Actually no isolation at all.
> The DXE is loaded by PEI. 

Not in OVMF ... DXE and PEI are actually loaded by SEC.  PEI eventually
jumps to execute DXE but that's after all its own tasks are completed.

> A bug in PEI has global impact and it can definitely be used to
> attack the DXE.

Only if it can be exploited.  Moving things to PEI is mitigating the
exploitability not the bugs.  The point about exploitability and PEI is
that it doesn't read any config files, it can't execute any EFI
binaries and it has no Human Interface modules so can't be influenced
even by a physically present attacker.  No ability to influence is what
removes the ability to exploit.

James




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




Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread Yao, Jiewen
> This strict isolation between DXE and PEI means that once we're in DXE,
> any bugs in PEI can't be exploited to attack the DXE environment.  

[jiewen] I would disagree the statement above. 
There is not strict isolation. Actually no isolation at all.
The DXE is loaded by PEI. 
A bug in PEI has global impact and it can definitely be used to attack the DXE.

thank you!
Yao, Jiewen


> 在 2021年11月23日,下午10:27,James Bottomley  写道:
> 
> On Tue, 2021-11-23 at 13:07 +, Yao, Jiewen wrote:
>> Comment below only:
>> 
>>> I am persuaded to let config-a adopt the OVMF way, because the
>>> threat model of config-A is same as the normal OVMF.
>>> But config-B is NOT.
>>> Different threat model drives different solution.
>>> I completely don't understand why they must be same.
>> 
>> I don't understand why you want separate them.  Improving OvmfPkg
>> security is good for both OVMF and TDVF.  For TDVF it is clearly much
>> more important due to the different threat model, but it is good for
>> OVMF too.  Likewise edk2 in general.
>> 
>> [Jiewen] My answer is very clear as I mentioned multiple times.
>> The threat model is different.
>> IMHO, talking about "Improving OvmfPkg security" without a clear
>> threat model is *meaningless*.
>> All mitigation must be based upon threat mode and security objective.
>> Otherwise, what you are doing might be either unnecessary or
>> insufficient.
> 
> Can we take a step back and look at the bigger picture.  The way EFI is
> supposed to operate, according to the architecture model:
> 
> https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
> (Figure 1 and Table 4)
> 
> is that SEC is supposed to be as small and compact as possible, so it
> could be ROM installed without worrying about upgrade issues.  It's job
> is only to get the CPU initialized to the point it can run PEI, measure
> PEI and transfer control.  Security depends on the smallness of SEC
> because if it's rom installed (as a root of trust ought to be) it can't
> be upgraded to fix a bug.
> 
> PEI is supposed to initialize the hardware: set up the CPU, memory
> Application Processors and board configuration so we're in a known
> state with described features for DXE.  It then measures DXE (only if
> SEC didn't measure it) and hands off to DXE.  PEI code is designed not
> to interact with anything except setup to minimize external
> exploitation of internal bugs.
> 
> DXE is supposed to contain only runtime code, including device drivers.
> 
> The security point here is that the job of PEI is over as soon as it
> hands off to DXE, so at that point all the PEI code could be discarded
> (it usually isn't, but it could be).
> 
> This strict isolation between DXE and PEI means that once we're in DXE,
> any bugs in PEI can't be exploited to attack the DXE environment.  This
> allows us to minimize DXE which is where most of the main risk of
> configuration based exploitation is.
> 
> In this security model, you increase security by moving as much code as
> you can from DXE to PEI because the true attack surface is DXE.
> 
> To a lot of us, cutting out PEI, which requires redistributing code
> into DXE sounds like an increase not a reduction in the attack surface
> of the code.  You can argue that OVMF doesn't obey the model above and
> has a lot of initialization code in DXE anyway, but then the correct
> route would be to fix our PEI/DXE separation to recover the security
> properties.
> 
>>> If you force me to add PEI to config-B. Finally, that causes TDVF
>>> config-B is compromised due to an issue in PEI.
>>> Who will take the responsibility?  Will you or RedHat take that?
>> 
>> Bugs happen.  There could also be bugs in the additional SEC code you
>> need for platform setup in a non-PEI configuration ...
>> 
>> [Jiewen] I agree. That is why we need smaller code.
>> We can just focus on review that small portion of code what we have
>> written for TDVF, instead of the whole PEI.
>> We have process to review and maintain the extra TDVF code.
> 
> This depends ... if you agree with the security model outlined above,
> bugs in PEI are less of a problem because they can't be exploited.  Or
> do you not agree with this security model?
> 
> Security isn't about total bug elimination, it's about exploit
> elimination.  You fix a security vulnerability either by fixing the bug
> that can be exploited or removing the ability to exploit it.  This is
> the reason for technologies like NX ... they don't stop people
> exploiting bugs to write code to the stack, but they do mean that once
> you have the code on the stack you can no-longer execute it and the
> attackers have to move on to other means of gaining control.
> 
> The great thing about exploit elimination vs bug elimination is the
> former can usually be done on a whole class of bugs and the latter
> requires a whack-a-mole per bug type approach.
> 
> James
> 
> 


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

Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread James Bottomley
On Tue, 2021-11-23 at 13:07 +, Yao, Jiewen wrote:
> Comment below only:
> 
> > I am persuaded to let config-a adopt the OVMF way, because the
> > threat model of config-A is same as the normal OVMF.
> > But config-B is NOT.
> > Different threat model drives different solution.
> > I completely don't understand why they must be same.
> 
> I don't understand why you want separate them.  Improving OvmfPkg
> security is good for both OVMF and TDVF.  For TDVF it is clearly much
> more important due to the different threat model, but it is good for
> OVMF too.  Likewise edk2 in general.
> 
> [Jiewen] My answer is very clear as I mentioned multiple times.
> The threat model is different.
> IMHO, talking about "Improving OvmfPkg security" without a clear
> threat model is *meaningless*.
> All mitigation must be based upon threat mode and security objective.
> Otherwise, what you are doing might be either unnecessary or
> insufficient.

Can we take a step back and look at the bigger picture.  The way EFI is
supposed to operate, according to the architecture model:

https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
(Figure 1 and Table 4)

is that SEC is supposed to be as small and compact as possible, so it
could be ROM installed without worrying about upgrade issues.  It's job
is only to get the CPU initialized to the point it can run PEI, measure
PEI and transfer control.  Security depends on the smallness of SEC
because if it's rom installed (as a root of trust ought to be) it can't
be upgraded to fix a bug.

PEI is supposed to initialize the hardware: set up the CPU, memory
Application Processors and board configuration so we're in a known
state with described features for DXE.  It then measures DXE (only if
SEC didn't measure it) and hands off to DXE.  PEI code is designed not
to interact with anything except setup to minimize external
exploitation of internal bugs.

DXE is supposed to contain only runtime code, including device drivers.

The security point here is that the job of PEI is over as soon as it
hands off to DXE, so at that point all the PEI code could be discarded
(it usually isn't, but it could be).

This strict isolation between DXE and PEI means that once we're in DXE,
any bugs in PEI can't be exploited to attack the DXE environment.  This
allows us to minimize DXE which is where most of the main risk of
configuration based exploitation is.

In this security model, you increase security by moving as much code as
you can from DXE to PEI because the true attack surface is DXE.

To a lot of us, cutting out PEI, which requires redistributing code
into DXE sounds like an increase not a reduction in the attack surface
of the code.  You can argue that OVMF doesn't obey the model above and
has a lot of initialization code in DXE anyway, but then the correct
route would be to fix our PEI/DXE separation to recover the security
properties.

> > If you force me to add PEI to config-B. Finally, that causes TDVF
> > config-B is compromised due to an issue in PEI.
> > Who will take the responsibility?  Will you or RedHat take that?
> 
> Bugs happen.  There could also be bugs in the additional SEC code you
> need for platform setup in a non-PEI configuration ...
> 
> [Jiewen] I agree. That is why we need smaller code.
> We can just focus on review that small portion of code what we have
> written for TDVF, instead of the whole PEI.
> We have process to review and maintain the extra TDVF code.

This depends ... if you agree with the security model outlined above,
bugs in PEI are less of a problem because they can't be exploited.  Or
do you not agree with this security model?

Security isn't about total bug elimination, it's about exploit
elimination.  You fix a security vulnerability either by fixing the bug
that can be exploited or removing the ability to exploit it.  This is
the reason for technologies like NX ... they don't stop people
exploiting bugs to write code to the stack, but they do mean that once
you have the code on the stack you can no-longer execute it and the
attackers have to move on to other means of gaining control.

The great thing about exploit elimination vs bug elimination is the
former can usually be done on a whole class of bugs and the latter
requires a whack-a-mole per bug type approach.

James




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




edk2-stable202111 Re: [edk2-devel] [PATCH] MdeModulePkg AtaAtapiPassThru: Skip the potential NULL pointer access

2021-11-23 Thread Leif Lindholm
Since BZ3732 has been triggered by a standard build of a platform in
edk2-platforms, I would request that this fix is brought into the
upcoming stable tag.

SbsaQemu isn't a "real" platform, so I don't consider that in itself
sufficient reason, but I feel the risk of it affecting other
(including out-of-tree) platforms justifies it.

Best Regards,

Leif

On Tue, Nov 23, 2021 at 06:10:14 -0700, Rebecca Cran wrote:
> Acked-by: Rebecca Cran 
> 
> 
> I've confirmed that this patch fixes the exception I was seeing when running
> the DEBUG build of SbsaQemu.
> 
> 
> -- 
> 
> Rebecca Cran
> 
> 
> On 11/15/21 7:53 PM, gaoliming wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3732
> > Recent change c974257821208fc6191779d1ddea918499f165b8 exposes this 
> > potential issue.
> > 
> > Signed-off-by: Liming Gao 
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > ---
> >   MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 7 +++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c 
> > b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> > index 7626bac38d..bda900a161 100644
> > --- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> > +++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
> > @@ -885,6 +885,13 @@ AhciPrintStatusBlock (
> > IN UINT32DebugLevel
> > )
> >   {
> > +  //
> > +  // Skip NULL pointer
> > +  //
> > +  if (AtaStatusBlock == NULL) {
> > +return;
> > +  }
> > +
> > //
> > // Only print status and error since we have all of the rest printed as
> > // a part of command block print.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83946): https://edk2.groups.io/g/devel/message/83946
Mute This Topic: https://groups.io/mt/87258062/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 AtaAtapiPassThru: Skip the potential NULL pointer access

2021-11-23 Thread Rebecca Cran

Acked-by: Rebecca Cran 


I've confirmed that this patch fixes the exception I was seeing when 
running the DEBUG build of SbsaQemu.



--

Rebecca Cran


On 11/15/21 7:53 PM, gaoliming wrote:

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3732
Recent change c974257821208fc6191779d1ddea918499f165b8 exposes this potential 
issue.

Signed-off-by: Liming Gao 
Cc: Hao A Wu 
Cc: Ray Ni 
---
  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
index 7626bac38d..bda900a161 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
@@ -885,6 +885,13 @@ AhciPrintStatusBlock (
IN UINT32DebugLevel
)
  {
+  //
+  // Skip NULL pointer
+  //
+  if (AtaStatusBlock == NULL) {
+return;
+  }
+
//
// Only print status and error since we have all of the rest printed as
// a part of command block print.



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




Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread Yao, Jiewen
Comment below only:

> I am persuaded to let config-a adopt the OVMF way, because the threat model 
> of config-A is same as the normal OVMF.
> But config-B is NOT.
> Different threat model drives different solution.
> I completely don't understand why they must be same.

I don't understand why you want separate them.  Improving OvmfPkg
security is good for both OVMF and TDVF.  For TDVF it is clearly much
more important due to the different threat model, but it is good for
OVMF too.  Likewise edk2 in general.

[Jiewen] My answer is very clear as I mentioned multiple times.
The threat model is different.
IMHO, talking about "Improving OvmfPkg security" without a clear threat model 
is *meaningless*.
All mitigation must be based upon threat mode and security objective.
Otherwise, what you are doing might be either unnecessary or insufficient.



> If you force me to add PEI to config-B. Finally, that causes TDVF config-B is 
> compromised due to an issue in PEI.
> Who will take the responsibility?  Will you or RedHat take that?

Bugs happen.  There could also be bugs in the additional SEC code you
need for platform setup in a non-PEI configuration ...

[Jiewen] I agree. That is why we need smaller code.
We can just focus on review that small portion of code what we have written for 
TDVF, instead of the whole PEI.
We have process to review and maintain the extra TDVF code.

I think it is totally *unfair* that you force me to add PEI, without knowing 
the quality of PEI.


Thank you
Yao Jiewen


> -Original Message-
> From: Gerd Hoffmann 
> Sent: Tuesday, November 23, 2021 8:38 PM
> To: Yao, Jiewen 
> Cc: Xu, Min M ; devel@edk2.groups.io; Ard Biesheuvel
> ; Justen, Jordan L ;
> Brijesh Singh ; Erdem Aktas
> ; James Bottomley ; Tom
> Lendacky 
> Subject: Re: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx
> 
>   Hi,
> 
> > > That totally makes sense.  I expect TDVF Config-B will look alot like
> > > the existing AmdSev configuration variant which is stripped down too.
> >
> > [Jiewen] I don't think TDVF config-B will be like the AMD SEV is right 
> > statement.
> > TDVF and SEV are two different platforms.
> 
> Yes, of course.  But even though there are differences in both
> implementation and supported features both platforms have similar goals
> and there is quite some overlap in concepts too.
> 
> > Intel mainly focuses on TDVF and we will let AMD defines the feature
> > set in SEV.  They MAY be alike if possible.  But difference is also
> > acceptable if there is architecture difference or different decision
> > in different company.
> 
> Yes.  Whenever they are close enough that merging them makes sense
> remains to be seen.
> 
> > > But I don't see how dropping the PEI phase altogether helps much in
> > > stripping down the firmware image.  The initialization currently handled
> > > by OvmfPkg/PlatformPei must happen somewhere else instead.  Given SEC is
> > > a very restricted environment I don't expect the code can be shared
> > > easily, so we will probably end up with code duplication.  Also two
> > > different boot workflows which I fear can easily introduce subtle bugs
> > > due to differences like a initialization order changes.  This is what I
> > > see as maintenance problem.
> >
> > [Jiewen] I don't think this is right statement.
> > In Tiano history, there were security bugs exposed in PEI phase, even the 
> > PEI
> Core on FV processing.
> > I do see the value to skip PEI core.
> 
> On the other hand there are probably more eyes are looking at PEI Core
> because it is used by a lot of platforms, increasing the chance that
> bugs are actually spotted.
> 
> > Again, I am very familiar with non-PEI flow.  Back to 10 years ago, I
> > was maintainer of a non-PEI platform (named DUET) and we jumped from
> > SEC to DXE directly.  I don't see any maintenance problem.
> 
> The maintenance problem isn't a non-PEI flow.  If a platform chooses
> that -- fine.  The problem having to maintain both PEI and non-PEI
> workflow.
> 
> > [Jiewen] I think we are debating two different things.
> > Your statement that "config-B is similar to AmdSev" does not support
> > the statement "config-B should be adopt what AmdSev chooses".
> 
> I never stated "config-B should be adopt what AmdSev chooses".
> 
> I stated "TDVF boot workflow should be simlar to the other OVMF
> platforms to simplify maintenance".
> 
> AmdSev is just an example showing that you can easily strip down the
> firmware  build without putting the boot workflow upside down (which one
> of the things config-b wants too).
> 
> > > I don't want question all that.  I still don't see the point in dropping
> > > the PEI phase and make config-b work different that all other ovmf
> > > variants though.
> >
> > [Jiewen] My point is simple - Threat Model is different.
> > That causes security objective difference and design difference.
> 
> Does not using PEI phase have any advantages from a security point of
> view (other than "not using

Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

2021-11-23 Thread Gerd Hoffmann
  Hi,

> > That totally makes sense.  I expect TDVF Config-B will look alot like
> > the existing AmdSev configuration variant which is stripped down too.
> 
> [Jiewen] I don't think TDVF config-B will be like the AMD SEV is right 
> statement.
> TDVF and SEV are two different platforms.

Yes, of course.  But even though there are differences in both
implementation and supported features both platforms have similar goals
and there is quite some overlap in concepts too.

> Intel mainly focuses on TDVF and we will let AMD defines the feature
> set in SEV.  They MAY be alike if possible.  But difference is also
> acceptable if there is architecture difference or different decision
> in different company.

Yes.  Whenever they are close enough that merging them makes sense
remains to be seen.

> > But I don't see how dropping the PEI phase altogether helps much in
> > stripping down the firmware image.  The initialization currently handled
> > by OvmfPkg/PlatformPei must happen somewhere else instead.  Given SEC is
> > a very restricted environment I don't expect the code can be shared
> > easily, so we will probably end up with code duplication.  Also two
> > different boot workflows which I fear can easily introduce subtle bugs
> > due to differences like a initialization order changes.  This is what I
> > see as maintenance problem.
> 
> [Jiewen] I don't think this is right statement.
> In Tiano history, there were security bugs exposed in PEI phase, even the PEI 
> Core on FV processing.
> I do see the value to skip PEI core.

On the other hand there are probably more eyes are looking at PEI Core
because it is used by a lot of platforms, increasing the chance that
bugs are actually spotted.

> Again, I am very familiar with non-PEI flow.  Back to 10 years ago, I
> was maintainer of a non-PEI platform (named DUET) and we jumped from
> SEC to DXE directly.  I don't see any maintenance problem.

The maintenance problem isn't a non-PEI flow.  If a platform chooses
that -- fine.  The problem having to maintain both PEI and non-PEI
workflow.

> [Jiewen] I think we are debating two different things.
> Your statement that "config-B is similar to AmdSev" does not support
> the statement "config-B should be adopt what AmdSev chooses".

I never stated "config-B should be adopt what AmdSev chooses".

I stated "TDVF boot workflow should be simlar to the other OVMF
platforms to simplify maintenance".

AmdSev is just an example showing that you can easily strip down the
firmware  build without putting the boot workflow upside down (which one
of the things config-b wants too).

> > I don't want question all that.  I still don't see the point in dropping
> > the PEI phase and make config-b work different that all other ovmf
> > variants though.
> 
> [Jiewen] My point is simple - Threat Model is different.
> That causes security objective difference and design difference.

Does not using PEI phase have any advantages from a security point of
view (other than "not using PEI Core code which might have bugs")?

> > The security workflow is a serious problem indeed.  Not only for TDVF,
> > also for OVMF in general, and other platforms too.  We should certainly
> > try to improve it.
> 
> [Jiewen] If you look at how we state config-A and config-B again, you will 
> find we made difference statement.
> I copy it here again.
> 1) Config-A is to keep current architecture, to maximum compatible with OVMF. 
> And we don't remove VMM out of TCB.
> 2) Config-B is to have a new TDVF design, to maximum satisfy the security 
> requirement. And we remove VMM out of TCB.
> 
> Because of the threat model difference, in config-A, we can safely
> make some assumption that the VMM is benign and VMM will not input
> malicious data. As such, we might not perform data validation. We just
> trust VMM input.
> 
> However, in config-B, VMM is malicious, which means we need be careful to NOT 
> trust VMM at any time.
> The code in config-A and config-B may do totally different thing to handle 
> the difference situation.
> 
> I don't think it is hidden assumption that if TDVF need do some check, then a 
> generic OVMF need do this check.
> If OVMF trusts the VMM, the check might be totally unnecessary.

Do you have a concrete example for that?

I can't think of a good reason to skip checks on OVMF.  When we -- for
example -- review and improve virtio drivers to make sure they can't be
used by the VMM to exploit a TDVF guest:  We surely would use the
improved sanity checks on OVMF too, for better OVMF stability and also
for better test coverage of the sanity checks.

> > Hmm?  Seeing TDVF as "other platform" is a rather strange view given
> > that we are integrating tdx support into OVMF right now ...
> 
> [Jiewen] This is how Intel views the "platform".
> In history, we call this one binary mode is "multiple-platform" or 
> "multiple-SKU".
> That means we only have one binary, and this single binary can boot different 
> platforms, which has similar CP

[edk2-devel] [PATCH v2 2/3] Silicon/ARM/NeoverseN1Soc: Port PCI Segment Library

2021-11-23 Thread Khasim Mohammed
The BasePCISegment Library in MdePkg doesn't allow configuring
multiple segments required for PCIe and CCIX root port
enumeration. Therefore, a custom PCI Segment library is adapted
from SynQuacerPciSegmentLib and ported for N1Sdp.

Change-Id: I0a124b0ea2fb7a8ee652de2d66b977d848c509b4
Signed-off-by: Khasim Syed Mohammed 
---
 .../Library/PciSegmentLib/PciSegmentLib.c | 1425 +
 .../Library/PciSegmentLib/PciSegmentLib.inf   |   35 +
 2 files changed, 1460 insertions(+)
 create mode 100644 
Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.c
 create mode 100644 
Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.inf

diff --git a/Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.c 
b/Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.c
new file mode 100644
index 00..dbf00e1f14
--- /dev/null
+++ b/Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.c
@@ -0,0 +1,1425 @@
+/** @file
+  PCI Segment Library for N1SDP SoC with multiple RCs
+
+  Having two distinct root complexes is not supported by the standard
+  set of PciLib/PciExpressLib/PciSegmentLib, this PciSegmentLib
+  reimplements the functionality to support multiple root ports on
+  different segment numbers.
+
+  Copyright (c) 2007 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef enum {
+  PciCfgWidthUint8  = 0,
+  PciCfgWidthUint16,
+  PciCfgWidthUint32,
+  PciCfgWidthMax
+} PCI_CFG_WIDTH;
+
+/**
+ Assert the validity of a PCI Segment address.
+ A valid PCI Segment address should not contain 1's in bits 28..31 and 48..63
+
+  @param A The address to validate.
+  @param M Additional bits to assert to be zero.
+**/
+#define ASSERT_INVALID_PCI_SEGMENT_ADDRESS(A,M) \
+  ASSERT (((A) & (0xf000ULL | (M))) == 0)
+
+/**
+  Function to return PCIe Physical Address for different RCs.
+  If address is invalid, then ASSERT().
+
+  @param  Address Address passed from bus layer.
+
+  @return Return PCIe base address.
+
+**/
+STATIC
+UINT64
+PciSegmentLibGetConfigBase (
+  IN  UINT64  Address
+  )
+{
+  switch ((UINT16)(Address >> 32)) {
+  case 0:
+return FixedPcdGet32 (PcdPcieExpressBaseAddress);
+  case 1:
+return FixedPcdGet32 (PcdCcixExpressBaseAddress);
+  default:
+ASSERT (FALSE);
+  }
+  return 0;
+}
+
+/**
+  Internal worker function to read a PCI configuration register.
+
+  @param AddressThe address that encodes the PCI Bus, Device, Function
+and Register.
+  @param Width  The width of data to read
+
+  @return The value read from the PCI configuration register.
+**/
+STATIC
+UINT32
+PciSegmentLibReadWorker (
+  IN  UINT64  Address,
+  IN  PCI_CFG_WIDTH   Width
+  )
+{
+  UINT64Base;
+
+  Base = PciSegmentLibGetConfigBase (Address);
+
+  switch (Width) {
+  case PciCfgWidthUint8:
+return PciRead8 (Base + (UINT32)Address);
+  case PciCfgWidthUint16:
+return PciRead16 (Base + (UINT32)Address);
+  case PciCfgWidthUint32:
+return PciRead32 (Base + (UINT32)Address);
+  default:
+ASSERT (FALSE);
+  }
+  return 0;
+}
+
+/**
+  Internal worker function to write to a PCI configuration register.
+
+  @param Address   The address that encodes the PCI Bus, Device, Function
+   and Register.
+  @param Width The width of data to write
+  @param Data  The value to write.
+
+  @return  The value written to the PCI configuration register.
+**/
+STATIC
+UINT32
+PciSegmentLibWriteWorker (
+  IN  UINT64  Address,
+  IN  PCI_CFG_WIDTH   Width,
+  IN  UINT32  Data
+  )
+{
+  UINT64Base;
+
+  Base = PciSegmentLibGetConfigBase (Address);
+
+  switch (Width) {
+  case PciCfgWidthUint8:
+PciWrite8 (Base + (UINT32)Address, Data);
+break;
+  case PciCfgWidthUint16:
+PciWrite16 (Base + (UINT32)Address, Data);
+break;
+  case PciCfgWidthUint32:
+PciWrite32 (Base + (UINT32)Address, Data);
+break;
+  default:
+ASSERT (FALSE);
+  }
+
+  return Data;
+}
+
+/**
+  Reads an 8-bit PCI configuration register.
+
+  Reads and returns the 8-bit PCI configuration register specified by Address.
+  This function must guarantee that all PCI read and write operations are
+  serialized.
+
+  If any reserved bits in Address are set, then ASSERT().
+
+  @param Address The address that encodes the PCI Segment, Bus,
+ Device, Function and Register.
+
+  @return The 8-bit PCI configuration register specified by the Address.
+**/
+UINT8
+EFIAPI
+PciSegmentRead8 (
+  IN UINT64Address
+  )
+{
+  ASSERT_INVALID_PCI_SEGMENT_ADDRESS (Address, 0);
+
+  return (UINT8) PciSegmentLibReadWorker (Address, PciCfgWidthUint8);
+}
+
+/**
+  Writes an 8-bit PCI configura

[edk2-devel] [PATCH v2 3/3] Silicon/ARM/NeoverseN1Soc: Add CCIX root complex support

2021-11-23 Thread Khasim Mohammed
This patch enables CCIX root complex support by updating
the root complex node info in PciHostBridge library
and enabling PciSegment library for N1Sdp.

Change-Id: I0510b1023aec16365b614d4eaf81858851d9fa28
Signed-off-by: Khasim Syed Mohammed 
---
 .../ConfigurationManagerDxe.inf   |  3 +-
 Platform/ARM/N1Sdp/N1SdpPlatform.dec  |  3 -
 Platform/ARM/N1Sdp/N1SdpPlatform.dsc  |  3 +-
 .../PciHostBridgeLib/PciHostBridgeLib.c   | 71 +--
 .../PciHostBridgeLib/PciHostBridgeLib.inf | 11 ++-
 .../Library/PlatformLib/PlatformLib.inf   |  1 +
 .../Library/PlatformLib/PlatformLibMem.c  |  4 +-
 7 files changed, 81 insertions(+), 15 deletions(-)

diff --git 
a/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 
b/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
index 027a4202ff..67b0c3a0ea 100644
--- 
a/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
+++ 
b/Platform/ARM/N1Sdp/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
@@ -76,8 +76,6 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
 
-  gArmN1SdpTokenSpaceGuid.PcdPcieExpressBaseAddress
-
   gArmNeoverseN1SocTokenSpaceGuid.PcdExtMemorySpace
   gArmNeoverseN1SocTokenSpaceGuid.PcdDramBlock2Base
 
@@ -91,6 +89,7 @@
   gArmNeoverseN1SocTokenSpaceGuid.PcdPcieBusCount
   gArmNeoverseN1SocTokenSpaceGuid.PcdPcieBusMax
   gArmNeoverseN1SocTokenSpaceGuid.PcdPcieBusMin
+  gArmNeoverseN1SocTokenSpaceGuid.PcdPcieExpressBaseAddress
   gArmNeoverseN1SocTokenSpaceGuid.PcdPcieIoBase
   gArmNeoverseN1SocTokenSpaceGuid.PcdPcieIoMaxBase
   gArmNeoverseN1SocTokenSpaceGuid.PcdPcieIoSize
diff --git a/Platform/ARM/N1Sdp/N1SdpPlatform.dec 
b/Platform/ARM/N1Sdp/N1SdpPlatform.dec
index 2ab6c20dcc..98d2d5ba81 100644
--- a/Platform/ARM/N1Sdp/N1SdpPlatform.dec
+++ b/Platform/ARM/N1Sdp/N1SdpPlatform.dec
@@ -34,9 +34,6 @@
   gArmN1SdpTokenSpaceGuid.PcdRamDiskBase|0x8800|UINT32|0x0001
   gArmN1SdpTokenSpaceGuid.PcdRamDiskSize|0x1800|UINT32|0x0002
 
-  # PCIe
-  
gArmN1SdpTokenSpaceGuid.PcdPcieExpressBaseAddress|0x7000|UINT32|0x0007
-
   # External memory
   gArmNeoverseN1SocTokenSpaceGuid.PcdExtMemorySpace|0|UINT64|0x0029
 
diff --git a/Platform/ARM/N1Sdp/N1SdpPlatform.dsc 
b/Platform/ARM/N1Sdp/N1SdpPlatform.dsc
index 7488bdc036..75d7871452 100644
--- a/Platform/ARM/N1Sdp/N1SdpPlatform.dsc
+++ b/Platform/ARM/N1Sdp/N1SdpPlatform.dsc
@@ -75,7 +75,7 @@
 [LibraryClasses.common.DXE_DRIVER]
   FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
   
PciHostBridgeLib|Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.inf
-  PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
+  
PciSegmentLib|Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.inf
   PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
   
PciExpressLib|Silicon/ARM/NeoverseN1Soc/Library/NeoverseN1SocPciExpressLib/PciExpressLib.inf
 
@@ -127,7 +127,6 @@
   gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x300C
 
   # PCIe
-  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x7000
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24
   gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE
 
diff --git 
a/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
index 9332939f63..c3a14a6c17 100644
--- a/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
+++ b/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -1,7 +1,7 @@
 /** @file
 *  PCI Host Bridge Library instance for ARM Neoverse N1 platform
 *
-*  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+*  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -16,6 +16,8 @@
 #include 
 #include 
 
+#define ROOT_COMPLEX_NUM 2
+
 GLOBAL_REMOVE_IF_UNREFERENCED
 STATIC CHAR16 CONST * CONST mPciHostBridgeLibAcpiAddressSpaceTypeStr[] = {
   L"Mem", L"I/O", L"Bus"
@@ -28,7 +30,7 @@ typedef struct {
 } EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
 #pragma pack ()
 
-STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH mEfiPciRootBridgeDevicePath[] = {
+STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH 
mEfiPciRootBridgeDevicePath[ROOT_COMPLEX_NUM] = {
   // PCIe
   {
 {
@@ -51,10 +53,33 @@ STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH 
mEfiPciRootBridgeDevicePath[] = {
 0
   }
 }
-  }
+  },
+  //CCIX
+  {
+{
+  {
+ACPI_DEVICE_PATH,
+ACPI_DP,
+{
+  (UINT8)sizeof (ACPI_HID_DEVICE_PATH),
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
+}
+  },
+  EISA_PNP_ID(0x0A09), // CCIX
+  0
+},
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  {
+END_DEVICE_PATH_LENGTH,
+  

[edk2-devel] [PATCH v2 1/3] Silicon/ARM/NeoverseN1Soc: Update PciExpressLib to enable CCIX port

2021-11-23 Thread Khasim Mohammed
Update the PciExpressLib to enable CCIX port as PCIe root host by
validating the PCIe addresses and introducing corresponding PCD
entries.

Change-Id: I0d1167b86e53a3781f59c4d68a3b2e61add4317e
Signed-off-by: Deepak Pandey 
Signed-off-by: Khasim Syed Mohammed 
---
 .../PciExpressLib.c   | 127 --
 .../PciExpressLib.inf |   7 +-
 Silicon/ARM/NeoverseN1Soc/NeoverseN1Soc.dec   |   5 +-
 3 files changed, 94 insertions(+), 45 deletions(-)

diff --git 
a/Silicon/ARM/NeoverseN1Soc/Library/NeoverseN1SocPciExpressLib/PciExpressLib.c 
b/Silicon/ARM/NeoverseN1Soc/Library/NeoverseN1SocPciExpressLib/PciExpressLib.c
index bb0246b4a9..3abe0a2d6b 100644
--- 
a/Silicon/ARM/NeoverseN1Soc/Library/NeoverseN1SocPciExpressLib/PciExpressLib.c
+++ 
b/Silicon/ARM/NeoverseN1Soc/Library/NeoverseN1SocPciExpressLib/PciExpressLib.c
@@ -20,7 +20,7 @@
   The description of the workarounds included for these limitations can
   be found in the comments below.
 
-  Copyright (c) 2020, ARM Limited. All rights reserved.
+  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -36,15 +36,29 @@
 #include 
 #include 
 
+#define BUS_OFFSET  20
+#define DEV_OFFSET  15
+#define FUNC_OFFSET 12
+#define REG_OFFSET  4096
+
 /**
-  Assert the validity of a PCI address. A valid PCI address should contain 1's
-  only in the low 28 bits.
+  Assert the validity of a PCI address. A valid PCI address should contain 1's.
 
   @param  A The address to validate.
 
 **/
 #define ASSERT_INVALID_PCI_ADDRESS(A) \
-  ASSERT (((A) & ~0xfff) == 0)
+  ASSERT (((A) & ~0x) == 0)
+
+#define EFI_PCIE_ADDRESS(bus, dev, func, reg) \
+  (UINT64) ( \
+  (((UINTN) bus)   << BUS_OFFSET)  | \
+  (((UINTN) dev)   << DEV_OFFSET)  | \
+  (((UINTN) func)  << FUNC_OFFSET) | \
+  (((UINTN) (reg)) <  REG_OFFSET ?   \
+   ((UINTN) (reg)) : (UINT64) (LShiftU64 ((UINT64) (reg), 32
+
+#define GET_PCIE_BASE_ADDRESS(Address)  (Address & 0xF800)
 
 /* Root port Entry, BDF Entries Count */
 #define BDF_TABLE_ENTRY_SIZE4
@@ -53,6 +67,7 @@
 
 /* BDF table offsets for PCIe */
 #define PCIE_BDF_TABLE_OFFSET   0
+#define CCIX_BDF_TABLE_OFFSET   (16 * 1024)
 
 #define GET_BUS_NUM(Address)(((Address) >> 20) & 0x7F)
 #define GET_DEV_NUM(Address)(((Address) >> 15) & 0x1F)
@@ -113,49 +128,64 @@ PciExpressRegisterForRuntimeAccess (
 }
 
 /**
-  Check if the requested PCI address can be safely accessed.
+  Check if the requested PCI address is a valid BDF address.
 
-  SCP performs the initial bus scan, prepares a table of valid BDF addresses
-  and shares them through non-trusted SRAM. This function validates if the
-  requested PCI address belongs to a valid BDF by checking the table of valid
-  entries. If not, this function will return false. This is a workaround to
-  avoid bus fault that occurs when accessing unavailable PCI device due to
-  hardware bug.
+  SCP performs the initial bus scan and prepares a table of valid BDF addresses
+  and shares them through non-trusted SRAM. This function validates if the PCI
+  address from any PCI request falls within the table of valid entries. If not,
+  this function will return 0x. This is a workaround to avoid bus fault
+  that happens when accessing unavailable PCI device due to RTL bug.
 
   @param  Address The address that encodes the PCI Bus, Device, Function and
   Register.
 
-  @return TRUEBDF can be accessed, valid.
-  @return FALSE   BDF should not be accessed, invalid.
+  @return The base address of PCI Express.
 
 **/
 STATIC
-BOOLEAN
+UINTN
 IsBdfValid (
-  IN  UINTN Address
+  IN UINTN Address
   )
 {
+  UINT8 Bus;
+  UINT8 Device;
+  UINT8 Function;
   UINTN BdfCount;
   UINTN BdfValue;
-  UINTN BdfEntry;
   UINTN Count;
   UINTN TableBase;
-  UINTN ConfigBase;
+  UINTN PciAddress;
+
+  Bus  = GET_BUS_NUM (Address);
+  Device   = GET_DEV_NUM (Address);
+  Function = GET_FUNC_NUM (Address);
+
+  PciAddress = EFI_PCIE_ADDRESS (Bus, Device, Function, 0);
+
+  if (GET_PCIE_BASE_ADDRESS (Address) ==
+FixedPcdGet64 (PcdPcieExpressBaseAddress)) {
+TableBase = NEOVERSEN1SOC_NON_SECURE_SRAM_BASE + PCIE_BDF_TABLE_OFFSET;
+  } else {
+TableBase = NEOVERSEN1SOC_NON_SECURE_SRAM_BASE + CCIX_BDF_TABLE_OFFSET;
+  }
 
-  ConfigBase = Address & ~0xFFF;
-  TableBase = NEOVERSEN1SOC_NON_SECURE_SRAM_BASE + PCIE_BDF_TABLE_OFFSET;
   BdfCount = MmioRead32 (TableBase + BDF_TABLE_ENTRY_SIZE);
-  BdfEntry = TableBase + BDF_TABLE_HEADER_SIZE;
-
-  /* Skip the header & check remaining entry */
-  for (Count = 0; Count < BdfCount; Count++, BdfEntry += BDF_TABLE_ENTRY_SIZE) 
{
-BdfValue = MmioRead32 (BdfEntry);
-if (BdfValue == ConfigBase) {
-  return TRUE;
-}
+
+  /* Start from the second entry */
+  for (Count = BDF_TABLE_HEADER_COUNT;
+   Count < (BdfCount + BDF_TABLE_HEADER_COUNT);
+   Count++) {
+Bdf

[edk2-devel] [PATCH v2 0/3] Enable CCIX port as PCIe root host on N1SDP

2021-11-23 Thread Khasim Mohammed
The patch series enables CCIX port as PCIe root on N1SDP.

V2:
- Removed few PCDs entries that were not used.
- Migrated to latest version edk2-platform and validated the patches.

V1:
-  The PciExpressLib is updated to validate the PCIe addresses
  and introducing corresponding PCD entries.
- A custom PCI Segment library is adapted from SynQuacerPciSegmentLib
  and ported for N1Sdp.
- The root complex node info in PciHostBridge library is updated to
  include the CCIX port information.

The changes can be seen at:
https://github.com/khasim/edk2-platforms-n1sdp/tree/n1sdp-ccix-root

Khasim Syed Mohammed (3):
  Silicon/ARM/NeoverseN1Soc: Update PciExpressLib to enable CCIX port
  Silicon/ARM/NeoverseN1Soc: Port PCI Segment Library
  Silicon/ARM/NeoverseN1Soc: Add CCIX root complex support

 .../ConfigurationManagerDxe.inf   |3 +-
 Platform/ARM/N1Sdp/N1SdpPlatform.dec  |3 -
 Platform/ARM/N1Sdp/N1SdpPlatform.dsc  |3 +-
 .../PciExpressLib.c   |  127 +-
 .../PciExpressLib.inf |7 +-
 .../PciHostBridgeLib/PciHostBridgeLib.c   |   71 +-
 .../PciHostBridgeLib/PciHostBridgeLib.inf |   11 +-
 .../Library/PciSegmentLib/PciSegmentLib.c | 1425 +
 .../Library/PciSegmentLib/PciSegmentLib.inf   |   35 +
 .../Library/PlatformLib/PlatformLib.inf   |1 +
 .../Library/PlatformLib/PlatformLibMem.c  |4 +-
 Silicon/ARM/NeoverseN1Soc/NeoverseN1Soc.dec   |5 +-
 12 files changed, 1635 insertions(+), 60 deletions(-)
 create mode 100644 
Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.c
 create mode 100644 
Silicon/ARM/NeoverseN1Soc/Library/PciSegmentLib/PciSegmentLib.inf

-- 
2.17.1



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




Re: [edk2-devel] [PATCH] MdePkg: DebugLib: Compilation fix for clang-13.

2021-11-23 Thread Michael Brown

On 23/11/2021 06:41, Marvin Häuser wrote:

23.11.2021 00:17:30 Michael Brown :

I would very strongly recommend having the non-debug version of the macro use 
something like:

#define ASSERT(Expression) do {   \
  if (FALSE) {  \
    (VOID) (Expression);    \
  } \
    } while (FALSE)

Without the "if (FALSE)", you will find that an expression that may have 
side-effects (e.g. by calling an external function) will result in executable code being 
generated.


In theory +1, but don't some compilers generate "unreachable code" warnings for 
this? I unfortunately cannot check them all right now. Maybe guards push/pop'ing the 
warning for that need to be defined, that are only allowed to be used with explicit 
documentation why they are necessary?


A quick experiment shows that gcc won't generate a warning but clang 
will.  Can be fixed by adding extra parentheses around FALSE:


#define ASSERT(Expression) do {   \
if ((FALSE)) {\
  (VOID) (Expression);\
} \
  } while (FALSE)

which is still clean and relatively elegant.

Thanks,

Michael


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




[edk2-devel] [PATCH v2 2/5] DynamicTablesPkg: DynamicPlatRepo: Add TokenGenerator

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the TokenGenerator files.

Signed-off-by: Pierre Gondois 
---
 .../DynamicPlatRepoLib/TokenGenerator.c   | 28 +++
 .../DynamicPlatRepoLib/TokenGenerator.h   | 26 +
 2 files changed, 54 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.h

diff --git 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.c 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.c
new file mode 100644
index ..637e784bd284
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.c
@@ -0,0 +1,28 @@
+/** @file
+  Token Generator
+
+  Copyright (c) 2021, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+**/
+
+#include 
+
+/** Generate a token.
+
+  @return A token.
+**/
+CM_OBJECT_TOKEN
+EFIAPI
+GenerateToken (
+  VOID
+  )
+{
+  // Start Tokens at 1 to avoid collisions with CM_NULL_TOKEN.
+  STATIC UINTN CurrentToken = 1;
+  return (CM_OBJECT_TOKEN)(CurrentToken++);
+}
diff --git 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.h 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.h
new file mode 100644
index ..44d32e5b41a1
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.h
@@ -0,0 +1,26 @@
+/** @file
+  Token Generator
+
+  Copyright (c) 2021, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+**/
+
+#ifndef TOKEN_GENERATOR_H_
+#define TOKEN_GENERATOR_H_
+
+/** Generate a token.
+
+  @return A token.
+**/
+CM_OBJECT_TOKEN
+EFIAPI
+GenerateToken (
+  VOID
+  );
+
+#endif // TOKEN_GENERATOR_H_
-- 
2.25.1



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




[edk2-devel] [PATCH v2 0/5] Add DynamicPlatRepoLib

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

v2:
- Various small fixes (change status returned, reset values when
  freeing memory, ...). [Sami]

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

The DynamicPlatRepoLib is library allowing to receive and then
give Configuration Manager (CM) objects.
After being initialized, a dynamic platform repository can receive
CMObjects. The library generates a token to uniquely identify the
CMObject in the repository. The dynamic platform repository must
then be 'finalized' before receiving CMObject queries.

This library is complementary to the 'static' definition of
CMObjects (i.e. as C structs). It is particularly useful when
using a HwInfoParserLib that dynamically creates CMObjects
(from a device tree for instance).

The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/1788_Add_Dynamic_Plarform_Repository_Lib_v2

Pierre Gondois (5):
  DynamicTablesPkg: Definition for DynamicPlatRepoLib interface
  DynamicTablesPkg: DynamicPlatRepo: Add TokenGenerator
  DynamicTablesPkg: DynamicPlatRepo: Add TokenFixer
  DynamicTablesPkg: DynamicPlatRepo: Add TokenMapper
  DynamicTablesPkg: Add DynamicPlatRepo library

 DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
 DynamicTablesPkg/DynamicTablesPkg.dsc |   1 +
 .../Include/Library/DynamicPlatRepoLib.h  | 114 
 .../DynamicPlatRepoLib/CmObjectTokenFixer.c   | 164 ++
 .../DynamicPlatRepoLib/CmObjectTokenFixer.h   |  52 ++
 .../DynamicPlatRepoLib/DynamicPlatRepo.c  | 515 ++
 .../DynamicPlatRepoInternal.h |  78 +++
 .../DynamicPlatRepoLib/DynamicPlatRepoLib.inf |  33 ++
 .../DynamicPlatRepoLib/TokenGenerator.c   |  28 +
 .../DynamicPlatRepoLib/TokenGenerator.h   |  26 +
 .../Common/DynamicPlatRepoLib/TokenMapper.c   | 218 
 .../Common/DynamicPlatRepoLib/TokenMapper.h   | 123 +
 12 files changed, 1355 insertions(+)
 create mode 100644 DynamicTablesPkg/Include/Library/DynamicPlatRepoLib.h
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.h
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoInternal.h
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenGenerator.h
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.h

--
2.25.1


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




[edk2-devel] [PATCH v2 3/5] DynamicTablesPkg: DynamicPlatRepo: Add TokenFixer

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the TokenFixer files, allowing to update the
self-token some CmObj have.

Signed-off-by: Pierre Gondois 
---
 .../DynamicPlatRepoLib/CmObjectTokenFixer.c   | 164 ++
 .../DynamicPlatRepoLib/CmObjectTokenFixer.h   |  52 ++
 2 files changed, 216 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.h

diff --git 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.c 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.c
new file mode 100644
index ..74eeefccf4ce
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/CmObjectTokenFixer.c
@@ -0,0 +1,164 @@
+/** @file
+  Configuration Manager object token fixer
+
+  Copyright (c) 2021, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+**/
+
+#include 
+#include 
+#include "CmObjectTokenFixer.h"
+
+/** Token fixer not implemented.
+
+  Most of the objects are not generated by this parser. Add the missing
+  functions when needed.
+
+  CmObjectToken fixer function that updates the Tokens in the CmObjects.
+
+  @param [in]  CmObjectPointer to the Configuration Manager Object.
+  @param [in]  Token   Token to be updated in the CmObject.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_UNSUPPORTED   Not supported.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+TokenFixerNotImplemented (
+  IN  CM_OBJ_DESCRIPTOR   * CmObject,
+  IN  CM_OBJECT_TOKEN   Token
+  )
+{
+  ASSERT (0);
+  return EFI_UNSUPPORTED;
+}
+
+/** EArmObjItsGroup token fixer.
+
+  CmObjectToken fixer function that updates the Tokens in the CmObjects.
+
+  @param [in]  CmObjectPointer to the Configuration Manager Object.
+  @param [in]  Token   Token to be updated in the CmObject.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_UNSUPPORTED   Not supported.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+TokenFixerItsGroup (
+  IN  CM_OBJ_DESCRIPTOR   * CmObject,
+  IN  CM_OBJECT_TOKEN   Token
+  )
+{
+  ASSERT (CmObject != NULL);
+  ((CM_ARM_ITS_GROUP_NODE*)CmObject)->Token = Token;
+  return EFI_SUCCESS;
+}
+
+/** TokenFixer functions table.
+
+  A CmObj having a CM_OBJECT_TOKEN field might need to have its
+  Token fixed. Each CmObj can have its Token in a specific way.
+*/
+CONST
+CM_OBJECT_TOKEN_FIXER TokenFixer[EArmObjMax] = {
+  NULL, ///<  0 - Reserved
+  NULL, ///<  1 - Boot Architecture Info
+  NULL, ///<  2 - CPU Info
+  NULL, ///<  3 - Power Management Profile Info
+  NULL, ///<  4 - GIC CPU Interface Info
+  NULL, ///<  5 - GIC Distributor Info
+  NULL, ///<  6 - GIC MSI Frame Info
+  NULL, ///<  7 - GIC Redistributor Info
+  NULL, ///<  8 - GIC ITS Info
+  NULL, ///<  9 - Serial Console Port Info
+  NULL, ///< 10 - Serial Debug Port Info
+  NULL, ///< 11 - Generic Timer Info
+  NULL, ///< 12 - Platform GT Block Info
+  NULL, ///< 13 - Generic Timer Block Frame Info
+  NULL, ///< 14 - Platform Generic Watchdog
+  NULL, ///< 15 - PCI Configuration Space Info
+  NULL, ///< 16 - Hypervisor Vendor Id
+  NULL, ///< 17 - Fixed feature flags for FADT
+  TokenFixerItsGroup,   ///< 18 - ITS Group
+  TokenFixerNotImplemented, ///< 19 - Named Component
+  TokenFixerNotImplemented, ///< 20 - Root Complex
+  TokenFixerNotImplemented, ///< 21 - SMMUv1 or SMMUv2
+  TokenFixerNotImplemented, ///< 22 - SMMUv3
+  TokenFixerNotImplemented, ///< 23 - PMCG
+  NULL, ///< 24 - GIC ITS Identifier Array
+  NULL, ///< 25 - ID Mapping Array
+  NULL, ///< 26 - SMMU Inter

[edk2-devel] [PATCH v2 5/5] DynamicTablesPkg: Add DynamicPlatRepo library

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the inf file of the module and the main module
functionnalities and update the dsc file of the package.

Signed-off-by: Pierre Gondois 
---
 DynamicTablesPkg/DynamicTablesPkg.dsc |   1 +
 .../DynamicPlatRepoLib/DynamicPlatRepo.c  | 515 ++
 .../DynamicPlatRepoInternal.h |  78 +++
 .../DynamicPlatRepoLib/DynamicPlatRepoLib.inf |  33 ++
 4 files changed, 627 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoInternal.h
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf

diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc 
b/DynamicTablesPkg/DynamicTablesPkg.dsc
index a2a1b8d004d2..068f0bc63080 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dsc
+++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
@@ -44,6 +44,7 @@ [Components.common]
   
DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
   DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
   DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
+  DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoLib.inf
 
 [BuildOptions]
   *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
diff --git 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
new file mode 100644
index ..faa431455761
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
@@ -0,0 +1,515 @@
+/** @file
+  Dynamic Platform Info Repository
+
+  Copyright (c) 2021, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "CmObjectTokenFixer.h"
+#include "DynamicPlatRepoInternal.h"
+#include "TokenGenerator.h"
+
+/** Allocate a CM_OBJ_NODE.
+
+  @param [in]  CmObjDesc  CmObj to wrap in a node.
+  All the fields of the CmObj (Data field included),
+  are copied.
+  @param [in]  Token  Token to assign to this CmObj/node.
+  @param [out] ObjNodeAllocated ObjNode.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_OUT_OF_RESOURCES  An allocation has failed.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+AllocCmObjNode (
+  IN  CONST CM_OBJ_DESCRIPTOR   * CmObjDesc,
+  INCM_OBJECT_TOKEN   Token,
+  OUT   CM_OBJ_NODE** ObjNode
+  )
+{
+  CM_OBJ_NODE   *Node;
+  CM_OBJ_DESCRIPTOR *Desc;
+
+  if ((CmObjDesc == NULL) || (ObjNode == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  Node = AllocateZeroPool (sizeof (CM_OBJ_NODE));
+  if (Node == NULL) {
+ASSERT (0);
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  // Initialise the list head.
+  InitializeListHead (&Node->Link);
+  Node->Token = Token;
+  Desc = &Node->CmObjDesc;
+  Desc->ObjectId = CmObjDesc->ObjectId;
+  Desc->Size = CmObjDesc->Size;
+  Desc->Count = CmObjDesc->Count;
+
+  // Allocate and copy the CmObject Data.
+  Desc->Data = AllocateCopyPool (CmObjDesc->Size, CmObjDesc->Data);
+  if (Desc->Data == NULL) {
+FreePool (Node);
+ASSERT (0);
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  *ObjNode = Node;
+  return EFI_SUCCESS;
+}
+
+/** Free a CM_OBJ_NODE.
+
+  @param [in]  ObjNodeObjNode to free.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+FreeCmObjNode (
+  IN  CM_OBJ_NODE   * ObjNode
+  )
+{
+  CM_OBJ_DESCRIPTOR   *Desc;
+
+  if (ObjNode == NULL) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  // Unlink Node
+  RemoveEntryList (&ObjNode->Link);
+
+  Desc = &ObjNode->CmObjDesc;
+  if (Desc->Data != NULL) {
+FreePool (Desc->Data);
+  }
+
+  FreePool (ObjNode);
+  return EFI_SUCCESS;
+}
+
+/** Add an object to the dynamic platform repository.
+
+  @param [in]  This   This dynamic platform repository.
+  @param [in]  CmObjDesc  CmObj to add. The data is copied.
+  @param [out] Token  If not NULL, token allocated to this CmObj.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+

[edk2-devel] [PATCH v2 1/5] DynamicTablesPkg: Definition for DynamicPlatRepoLib interface

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The DynamicPlatRepoLib library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to
retrieve dynamic CmObjs among all CmObj (static CmObj for instance).

This patch defines the library interface of the DynamicPlatRepo.

Signed-off-by: Pierre Gondois 
---
 DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
 .../Include/Library/DynamicPlatRepoLib.h  | 114 ++
 2 files changed, 117 insertions(+)
 create mode 100644 DynamicTablesPkg/Include/Library/DynamicPlatRepoLib.h

diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec 
b/DynamicTablesPkg/DynamicTablesPkg.dec
index 80a61dd2dbac..9b74c5a67178 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.dec
+++ b/DynamicTablesPkg/DynamicTablesPkg.dec
@@ -24,6 +24,9 @@ [LibraryClasses]
   ##  @libraryclass  Defines a set of APIs for Dynamic AML generation.
   AmlLib|Include/Library/AmlLib/AmlLib.h
 
+  ##  @libraryclass  Defines a set of APIs to handle dynamically created CmObj.
+  DynamicPlatRepoLib|Include/Library/DynamicPlatRepoLib.h
+
   ##  @libraryclass  Defines a set of APIs to a hardware information parser.
   HwInfoParserLib|Include/Library/HwInfoParserLib.h
 
diff --git a/DynamicTablesPkg/Include/Library/DynamicPlatRepoLib.h 
b/DynamicTablesPkg/Include/Library/DynamicPlatRepoLib.h
new file mode 100644
index ..4a76b30399b4
--- /dev/null
+++ b/DynamicTablesPkg/Include/Library/DynamicPlatRepoLib.h
@@ -0,0 +1,114 @@
+/** @file
+  Dynamic Platform Info Repository
+
+  Copyright (c) 2021, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+**/
+
+#ifndef DYNAMIC_PLAT_REPO_H_
+#define DYNAMIC_PLAT_REPO_H_
+
+#include 
+
+/** A structure describing the platform configuration
+manager repository information
+*/
+typedef VOID*DYNAMIC_PLATFORM_REPOSITORY_INFO;
+
+/** Add an object to the dynamic platform repository.
+
+  @param [in]  This   This dynamic platform repository.
+  @param [in]  CmObjDesc  CmObj to add. The data is copied.
+  @param [out] Token  If not NULL, token allocated to this CmObj.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_OUT_OF_RESOURCES  An allocation has failed.
+**/
+EFI_STATUS
+EFIAPI
+DynPlatRepoAddObject (
+  INDYNAMIC_PLATFORM_REPOSITORY_INFO* This,
+  IN  CONST CM_OBJ_DESCRIPTOR   * CmObjDesc,
+  OUT   CM_OBJECT_TOKEN * Token OPTIONAL
+  );
+
+/** Finalise the dynamic repository.
+
+  Finalising means:
+   - Preventing any further objects from being added.
+   - Allowing to get objects from the dynamic repository
+ (not possible before a call to this function).
+
+  @param [in]  This   This dynamic platform repository.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_ALREADY_STARTED   Instance already initialised.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_BUFFER_TOO_SMALL  Buffer too small.
+  @retval EFI_OUT_OF_RESOURCES  An allocation has failed.
+**/
+EFI_STATUS
+EFIAPI
+DynamicPlatRepoFinalise (
+  IN  DYNAMIC_PLATFORM_REPOSITORY_INFO  * This
+  );
+
+/** Get a CmObj from the dynamic repository.
+
+  @param [in]  ThisPointer to the Dynamic Platform Repository.
+  @param [in]  CmObjectId  The Configuration Manager Object ID.
+  @param [in]  Token   An optional token identifying the object. If
+   unused this must be CM_NULL_TOKEN.
+  @param [in, out] CmObjDesc   Pointer to the Configuration Manager Object
+   descriptor describing the requested Object.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_NOT_FOUND The required object information is not found.
+**/
+EFI_STATUS
+EFIAPI
+DynamicPlatRepoGetObject (
+  IN  DYNAMIC_PLATFORM_REPOSITORY_INFO* This,
+  IN  CM_OBJECT_ID  CmObjectId,
+  IN  CM_OBJECT_TOKEN   Token OPTIONAL,
+  IN  OUT CM_OBJ_DESCRIPTOR   * CmObjDesc
+  );
+
+/** Initialize the dynamic platform repository.
+
+  @param [out]  DynPlatRepo   If success, contains the initialised dynamic
+  platform repository.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_OUT_OF_RESOURCES  An allocation has failed.
+**/
+EFI_STATUS
+EFIAPI
+DynamicPlatRepoInit (
+  OUT DYNAMIC_PLATFORM_REPOSITORY_INFO

[edk2-devel] [PATCH v2 4/5] DynamicTablesPkg: DynamicPlatRepo: Add TokenMapper

2021-11-23 Thread PierreGondois
From: Pierre Gondois 

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the TokenMapper files, allowing to retrieve a CmObj
from a token/CmObjId couple.

Signed-off-by: Pierre Gondois 
---
 .../Common/DynamicPlatRepoLib/TokenMapper.c   | 218 ++
 .../Common/DynamicPlatRepoLib/TokenMapper.h   | 123 ++
 2 files changed, 341 insertions(+)
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.c
 create mode 100644 
DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.h

diff --git a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.c 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.c
new file mode 100644
index ..a871320715a3
--- /dev/null
+++ b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/TokenMapper.c
@@ -0,0 +1,218 @@
+/** @file
+  Token Mapper
+
+  Copyright (c) 2021, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Glossary:
+- Cm or CM   - Configuration Manager
+- Obj or OBJ - Object
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+#include "TokenMapper.h"
+
+/** Add a CmObjDesc to the TokenMapper.
+
+  @param [in] TokenMapper   The TokenMapper instance.
+  @param [in] Token CmObj token.
+  @param [in] ObjectId  CmObj ObjectId.
+  @param [in] Size  CmObj Size.
+  @param [in] Data  CmObj Data.
+This memory is referenced, not copied.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_BUFFER_TOO_SMALLBuffer too small.
+  @retval EFI_INVALID_PARAMETER   A parameter is invalid.
+**/
+EFI_STATUS
+EFIAPI
+TokenMapperAddObject (
+  IN  TOKEN_MAPPER  *TokenMapper,
+  IN  CM_OBJECT_TOKEN   Token,
+  IN  CM_OBJECT_ID  ObjectId,
+  IN  UINT32Size,
+  IN  VOID  *Data
+  )
+{
+  TOKEN_MAP_DESCRIPTOR  *TokenMapDesc;
+  CM_OBJ_DESCRIPTOR *CmObjDesc;
+
+  if ((TokenMapper == NULL) ||
+  (TokenMapper->TokenDescArray == NULL) ||
+  (Size == 0)   ||
+  (Data == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (TokenMapper->ItemCount >= TokenMapper->MaxTokenDescCount) {
+ASSERT (0);
+return EFI_BUFFER_TOO_SMALL;
+  }
+
+  TokenMapDesc = &TokenMapper->TokenDescArray[TokenMapper->ItemCount++];
+  TokenMapDesc->Token = Token;
+  CmObjDesc = &TokenMapDesc->CmObjDesc;
+  CmObjDesc->ObjectId = ObjectId;
+  CmObjDesc->Size = Size;
+
+  // Point inside the finalized array.
+  CmObjDesc->Data = Data;
+
+  // Only EArmObjCmRef CmObj can be added as arrays (more than 1 elements).
+  if ((GET_CM_NAMESPACE_ID (ObjectId) == EObjNameSpaceArm) &&
+  (GET_CM_OBJECT_ID (ObjectId) == EArmObjCmRef)) {
+CmObjDesc->Count = Size / sizeof (CM_ARM_OBJ_REF);
+  } else {
+CmObjDesc->Count = 1;
+  }
+
+  return EFI_SUCCESS;
+}
+
+/** Get a CmObjDesc from a ObjectId/Token couple.
+
+  The Token parameter is not optional. An existing token must be provided.
+
+  @param [in]  TokenMapper   The TokenMapper instance.
+  @param [in]  Token Token of the CmObj to search.
+  @param [in]  ObjectId  Object Id of the CmObj to search.
+  @param [out] CmObjDesc CM_OBJ_DESCRIPTOR containing the CmObj searched.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   A parameter is invalid.
+  @retval EFI_NOT_FOUND   Not found.
+**/
+EFI_STATUS
+EFIAPI
+TokenMapperGetObject (
+  IN  TOKEN_MAPPER*TokenMapper,
+  IN  CM_OBJECT_TOKEN Token,
+  IN  CM_OBJECT_IDObjectId,
+  OUT CM_OBJ_DESCRIPTOR   *CmObjDesc
+  )
+{
+  UINTN Index;
+  UINTN MaxCount;
+  TOKEN_MAP_DESCRIPTOR  *TokenMapDesc;
+
+  // Nothing to do.
+  if ((TokenMapper != NULL) && (TokenMapper->MaxTokenDescCount == 0)) {
+goto exit_handler;
+  }
+
+  if ((Token == CM_NULL_TOKEN)  ||
+  (CmObjDesc == NULL)   ||
+  (TokenMapper == NULL) ||
+  (TokenMapper->TokenDescArray == NULL)) {
+ASSERT (0);
+return EFI_INVALID_PARAMETER;
+  }
+
+  TokenMapDesc = TokenMapper->TokenDescArray;
+  MaxCount = TokenMapper->MaxTokenDescCount;
+  for (Index = 0; Index < MaxCount; Index++) {
+if ((TokenMapDesc->CmObjDesc.ObjectId == ObjectId)  &&
+(TokenMapDesc->Token == Token)) {
+  CopyMem (
+CmObjDesc,
+&TokenMapDesc->CmObjDesc,
+sizeof (CM_OBJ

Re: [edk2-devel] [PATCH V2 2/3] MdePkg/Base.h: Introduce various alignment-related macros

2021-11-23 Thread Marvin Häuser

Ping? :)

On 16.08.21 15:10, Marvin Häuser wrote:

Hey Ray,

On 16/08/2021 11:42, Ni, Ray wrote:

Marvin,
So lucky to have you in the edk2 project looking into these 
fundamentals!


Thank you. :)


+  #define ALIGNOF(TYPE) OFFSET_OF (struct { CHAR8 C; TYPE A; }, A)

1. Does struct{} inside a macro conform to C standard? How is the 
compatibility with different compilers?


This should work, yes. The C standard defines offsetof as such:

"The macros are [...]

        offsetof(type, member-designator)

which expands to an integer constant expression that has type size_t, 
the value of
which is the offset in bytes, to the structure member (designated by 
member-designator),
from the beginning of its structure (designated by type). The type and 
member designator

shall be such that given

        static type t;

then the expression &(t.member-designator) evaluates to an address 
constant. [...]" [1]


If we plug in t:

        static struct { CHAR8 C; TYPE A; } t;

we get a valid static storage duration variable declaration that 
satisfies the the last condition because:


"An address constant is [...], a pointer to an lvalue designating an 
object of static

storage duration, or [...]" [2]

It worked with all compilers I tinkered with at https://godbolt.org/
I sadly do not have access to any of the compilers where this may be 
used effectively (RVCT, EBC).



+#define IS_POW2(Value)  ((Value) != 0U && ((Value) & ((Value) - 1U)) ==
+0U)

2. Good to me. I learned this trick when implementing the MtrrLib.

+#define ALIGN_VALUE_ADDEND(Value, Alignment)  (((Alignment) - (Value))
+& ((Alignment) - 1U))

3. Is any other open source project using the same macro for the addend?
This is actually a general question to all new macros.
I would like the macros look familiar to developers from other open 
source projects.


Good question, I never really saw it. I only came up with it because 
for the new PE loader, we may align the PE memory within an 
underaligned buffer, and for that we need the addend. I initially used 
to align up and then subtract, but I saw this could be simplified with 
ALIGN_VALUE_ADDEND, which was used in ALIGN_VALUE anyway. If you have 
a better name, I'll change it.


Best regards,
Marvin


[1] ISO/IEC 9899:2011, 7.19, 3.

[2] ISO/IEC 9899:2011, 6.6, 9.













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




Re: [edk2-devel] [PATCH V3 3/3] OvmfPkg: Move LocalApicTimerDxe to UefiCpuPkg

2021-11-23 Thread Gerd Hoffmann
  Hi,

> > 2. Can SourceLevelDebug (rely on Local APIC timer) work if this driver is
> > chosen as DXE timer driver?
> After checking the code and running the PoC (enable SourceLevelDebug and 
> LocalApicTimerDxe),  I find this driver doesn't work anymore. 
> Actually it asserts in 
> https://github.com/mxu9/edk2/blob/ovmf_lapic_timer.v3/UefiCpuPkg/LocalApicTimerDxe/LocalApicTimerDxe.c#L334

Hmm, I guess this makes LocalApicTimerDxe alot less useful on physical
hardware.  So keep it in OvmdPkg?

For virtual machines there are other debugging options, using qemu's
builtin gdb server for example, so SourceLevelDebug not being available
isn't a big issue IMHO.

> For TDVF we assume SourceLevelDebug is not supported. So LocalApicTimerDxe is 
> still working for TDVF.
> 
> For other VM guests in OvmfPkg, can we assume SourceLevelDebug is NOT 
> supported after LocalApicTimer is used (the older timer is 8254)?
> @ Gerd Hoffmann (OvmfPkg)

Fine with me.

> @ Anthony Perard , Julien Grall (Xen) 

Xen already uses the apic timer today, so that shouldn't be a problem
either ;)

take care,
  Gerd



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




Re: [edk2-devel] [PATCH V3 3/3] OvmfPkg: Move LocalApicTimerDxe to UefiCpuPkg

2021-11-23 Thread Min Xu
On November 22, 2021 11:05 AM, Ni Ray wrote:
> Min,
> What's the reason of moving this driver to UefiCpuPkg?
Please refer to the discussion in 
https://edk2.groups.io/g/devel/topic/86735078#83126
Because localApicTimerDxe is hardware feature. There is no specific OVMF or 
QEMU related thing there. It does not make sense to keep it to OvmfPkg.
> 
> When the LocalApicTimerDxe is in OvmfPkg, it's clear that this driver is only
> used by OVMF/QEMU platform.
> Now since the patch moves the driver to UefiCpuPkg, it's possible that other
> platforms may choose this driver as the timer driver in DXE phase.
> 
> So, we need to make sure the quality of this driver is good enough for a
> broad scope of platforms.
> 
> 1. What's the issue when this driver still stays in OvmfPkg? If it's a must 
> that
> this driver stays in UefiCpuPkg, please help to address following questions:
> 
> 2. Can SourceLevelDebug (rely on Local APIC timer) work if this driver is
> chosen as DXE timer driver?
After checking the code and running the PoC (enable SourceLevelDebug and 
LocalApicTimerDxe),  I find this driver doesn't work anymore. 
Actually it asserts in 
https://github.com/mxu9/edk2/blob/ovmf_lapic_timer.v3/UefiCpuPkg/LocalApicTimerDxe/LocalApicTimerDxe.c#L334

For TDVF we assume SourceLevelDebug is not supported. So LocalApicTimerDxe is 
still working for TDVF.

For other VM guests in OvmfPkg, can we assume SourceLevelDebug is NOT supported 
after LocalApicTimer is used (the older timer is 8254)?
@Gerd Hoffmann (OvmfPkg)
@ Rebecca Cran, @ Peter Grehan  (Bhyve)
@ Tom Lendacky, @Brijesh Singh (Sev)
@ Anthony Perard , Julien Grall (Xen) 

This limitation will be documented in LocalApicTimerDxe.inf so that the user of 
this timer driver is aware of it.

> 3. Can detailed comments be added for " @bug : This does not handle
> missed timer interrupts" in TimerInterruptHandler()?
Sure. More comments will be added.
> 4. Can detailed comments be added for " DisableInterrupts ();" in
> TimerInterruptHandler()?
Sure. More comments will be added.
> 5. In general what kinds of platforms are capable of using this driver as 
> Timer
> driver?
Platforms that support local Apic are capable of using this driver.
> 

Thanks
Min


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