[edk2-devel] 回复: [Patch V2 0/3] Remove git reset and optimize
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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] -=-=-=-=-=-=-=-=-=-=-=-