According to UEFI spec, only bits 0-15 of CapsuleFlags are
meaningful and CapsuleGuid specific, CAPSULE_FLAGS_PERSIST_ACROSS_RESET
CAPSULE_FLAGS_POPULATE_SYSTEM_TABLE/CAPSULE_FLAGS_INITIATE_RESET
defined in UEFI spec are in bits 16-31, they should not be parsed in
CapsuleFlags of ESRT.
CapsuleFlags
The capsule flags field contains the CapsuleGuid flags (bits 0-15)
as defined in the EFI_CAPSULE_HEADER that will be set in the capsule
header.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Image buffer should be freed after using.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Also add help info for CapsuleApp -P GET option.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
V3: Add some invalid type and datum check
V2: limit the PCD used in the [Depex] section should be used in the module
The PCD item used in INF [Depex] section must be defined as FixedAtBuild
type and VOID* datum type, and the size of the PCD must be 16 bytes.
Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=443
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Add more logic to filter invalid function parameter in MOR Control SMI handler
Cc: Long Qin <qin.long@intel.com>
Cc: Yao Jiewen <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Long Qin <qin.long@intel.com>
XenPvBlkDxe doesn't reference gEfiDevicePathProtocolGuid; remove it from
the INF file.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Steven Shi <steven.shi@intel.com>
Reported-by: Steven Shi <steven.shi@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1034
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This patch adds a simple CPU driver that exports the
EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
MM Foundation entry point. It preserves the existing notification
mechanism for the configuration protocol.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms and is initialised during the SEC phase. ARM Trusted firmware
in EL3 is responsible for initialising the architectural context for
S-EL0 and loading the Standalone MM image. The memory allocated to this
image is marked as RO+X. Heap memory is marked as RW+XN.
Certain actions have to be completed prior to executing the generic code
in the Standalone MM Core module. These are:
1. Memory permission attributes for each section of the Standalone MM
Core module need to be changed prior to accessing any RW data.
2. A Hob list has to be created with information that allows the MM
environment to initialise and dispatch drivers.
Furthermore, this module is responsible for handing over runtime MM
events to the Standalone MM CPU driver and returning control to ARM
Trusted Firmware upon event completion. Hence it needs to know the CPU
driver entry point.
This patch implements an entry point module that ARM Trusted Firmware
jumps to in S-EL0. It then performs the above actions before calling the
Standalone MM Foundation entry point and handling subsequent MM events.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The Standalone MM environment is initialized during the SEC phase on ARM
Standard Platforms. The MM Core driver implements an entry point module
which is architecture specific and runs prior to the generic core driver
code. The former creates a Hob list that the latter consumes. This
happens in the same phase.
This patch implements a Hob library that can be used by the entry point
module to produce a Hob list and by the core driver code to consume it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
MM memory check library library implementation. This library consumes
MM_ACCESS_PROTOCOL to get MMRAM information. In order to use this
library instance, the platform should produce all MMRAM range via
MM_ACCESS_PROTOCOL, including the range for firmware (like MM Core
and MM driver) and/or specific dedicated hardware.
This patch provides services for MM Memory Operation.
The management mode Mem Library provides function for checking if buffer
is outside MMRAM and valid. It also provides functions for copy data
from MMRAM to non-MMRAM, from non-MMRAM to MMRAM,
from non-MMRAM to non-MMRAM, or set data in non-MMRAM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
This patch implements a firmware volume library that can be used by the
Standalone management mode core module to parse the firmware volume.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
This patch deletes "StandaloneMmPkg" which was created as a file
intially. This patch enables creation of "StandaloneMmPkg" as a folder.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Current IsInSmm() method makes use of gEfiSmmBase2ProtocolGuid.InSmm() to
check if current processor is in SMM mode or not. But this is not correct
because gEfiSmmBase2ProtocolGuid.InSmm() can only detect if the caller is
running in SMRAM or from SMM driver. It cannot guarantee if the caller is
running in SMM mode. Because SMM mode will load its own page table, adding
an extra check of saved DXE page table base address against current CR3
register value can help to get the correct answer for sure (in SMM mode or
not in SMM mode).
There's indiscriminate uses of Context.X64 and Context.Ia32 in code which
is not a good coding practice and will cause potential issue. In addition,
the related structure type definition is not packed and has also potential
issue. This will not be covered by this patch but be tracked by a bug below.
https://bugzilla.tianocore.org/show_bug.cgi?id=1039
This is an issue caused by check-in at
2a1408d1d7
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Current function has low performance because it calls GetApicId
in the loop, so it maybe called more than once.
New logic call GetApicId once and base on this value to search
the processor.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <vanjeff_919@hotmail.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
None of the source files referenced by "AcpiPlatformDxe.inf" #include
"MdePkg/Include/Library/DxeServicesLib.h" or use interfaces declared
therein, so drop DxeServicesLib from [LibraryClasses].
"AcpiPlatformDxe.inf" references "AcpiPlatform.c", which installs ACPI
tables built into the firmware image from under "OvmfPkg/AcpiTables/", in
case dynamically generated ACPI tables are not available from Xen or QEMU.
For this, the driver consumes gEfiFirmwareVolume2ProtocolGuid. Account for
that in [Protocols].
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reported-by: Steven Shi <steven.shi@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1014
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
When resume from S3 and CPU loop mode is MWait mode,
if driver calls APs to do task at EndOfPei point, the
APs can't been wake up and bios hang at that point.
The root cause is PiSmmCpuDxeSmm driver wakes up APs
with HLT mode during S3 resume phase to do SMM relocation.
After this task, PiSmmCpuDxeSmm driver not restore APs
context which make CpuMpPei driver saved wake up buffer
not works.
The solution for this issue is let CpuMpPei driver hook
S3SmmInitDone ppi notification. In this notify function,
it check whether Cpu Loop mode is not HLT mode. If yes,
CpuMpPei driver will set a flag to force BSP use INIT-SIPI
-SIPI command to wake up the APs.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The SDM requires only one thread per core to load the
microcode.
This change enables this solution.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Search uCode costs much time, if AP has same processor type
with BSP, AP can use BSP saved uCode info to get better performance.
This change enables this solution.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Read uCode from memory has better performance than from flash.
But it needs extra effort to let BSP copy uCode from flash to
memory. Also BSP already enable cache in SEC phase, so it use
less time to relocate uCode from flash to memory. After
verification, if system has more than one processor, it will
reduce some time if load uCode from memory.
This change enable this optimization.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The case is the Pcd item both used in 1 module inf and 1 lib inf, and
in the DSC component section, it override the Pcd value.
In the module, the pcd value is the override value, but in the lib inf
the pcd value is the value that in the DSC PCD section's value, then it
cause the Pcd value is different in the module and lib. but actually we
only need use the Pcd value in the module to decide whether it use the
same value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
"Triggle" is a typo. Replace it with "Trigger"
Cc: Long Qin <qin.long@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Long Qin <qin.long@intel.com>
Since Ecc.py import modules from its own directory, add "-m" to the
python parameters so that they can import its own modules after adopting
absolute import.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Since BPDG.py import modules from its own directory, add "-m" to the
python parameters so that they can import its own modules after adopting
absolute import.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Move "ImageBinDict" from GenFds.py to GenFdsGlobalVariable.py so that we
can remove the requirement to import GenFds.GenFds in Capsule.py, Fd.py and
Fv.py. This breaks the following circular imports:
* GenFds.FdfParser => GenFds.Capsule => GenFds.GenFds => GenFds.FdfParser
* GenFds.FdfParser => GenFds.Fd => GenFds.GenFds => GenFds.FdfParser
* GenFds.FdfParser => GenFds.Fd => GenFds.Fv => GenFds.GenFds =>
GenFds.FdfParser
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Since GenFds.py import modules from its own directory, add "-m" to the
python parameters so that they can import its own modules after adopting
absolute import.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Add the IPv6 stack to ArmVirtQemu with a cumulative port of the following
OvmfPkg commits:
* 36c6413f76 "OvmfPkg: enable the IPv6 support", 2014-12-19
* 96302b80d9 "OvmfPkg: Enable Network2 Shell Commands for IPv6",
2016-03-08
* 6d0f8941bd "OvmfPkg: always resolve OpenSslLib, IntrinsicLib and
BaseCryptLib", 2017-01-17
* 32e22f20c9 "OvmfPkg: correct the IScsiDxe module included for the IPv6
stack", 2017-01-17
The IPv6-enabled IScsiDxe driver depends on BaseCryptLib, and the
"CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf" instance depends on
IntrinsicLib and OpensslLib. This is why commit 6d0f8941bd is relevant.
However, unlike in OvmfPkg, in ArmVirtPkg we'll precisely track the
firmware features that require these library classes. (The OvmfPkg
discussion was quite complex, and the OvmfPkg solution was a compromise:
<http://mid.mail-archive.com/1484569332-13440-1-git-send-email-jiaxin.wu@intel.com>.)
The ArmVirtXen platform is not extended with the relevant drivers because
currently it doesn't include any networking support.
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1007
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Star Zeng
Yunhua Feng
Zhang, Chao B
Laszlo Ersek
Supreeth Venkatesh
Jian J Wang
Eric Dong
Yonghong Zhu
BobCF
Gary Lin
Dandan Bi