aab3b9b9a1
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2220 This change reduces SMIs for GetVariable () by maintaining a UEFI variable cache in Runtime DXE in addition to the pre- existing cache in SMRAM. When the Runtime Service GetVariable() is invoked, a Runtime DXE cache is used instead of triggering an SMI to VariableSmm. This can improve overall system performance by servicing variable read requests without rendezvousing all cores into SMM. The runtime cache can be disabled with by setting the FeaturePCD gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache to FALSE. If the PCD is set to FALSE, the runtime cache will not be used and an SMI will be triggered for Runtime Service GetVariable () and GetNextVariableName () invocations. The following are important points regarding the behavior of the variable drivers when the variable runtime cache is enabled. 1. All of the non-volatile storage contents are loaded into the cache upon driver load. This one time load operation from storage is preferred as opposed to building the cache on demand. An on- demand cache would require a fallback SMI to load data into the cache as variables are requested. 2. SetVariable () requests will continue to always trigger an SMI. This occurs regardless of whether the variable is volatile or non-volatile. 3. Both volatile and non-volatile variables are cached in a runtime buffer. As is the case in the current EDK II variable driver, they continue to be cached in separate buffers. 4. The cache in Runtime DXE and SMM are intended to be exact copies of one another. All SMM variable accesses only return data from the SMM cache. The runtime caches are only updated after the variable I/O operation is successful in SMM. The runtime caches are only updated from SMM. 5. Synchronization mechanisms are in place to ensure the runtime cache content integrity with the SMM cache. These may result in updates to runtime cache that are the same in content but different in offset and size from updates to the SMM cache. When using SMM variables with runtime cache enabled, two caches will now be present. 1. "Runtime Cache" - Maintained in VariableSmmRuntimeDxe. Used to service Runtime Services GetVariable () and GetNextVariableName () callers. 2. "SMM Cache" - Maintained in VariableSmm to service SMM GetVariable () and GetNextVariableName () callers. a. This cache is retained so SMM modules do not operate on data outside SMRAM. Because a race condition can occur if an SMI occurs during the execution of runtime code reading from the runtime cache, a runtime cache read lock is introduced that explicitly moves pending updates from SMM to the runtime cache if an SMM update occurs while the runtime cache is locked. Note that it is not expected a Runtime services call will interrupt SMM processing since all CPU cores rendezvous in SMM. It is possible to view UEFI variable read and write statistics by setting the gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics FeaturePcd to TRUE and using the VariableInfo UEFI application in MdeModulePkg to dump variable statistics to the console. By doing so, a user can view the number of GetVariable () hits from the Runtime DXE variable driver (Runtime Cache hits) and the SMM variable driver (SMM Cache hits). SMM Cache hits for GetVariable () will occur when SMM modules invoke GetVariable (). Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> |
||
---|---|---|
ArmPkg | ||
ArmPlatformPkg | ||
ArmVirtPkg | ||
BaseTools | ||
Conf | ||
CryptoPkg | ||
DynamicTablesPkg | ||
EmbeddedPkg | ||
EmulatorPkg | ||
FatPkg | ||
FmpDevicePkg | ||
IntelFsp2Pkg | ||
IntelFsp2WrapperPkg | ||
MdeModulePkg | ||
MdePkg | ||
NetworkPkg | ||
OvmfPkg | ||
PcAtChipsetPkg | ||
SecurityPkg | ||
ShellPkg | ||
SignedCapsulePkg | ||
SourceLevelDebugPkg | ||
StandaloneMmPkg | ||
UefiCpuPkg | ||
UefiPayloadPkg | ||
.gitignore | ||
.gitmodules | ||
License-History.txt | ||
License.txt | ||
Maintainers.txt | ||
Readme.md | ||
edksetup.bat | ||
edksetup.sh |
Readme.md
EDK II Project
A modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org.
The majority of the content in the EDK II open source project uses a BSD-2-Clause Plus Patent License. The EDK II open source project contains the following components that are covered by additional licenses:
- BaseTools/Source/C/BrotliCompress
- MdeModulePkg/Library/BrotliCustomDecompressLib
- BaseTools/Source/C/LzmaCompress
- MdeModulePkg/Library/LzmaCustomDecompressLib
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/Sdk
- BaseTools/Source/C/VfrCompile/Pccts
- MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma
- OvmfPkg
- CryptoPkg/Library/OpensslLib/openssl
- ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
The EDK II Project is composed of packages. The maintainers for each package are listed in Maintainers.txt.
Resources
- TianoCore
- EDK II
- Getting Started with EDK II
- Mailing Lists
- TianoCore Bugzilla
- How To Contribute
- Release Planning
Code Contributions
To make a contribution to a TianoCore project, follow these steps.
-
Create a change description in the format specified below to use in the source control commit log.
-
Your commit message must include your
Signed-off-by
signature -
Submit your code to the TianoCore project using the process that the project documents on its web page. If the process is not documented, then submit the code on development email list for the project.
-
It is preferred that contributions are submitted using the same copyright license as the base project. When that is not possible, then contributions using the following licenses can be accepted:
- BSD (2-clause): http://opensource.org/licenses/BSD-2-Clause
- BSD (3-clause): http://opensource.org/licenses/BSD-3-Clause
- MIT: http://opensource.org/licenses/MIT
- Python-2.0: http://opensource.org/licenses/Python-2.0
- Zlib: http://opensource.org/licenses/Zlib
For documentation:
- FreeBSD Documentation License https://www.freebsd.org/copyright/freebsd-doc-license.html
Contributions of code put into the public domain can also be accepted.
Contributions using other licenses might be accepted, but further review will be required.
Developer Certificate of Origin
Your change description should use the standard format for a
commit message, and must include your Signed-off-by
signature.
In order to keep track of who did what, all patches contributed must include a statement that to the best of the contributor's knowledge they have the right to contribute it under the specified license.
The test for this is as specified in the Developer's Certificate of Origin (DCO) 1.1. The contributor certifies compliance by adding a line saying
Signed-off-by: Developer Name developer@example.org
where Developer Name
is the contributor's real name, and the email
address is one the developer is reachable through at the time of
contributing.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Sample Change Description / Commit Message
From: Contributor Name <contributor@example.com>
Subject: [Repository/Branch PATCH] Pkg-Module: Brief-single-line-summary
Full-commit-message
Signed-off-by: Contributor Name <contributor@example.com>
Notes for sample patch email
- The first line of commit message is taken from the email's subject
line following
[Repository/Branch PATCH]
. The remaining portion of the commit message is the email's content. git format-patch
is one way to create this format
Definitions for sample patch email
Repository
is the identifier of the repository the patch applies. This identifier should only be provided for repositories other thanedk2
. For exampleedk2-BuildSpecification
orstaging
.Branch
is the identifier of the branch the patch applies. This identifier should only be provided for branches other thanedk2/master
. For exampleedk2/UDK2015
,edk2-BuildSpecification/release/1.27
, orstaging/edk2-test
.Module
is a short identifier for the affected code or documentation. For exampleMdePkg
,MdeModulePkg/UsbBusDxe
,Introduction
, orEDK II INF File Format
.Brief-single-line-summary
is a short summary of the change.- The entire first line should be less than ~70 characters.
Full-commit-message
a verbose multiple line comment describing the change. Each line should be less than ~70 characters.Signed-off-by
is the contributor's signature identifying them by their real/legal name and their email address.
Submodules
Submodule in EDK II is allowed but submodule chain should be avoided as possible as we can. Currently EDK II contains two submodules
- CryptoPkg/Library/OpensslLib/openssl
- ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
The latter one is actually required by previous one. It's inevitable in openssl-1.1.1 (since stable201905) for floating point parameter conversion, but should be dropped once there's no such need in future release of openssl.
To get a full, buildable EDK II repository, use following steps of git command
$ git clone https://github.com/tianocore/edk2.git
$ cd edk2
$ git submodule update --init
$ cd ..
If there's update for submodules, use following git commands to get the latest submodules code.
$ cd edk2
$ git pull
$ git submodule update
Note: When cloning submodule repos, '--recursive' option is not recommended. EDK II itself will not use any code/feature from submodules in above submodules. So using '--recursive' adds a dependency on being able to reach servers we do not actually want any code from, as well as needlessly downloading code we will not use.