The current variable policy is allocated by AllocatePool(), which is
boot time only. This means that if you do any variable setting in the
runtime, the policy has been freed. Ordinarily this isn't detected
because freed memory is still there, but when you boot the Linux
kernel, it's been remapped so the actual memory no longer exists in
the memory map causing a page fault.
Fix this by making it AllocateRuntimePool(). For SMM drivers, the
platform DSC is responsible for resolving the MemoryAllocationLib
class to the SmmMemoryAllocationLib instance. In the
SmmMemoryAllocationLib instance, AllocatePool() and
AllocateRuntimePool() are implemented identically. Therefore this
change is a no-op when the RegisterVariablePolicy() function is built
into an SMM driver. The fix affects runtime DXE drivers only.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3092
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The LzmaUefiDecompressGetInfo() function
[MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaDecompress.c] currently
silently truncates the UINT64 "DecodedSize" property of the compressed
blob to the UINT32 "DestinationSize" output parameter.
If "DecodedSize" is 0x1_0000_0100, for example, then the subsequent memory
allocation (for decompression) will likely succeed (allocating 0x100 bytes
only), but then the LzmaUefiDecompress() function (which re-fetches the
uncompressed buffer size from the same LZMA header into a "SizeT"
variable) will overwrite the buffer.
Catch (DecodedSize > MAX_UINT32) in LzmaUefiDecompressGetInfo() at once.
This should not be a practical limitation. (The issue cannot be fixed for
32-bit systems without spec modifications anyway, given that the
"OutputSize" output parameter of
EFI_GUIDED_SECTION_EXTRACTION_PROTOCOL.ExtractSection() has type UINTN,
not UINT64.)
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1816
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119115034.12897-2-lersek@redhat.com>
The DXE Core sets up a protocol notify function in its entry point, for
instances of the Firmware Volume Block2 Protocol:
DxeMain() [DxeMain/DxeMain.c]
FwVolDriverInit() [FwVol/FwVol.c]
Assume that a 3rd party UEFI driver or application installs an FVB
instance, with crafted contents. The notification function runs:
NotifyFwVolBlock() [FwVol/FwVol.c]
installing an instance of the Firmware Volume 2 Protocol on the handle.
(Alternatively, assume that a 3rd party application calls
gDS->ProcessFirmwareVolume(), which may also produce a Firmware Volume 2
Protocol instance.)
The EFI_FIRMWARE_VOLUME2_PROTOCOL.ReadSection() member performs "a
depth-first, left-to-right search algorithm through all sections found in
the specified file" (quoting the PI spec), as follows:
FvReadFileSection() [FwVol/FwVolRead.c]
GetSection() [SectionExtraction/CoreSectionExtraction.c]
FindChildNode() [SectionExtraction/CoreSectionExtraction.c]
FindChildNode() // recursive call
FindChildNode() is called recursively for encapsulation sections.
Currently this recursion is not limited. Introduce a new PCD
(fixed-at-build, or patchable-in-module), and make FindChildNode() track
the section nesting depth against that PCD.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1743
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119105340.16225-3-lersek@redhat.com>
FindChildNode() has two callers: GetSection(), and FindChildNode() itself.
- At the GetSection() call site, a positive (i.e., nonzero)
SectionInstance is passed. This is because GetSection() takes a
zero-based (UINTN) SectionInstance, and then passes
Instance=(SectionInstance+1) to FindChildNode().
- For reaching the recursive FindChildNode() call site, a section type
mismatch, or a section instance mismatch, is necessary. This means,
respectively, that SectionInstance will either not have been decreased,
or not to zero anyway, at the recursive FindChildNode() call site.
Add two ASSERT()s to FindChildNode(), for expressing the (SectionSize>0)
invariant.
In turn, the invariant provides the explanation why, after the recursive
call, a zero SectionInstance implies success. Capture it in a comment.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119105340.16225-2-lersek@redhat.com>
When trying to get page table base, if mInternalCr3 is zero, it will use
the page table from CR3, and reflect the page table depth by CR4 LA57 bit.
If mInternalCr3 is non zero, it will use the page table from mInternalCr3
and reflect the page table depth of mInternalCr3 at same time.
In the case of X64, we use m5LevelPagingNeeded to reflect the depth of
the page table. And in the case of IA32, it will not the page table depth
information.
This patch is a bug fix when enable CET feature with 5 level paging.
The SMM page tables are allocated / initialized in PiCpuSmmEntry().
When CET is enabled, PiCpuSmmEntry() must further modify the attribute of
shadow stack pages. This page table is not set to CR3 in PiCpuSmmEntry().
So the page table base address is set to mInternalCr3 for modifty the
page table attribute. It could not use CR4 LA57 bit to reflect the
page table depth for mInternalCr3.
So we create a architecture-specific implementation GetPageTable() with
2 output parameters. One parameter is used to output the page table
address. Another parameter is used to reflect if it is 5 level paging
or not.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3015
Signed-off-by: Sheng Wei <w.sheng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
1. Add the NetworkBuildOptions.dsc.inc to define
the MACRO for build (support: GCC, INTEL, MSFT and
RVCT)
2. Add the BuildOption file to Network.dsc.inc
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20201112055558.2348-5-zhichao.gao@intel.com>
[lersek@redhat.com: clean up comments in "NetworkBuildOptions.dsc.inc"]
[lersek@redhat.com: hoist "BuildOptions" above "Components" in
"Network.dsc.inc" for bug compat with edk2-platforms]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3074
* Fix offset of LinkLayerControlAndStatus in the
CXL_1_1_LINK_CAPABILITY_STRUCTURE structure
* Fix offset of LinkLayerAckTimerControl in the
CXL_1_1_LINK_CAPABILITY_STRUCTURE structure
* Fix offset of LinkLayerDefeature in
the CXL_1_1_LINK_CAPABILITY_STRUCTURE structure
* Add CXL_11_SIZE_ASSERT() macro to verify the size of
a register layout structure at compile time and use
it to verify the sizes of the CXL 1.1 register structures.
* Add CXL_11_OFFSET_ASSERT() macro to verify the offset of
fields in a register layout structure at compiler time and
use it to verify the offset of fields in CXL 1.1
register structures.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Ashraf Javeed <ashraf.javeed@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Ashraf Javeed <ashraf.javeed@intel.com>
Current FSP rebasing script SplitFspBin.py has support for both
PE32 and PE32+ image formats. However, while updating the ImageBase
field in the image header, it always assumed the ImageBase field is
32bit long. Since PE32+ image format defined ImageBase as 64bit,
the current script will only update the lower 32bit value and leave
the upper 32bit untouched. It does not work well for PE32+ image
that requires update in the upper 32bit ImageBase field. The
expected behavior is to update the full 64bit field. This patch
implemented this fix.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2946
This is the regression issue in BaseTools BrotliCompress after Brotli
is changed to submodule. BrotliCompress should store the source size
and scratch buffer size into the header of the compressed binary data.
But now, BrotliCompress doesn't store them. So, BrotliDecompress
can't work.
To fix this issue, BrotliCompress tool main() function should be provided.
It needs to support the options of -e, -d, -o file, -g gap, -q level.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Yunhua Feng <fengyunhua@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The Raspberry Pi platform with Secure Boot enabled currently fails to build
with error:
Module type [DXE_RUNTIME_DRIVER] is not supported by library instance
[/home/appveyor/projects/rpi4/edk2/MdePkg/Library/DxeRngLib/DxeRngLib.inf]
Add the missing class to fix this issue.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
- Include Redfish.dsc.inc in RedfishPkg.dsc. which
consolidates the necessary components in Redfish.dsc.inc.
- Remove unnecessary library instances from RedfishPkg.dsc.
- Add build option in RedfishPkg.yaml.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
This simplify ATA driver debugging all ATA packets will be printed to
debug port on DEBUG_VERBOSE level along with the packet execution
status. Additionally failed packets and the failed packet execution
status will be printed on DEBUG_ERROR level.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3026
This commit adds code to restart the ATA packets that failed due to the
CRC error or other link condition. For sync transfers the code will try
to get the command working for up to 5 times. For async transfers, the
command will be retried until the timeout value timeout specified by the
requester is reached. For sync case the count of 5 retries has been
chosen arbitrarily and if needed can be increased or decreased.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3024
AHCI driver used to poll D2H register type to determine whether the FIS
has been received. This caused a problem of long timeouts when the link
got a CRC error and the FIS never arrives. To fix this this change
switches AHCI driver to poll the IS register which will signal both the
reception of FIS and the occurrence of error.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit()
directly to perform the flash write when running as an SEV-ES guest. If an
interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the
interrupt handler will generate a #VC, which can overwrite information in
the GHCB that QemuFlashPtrWrite() has set. This has been seen with the
timer interrupt firing and the CpuExceptionHandlerLib library code,
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/
Xcode5ExceptionHandlerAsm.nasm and
ExceptionHandlerAsm.nasm
reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In
general, it is necessary to protect the GHCB whenever it is used, not just
in QemuFlashPtrWrite().
Disable interrupts around the usage of the GHCB by modifying the VmgInit()
and VmgDone() interfaces:
- VmgInit() will take an extra parameter that is a pointer to a BOOLEAN
that will hold the interrupt state at the time of invocation. VmgInit()
will get and save this interrupt state before updating the GHCB.
- VmgDone() will take an extra parameter that is used to indicate whether
interrupts are to be (re)enabled. Before exiting, VmgDone() will enable
interrupts if that is requested.
Fixes: 437eb3f7a8
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
In upcoming patches, the setting of the bits in the GHCB ValidBitmap will
be performed in multiple places. In order to reduce code duplication, add
an interface, VmgSetOffsetValid(), to VmgExitLib library to perform this
function. Also, to keep management of the ValidBitmap within the library,
add an inteface, VmgIsOffsetValid(), to return whether the bit in the
ValidBitmap is set for a specified offset.
The new VmgSetOffsetValid() function is a VOID function and will be an
empty function in the VmgExitLibNull implementation of the VmgExitLib
library.
The new VmgIsOffsetValid() function returns a BOOLEAN to indicate if the
offset is valid. This will always return FALSE in the VmgExitLibNull
implementation of the VmgExitLib library.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Acked-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0bcb2373f8c6e0171ae277d3d7c2eb284621355e.1604685192.git.thomas.lendacky@amd.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2528
Currently, CL command contains multiple C files will be compiled,
and that caused command line too long, which may trigger build error.
In order to solve this issue, the following rules is used in this scene:
If the number of C files is greater than one, a txt file will be used
to record these C files, and replaces the corresponding content in
command line with the file name.
Else (only one C file listed in the command line), the length of the
whole CL command line will determine whether use a file to record. If
the length exceeds the limited max length, use the recording file; else
C file name directly listed in the command line
Signed-off-by: Mingyue Liang <mingyuex.liang@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Commit 6ad819c introduced two new functions in FmpDeviceLib:
1. FmpDeviceCheckImageWithStatus ()
2. FmpDeviceSetImageWithStatus ()
These functions allow an FmpDeviceLib implementation to return a
Last Attempt Status code value within the Device Library range from
LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_MIN_ERROR_CODE_VALUE to
LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_MAX_ERROR_CODE_VALUE.
To maintain backward compatibility, commit 6ad819c did not update
the FmpDxe driver to invoke these functions. FmpDeviceLib instances
should update their FmpDeviceCheckImage () function to simply call
FmpDeviceCheckImageWithStatus (). Similarly, FmpDeviceSetImage ()
should simply call FmpDeviceSetImageWithStatus (). This is
demonstrated in the implementation of these functions in
FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c. By doing so,
the library can remain compatible with FmpDxe implementations before
and after this transition.
This commit updates FmpDxe to call the WithStatus () version of
these functions enabling the Last Attempt Status code returned to
be accessible to FmpDxe.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
CoreInitializeMemoryServices() logs "BaseAddress" and "Length" with
DEBUG() before DxeMain() calls ProcessLibraryConstructorList()
explicitly. (Library construction is not an automatic part of the DXE
Core entry point.)
So those DEBUG()s in CoreInitializeMemoryServices() are issued against
an un-constructed DebugLib, and also against a -- possibly underlying --
un-constructed SerialPortLib.
Some DebugLib instances can deal with this (see for example commit
91a5b13650, "OvmfPkg/PlatformDebugLibIoPort: fix port detection for
use in the DXE Core", 2018-08-06), while some others can't (see for
example the DebugLib instance
"MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf"
coupled with the SerialPortLib instance
"ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf").
Addressing this issue in a SerialPortLib instance that underlies
BaseDebugLibSerialPort seems wrong; either the DebugLib instance should
cope directly with being called un-constructed (see again commit
91a5b13650), or the DXE Core should log relevant information *at
least* after library instances have been constructed. This patch
implements the latter (only for the "BaseAddress" and "Length" values
calculated by CoreInitializeMemoryServices()).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201103161557.30621-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
On windows system, when use command chcp displays the number of the
active console code page, if the active console code is 936, run
make cleanall in the BaseTools will hang.
Issue reproduce step:
chcp 936
edksetup.bat VS2015
cd BaseTools
nmake cleanall
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Yunhua Feng <fengyunhua@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
CoreInitializeMemoryServices was not checking for any existing memory
allocation created in the HOB producer phase. If there are memory
allocations outside of the region covered by the HOB List then Gcd could
select that region for memory which can result in the memory allocation
to not be handled and memory overwrites.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
When generating compressed section, the build tool rely on the
build intermediate files, which were generated in last build, to
get the file list. This method will cause the incremental build to
generate incorrect build result. To reproduce this incremental build
error, you can do:
1. build Ovmf
2. change the module OvmfPkg\AcpiTables a source file Facp.aslc
name from Facp.aslc to Facpxxx.aslc.
3. change the Facp.aslc file name in [sources] section of AcpiTables.inf
4. incremental build Ovmf
you will see the in AcpiTables module Makefile, the corresponding
Facp.acpi file is not changed.
This patch is to make the build always get file list from the INF.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The Generic ACPI for Arm Components 1.0 Platform Design
Document, s2.6.4 "ASL code examples" provides information
to describe an Arm CoreLink CMN-600 Coherent Mesh Network
using an ASL definition block table.
The SSDT CMN-600 Table Generator uses the Configuration
Manager protocol to obtain the following information about
the CMN-600 device on the platform:
- the PERIPHBASE address location and address range;
- the ROOTNODEBASE address location;
- the number of Debug and Trace Controller (DTC)
and their respective interrupt number;
The CMN-600 mesh is described using the CM_ARM_CMN_600_INFO
and CM_ARM_EXTENDED_INTERRUPT structures in the Configuration
Manager.
The SSDT CMN-600 Table generator:
- gets the CMN-600 hardware information
from the configuration manager.
- uses the AmlLib interfaces to parse the AML
template BLOB and construct an AML tree.
- uses the AmlLib to update:
- the "_UID" value;
- the address location and range of the PERIPHBASE;
- the address location of the ROOTNODEBASE;
- the number of Debug and Trace Controller (DTC)
and their respective interrupt number;
- serializes the AML tree to an output buffer.
This output buffer contains the fixed-up AML code,
which is then installed as an ACPI SSDT table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Co-authored-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
With some super-speed USB mass storage devices it has been observed
that a USB transaction error may occur when attempting the set the
device address during enumeration.
According the the xHCI specification (section 4.6.5) ...
"A USB Transaction ErrorCompletion Code for an Address Device Command
may be due to a Stall response from a device. Software should issue a
Disable Slot Commandfor the Device Slot then an Enable Slot Command
to recover from this error."
To fix this, retry the device slot initialization if it fails due to a
device error.
Change was verified using a superspeed mass storage device that was
occasionally failing to enumerate in UEFI. With this change this failure
to enumerate was resolved. This failure was also only seen in UEFI and not
in the OS.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Use a pool allocation for the RSDP ACPI root pointer structure if no
memory limit is in effect that forces us to use page based allocation,
which may be wasteful if they get rounded up to 64 KB as is the case
on AArch64.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
If no memory allocation limit is in effect for ACPI tables, prefer
pool allocations over page allocations, to avoid wasting memory on
systems where page based allocations are rounded up to 64 KB, such
as AArch64.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
On AArch64 systems, page based allocations for memory types that are
relevant to the OS are rounded up to 64 KB multiples. This wastes
some space in the ACPI table memory allocator, since it uses page
based allocations in order to be able to place the ACPI tables low
in memory.
Since the latter requirement does not exist on AArch64, switch to pool
allocations for all ACPI tables except the root tables if the active
allocation policy permits them to be anywhere in memory. The root
tables will be handled in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The ProcessorCharacteristics is a UINT16 field, so the
PROCESSOR_CHARACTERISTIC_FLAGS bitfield should be UINT16 too.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
SMBIOS 3.4.0 defines bit 9 of the Type 4 table Processor Characteristics
field to be the ARM64 SoC ID support. Add it to the
PROCESSOR_CHARACTERISTIC_FLAGS struct bitfield.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
SMBIOS 3.4.0 defines bit 9 of the Type 4 table Processor Characteristics
field to be the ARM64 SoC ID support. Add support for it to the
smbiosview command.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Fix a couple of typos in SmbiosViewStrings.uni:
"Boot form CD" should be "Boot from CD", and "plugged from the wall"
should be "plugged into the wall".
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3028
The FirmwareVolume2Protocol->GetNextFile() produced by DXE Core can be used
to search for a file based on the value of *FileType input. However, this
service will always return EFI_NOT_FOUND if the input FileType is set to
EFI_FV_FILETYPE_MM_STANDALONE or EFI_FV_FILETYPE_MM_CORE_STANDALONE, Which
means user can't use this service to search any standalone MM image in that
FV.
This patch update the FirmwareVolume2Protocol->GetNextFile() service to
support searching standalone MM module.
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
CheckTheImage() is currently used to provide the CheckImage()
implementation for the EFI_FIRMWARE_MANAGEMENT_PROTOCOL instance
produced by FmpDxe in addition to being called internally in the
SetImage() path.
Since CheckTheImage() plays a major role in determining the
validity of a given firmware image, an internal version of the
function is introduced - CheckTheImageInternal() that is capable
of returning a Last Attempt Status code to internal callers such
as SetTheImage().
The CheckImage() API as defined in the UEFI Specification for
EFI_FIRMWARE_MANAGEMENT_PROTOCOL is not impacted by this change.
CheckTheImageInternal() contains unique Last Attempt Status codes
during error paths in the function so it is easier to identify
the issue with a particular image through the Last Attempt Status
code value.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Introduces a public and a private header file to define more
granular usage of the UEFI Specification defined unsuccessful
vendor range for Last Attempt Status codes. The unsuccessful
vendor range is described in UEFI Specification 2.8A section 23.4.
The public header file Include/LastAttemptStatus.h defines ranges
within the unsuccessful vendor range. At a high-level, the two
main ranges are defined are the FMP Reserved range and the Device
Library Reserved range.
The FMP Reserved range is reserved for usage of components within
FmpDevicePkg. PrivateInclude/FmpLastAttemptStatus.h contains
usage details and specific Last Attempt Status code definitions.
The Device Library Reserved range is reserved for usage by
FmpDeviceLib instances. Each library may define custom Last
Attempt Status codes within the bounds defined in
Include/LastAttemptStatus.h:
[LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_MIN_ERROR_CODE_VALUE,
LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_MAX_ERROR_CODE_VALUE]
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3007
Currently UsbDevContext is not cleaned up if USB slot initialization is
failed, the wrong context data will affect next USB devices and
the USB devices can not be enumerated.
Need to disable slot if USB slot initialization is failed.
Below test cases are passed on UpXtreme:
a. USB 3.0 thumb drives can be recognized in UEFI shell
b. SUT can boot to Puppylinux from USB3.0 mass storage,
the storage can be recognized in linux
c. Plug in a USB keyboard (hot plug) and enumeration is OK
in UEFI shell and linux
d. Plug in a USB mouse(hot plug) and enumeration is OK in linux.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Heng Luo <heng.luo@intel.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The function ArmReplaceLiveTranslationEntry () is passed as a VOID
pointer to WriteBackDataCacheRange (). This produces the following
warning on VS2019:
warning C4152: nonstandard extension, function/data pointer
conversion in expression
This change explicitly casts the argument to the formal parameter
type VOID*.
This can be reproduced with the following build command:
build -b DEBUG -a AARCH64 -t VS2019 -p ArmPkg/ArmPkg.dsc
-m ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2835
There's several occurrences of a UINT64 or an EFI_PHYSICAL_ADDRESS
being assigned to a UINT32 value in ArmMmuLib. These result in
warning C4244 in VS2019:
warning C4244: '=': conversion from 'UINT64' to 'UINT32', possible
loss of data
warning C4244: '=': conversion from 'EFI_PHYSICAL_ADDRESS' to
'UINT32', possible loss of data
This change explicitly casts the values to UINT32.
These can be reproduced with the following build command:
build -b DEBUG -a ARM -t VS2019 -p ArmPkg/ArmPkg.dsc
-m ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Addresses BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2380 where
explicit casts are required for 64 to 32 bit assignment.
We can apply a straight cast for Time->Nanosecond since we already checked
for overflow.
On the other hand, we may have a frequency that is greater than UINT32_MAX
for Capabilities->Resolution. But using the frequency for the resolution
is the wrong approach anyway, since we can't actually vouch for the actual
resolution of the virtual library. Instead, play it safe by defaulting to
1 Hz, which is what a standard PC-AT CMOS RTC device would use.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Fix the following ECC reported errors in SsdtSerialPortFixupLib.
- [9002] The function headers should follow Doxygen special
documentation blocks in section 2.3.5 in Comment,
<@param [in]> does NOT have [in, out]
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Change the AML_DEBUG_STR() macro to AML_OPCODE_DEF() that takes a string
and the AML OpCode as input so that the text description and the AML
OpCode are grouped. The AML_OPCODE_DEF() macro also strips the string
description for release builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Fix ECC error 8001 reported errors in AmlDbgPrint.
[8001] Only capital letters are allowed to be used
for #define declarations.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Fix the following ECC reported errors in AmlLib.
- [1008] File has invalid Non-ACSII char.
- [9002] The function headers should follow Doxygen special
documentation blocks in section 2.3.5 Comment does NOT
have tail **/
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Fix the following ECC reported error in AcpiSratLibArm.
- [9002] The function headers should follow Doxygen special
documentation blocks in section 2.3.5 Comment does NOT
have tail **/
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Fix the following ECC reported error in SsdtSerialPortLibArm.
- [5007] There should be no initialization of a variable as part of
its declaration Variable Name.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reordered the asserts to first check if the pointer is valid
before de-referencing the pointer.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
AuthenticodeVerify() calls OpenSSLs d2i_PKCS7() API to parse asn encoded
signed authenticode pkcs#7 data. when this successfully returns, a type
check is done by calling PKCS7_type_is_signed() and then
Pkcs7->d.sign->contents->type is used. It is possible to construct an asn1
blob that successfully decodes and have d2i_PKCS7() return a valid pointer
and have PKCS7_type_is_signed() also return success but have Pkcs7->d.sign
be a NULL pointer.
Looking at how PKCS7_verify() [inside of OpenSSL] implements checking for
pkcs7 structs it does the following:
- call PKCS7_type_is_signed()
- call PKCS7_get_detached()
Looking into how PKCS7_get_detatched() is implemented, it checks to see if
p7->d.sign is NULL or if p7->d.sign->contents->d.ptr is NULL.
As such, the fix is to do the same as OpenSSL after calling d2i_PKCS7().
- Add call to PKS7_get_detached() to existing error handling
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
This reverts commit e0eacd7daa.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3012
The patch to fix LBA size would cause a regression that make the
partition of CD image with media type other than NO_EMULATOR unobserved.
The patch used to fix the CD image's MBR table issue. The CD MBR
table would always be ignored because it would be handled by the
Eltorito partition handler first and never go into the MBR handler.
So directly revert it.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Tested-by: Gary Lin <glin@suse.com>
The AP reset vector stack allocation is only required if running as an
SEV-ES guest. Since the reset vector allocation is below 1MB in memory,
eliminate the requirement for bare-metal systems and non SEV-ES guests
to allocate the extra stack area, which can be large if the
PcdCpuMaxLogicalProcessorNumber value is large, and also remove the
CPU_STACK_ALIGNMENT alignment.
Fixes: 7b7508ad78 ("UefiCpuPkg: Allow AP booting under SEV-ES")
Cc: Garrett Kirkendall <garrett.kirkendall@amd.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <21345cdbc906519558202b3851257ca07b9239ba.1600884239.git.thomas.lendacky@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: supply missing space character after "PcdGet32"]
This adds a new INF for BaseCryptLib suitable for
host based environments. It adds a host based unit test for
BaseCryptLib that can also be built as a shell based Unit Test.
In addition, this also adds a UnitTestHostCrtWrapper.c file, which provides
some of the functionality not provided by the default host based unit test
system that OpenSSL expects. This is used by UnitTestHostBaseCryptLib, a
version of the BaseCryptLib meant specifically for host based unit testing.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Kvmtool is a virtual machine manager that can be used
to launch guest partitions. It additionally emulates
some hardware components e.g. RTC, CFI etc. essentially
providing a virtual platform for a guest operating
system (OS) to run.
A standards-based OS would need UEFI firmware support
for the Kvmtool virtual platform, for which additional
modules are added to ArmVirtPkg.
Adding myself as reviewer for these modules as
advised on mailing list discussion at
- https://edk2.groups.io/g/devel/topic/30915279#30693
- https://edk2.groups.io/g/devel/topic/74200911#59650
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
The EDKII Core CI reports spelling error for XIPFLAGS. The
XIPFLAGS are typically used to specify XIP options to the
compiler. e.g. GCC:*_*_*_CC_XIPFLAGS = -fno-jump-tables
Add 'XIPFLAGS' to "words" section in cspell.base.yaml file
to avoid spelling check error.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool is a virtual machine manager that can be used
to launch guest VMs. Support for Kvmtool virtual
platform has been added to ArmVirtPkg.
Add kvmtool to the ArmVirtPkg dictionary to prevent
the CI Spell check plugin from failing.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool emulates a MC146818 RTC controller in the
MMIO space. To support this the MC146818 RTC driver
PcatRealTimeClockRuntimeDxe has been updated to
support MMIO accesses. PCDs for RTC Index and
Target register base addresses in the MMIO space
have been introduced. The KvmtoolRtcFdtClientLib
reads the MC146818 RTC MMIO base address region
from the Kvmtool device tree and updates the
Index and Target register PCDs.
As these PCDs are defined in PcAtChipsetPkg.dec,
this patch updates the CI script to add this
dependency.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool is a virtual machine manager that enables hosting
KVM guests. Kvmtool emulates certain devices like serial
port, RTC, etc. essentially providing a virtual platform.
This patch adds support for kvmtool virtual platform.
Following is a brief description of the firmware
implementation choices:
- Serial Port: 16550 UART
On some platforms the 16550 UART is interfaced using
PCI. Therefore, the 16550 Serial port library is
dependent on the PCI library. The 16550 UART driver
checks the Device ID represented using the PCD
gEfiMdeModulePkgTokenSpaceGuid.PcdSerialPciDeviceInfo
to determine if the UART is behind PCI.
If the Device ID is 0xFF then the serial 16550 UART
is not behind PCI.
On Kvmtool the Serial 16550 UART is not behind PCI,
and therefore a combination of BasePciLibPciExpress
and BasePciExpressLib is used to satisfy the PCI
library dependency.
The PcdSerialPciDeviceInfo is also set to 0xFF to
indicate that the Serial 16550 UART is not behind
PCI. The PCD PcdSerialUseMmio is also set to TRUE
to indicate MMIO accesses are required for the
UART registers.
Additionally two instances of PlatformHookLibs are
provided EarlyFdt16550SerialPortHookLib and
Fdt16550SerialPortHookLib to patch the
PcdSerialRegisterBase so that BaseSerialPortLib16550
and retrieve the base address of the 16550 UART.
- Dependency order for Flash
FaultTolerantWriteDxe makes use of PCDs (e.g.
PcdFlashNvStorageFtwSpareBase64 etc.), which in
case of kvmtool will be evaluated based on the CFI
flash base address read from the DT. These variables
are populated in the NorFlashPlatformLib loaded by
ArmVeNorFlashDxe.
This results in a dependency issue with
FaultTolerantWriteDxe. To resolve this make the
NorFlashPlatformLib as a library dependency for
FaultTolerantWriteDxe.
- RTC Controller
A separate patch updates the MC146818 RTC controller
driver to support MMIO accesses.
A KvmtoolRtcFdtClientLib has been introduced to
extract the base addresses of the RTC controller
from the platform device tree and map the RTC
register space as Runtime Memory.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The PlatformPeim() in the PlatformPeiLib is invoked
by the PrePiMain() and provides the platform an
opportunity to setup the plaform specific HOBs.
This PlatfromPeiLib initialises the Kvmtool platform
HOBs like the Fdt, 16550BaseAddress, etc.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The BaseSerialPort16550 library invokes the
PlatformHookSerialPortInitialize() implemented as
part of the PlatformHook library, to perform platform
specific initialization required to enable use of the
16550 device. The BaseSerialPort16550 library uses
the PcdSerialRegisterBase to obtain the base address
of the UART for MMIO operations.
Some VMMs like Kvmtool provide the base address of
the console serial port in the platform device tree.
This patch introduces two instances of the Platform
Hook library:
1. EarlyFdt16550SerialPortHookLib - parses the
platform device tree to extract the base
address of the 16550 UART and update the PCD
PcdSerialRegisterBase.
2. Fdt16550SerialPortHookLib - reads the GUID
Hob gEarly16550UartBaseAddressGuid (that caches
the base address of the 16550 UART discovered
during early stages) and updates the PCD
PcdSerialRegisterBase.
Note:
a. The PCD PcdSerialRegisterBase is configured
as PatchableInModule.
b. A separate patch introduces a PlatformPeiLib
that trampolines the 16550 UART base address
from the Pcd PcdSerialRegisterBase to the
GUID Hob gEarly16550UartBaseAddressGuid.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Introduce a new GUID Hob gEarly16550UartBaseAddressGuid
to cache the base address of the 16550 UART, for when
PCD access is not available.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The BaseSerialPortLib16550 library does not implement
a constructor. This prevents the correct constructor
invocation order for dependent libraries.
e.g. A PlatformHookLib (for the Serial Port) may have
a dependency on retrieving data from a Hob. A Hob
library implementation may configure its initial state
in the HobLib constructor. Since BaseSerialPortLib16550
does not implement a constructor, the Basetools do not
resolve the correct order for constructor invocation.
To fix this, add an empty constructor to the serial port
library BaseSerialPortLib16550.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool places the base address of the CFI flash in
the device tree it passes to UEFI. This library
parses the kvmtool device tree to read the CFI base
address and initialise the PCDs use by the NOR flash
driver and the variable storage.
UEFI takes ownership of the CFI flash hardware, and
exposes its functionality through the UEFI Runtime
Variable Service. Therefore, disable the device tree
node for the CFI flash used for storing the UEFI
variables, to prevent the OS from attaching its device
driver as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Kvmtool is a virtual machine manager that enables
hosting KVM guests. Kvmtool allows to vary the
hardware configuration of the virtual platform
it provides to the guest partition. It provides
the current hardware configuration to the firmware
by handing off a device tree containing the hardware
information.
This library parses the kvmtool provided device
tree and populates the system memory map for the
kvmtool virtual platform.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool is a virtual machine manager that enables
hosting KVM guests. It essentially provides a
virtual hardware platform for guest operating
systems.
Kvmtool hands of a device tree containing the
current hardware configuration to the firmware.
A standards-based operating system would use
ACPI to consume the platform hardware
information, while some operating systems may
prefer to use Device Tree.
The KvmtoolPlatformDxe performs the platform
actions like determining if the firmware should
expose ACPI or the Device Tree based hardware
description to the operating system.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Some virtual machine managers like kvmtool can relocate
the devices in the system memory map. The information
about the devices location in memory is described in the
device tree. Therefore, the CFI memory region and the
associated Non volatile storage variables need to be
adjusted accordingly.
To support such use cases the non-volatile storage
variable base PCD PcdFlashNvStorageVariableBase has
been defined as a dynamic PCD.
The NOR flash driver was using the Flash non-volatile
storage variable base PCD as a fixed PCD, thereby
preventing runtime resolution of the variable base
address.
Therefore update the NOR flash driver to load the
PCD using PcdGet32 instead of FixedPcdGet32.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Add library that parses the Kvmtool device tree and updates
the dynamic PCDs describing the RTC Memory map.
It also maps the MMIO region used by the RTC as runtime memory
so that the RTC registers are accessible post ExitBootServices.
Since UEFI takes ownership of the RTC hardware disable the RTC
node in the DT to prevent the OS from attaching its device
driver as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Some virtual machine managers like Kvmtool emulate the MC146818
RTC controller in the MMIO space so that architectures that do
not support I/O Mapped I/O can use the RTC. This patch adds MMIO
support to the RTC controller driver.
The PCD PcdRtcUseMmio has been added to select I/O or MMIO support.
If PcdRtcUseMmio is:
TRUE - Indicates the RTC port registers are in MMIO space.
FALSE - Indicates the RTC port registers are in I/O space.
Default is I/O space.
Additionally two new PCDs PcdRtcIndexRegister64 and
PcdRtcTargetRegister64 have been introduced to provide the base
address for the RTC registers in the MMIO space.
When MMIO support is selected (PcdRtcUseMmio == TRUE) the driver
converts the pointers to the RTC MMIO registers so that the
RTC registers are accessible post ExitBootServices.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The current SSE2 implementation of the ZeroMem(), SetMem(),
SetMem16(), SetMem32 and SetMem64 functions is writing 16 bytes per 16
bytes. It hurts the performances so bad that this is even slower than
a simple 'rep stos' (4% slower) in regular DRAM.
To take full advantages of the 'movntdq' instruction it is better to
"queue" a total of 64 bytes in the write combining buffers. This
patch implement such a change. Below is a table where I measured
(with 'rdtsc') the time to write an entire 100MB RAM buffer. These
functions operate almost two times faster.
| Function | Arch | Untouched | 64 bytes | Result |
|----------+------+-----------+----------+--------|
| ZeroMem | Ia32 | 17765947 | 9136062 | 1.945x |
| ZeroMem | X64 | 17525170 | 9233391 | 1.898x |
| SetMem | Ia32 | 17522291 | 9137272 | 1.918x |
| SetMem | X64 | 17949261 | 9176978 | 1.956x |
| SetMem16 | Ia32 | 18219673 | 9372062 | 1.944x |
| SetMem16 | X64 | 17523331 | 9275184 | 1.889x |
| SetMem32 | Ia32 | 18495036 | 9273053 | 1.994x |
| SetMem32 | X64 | 17368864 | 9285885 | 1.870x |
| SetMem64 | Ia32 | 18564473 | 9241362 | 2.009x |
| SetMem64 | X64 | 17506951 | 9280148 | 1.886x |
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Correct the memory offsets used in REG_ONE/REG_PAIR macros to
synchronize them with definition of the BASE_LIBRARY_JUMP_BUFFER
structure on AArch64.
The REG_ONE macro declares only a single 64-bit register be
read/written; however, the subsequent offset is 16 bytes larger,
creating an unused memory gap in the middle of the structure and
causing SetJump/LongJump functions to read/write 8 bytes of memory
past the end of the jump buffer struct.
Signed-off-by: Jan Bobek <jbobek@nvidia.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
Update function behavior to not modify the incoming string that is
marked as CONST in the prototype.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2881
Currently, the build tool try to read the section alignment
from efi file if the section alignment type is Auto.
If there is no efi generated, the section alignment will
be set to zero. This behavior causes the Makefile to be different
between the full build and the incremental build.
Since the Genffs can auto get the section alignment from
efi file during Genffs procedure, the build tool can just set section
alignment as zero. This change can make the autogen makefile
consistent for the full build and the incremental build.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2978
If a module add a new PCD, the pcd token number will be
reassigned. The new Pcd token number should be updated
to all module's autogen files. CanSkip can only detect a
single module's change but not others. CanSkip block the
pcd token number update in incremental build, so this
patch is going to remove this call.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2880
Currently, When doing the Incremental build, the directory
macros extended to absolute path in output Makefile, which
is inconsistent with the output of Clean build.
When we do macro replacement, we can't replace macro due to
inconsistent path case, which results in inconsistent display
of incremental build and clean build in makefile.Therefore,
the path is converted to achieve the correct macro replacement.
Signed-off-by: Mingyue Liang <mingyuex.liang@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2947
When calculating memory regions and store the information in the
gSystemMemory in file WinHost.c, the code below will cause overflow,
because _wtoi (MemorySizeStr) return an int value and SIZE_1MB is
also an int value, if MemorySizeStr is lager for example 2048, then
result of multiplication will overflow.
for (Index = 0, Done = FALSE; !Done; Index++) {
//
// Save the size of the memory and make a Unicode filename SystemMemory00
//
gSystemMemory[Index].Size = _wtoi (MemorySizeStr) * SIZE_1MB;
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU
commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the
host-side TLS cipher suite configuration to OVMF. The purpose is to
control the permitted ciphers in the guest's UEFI HTTPS boot. This
complements the forwarding of the host-side crypto policy from the host to
the guest -- the other facet was the set of CA certificates (for which
p11-kit patches had been upstreamed, on the host side).
Mention the new command line options in "OvmfPkg/README".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200922091827.12617-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
... for git-shortlog purposes.
NOTE: this patch does not introduce a cross-domain mapping; it only maps
both email addresses of Rebecca to the full name "Rebecca Cran".
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Rebecca Cran <rebecca@bsdio.com>
... for git-shortlog purposes.
NOTE: this patch does not introduce a cross-domain mapping; it only maps
the name "gaoliming" in Liming's new email address to "Liming Gao" (see
the Author field on commit aad9cba85f).
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* Recently, OpensslLib [LibraryClasses] has been changed
to include RngLib which causes the SECURE_BOOT_ENABLE
build to fail in want of RngLib
* This patch adds the RngLib for OpensslLib
Signed-off-by: Divneil Rai Wadhawan <divneil.r.wadhawan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
SECURE_BOOT_ENABLE feature flag is introduced to enable Secure Boot.
The following gets enabled with this patch:
* Secure Boot Menu in "Device Manager" for enrolling keys
* Storage space for Authenticated Variables
* Authenticated execution of 3rd party images
Signed-off-by: Divneil Rai Wadhawan <divneil.r.wadhawan@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add check for NULL HostAddress in AllocateBuffer as required by UEFI
specification.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
There is a DEBUG warning printout in VirtioMmioDeviceLib if the current
device's VendorID does not match the traditional 16-bit Red Hat PCIe
vendor ID used with virtio-pci. The virtio-mmio vendor ID is 32-bit and
has no connection to the PCIe registry.
Most specifically, this causes a bunch of noise when booting an AArch64
QEMU platform, since QEMU's virtio-mmio implementation used 'QEMU' as
the vendor ID:
VirtioMmioInit: Warning:
The VendorId (0x554D4551) does not match the VirtIo VendorId (0x1AF4).
Drop the warning message.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The BaseSerialPortLib16550 does fallback to a fixed address UART defined
by PcdSerialRegisterBase and does not initialize if it is zero. Do not
assume a serial port at 0x3F8, otherwise it could cause errors during
initialization of a non-existent serial port on non legacy platforms.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Marcello Sylvester Bauer <marcello.bauer@9elements.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
If VPD PcdNvStoreDefaultValueBuffer is used, all DynamicHii and
DynamicExHii PCD value will be generated into that VPD.
In order to generate the same VPD binary file in every build,
sort the Pcd set when generating VPD.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The following two quantities:
SecDataDir->VirtualAddress + SecDataDir->Size
SecDataDir->VirtualAddress + SecDataDir->Size - OffSet
are used multiple times in DxeImageVerificationHandler(). Introduce helper
variables for them: "SecDataDirEnd" and "SecDataDirLeft", respectively.
This saves us multiple calculations and significantly simplifies the code.
Note that all three summands above have type UINT32, therefore the new
variables are also of type UINT32.
This patch does not change behavior.
(Note that the code already handles the case when the
SecDataDir->VirtualAddress + SecDataDir->Size
UINT32 addition overflows -- namely, in that case, the certificate loop is
never entered, and the corruption check right after the loop fires.)
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Wenyi Xie <xiewenyi2@huawei.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200901091221.20948-2-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Min M Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for a malicious
guest OS, the issue is not exploitable -- the symptom is a hang on the
BSP, in the above-noted loop in SmbaseRelocate(). Instead, the patch fixes
behavior for a benign guest OS.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 51a6fb4118
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200826222129.25798-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just before* ACPI raises the broadcast SMI,
then:
- OVMF processes the hot-added CPU well.
- However, QEMU's post-SMI ACPI loop -- which clears the pending events
for the hot-added CPUs that were collected before raising the SMI -- is
unaware of the stray CPU. Thus, the pending event is not cleared for it.
As a result of the stuck event, at the next hot-plug, OVMF tries to re-add
(relocate for the 2nd time) the already-known CPU. At that time, the AP is
already in the normal edk2 SMM busy-wait however, so it doesn't respond to
the exchange that the BSP intends to do in SmbaseRelocate(). Thus the VM
gets stuck in SMM.
(Because of the above symptom, this is not considered a security patch; it
doesn't seem exploitable by a malicious guest OS.)
In CpuHotplugMmi(), skip the supposedly hot-added CPU if it's already
known. The post-SMI ACPI loop will clear the pending event for it this
time.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: bc498ac4ca
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200826222129.25798-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
For the implementation which utilizes libfdt provided in EmbeddedPkg
however it uses strncmp function in the libfdt helper library,
libfdt_env.h should provide the macro implied with edk2 strncmp
implementation.
The example is RISC-V OpenSBI library. edk2 RISC-V port uses OpenSBI
library and incorporate with edk2 libfdt. edk2 libfdt_env.h provides
the necessary macros to build OpenSBI which uses fdt functions in edk2
environment. However, OpenSBI also has libfdt helper library that uses
strncmp function which is not defined in edk2 libfdt_env.h. This commit
addresses the build issue caused by missing strncmp macro in
libfdt_env.h.
Check below three commits for the corresponding changes on OpenSBI,
8e47649eff2845d2d2cf2cfd2fc904
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Message-Id: <20200806023421.25161-1-abner.chang@hpe.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
[lersek@redhat.com: remove stray newline between S-o-b and first Cc]
The ICH9_LPC_SMI_F_BROADCAST and ICH9_LPC_SMI_F_CPU_HOTPLUG feature flags
cause QEMU to behave as follows:
BROADCAST CPU_HOTPLUG use case / behavior
--------- ----------- ------------------------------------------------
clear clear OVMF built without SMM_REQUIRE; or very old OVMF
(from before commit a316d7ac91 / 2017-02-07).
QEMU permits CPU hotplug operations, and does
not cause the OS to inject an SMI upon hotplug.
Firmware is not expected to be aware of hotplug
events.
clear set Invalid feature set; QEMU rejects the feature
negotiation.
set clear OVMF after a316d7ac91 / 2017-02-07, built with
SMM_REQUIRE, but no support for CPU hotplug.
QEMU gracefully refuses hotplug operations.
set set OVMF after a316d7ac91 / 2017-02-07, built with
SMM_REQUIRE, and supporting CPU hotplug. QEMU
permits CPU hotplug operations, and causes the
OS to inject an SMI upon hotplug. Firmware is
expected to deal with hotplug events.
Negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG -- but only if SEV is disabled, as
OvmfPkg/CpuHotplugSmm can't deal with SEV yet.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200714184305.9814-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
If the size of the supplied buffer in FileHandleReadLine(), module
UefiFileHandleLib.c, was not 0, but was not enough to fit in
the line, the size is increased, and then the Buffer of the new
size is zeroed. This size is always larger than the supplied buffer size,
causing supplied buffer overrun. Fix the issue by using the
supplied buffer size in ZeroMem().
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Message-Id: <20200702023113.10517-1-vladimir.olovyannikov@broadcom.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
[lersek@redhat.com: remove stray space character from subject line]
Add configuration ExceptionList and IgnoreFiles for package config
files. So users can rely on this to ignore some Ecc issues.
Besides, add submodule path in IgnoreFiles section.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Before UEFI transfers control to the OS, it must park the AP. This is
done using the AsmRelocateApLoop function to transition into 32-bit
non-paging mode. For an SEV-ES guest, a few additional things must be
done:
- AsmRelocateApLoop must be updated to support SEV-ES. This means
performing a VMGEXIT AP Reset Hold instead of an MWAIT or HLT loop.
- Since the AP must transition to real mode, a small routine is copied
to the WakeupBuffer area. Since the WakeupBuffer will be used by
the AP during OS booting, it must be placed in reserved memory.
Additionally, the AP stack must be located where it can be accessed
in real mode.
- Once the AP is in real mode it will transfer control to the
destination specified by the OS in the SEV-ES AP Jump Table. The
SEV-ES AP Jump Table address is saved by the hypervisor for the OS
using the GHCB VMGEXIT AP Jump Table exit code.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
After having transitioned from UEFI to the OS, the OS will need to boot
the APs. For an SEV-ES guest, the APs will have been parked by UEFI using
GHCB pages allocated by UEFI. The hypervisor will write to the GHCB
SW_EXITINFO2 field of the GHCB when the AP is booted. As a result, the
GHCB pages must be marked reserved so that the OS does not attempt to use
them and experience memory corruption because of the hypervisor write.
Change the GHCB allocation from the default boot services memory to
reserved memory.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A hypervisor is not allowed to update an SEV-ES guest's register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead an SEV-ES AP must be
re-directed from within the guest to the actual requested staring location
as specified in the INIT-SIPI-SIPI sequence.
Use the SEV-ES work area for the reset vector code that contains support
to jump to the desired RIP location after having been started. This is
required for only the very first AP reset.
This new OVMF source file, ResetVectorVtf0.asm, is used in place of the
original file through the use of the include path order set in
OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Typically, an AP is booted using the INIT-SIPI-SIPI sequence. This
sequence is intercepted by the hypervisor, which sets the AP's registers
to the values requested by the sequence. At that point, the hypervisor can
start the AP, which will then begin execution at the appropriate location.
Under SEV-ES, AP booting presents some challenges since the hypervisor is
not allowed to alter the AP's register state. In this situation, we have
to distinguish between the AP's first boot and AP's subsequent boots.
First boot:
Once the AP's register state has been defined (which is before the guest
is first booted) it cannot be altered. Should the hypervisor attempt to
alter the register state, the change would be detected by the hardware
and the VMRUN instruction would fail. Given this, the first boot for the
AP is required to begin execution with this initial register state, which
is typically the reset vector. This prevents the BSP from directing the
AP startup location through the INIT-SIPI-SIPI sequence.
To work around this, the firmware will provide a build time reserved area
that can be used as the initial IP value. The hypervisor can extract this
location value by checking for the SEV-ES reset block GUID that must be
located 48-bytes from the end of the firmware. The format of the SEV-ES
reset block area is:
0x00 - 0x01 - SEV-ES Reset IP
0x02 - 0x03 - SEV-ES Reset CS Segment Base[31:16]
0x04 - 0x05 - Size of the SEV-ES reset block
0x06 - 0x15 - SEV-ES Reset Block GUID
(00f771de-1a7e-4fcb-890e-68c77e2fb44e)
The total size is 22 bytes. Any expansion to this block must be done
by adding new values before existing values.
The hypervisor will use the IP and CS values obtained from the SEV-ES
reset block to set as the AP's initial values. The CS Segment Base
represents the upper 16 bits of the CS segment base and must be left
shifted by 16 bits to form the complete CS segment base value.
Before booting the AP for the first time, the BSP must initialize the
SEV-ES reset area. This consists of programming a FAR JMP instruction
to the contents of a memory location that is also located in the SEV-ES
reset area. The BSP must program the IP and CS values for the FAR JMP
based on values drived from the INIT-SIPI-SIPI sequence.
Subsequent boots:
Again, the hypervisor cannot alter the AP register state, so a method is
required to take the AP out of halt state and redirect it to the desired
IP location. If it is determined that the AP is running in an SEV-ES
guest, then instead of calling CpuSleep(), a VMGEXIT is issued with the
AP Reset Hold exit code (0x80000004). The hypervisor will put the AP in
a halt state, waiting for an INIT-SIPI-SIPI sequence. Once the sequence
is recognized, the hypervisor will resume the AP. At this point the AP
must transition from the current 64-bit long mode down to 16-bit real
mode and begin executing at the derived location from the INIT-SIPI-SIPI
sequence.
Another change is around the area of obtaining the (x2)APIC ID during AP
startup. During AP startup, the AP can't take a #VC exception before the
AP has established a stack. However, the AP stack is set by using the
(x2)APIC ID, which is obtained through CPUID instructions. A CPUID
instruction will cause a #VC, so a different method must be used. The
GHCB protocol supports a method to obtain CPUID information from the
hypervisor through the GHCB MSR. This method does not require a stack,
so it is used to obtain the necessary CPUID information to determine the
(x2)APIC ID.
The new 16-bit protected mode GDT entry is used in order to transition
from 64-bit long mode down to 16-bit real mode.
A new assembler routine is created that takes the AP from 64-bit long mode
to 16-bit real mode. This is located under 1MB in memory and transitions
from 64-bit long mode to 32-bit compatibility mode to 16-bit protected
mode and finally 16-bit real mode.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
When starting APs in an SMP configuration, the AP needs to know if it is
running as an SEV-ES guest in order to assign a GHCB page.
Add a field to the CPU_MP_DATA structure that will indicate if SEV-ES is
enabled. This new field is set during MP library initialization with the
PCD value PcdSevEsIsEnabled. This flag can then be used to determine if
SEV-ES is enabled.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A hypervisor is not allowed to update an SEV-ES guests register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead, an SEV-ES AP must be
transition from 64-bit long mode to 16-bit real mode in response to an
INIT-SIPI-SIPI sequence. This requires a 16-bit code segment descriptor.
For PEI, create this descriptor in the reset vector GDT table. For DXE,
create this descriptor from the newly reserved entry at location 0x28.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The flash detection routine will attempt to determine how the flash
device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
the flash device behaves as a ROM device (meaning it is marked read-only
by the hypervisor), this check may result in an infinite nested page fault
because of the attempted write. Since the instruction cannot be emulated
when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
nested page faults.
When SEV-ES is enabled, exit the flash detection early and assume that
the FD behaves as Flash. This will result in QemuFlashWrite() being called
to store EFI variables, which will also result in an infinite nested page
fault when the write is performed. In this case, update QemuFlashWrite()
to use the VMGEXIT MMIO write support to have the hypervisor perform the
write without having to emulate the instruction.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
An SEV-ES guest will generate a #VC exception when it encounters a
non-automatic exit (NAE) event. It is expected that the #VC exception
handler will communicate with the hypervisor using the GHCB to handle
the NAE event.
NAE events can occur during the Sec phase, so initialize exception
handling early in the OVMF Sec support.
Before establishing the exception handling, validate that the supported
version of the SEV-ES protocol in OVMF is supported by the hypervisor.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
During BSP startup, the reset vector code will issue a CPUID instruction
while in 32-bit mode. When running as an SEV-ES guest, this will trigger
a #VC exception.
Add exception handling support to the early reset vector code to catch
these exceptions. Also, since the guest is in 32-bit mode at this point,
writes to the GHCB will be encrypted and thus not able to be read by the
hypervisor, so use the GHCB CPUID request/response protocol to obtain the
requested CPUID function values and provide these to the guest.
The exception handling support is active during the SEV check and uses the
OVMF temporary RAM space for a stack. After the SEV check is complete, the
exception handling support is removed and the stack pointer cleared.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Protect the SEV-ES work area memory used by an SEV-ES guest.
Regarding the lifecycle of the SEV-ES memory area:
PcdSevEsWorkArea
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the SEV-ES area is initialized during
the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].
(b) how it is protected from memory allocations during DXE
If SEV-ES is enabled, then InitializeRamRegions()
[OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with either
an AcpiNVS (S3 enabled) or BootServicesData (S3 disabled) memory
allocation HOB, in PEI.
(c) how it is protected from the OS
If S3 is enabled, then (b) reserves it from the OS too.
If S3 is disabled, then the range needs no protection.
(d) how it is accessed on the S3 resume path
It is rewritten same as in (a), which is fine because (b) reserved it.
(e) how it is accessed on the warm reset path
It is rewritten same as in (a).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.
This area will be used by SEV-ES support for two purposes:
1. Communicating the SEV-ES status during BSP boot to SEC:
Using a byte of memory from the page, the BSP reset vector code can
communicate the SEV-ES status to SEC for use before exception
handling can be enabled in SEC. After SEC, this field is no longer
valid and the standard way of determine if SEV-ES is active should
be used.
2. Establishing an area of memory for AP boot support:
A hypervisor is not allowed to update an SEV-ES guest's register
state, so when booting an SEV-ES guest AP, the hypervisor is not
allowed to set the RIP to the guest requested value. Instead an
SEV-ES AP must be re-directed from within the guest to the actual
requested staring location as specified in the INIT-SIPI-SIPI
sequence.
Use this memory for reset vector code that can be programmed to have
the AP jump to the desired RIP location after starting the AP. This
is required for only the very first AP reset.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The SEV support will clear the C-bit from non-RAM areas. The early GDT
lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
will be read as un-encrypted even though it is encrypted. This will result
in a failure to be able to handle the exception.
Move the GDT into RAM so it can be accessed without error when running as
an SEV-ES guest.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Allocate memory for the GHCB pages and the per-CPU variable pages during
SEV initialization for use during Pei and Dxe phases. The GHCB page(s)
must be shared pages, so clear the encryption mask from the current page
table entries. Upon successful allocation, set the GHCB PCDs (PcdGhcbBase
and PcdGhcbSize).
The per-CPU variable page needs to be unique per AP. Using the page after
the GHCB ensures that it is unique per AP. Only the GHCB page is marked as
shared, keeping the per-CPU variable page encyrpted. The same logic is
used in DXE using CreateIdentityMappingPageTables() before switching to
the DXE pagetables.
The GHCB pages (one per vCPU) will be used by the PEI and DXE #VC
exception handlers. The #VC exception handler will fill in the necessary
fields of the GHCB and exit to the hypervisor using the VMGEXIT
instruction. The hypervisor then accesses the GHCB associated with the
vCPU in order to perform the requested function.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Protect the memory used by an SEV-ES guest when S3 is supported. This
includes the page table used to break down the 2MB page that contains
the GHCB so that it can be marked un-encrypted, as well as the GHCB
area.
Regarding the lifecycle of the GHCB-related memory areas:
PcdOvmfSecGhcbPageTableBase
PcdOvmfSecGhcbBase
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the GHCB-related areas are initialized during
the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].
(b) how it is protected from memory allocations during DXE
If S3 and SEV-ES are enabled, then InitializeRamRegions()
[OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
memory allocation HOB, in PEI.
If S3 is disabled, then these ranges are not protected. DXE's own page
tables are first built while still in PEI (see HandOffToDxeCore()
[MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are
located in permanent PEI memory. After CR3 is switched over to them
(which occurs before jumping to the DXE core entry point), we don't have
to preserve PcdOvmfSecGhcbPageTableBase. PEI switches to GHCB pages in
permanent PEI memory and DXE will use these PEI GHCB pages, so we don't
have to preserve PcdOvmfSecGhcbBase.
(c) how it is protected from the OS
If S3 is enabled, then (b) reserves it from the OS too.
If S3 is disabled, then the range needs no protection.
(d) how it is accessed on the S3 resume path
It is rewritten same as in (a), which is fine because (b) reserved it.
(e) how it is accessed on the warm reset path
It is rewritten same as in (a).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since the GHCB must be marked as an un-encrypted,
or shared, page, an additional pagetable page is required to break down
the 2MB region where the GHCB page lives into 4K pagetable entries.
Create a new entry in the OVMF memory layout for the new page table
page and for the SEC GHCB and per-CPU variable pages. After breaking down
the 2MB page, update the GHCB page table entry to remove the encryption
mask.
The GHCB page will be used by the SEC #VC exception handler. The #VC
exception handler will fill in the necessary fields of the GHCB and exit
to the hypervisor using the VMGEXIT instruction. The hypervisor then
accesses the GHCB in order to perform the requested function.
Four new fixed PCDs are needed to support the SEC GHCB page:
- PcdOvmfSecGhcbBase UINT32 value that is the base address of the
GHCB used during the SEC phase.
- PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the
GHCB area used during the SEC phase.
- PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page
table page used to break down the 2MB page into
512 4K pages.
- PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes,
of the page table page.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
The #VC handler must provide special support to the guest for this. On
a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
to notify the hypervisor of the write. However, the #VC handler must
not actually set the value of the DR7 register. On a DR7 read, the #VC
handler must return the cached value of the DR7 register to the guest.
VMGEXIT is not invoked for a DR7 register read.
The caching of the DR7 values will make use of the per-CPU data pages
that are allocated along with the GHCB pages. The per-CPU page for a
vCPU is the page that immediately follows the vCPU's GHCB page. Since
each GHCB page is unique for a vCPU, the page that follows becomes
unique for that vCPU. The SEC phase will reserves an area of memory for
a single GHCB and per-CPU page for use by the BSP. After transitioning
to the PEI phase, new GHCB and per-CPU pages are allocated for the BSP
and all APs.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a NPF intercept for an NPT entry with a reserved bit set
generates a #VC exception. This condition is assumed to be an MMIO access.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a NPF NAE
event for MMIO. Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXIT_INFO1, SW_EXITINFO2 and SW_SCRATCH values in the GHCB.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MSR_PROT intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support an MSR_PROT
NAE event. Parse the instruction that generated the #VC exception to
determine whether it is RDMSR or WRMSR, setting the required register
register values in the GHCB and creating the proper SW_EXIT_INFO1 value in
the GHCB.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a CPUID intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a CPUID NAE
event. Additionally, CPUID 0x0000_000d (CPUID_EXTENDED_STATE) requires
XCR0 to be supplied in the GHCB, so add support to issue the XGETBV
instruction.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Add support to the #VC exception handler to handle string IO. This
requires expanding the IO instruction parsing to recognize string based
IO instructions as well as preparing an un-encrypted buffer to be used
to transfer (either to or from the guest) the string contents for the IO
operation. The SW_EXITINFO2 and SW_SCRATCH fields of the GHCB are set
appropriately for the operation. Multiple VMGEXIT invocations may be
needed to complete the string IO operation.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a IOIO_PROT intercept generates a #VC exception. VMGEXIT
must be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a IOIO_PROT
NAE event. Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXITINFO1 value in the GHCB.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
The base VmgExitLib library provides a default limited interface. As it
does not provide full support, create an OVMF version of this library to
begin the process of providing full support of SEV-ES within OVMF.
SEV-ES support is only provided for X64 builds, so only OvmfPkgX64.dsc is
updated to make use of the OvmfPkg version of the library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Add base support to handle #VC exceptions. Update the common exception
handlers to invoke the VmgExitHandleVc () function of the VmgExitLib
library when a #VC is encountered. A non-zero return code will propagate
to the targeted exception handler.
Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
To avoid exception recursion, a #VC exception will not try to read and
push the actual debug registers into the EFI_SYSTEM_CONTEXT_X64 struct
and instead push zeroes. The #VC exception handler does not make use of
the debug registers from the saved context and the exception processing
exit code does not attempt to restore the debug register values.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
To support handling #VC exceptions and issuing VMGEXIT instructions,
create a library with functions that can be used to perform these
#VC/VMGEXIT related operations. This includes functions for:
- Handling #VC exceptions
- Preparing for and issuing a VMGEXIT
- Performing MMIO-related write operations to support flash emulation
- Performing AP related boot opeations
The base functions in this driver will not do anything and will return
an error if a return value is required. It is expected that other packages
(like OvmfPkg) will create a version of the library to fully support an
SEV-ES guest.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
VMGEXIT is a new instruction used for Hypervisor/Guest communication when
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE)
to occur, resulting in a #VMEXIT with an exit code value of 0x403.
Since SEV-ES is only supported in X64, provide the necessary X64 support
to execute the VMGEXIT instruction, which is coded as "rep vmmcall". For
IA32, since "vmmcall" is not supported in NASM 32-bit mode and VMGEXIT
should never be called, provide a stub implementation that is identical
to CpuBreakpoint().
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
In python3, array.array.tostring() was a compat alias for tobytes().
tostring() was removed in python 3.9.
Convert this to use tolist() which should be valid for all python
versions.
This fixes this build error on python3.9:
(Python 3.9.0b5 on linux) Traceback (most recent call last):
File "/root/edk2/edk2-edk2-stable202002/BaseTools/BinWrappers/PosixLike/../../Source/Python/Trim/Trim.py", line 593, in Main
GenerateVfrBinSec(CommandOptions.ModuleName, CommandOptions.DebugDir, CommandOptions.OutputFile)
File "/root/edk2/edk2-edk2-stable202002/BaseTools/BinWrappers/PosixLike/../../Source/Python/Trim/Trim.py", line 449, in GenerateVfrBinSec
VfrUniOffsetList = GetVariableOffset(MapFileName, EfiFileName, VfrNameList)
File "/root/edk2/edk2-edk2-stable202002/BaseTools/Source/Python/Common/Misc.py", line 88, in GetVariableOffset
return _parseForGCC(lines, efifilepath, varnames)
File "/root/edk2/edk2-edk2-stable202002/BaseTools/Source/Python/Common/Misc.py", line 151, in _parseForGCC
efisecs = PeImageClass(efifilepath).SectionHeaderList
File "/root/edk2/edk2-edk2-stable202002/BaseTools/Source/Python/Common/Misc.py", line 1638, in __init__
if ByteArray.tostring() != b'PE\0\0':
AttributeError: 'array.array' object has no attribute 'tostring'
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
python3.9 changed/fixed codec.register behavior to always replace
hyphen with underscore for passed in codec names:
https://bugs.python.org/issue37751
So the custom Ucs2Search needs to be adapted to handle 'ucs_2' in
addition to existing 'ucs-2' for back compat.
This fixes test failures on python3.9, example:
======================================================================
FAIL: testUtf16InUniFile (CheckUnicodeSourceFiles.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/builddir/build/BUILD/edk2-edk2-stable202002/BaseTools/Source/Python/AutoGen/UniClassObject.py", line 375, in PreProcess
FileIn = UniFileClassObject.OpenUniFile(LongFilePath(File.Path))
File "/builddir/build/BUILD/edk2-edk2-stable202002/BaseTools/Source/Python/AutoGen/UniClassObject.py", line 303, in OpenUniFile
UniFileClassObject.VerifyUcs2Data(FileIn, FileName, Encoding)
File "/builddir/build/BUILD/edk2-edk2-stable202002/BaseTools/Source/Python/AutoGen/UniClassObject.py", line 312, in VerifyUcs2Data
Ucs2Info = codecs.lookup('ucs-2')
LookupError: unknown encoding: ucs-2
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The SSDT Serial port fixup library provides
interfaces to generate a SSDT Serial port table
based on the serial port information.
Update the DBG2 Generator to use the SSDT serial
port fixup library to build a serial port definition
block for the DBG2 serial port and install the
SSDT table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
According to Arm Server Base Boot Requirements,
Platform Design Document version 1.2 revision D,
September 2, 2019, section '4.2.1.8 SPCR'; the
SPCR console device must be included in the DSDT.
The SSDT Serial port fixup library provides
interfaces to generate a SSDT Serial port table
based on the serial port information.
Update the SPCR Generator to use the SSDT serial
port fixup library to build a serial port definition
block corresponding to the SPCR serial port and
install the SSDT table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Most platforms have several serial ports. These serial ports
are described to an operating system using definition block
tables.
The SSDT Serial Port Table Generator uses the Configuration
Manager protocol to obtain information for the Serial Ports
on the platform. The serial ports are described using the
CM_ARM_SERIAL_PORT_INFO structure. The EArmObjSerialPortInfo
ID is used to represent a standard serial port.
The SSDT Serial port fixup library provides interfaces to
generate a SSDT Serial port table based on the serial port
information. The SSDT Serial Port Table Generator uses the
SSDT serial port fixup library to build serial port
definition blocks and installs the SSDT tables.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
According to Arm Server Base Boot Requirements,
Platform Design Document version 1.2 revision D,
September 2, 2019, section '4.2.1.8 SPCR'; The
SPCR console device must be included in the DSDT.
Additionally, it is often desirable to describe the
serial ports available on a platform so that they
are available for use by a rich OS.
To facilitate the description of serial ports on a
platform a common SSDT Serial Port Fixup library is
introduced. It provides interfaces to build a SSDT
serial port definition block table based on the
serial port information.
The SSDT Serial Port Fixup library is used by the
SPCR, DBG2 and SSDT Serial Port generator to describe
the serial port information in a definition block.
+------------+ +------------+ +------------+
| SPCR Gen | | DBG2 Gen | | SERIAL Gen |
+------------+ +------------+ +------------+
+----------------------------------+
| SSDT Serial Port Fixup library |
+----------------------------------+
The SSDT Serial Port Fixup library:
- Parses the SSDT Serial Port template using the
AmlLib library to generate an AML tree.
- Updates the _UID, _HID and _CID values.
- Fixes up the Serial port base address, length
and the interrupt number in the _CRS descriptor.
- Fixes up the serial-port name.
- Serialises the AML Tree to a buffer containing
the definition block data.
The definition block data is then installed by the
corresponding table generator.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AsciiFromHex is a function converts a hex number to an
ASCII character. This function is used across multiple
generators, so add it to the TableHelperLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
ACPI Definition blocks are implemented using AML which has
a complex grammar making run-time generation of definition
blocks difficult. Dynamic AML is a feature of Dynamic Tables
framework that provides a solution for dynamic generation of
ACPI Definition block tables.
Since, AML bytecode represents complex AML grammar, an AmlLib
library is introduced to assist parsing and traversing of the
AML bytecode at run-time.
The AmlLib library parses a definition block and represents it
as an AML tree. The AML objects, methods and data are represented
as tree nodes. Since the AML data is represented as tree nodes,
it is possible to traverse the tree, locate a node and modify the
node data. The tree can then be serialized to a buffer (that
represents the definition block). This definition block containing
the fixed-up AML code can then be installed as an ACPI Definition
Block table.
Dynamic AML introduces the following techniques:
* AML Fixup
* AML Codegen
* AML Fixup + Codegen
AML Fixup is a technique that involves compiling an ASL template
file to generate AML bytecode. This template AML bytecode can be
parsed at run-time and a fixup code can update the required fields
in the AML template.
AML Codegen employs generating small segments of AML code.
AmlLib provides a rich set of APIs to operate on AML data for AML
Fixup and Codegen.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AmlLib library implements an AML parser, AML tree interface,
serialiser, code generator and other interfaces to generate
Definition Block tables.
The AmlLib APIs are a collection of interfaces that enable
parsing, iterating, modifying, adding, and serialising AML
data to generate a Definition Block table.
The AmlLib APIs are declared in Include\AmlLib\AmlLib.h
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Core interface APIs are internal APIs of the
AmlLib library. These APIs can be used to:
- Create/Delete/Clone an AML tree/node
- Get/update Fixed and Variable arguments
- Serialize an AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Codegen is a Dynamic AML technique that facilitates
generation of small segments of AML code. The AML code
generated using AML Codegen is represented as nodes in
the AML Tree.
AML Resource Data Codegen implements interfaces required
for generating Resource Data elements that can be attached
to an AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Codegen is a Dynamic AML technique that facilitates
generation of small segments of AML code. The AML code
generated using AML Codegen is represented as nodes in
the AML Tree.
Some examples where AML Codegen can be used are:
- AML Codegen APIs can be used to generate a simple
AML tree.
- An AML template can be parsed to create an AML
tree. This AML Tree can be searched to locate a
node that needs updating. The AML Codegen APIs
can be used to attach new AML nodes.
- A combination of AML Fixup and AML Codegen can
be used to generate an AML tree.
The AML tree can then be serialised as a Definition
Block table.
Following AML Codegen APIs are implemented:
- AmlCodeGenDefinitionBlock()
- AmlCodeGenScope()
- AmlCodeGenNameString()
- AmlCodeGenNameInteger()
- AmlCodeGenDevice()
These AML Codegen APIs in combination with AML Resource
Data Codegen APIs can be used to generate a simple AML
tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML language allows defining field lists in a Definition
Block. Although Dynamic AML does not provide interfaces to
modify Field Lists; an AML template code may contain Field
lists and the AML parser must be capable of parsing and
representing the Field lists in the AML tree.
The AML parser creates an Object node that represents the
'Field Node'. The AML Field list parser creates an object
node for each field element parsed in the AML byte stream,
and adds them to the variable list of arguments of the
'Field Node'.
Nodes that can have a field list are referred as 'Field
nodes'. They have the AML_HAS_FIELD_LIST attribute set in
the AML encoding.
According to the ACPI 6.3 specification, s20.2.5.2 "Named
Objects Encoding", field elements can be:
- NamedField := NameSeg PkgLength;
- ReservedField := 0x00 PkgLength;
- AccessField := 0x01 AccessType AccessAttrib;
- ConnectField := <0x02 NameString> | <0x02 BufferData>;
- ExtendedAccessField := 0x03 AccessType ExtendedAccessAttrib
AccessLength.
A small set of opcodes describes the field elements. They are
referred as field opcodes. An AML_BYTE_ENCODING table has been
created for field OpCodes.
Field elements:
- don't have a SubOpCode;
- have at most 3 fixed arguments (as opposed to 6 for standard
AML objects);
- don't have a variable list of arguments;
- only the NamedField field element is part of the AML namespace.
ConnectField's BufferData is a buffer node containing a single
resource data element.
NamedField field elements do not have an AML OpCode. NameSeg
starts with a Char type and can thus be differentiated from the
Opcodes for other fields.
A pseudo OpCode has been created to simplify the parser.
Following is a representation of a field node in an AML tree:
(FieldNode)
\
|- [0][1][3] # Fixed Arguments
|- {(FldEl0)->(FldEl1)->...)} # Variable Arguments
Where FldEl[n] is one of NamedField, ReservedField, AccessField,
ConnectField, ExtendedAccessField.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML language allows a Definition Block to implement
methods that an Operating System can invoke at runtime.
Although Dynamic AML does not provide interfaces to
modify AML methods; an AML template code may contain
methods and/or method invocations.
Method definitions have an opcode defined in the AML
encoding and can be easily parsed. However, the language
does not define an opcode for method invocation. Method
invocations are represented as a NameString followed by
the arguments to the method. This poses a significant
challenge for the AML parser as it has to determine if
a NameString appearing in the AML byte stream is a method
invocation and if it is a method invocation, then how
many arguments follow.
This also means the Method definition must occur prior to
the method invocation in the AML byte stream. This is a
hard requirement for the AML parser.
The AML method parser maintains a NameSpaceRefList that
keeps a track of every namespace node and its raw AML
absolute path. The AmlIsMethodInvocation() searches the
NameSpaceRefList to determine if a NameString matches
a Method definition.
A pseudo opcode has been defined in the AML encoding to
represent the Method invocation in the AML tree.
The AML encoding for method invocations in the ACPI
specification 6.3 is:
MethodInvocation := NameString TermArgList
The AmlLib library redefines this as:
MethodInvocation := MethodInvocationOp NameString
ArgumentCount TermArgList
ArgumentCount := ByteData
Where MethodInvocationOp is the pseudo opcode and
ArgumentCount is the number of arguments passed to
the method.
NOTE:
The AmlLib library's definition for a method
invocation only applies to the representation
of method invocation node in the AML tree.
When computing the size of a tree or serialising
it, the additional data is not taken into account
i.e. the MethodInvocationOp and the ArgumentCount
are stripped before serialising.
Method invocation nodes have the AML_METHOD_INVOVATION
attribute set in the AmlLib library's representation of
the AML encoding.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Resource data are defined in the ACPI 6.3 specification,
s6.4 "Resource Data Types for ACPI". They can be created
using the ASL ResourceTemplate () statement, cf s19.3.3
"ASL Resource Templates".
Resource data can be of the small or large type and are
defined by their encoding. The resource data is stored
in the Bytelist of a BufferOp node. The Bytelist of a
BufferOp node is represented by an AML Data node in
the AML tree.
The resource data parser, examines the Bytelist (Data
node buffer) to detect the presence of resource data.
If the Bytelist data matches the encoding for resource
data types, the resource data parser fragments the
Bytelist containing the resource data buffer into
resource data elements represented as individual Data
nodes and stores them in the variable arguments list
of the BufferOp object nodes.
Example: ASL code and the corresponding AML tree
representation for the resource data.
ASL Code
--------
Name (_CRS, ResourceTemplate() {
QWordMemory (...)
Interrupt (...)
}
AML Tree
--------
(NameOp)
\
|-[_CRS]-[BufferOp] # Fixed Arguments
|-{NULL} \ # Variable Argument
\ list
|-[BuffSize] # Fixed Arguments
|-{(Rd1)->(Rd2)->(EndTag)} # Variable Argument
list
Where:
Rd1 - QWordMemory resource data element.
Rd2 - Interrupt resource data element.
EndTag - Resource data end tag.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Resource data are defined in the ACPI 6.3 specification,
s6.4 "Resource Data Types for ACPI". They can be created
using the ASL ResourceTemplate () statement, cf s19.3.3
"ASL Resource Templates".
Resource data can be of the small or large type and are
defined by their encoding. The resource data is stored
in the Bytelist of a BufferOp node. To simplify
operations on resource data, the resource data parser
examines the Bytelist to detect the presence of resource
data. If the data matches the encoding of resource
data type(s), the parser fragments the resource data
buffer into resource data elements (data nodes) and
stores them in the variable arguments list of the
BufferOp node.
The resource data helper provides functions and macros
to assist operations on resource data elements.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Both ASL and AML are declarative language. The ASL code
is compiled to AML bytecode. The AML bytecode is processed
by the ACPI AML interpreter that runs as part of an OS.
AML has a complex encoding making dynamic generation of
Definition Block tables difficult.
Dynamic AML generation involves techniques like AML Fixup
and AML Codegen, both requiring parsing of AML bytecode.
The AML parser is a module that parses an AML byte stream
and represents it as an AML tree. Representing the AML
bytecode as an AML tree is key to reducing the complexity
and enabling Dynamic AML generation.
In an AML Tree each AML statement (that also corresponds
to an ASL statement) is represented as an 'Object Node'.
Each Object Node has an OpCode and up to 6 Fixed Arguments
followed by a list of Variable Arguments.
(ObjectNode)
\
|- [0][1][2][3][4][5] # Fixed Arguments
|- {(VarArg1)->(VarArg2)->...N} # Variable Arguments
A Fixed Argument or Variable Argument can be either an
Object Node or a Data Node.
A 'Data Node' consists of a data buffer.
A 'Root Node' is a special type of Object Node that does
not have an Opcode or Fixed Arguments. It only has a list
of Variable Arguments. The Root Node is at the top of the
AML tree and contains the Definition Block Header.
The AML parser uses the 'AML Encoding' to parse an AML byte
stream and represents it as an AML Tree. Representing in the
form of an AML tree simplifies modification, addition and
removal of the tree nodes. The modified tree can then be
serialised to a buffer representing a Definition Block table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML is a declarative language that is processed by the
ACPI AML interpreter. The ACPI AML interpreter will
compile the set of declarations into the ACPI Namespace
at definition block load time.
The hardware information described in AML is effectively
mapped in the ACPI Namespace. The AML ACPI namespace
interface implement the functionality to search the ACPI
Namespace. Example: The AmlFindNode() can be used to locate
a device node in the ACPI namespace using an ASL path as
the search input.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML debug print functions enable logging
of the operations on the AML tree and the data
output. The debug logging functionality is
enabled for debug builds when the DEBUG_INFO
or DEBUG_VERBOSE mask is enabled in the PCD
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Fixup and AML Codegen facilitate dynamic generation
of Definition Block tables. The AML byte stream that is
generated is represented in an AML tree. Once the AML
table generation is completed, the AML tree needs to be
serialised for installing as an ACPI table.
The AML serialise interface implements the functionality
to iterate the nodes in the AML tree, collating the AML
bytecode, computing the checksum and writing the AML byte
stream to a buffer that represents the Definition Block
table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Co-authored-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Dynamic AML involves parsing/packing of AML opcode and
data into AML byte streams. The AML stream interface
provides safe buffer management as well as supports
forward and reverse streams. It provides functions to
create, read, write, clone and compare AML streams.
Co-authored-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Dynamic AML requires encoding/decoding and conversion of
AML and ASL strings. A collection of helper functions
have been provided for internal use in the AmlLib Library.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML utility interfaces are a collection of helper functions
that assist in computing the checksum, size and to propagate the
node information as a result of addition or update of AML nodes.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
It is often desirable to clone an AML branch/tree
or an AML node. An example of could be to clone
an AML template before fixup so that the original
AML template remains unmodified. Another example
would be replicating a device branch in the AML
tree and fixing up the device information.
To facilitate such scenarios the AmlLib library
provides functions that can be used to clone an
AML branch/tree or an AML node.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree iterator provides interfaces to traverse the nodes
in the AML tree. The iterator can traverse the AML tree nodes in
the following order:
- Linear progression: Iterate following the AML byte stream
order (depth first).
- Branch progression: Iterate following the AML byte stream
order (depth first), but stop iterating
at the end of the branch.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree traversal provides interfaces to traverse the
nodes in the AML tree.
It provides interfaces to traverse the AML tree in the
following order:
- Traverse sibling nodes.
(Node) /-i # Child of fixed argument b
\ /
|- [a][b][c][d] # Fixed Arguments
|- {(e)->(f)->(g)} # Variable Arguments
\
\-h # Child of variable argument e
Traversal Order:
- AmlGetNextSibling() : a, b, c, d, e, f, g, NULL
- AmlGetPreviousSibling(): g, f, e, d, c, b, a, NULL
- Iterate depth-first path (follow AML byte stream).
(Node) /-i # Child of fixed argument b
\ /
|- [a][b][c][d] # Fixed Arguments
|- {(e)->(f)->(g)} # Variable Arguments
\
\-h # Child of variable argument e
Traversal Order:
- AmlGetNextNode(): a, b, i, c, d, e, h, f, g, NULL
- AmlGetPreviousNode() g, f, h, e, d, c, i, b, a, NULL
Note: The branch i and h will be traversed if it has
any children.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree enumerator interface allows enumeration of the
nodes in the AML tree. The enumerator interface can be useful
to search, serialise, print etc. the nodes in the AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree is composite and has the following node types:
- Root node.
- Object node.
- Data node.
These nodes are part of the Fixed Arguments or the Variable
arguments list in the AML tree.
The AML tree interface provides functions to manage the fixed
and the variable argument nodes in the AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML has a complex grammar, and this makes runtime modifications
on an AML byte stream difficult. A solution is to parse the AML
bytecode and represent it in a tree data structure, henceforth
called the AML tree.
The AML tree is composite in the sense it has the following node
types:
- A 'Root node' that represents the root of the AML tree.
- An 'Object node' that contains the OP Code (AML Encoding).
- A 'Data node' that contains a data buffer.
The Root node contains the Definition block header (ACPI header)
and a Variable Argument list.
The Object node is composed of an array of Fixed Arguments and
a Variable Argument list.
Fixed arguments can be either Object Nodes or Data nodes. Their
placement (index) in the Fixed Argument array is defined by the
AML encoding of the enclosing Object Node.
Variable arguments can be Object nodes or Data nodes.
Following is a depiction of a typical AML tree:
(/) # Root Node
\
|-{(N1)->...} # Variable Argument list, N1 is
\ # an Object Node
\ /-i # Child of fixed argument b
\ /
|- [a][b][c][d] # Fixed Arguments
|- {(e)->(f)->(g)} # Variable Arguments
\
\-h # Child of variable argument e
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
ASL is a source language for defining ACPI objects including
writing ACPI control methods. An ASL file is compiled using
an ASL compiler tool to generate ACPI Machine Language (AML).
This AML bytecode is processed by the ACPI AML interpreter
that runs as part of an Operating System (OS).
Both ASL and AML are declarative languages. Although they
are closely related they are different languages.
ASL statements declare objects. Each object has three parts,
two of which can be NULL:
Object := ObjectType FixedList VariableList
The AML grammar defines corresponding encodings that makes
up the AML byte stream.
This patch introduces the AML grammar definitions used by
AmlLib for encoding/decoding AML byte streams.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Dynamic AML is a solution to generate Definition Block tables
at runtime. Dynamic AML provides the following techniques for
generating AML tables.
- AML Fixup
- AML Codegen
- AML Fixup + Codegen
AML fixup involves patching small sections of a template AML
code at runtime, while AML Codegen provides APIs to generate
small sections of AML code at runtime. A combination of
Fixup and Codegen can also be used.
AML has a complex grammar. To simplify the generation of
AML tables, Dynamic AML introduces AmlLib that provides a
rich set of APIs for parsing, traversing, fixup, codegen
and serialisation of AML byte code.
This patch introduces the definitions used by AmlLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
ACPI Definition block (e.g. DSDT or SSDT) tables are implemented
using ACPI source language (ASL) and compiled to ACPI Machine
language (AML). The AML bytecode runs in the OS ACPI Interpreter.
AML has a complex grammar which makes generation of ACPI Definition
block tables difficult.
Dynamic Tables Framework introduces a new feature 'Dynamic AML' that
aims at simplifying the generation of ACPI Definition block tables.
Dynamic AML provides the following techniques for generating ACPI
Definition blocks.
- AML Fixup
- AML Codegen
- AML Fixup + Codegen
AML Fixup involves patching an AML template code at runtime and then
installing the fixed-up AML code as an ACPI table.
AML Codegen provides APIs to generate small segments of AML code that
can be serialised for installation as an ACPI table.
AML Fixup + Codegen is an approach where parts of an AML template are
fixed-up at runtime as well as the AML Codegen APIs are used to insert
small segments of AML code in the AML template. This AML code is then
serialised for installation as an ACPI table.
To assist Dynamic AML generation an AmlLib library is introduced that
provides a rich set of APIs that can be used to parse, traverse, fixup,
codegen and serialise AML definition blocks.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2823
Refer to UEFI spec 2.8, Section 13.3.2, a block device should
be scanned as below order:
1. GPT
2. ISO 9660 (El Torito) (UDF should aslo be here)
3. MBR
4. no partition found
Note: UDF is using the same boot method as CD, so put it in
the same priority with ISO 9660.
This would also solve the issue that ISO image with MBR would
be treat as MBR device instead of CD/DVD. That would make the
behavior of the image boot different:
If the CD/DVD's MBR be handled correctly, it would be enumerated
as a bootable device with MBR path and FAT filesystem. Some Linux
Distributions boot from such path (FAT with MBR path for ISO) would
come into the grub console instead of the installation selection.
With this change, the CD/DVD would always be enumerated with CD path.
And it would always boot to the installation selection.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Gary Lin <glin@suse.com>
Cc: Andrew Fish <afish@apple.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Gary Lin <glin@suse.com>
The unit test app supports running in 3 mode:
1. MtrrLibUnitTest generate-random-numbers
<path to MtrrLib/UnitTest/RandomNumber.c> <random-number count>
It generates random numbers and writes to RandomNumber.c.
2. MtrrLibUnitTest [<iterations>]
It tests MtrrLib APIs using configurations generated from static
numbers generated by mode #1.
This is the default execution mode running in CI environment.
3. MtrrLibUnitTest <iterations> random
It tests MtrrLib APIs using configurations generated from random
numbers.
This is what developers can use to test MtrrLib for regressions.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ming Shao <ming.shao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Add host based unit tests for the MtrrLib services.
The BaseLib services AsmCpuid(), AsmReadMsr64(), and
AsmWriteMsr64() are hooked and provide simple emulation
of the CPUID leafs and MSRs required by the MtrrLib to
run as a host based unit test.
Test cases are developed for each of the API.
For the most important APIs MtrrSetMemoryAttributesInMtrrSettings()
and MtrrSetMemoryAttributeInMtrrSettings(), random inputs are
generated and fed to the APIs to make sure the implementation is
good. The test application accepts an optional parameter which
specifies how many iterations of feeding random inputs to the two
APIs. The overall number of test cases increases when the iteration
increases. Default iteration is 10 when no parameter is specified.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Ming Shao <ming.shao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ming Shao <ming.shao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
While RISC-V hart is trapped into S-Mode, the S-Mode interrupt
CSR (SIE) is disabled by RISC-V hart. However the (SIE) is enabled
again by RestoreTPL, this causes the second S-Mode trap is triggered
by the machine mode (M-Mode)timer interrupt redirection. The SRET
instruction clear Supervisor Previous Privilege (SPP) to zero
(User mode) in the second S-Mode interrupt according to the RISC-V
spec. Above brings hart to the user mode (U-Mode) when execute
SRET in the nested S-Mode interrupt handler because SPP is set to
User Mode in the second interrupt. Afterward, system runs in U-Mode
and any accesses to S-Mode CSR causes the invalid instruction exception.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Acked-by: Liming Gao <liming.gao@intel.com>
If MDEPKG_NDEBUG is defined, then debug and assert related
macros wrapped by it are mapped to NULL implementations.
Therefore, add MDEPKG_NDEBUG flags for release builds of
DynamicTablesPkg.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The EdkII BaseTools have been updated to facilitate the
generation of C file containing AML data using the AmlToC
script. The build system follows the following sequence
for an ASL file compilation:
- The ASL file is preprocessed using the C preprocessor
- The Trim utility prunes the preprocessed file to removed
unwanted data.
- This file is compiled using an ASL compiler to generate
an AML file.
- The AmlToC python script reads the AML data and generates
a C file with an array containing the AML data.
- This C file containing a unique symbol name for the AML
data array is then compiled with the firmware module.
This removes the dependency on the ACPICA iASL compiler's
"-tc" option which achieved the same effect but was less
portable. Therefore, remove the "-tc" option from the ASL
flags as this option is only been supported by the ACPICA
iASL compiler.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The TianoCore EDKII project has introduced a Core CI infrastructure
using TianoCore EDKII Tools PIP modules:
* https://pypi.org/project/edk2-pytool-library/
* https://pypi.org/project/edk2-pytool-extensions/
The edk2\.pytool\Readme.md provides information to configure the
environment and to run local builds.
This patch defines the necessary settings for enabling the Core CI
builds for DynamicTablesPkg.
- Add DynamicTablesPkg.ci.yaml for Core CI
- Update ReadMe.md for details and instructions
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The TianoCore EDKII project has introduced a Core CI infrastructure
using TianoCore EDKII Tools PIP modules:
* https://pypi.org/project/edk2-pytool-library/
* https://pypi.org/project/edk2-pytool-extensions/
More information on configuring the environment and running the
builds can be found in edk2\.pytool\Readme.md
This patch fixes the issues reported by the CI system mainly around
fixing typo errors and package dec and dsc files. A subsequent patch
enables the CI builds for the DynamicTablesPkg.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Change how some SMBIOS TYpe 17 field values are printed:
- TotalWidth, DataWidth, ConfiguredMemoryClockSpeed: Print as
hex values instead of decimal, since there are some special meanings
for certain values (e.g. 0xFFFF)
- VolatileSize, NonVolatileSize, CacheSize, and LogicalSize: Print
as "0x%lx" instead of "0x%x" to prevent truncating output when
printing these QWORD fields.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
A user may fall through to the case they depend on the
PcdFmpDeviceImageTypeIdGuid value to get the ImageTypeId GUID
value. The default PCD value is 0 (NULL) so the code would
further fall back on the gEfiCallerIdGuid value.
This change modifies the print error level for the message that
indicates this occurred to DEBUG_WARN from DEBUG_INFO to better
warn the user that this occurred.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
Update list of content that is covered by a license other than
the BSD-2-Clause Plus Patent License and break out list of
content that is included as a git submodule from upstream
projects.
* Use alphabetic order of content
* Remove references to IntelFrameworkModulePkg
* Add reference for UnitTestFrameworkPkg use of cmocka
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
These can be used, for instance, to automate the population of an SMBIOS
Type 0 BIOS Release Date when building a UEFI firmware (which is how we
plan to use these macros for the Raspberry Pi platform).
These macros should work for any compiler that follows ISO/IEC 9899, but
we add a check for the compiler we have tested to be on the safe side.
Note that we decided against adding a #error or #warn for compilers that
haven't been validated, as we don't want to introduce breakage for people
who may already be using the header with something else than gcc, MSVC or
Clang. Instead, we expect those to send a patch that adds their compiler
to the list, once they have tested the macros there.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Sean reports that having two DEC files under OvmfPkg violates the DEC
spec:
> An EDK II Package (directory) is a directory that contains an EDK II
> package declaration (DEC) file. Only one DEC file is permitted per
> directory. EDK II Packages cannot be nested within other EDK II
> Packages.
This issue originates from commit 656419f922 ("Add BhyvePkg, to support
the bhyve hypervisor", 2020-07-31).
Remedy the problem as follows. (Note that these steps are not split to
multiple patches in order to keep Bhyve buildable across the transition.)
(1) Delete "OvmfPkg/Bhyve/BhyvePkg.dec".
(2) Point the [Packages] sections of the Bhyve-specific AcpiPlatformDxe,
BhyveRfbDxe, and BhyveFwCtlLib INF files to "OvmfPkg.dec".
(3) Migrate the artifacts that "BhyvePkg.dec" used to have on top of
"OvmfPkg.dec" as follows:
(3a) Merge the copyright notices from Rebecca Cran and Pluribus Networks
into "OvmfPkg.dec".
(3b) Merge the "BhyveFwCtlLib" class header definition into "OvmfPkg.dec".
(3c) Merge value 0x2F8 for the fixed PcdDebugIoPort into
"BhyvePkgX64.dsc".
(4) Unnest the the Include/Library/ and Library/ subtrees from under
OvmfPkg/Bhyve to the corresponding, preexistent subtrees in OvmfPkg.
The goal is to keep the [Includes] section in the "OvmfPkg.dec" file
unchanged, plus simplify references in "BhyvePkgX64.dsc". Non-library
modules remain under "OvmfPkg/Bhyve/".
(4a) The BhyveFwCtlLib class header, and sole instance, are already
uniquely named, so their movements need not involve file renames.
(4b) Rename the Bhyve-specific PlatformBootManagerLib instance to
PlatformBootManagerLibBhyve, in additon to moving it, for
distinguishing it from OvmfPkg's preexistent lib instance. Apply the
name change to all three of the lib instance directory name, the INF
file, and the BASE_NAME define in the INF file.
(4c) Update lib class resolutions in "BhyvePkgX64.dsc" accordingly.
(5) Replace the "ACPI table storage" FILE_GUID in
"OvmfPkg/Bhyve/AcpiTables/AcpiTables.inf" with a new GUID, and
open-code the "ACPI table storage" GUID in the "ACPITABLE" FDF rule
instead, replacing $(NAMED_GUID). This step is necessary because CI
requires unique FILE_GUIDs over all INF files, and OVMF's original
"AcpiTables.inf" already uses the "ACPI table storage" GUID as
FILE_GUID.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sean Brogan <spbrogan@outlook.com>
Fixes: 656419f922
Reported-by: Sean Brogan <spbrogan@outlook.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200801155024.16439-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Most busy waits (spinlocks) in "UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c"
already call CpuPause() in their loop bodies; see SmmWaitForApArrival(),
APHandler(), and SmiRendezvous(). However, the "main wait" within
APHandler():
> //
> // Wait for something to happen
> //
> WaitForSemaphore (mSmmMpSyncData->CpuData[CpuIndex].Run);
doesn't do so, as WaitForSemaphore() keeps trying to acquire the semaphore
without pausing.
The performance impact is especially notable in QEMU/KVM + OVMF
virtualization with CPU overcommit (that is, when the guest has
significantly more VCPUs than the host has physical CPUs). The guest BSP
is working heavily in:
BSPHandler() [MpService.c]
PerformRemainingTasks() [PiSmmCpuDxeSmm.c]
SetUefiMemMapAttributes() [SmmCpuMemoryManagement.c]
while the many guest APs are spinning in the "Wait for something to
happen" semaphore acquisition, in APHandler(). The guest APs are
generating useless memory traffic and saturating host CPUs, hindering the
guest BSP's progress in SetUefiMemMapAttributes().
Rework the loop in WaitForSemaphore(): call CpuPause() in every iteration
after the first check fails. Due to Pause Loop Exiting (known as Pause
Filter on AMD), the host scheduler can favor the guest BSP over the guest
APs.
Running a 16 GB RAM + 512 VCPU guest on a 448 PCPU host, this patch
reduces OVMF boot time (counted until reaching grub) from 20-30 minutes to
less than 4 minutes.
The patch should benefit physical machines as well -- according to the
Intel SDM, PAUSE "Improves the performance of spin-wait loops". Adding
PAUSE to the generic WaitForSemaphore() function is considered a general
improvement.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1861718
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200729185217.10084-1-lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Add configuration IgnoreFiles for package config files.
So users can rely on this to skip license conflict for
some generated files.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add configuration IgnoreFiles for package config files.
So users can rely on this to skip license conflict for
some generated files.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614
Introduces new changes to PeiCore to move the contents of temporary
RAM visible to the PeiCore to permanent memory. This expands on
pre-existing shadowing support in the PeiCore to perform the following
additional actions:
1. Migrate pointers in PPIs installed in PeiCore to the permanent
memory copy of PeiCore.
2. Copy all installed firmware volumes to permanent memory.
3. Relocate and fix up the PEIMs within the firmware volumes.
4. Convert all PPIs into the migrated firmware volume to the corresponding
PPI address in the permanent memory location.
This applies to PPIs and PEI notifications.
5. Convert all status code callbacks in the migrated firmware volume to
the corresponding address in the permanent memory location.
6. Update the FV HOB to the corresponding firmware volume in permanent
memory.
7. Use PcdMigrateTemporaryRamFirmwareVolumes to control if enable the
feature or not. when disable the PCD, the EvacuateTempRam() will
never be called.
The function control flow as below:
PeiCore()
DumpPpiList()
EvacuateTempRam()
ConvertPeiCorePpiPointers()
ConvertPpiPointersFv()
MigratePeimsInFv()
MigratePeim()
PeiGetPe32Data()
LoadAndRelocatePeCoffImageInPlace()
MigrateSecModulesInFv()
ConvertPpiPointersFv()
ConvertStatusCodeCallbacks()
ConvertFvHob()
RemoveFvHobsInTemporaryMemory()
DumpPpiList()
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Harry Han <harry.han@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614
The security researcher found that we can get control after NEM disable.
The reason is that the flash content reside in NEM at startup and the
code will get the content from flash directly after disable NEM.
To avoid this vulnerability, the feature will copy the PEIMs from
temporary memory to permanent memory and only execute the code in
permanent memory.
The vulnerability is exist in physical platform and haven't report in
virtual platform, so the virtual can disable the feature currently.
When enable the PcdMigrateTemporaryRamFirmwareVolumes, always shadow
all PEIMs no matter the condition of PcdShadowPeimOnBoot or
PcdShadowPeimOnS3Boot.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1004
Being a compiler builtin, the type of __builtin_return_address is
already known to the compiler so no prototype is needed. Clang also
errors out when redeclaring certain builtins like this[1], though
currently only for ones with custom type checking. At the moment,
__builtin_return_address does not use custom type checking and so does
not trigger this error, however, the CHERI fork of LLVM, which will form
the basis of the toolchain for Arm's experimental Morello platform, does
use custom type checking for it, and so gives an error. Thus, simply
delete the unnecessary line.
[1] llvm/llvm-project@41af971375
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Upgrade openssl to 1.1.1g. the directory have been reorganized,
openssl moved crypto/include/internal to include/crypto folder.
So we change directory to match the re-organization.
The dso_conf.h and opensslconf.h will generated in UNIX format,
change process_files.pl to covent the EOL automatically.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Signed-off-by: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2827
Fix a bug about parse the macro value which use another macro.
Use the following example to verify:
[Define]
DEFINE M1 = V1
DEFINE M2 = $(M1)/V2
!include $(M2)/pcd.dsc
The old code will failed parse M2 and cause following error:
Traceback (most recent call last):
File "Edk2\IntelFsp2Pkg\Tools\GenCfgOpt.py", line 1550, in <module>
sys.exit(Main())
File "Edk2\IntelFsp2Pkg\Tools\GenCfgOpt.py", line 1513, in Main
if GenCfgOpt.ParseDscFile(DscFile, FvDir) != 0:
File "Edk2\IntelFsp2Pkg\Tools\GenCfgOpt.py", line 533, in ParseDscFile
NewDscLines = IncludeDsc.readlines()
ValueError: I/O operation on closed file.
The tool should support the value use another macro, and expand it.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
The following command line:
build -b NOOPT -a IA32 -t VS2017 -p edk2\EmbeddedPkg\EmbeddedPkg.dsc
Generates the following error:
MmcDxe.lib(Diagnostics.obj) : error LNK2001:
unresolved external symbol __allshl
MmcDxe.lib(Diagnostics.obj) : error LNK2001:
unresolved external symbol __aullshr
MmcDxe.lib(MmcBlockIo.obj) : error LNK2001:
unresolved external symbol __allmul
These erros are due to the use of shift/multiply operations
on UINT64 variable on a IA32 architecture.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
UnicodeStrToAsciiStrS requires that the source string is shorter than
the destination buffer and will ASSERT if this is not true. Switch to
UnicodeStrnToAsciiStrS as there are cases where the source string is
longer than the buffer allocated for the device path.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
During build, the meta files are not changed, so it's no need
to check file timestamp.
This patch is to remove useless logic.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
ReadMe.txt contained outdated information. Update it to match current
functionality (e.g. sqlite3 is no longer used), and convert the
formatting from ad-hoc to reStructuredText.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
GCC48_ALL_CC_FLAGS has no dependency on GCC_ALL_CC_FLAGS.
By definition, there should be such dependency.
The outcomes of this patch is that GCC48_ALL_CC_FLAGS and
other dependent configurations will inherit from the
additional "-Os" flag.
The "-Os" flag optimizes a build in size, not breaking any
build. In a gcc command line, the last optimization flag
has precedence. This means that this "-Os" flag will be
overriden by a more specific optimization configuration,
provided that this more specific flag is appended at the
end of the CC_FLAGS.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com>
Reviewed-by: Bob Feng<bob.c.feng@intel.com>
By default, gcc allows void* pointer arithmetic.
This is a GCC extension.
However:
- the C reference manual states that void*
pointer "cannot be operands of addition
or subtraction operators". Cf s5.3.1
"Generic Pointers";
- Visual studio compiler treat such operation as
an error.
To prevent such pointer arithmetic, the "-Wpointer-arith"
flag should be set for all GCC versions.
The "-Wpointer-arith" allows to:
"Warn about anything that depends on the "size of"
a function type or of void. GNU C assigns these
types a size of 1, for convenience in calculations
with void * pointers and pointers to functions."
This flag is available since GCC2.95.3 which came out in 2001.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng<bob.c.feng@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2818
For better memory management, re-ordered the DestroyRamDisk and
ReportStatusCode calls inside the EfiBootManagerBoot() function.
This will help to clean the unused memory before reporting the
failure status, so that OEMs can use RSC Listener to launch
custom boot option or application for recovering the failed
hard drive.
This change will help to ensure that the allocated pool of memory
for the failed boot option is freed before executing OEM's RSC
listener callback to handle every boot option failure.
Signed-off-by: KrishnadasX Veliyathuparambil Prakashan <krishnadasx.veliyathuparambil.prakashan@intel.com>
Cc: "Gao, Zhichao" <zhichao.gao@intel.com>
Cc: "Ni, Ray" <ray.ni@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
This is the second part of LsiScsiPassThru(). LsiScsiProcessRequest() is
added to translate the SCSI Request Packet into the LSI 53C895A
commands. This function utilizes the so-called Script buffer to transmit
a series of commands to the chip and then polls the DMA Status (DSTAT)
register until the Scripts Interrupt Instruction Received (SIR) bit
sets. Once the script is done, the SCSI Request Packet will be modified
to reflect the result of the script. The Cumulative SCSI Byte Count
(CSBC) register is fetched before and after the script to calculate the
transferred bytes and update InTransferLength/OutTransferLength if
necessary.
v3:
- Set DStat, SIst0, and SIst1 to 0 before using them
- Amend the if statements for the DMA data instruction and add the
assertions for the data direction
- Also set SenseDataLength to 0 on the error path
- Fix typos and amend comments
- Amend the error handling of the calculation of transferred bytes
v2:
- Use the BITx macros for the most of LSI_* constants
- Fix a typo: contorller => controller
- Add SeaBIOS lsi-scsi driver as one of the references of the script
- Cast the result of sizeof to UINT32 for the instructions of the
script
- Drop the backslashes
- Replace LSI_SCSI_DMA_ADDR_LOW with LSI_SCSI_DMA_ADDR since we
already removed DUAL_ADDRESS_CYCLE
- Add more comments for the script
- Fix the check of the script size at the end of the script
- Always set SenseDataLength to 0 to avoid the caller to access
SenseData
- Improve the error handling in LsiScsiProcessRequest()
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200717061130.8881-11-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Open PciIo protocol and use it to initialize the device. The
initialization of LSI 53C895A is simple: just set the SRST bit in
Interrupt Status Zero register to reset the device.
v2:
- Use the BITx macros for the bit constants
- Add the closing of PciIo protocol in LsiScsiControllerStop()
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200717061130.8881-8-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Implement LsiScsiGetNextTargetLun(), LsiScsiBuildDevicePath(),
LsiScsiGetTargetLun(), and LsiScsiGetNextTarget() to report Targets and
LUNs and build the device path.
This commit also introduces two PCD value: PcdLsiScsiMaxTargetLimit and
PcdLsiScsiMaxLunLimit as the limits for Targets and LUNs.
v3:
- Update the range of LUN in the assertioin
- Squash the spurious newline into the previous commit
v2:
- Zero out (*Target) in LsiScsiGetTargetLun()
- Use CopyMem() instead of the one-byte shortcut to copy target from
ScsiDevicePath->Pun
- Add asserts for PcdLsiScsiMaxTargetLimit and PcdLsiScsiMaxLunLimit
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200717061130.8881-7-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Partially implement LsiScsiControllerStart() and LsiScsiControllerStop()
to insert the scaffolding of EXT_SCSI_PASS_THRU functions.
v3: Squash the newline below the declaration of LSI_SCSI_FROM_PASS_THRU
v2: Remove the closing of PciIo protocol from LsiScsiControllerStop().
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-6-glin@suse.com>
Original code GetFmpImageDescriptors for OriginalFmpImageInfoBuf
pointer, if failed, return a NULL pointer. The OriginalFmpImageInfoBuf
should not be NULL and the NULL pointer dereference case
should be false positive.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Vin Xue <vinxue@outlook.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Update INF file to use a [Pcd] section instead of a
[FixedPcd] section. [FixedPcd] should only be used in an
INF file if the source code looks up the PCD value using
the PcdLib FixedPcdGetxx() services. Using [FixedPcd]
forces a platform to configure the PCD to type FixedAtBuild.
In this case, PcdDebugPropertyMask supports PCD types
FixedAtBuild and PatchableInModule. Without this change
any platform that wants to use PcdDebugPropertyMask as
type PatchableInModule breaks the build.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2801
Add the UT_EXPECT_ASSERT_FAILURE(FunctionCall, Status) macro
to the UnitTestLib that can be used to check if a function
under test triggers an ASSERT() condition. If an ASSERT()
condition is triggered, then the macro returns. If the
ASSERT() condition is not triggered, then the current unit
test fails with a status of UNIT_TEST_ERROR_TEST_FAILED.
If ASSERT()s are disabled, then this check for ASSERT()
behavior is not possible, and the check is skipped.
The global variable gUnitTestExpectAssertFailureJumpBuffer
is added to the UnitTestLib to save/restore context when
the UT_EXPECT_ASSERT_FAILURE(FunctionCall, Status) macro
is used. The UT_EXPECT_ASSERT_FAILURE() macro uses the
SetJump() service with this global variable. The UnitTestLib
service UnitTestDebugAssert() uses the LongJump() service
with this global to restore context if an ASSERT() is
triggered by the code under test.
Add UnitTestExpectAssertFailure() to the UnitTestLib class.
The UnitTestExpectAssertFailure() is called from the new
UT_EXPECT_ASSERT_FAILURE() macro after the status of this
macro check is known.
Add UnitTestDebugAssert() to the UnitTestLib class. The
UnitTestDebugAssert() service is the same as the DebugLib
DebugAssert() service and is invoked from the DebugLib
_ASSERT() macro if unit testing is enabled. This allows the
Unit Test Framework to know when code under test triggers an
ASSERT() condition.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2801
Add UnitTestDebugAssertLib that provides the UnitTestDebugAssert()
service and the gUnitTestExpectAssertFailureJumpBuffer global
variable. This NULL library is linked against all host and target
unit test builds. This guarantees that the UnitTestDebugAssert()
service is available to link against all libraries and modules that
use the DebugLib class.
EDKII_UNIT_TEST_FRAMEWORK_ENABLED must always be defined when
building unit tests so the behavior of the DebugLib ASSERT()
macros can be adjusted to allow the unit test framework to
catch an ASSERT() if it is triggered by a function under test.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2805
If a unit test fails with an exception or an assert, then the
CmockaUnitTestFunctionRunner() is terminated and the logic
that follows the invocation of the unit test is skipped. This
currently skips the logic that prints log messages.
Move the print of log messages to the end of the function
CmockaUnitTestTeardownFunctionRunner() that is guaranteed to
be executed when a unit test completes normally or is
terminated with an exception or an assert.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2801
The default DebugLib for target mode was DebugLibNull. This
library instance disables all ASSERT() and DEBUG() macros
which removes the ability to write unit tests that check for
ASSERT() behaviors.
The DebugLib is changed to PeiDxeDebugLibReportStatusCode.inf
that guarantees that DEBUG() and ASSERT() macros are active. The
default ReportStatusCodeLib is set to BaseReportStatusCodeLibNull.inf
so no messages are sent to any devices preserving the DebugLibNull
behavior.
A platform specific unit test can always override these mappings
with a platform specific DebugLib.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2804
Optionally enable a feature to support source level debug of a
host based unit test. By default, this feature is disabled.
Exceptions are caught by the unit test framework and are
interpreted as a test failure.
When a unit test is under development, bugs may generate
exceptions or a unit test developer may want to trace the
execution of unit tests to debug some unexpected behavior.
Defining UNIT_TESTING_DEBUG in the DSC file or from the build
command line allows exceptions to be caught by the host OS
and allows the developer to debug their unit test under
development or debug the Unit Test Framework itself.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2800
Add a new version of BaseLib that is safe for use from host based
unit test applications. Host based unit test applications may need
to provide implementations of some BaseLib functions that provide
simple emulation to exercise the code under test. The structure
UNIT_TEST_HOST_BASE_LIB is filled in with services that provide
default emulation for BaseLib APIs that would normally generate
exceptions in a host based unit test application. This structure
allows an individual unit test to replace the default emulation of
a BaseLib service with an alternate version that is required by a
specific unit test. A global variable of type UNIT_TEST_HOST_BASE_LIB
is provided through the new UnitTestHostBaseLib library class.
Normally cmocka would be used to mock services the code under
test calls. However, the BaseLib is used by the Unit Test
Framework itself, so using a mocked interface is not possible.
The use of a structure to provide hooks for unit test is not
expected to be a common feature. It should only be required
for libraries that are used by both the Unit Test Framework and
the code under test where the code under test requires a
different behavior than the Unit Test Framework.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2823
The partition binding driver would run serval times during BDS.
If the partition support MBR, it would pass the first connection
in MBR partition child handler. The second connect for the same
device would return already started which would be treated as
not found. And it would continue to run next partition child
handler check. That is incorrect behavior to do next check if one
of the routine functions is passed. It may cause one device
installed serval partition child handle on it.
So treat the EFI_ALREADY_STARTED as EFI_SUCCESS to avoid incorrect
next partition child handle check.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2823
Refer to
http://manpages.ubuntu.com/manpages/bionic/man8/mkudffs.8.html.
Some Linux ISOs may have the MBR table for compatibility reasons
for Windows. The MBR tale would contain the partition entry with
start LBA0 and whole media size. There are two methods to check
the filesystem in the CD-ROM:
1. MBR partition check (Windows)
2. Whole disk check (MAC OS)
UEFI doesn't have the MBR check for UDF and Eltorito. But it may
pass the MBR check for such table and fail to detect the filesystem
of UDF. Skip the MBR check if the MBR is added for Windows
compatiblity so that the partition driver can continue UDF and
ElTorito check.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2823
PartitionValidMbr function's second parameter should be the
last sector of the device. For MBR partition, the block size is
sector size, i.e. 512 bytes. The original value is media block
last LBA which is counted by the media block size. And media
block size is not always 512 bytes, it may be larger which would
cause the MBR boundary check incorrect. The boundary check is
based on the partition entry start LBA and size of LBA which
are both counted by the sector number (512 bytes).
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2844
Update Reclaim() to return the error status from the reclaim
operation and not the status of SynchronizeRuntimeVariableCache()
that can be EFI_SUCCESS even through the status from reclaim
is an error. Without this change, the return status from
SetVariable() can be EFI_SUCCESS even though the variable was
not actually set. This occurs if the variable store is full
and a Reclaim() is invoked to free up space and even after all
possible space is freed, there is still not enough room for
the variable being set. This condition should return
EFI_OUT_OF_RESOURCES.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2849
MtrrSetFixedMtrr() sets all the fixed MTRR settings.
But in fact MtrrSetAllMtrrs() is always used by callers to set all
MTRR settings including the fixed and variable ones.
The patch removes the unnecessary API MtrrSetFixedMtrr()
to simplify the MtrrLib API.
There is no code in edk2 and edk2-platforms repo that calls
MtrrSetFixedMtrr().
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2849
MtrrSetVariableMtrr() sets all the variable MTRR settings.
But in fact MtrrSetAllMtrrs() is always used by callers to set all
MTRR settings including the fixed and variable ones.
The patch removes the unnecessary API MtrrSetVariableMtrr() to
simplify the MtrrLib API.
There is no code in edk2 and edk2-platforms repo that calls
MtrrSetVariableMtrr().
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2849
MtrrGetVariableMtrr() returns all the variable MTRR settings.
But in fact MtrrGetAllMtrrs() and
MtrrGetMemoryAttributeInVariableMtrr() are used by callers to get the
MTRR settings. The former one returns both the fixed and variable
MTRR settings.
The patch removes the unnecessary API MtrrGetVariableMtrr() to
simplify the MtrrLib API.
There is no code in edk2 and edk2-platforms repo that calls
MtrrGetVariableMtrr().
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
When build UEFI payload using NOOPT, it would build failure since
the FV size. So this patch increases FV size to support NOOPT.
If not NOOPT build, there is no change to FV size.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Refactor StandardSignatureIsAuthenticAMD into BaseUefiCpuLib from
separate copies in BaseXApicLib, BaseXApicX2ApicLib, and MpInitLib.
This allows for future use of StandarSignatureIsAuthinticAMD without
creating more instances in other modules.
This function allows IA32/X64 code to determine if it is running on an
AMD brand processor.
UefiCpuLib is already included directly or indirectly in all modified
modules. Complete move is made in this change.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Message-Id: <20200622131825.1352-4-Garrett.Kirkendall@amd.com>
In preparation for moving StandardSignatureIsAuthenticAMD to UefiCpuLib
in UefiCpuPkg, SourceLevelDebugPkg/SourceLevelDebugPkg.dsc needs
LibraryClass UefiCpuLib.
LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf will need
UefiCpuLib LibraryClass. Likely most "real" platforms will be using
BaseX2XApicLib instance which already required UefiCpuLib.
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
Message-Id: <20200622131825.1352-3-Garrett.Kirkendall@amd.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
In preparation for moving StandardSignatureIsAuthenticAMD to UefiCpuLib
in UefiCpuPkg, PcAtChipset/PcAtChipsetPkg.dsc needs LibraryClass
UefiCpuLib.
LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf will need
UefiCpuLib LibraryClass. Likely most "real" platforms will be using
BaseX2XApicLib instance which already required UefiCpuLib.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
Message-Id: <20200622131825.1352-2-Garrett.Kirkendall@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
SetupGit.py sets the git config option diff.orderFile to
{edk2 directory}/BaseTools/Conf/diff.order, to override the default order
in which files are shown in a diff/patch/whatever. This is in imitation
of what is done manually in Laszlo's Unkempt Guide.
However, the version currently in the tree is in CRLF format, which makes
git interpret e.g. *.c as matching on *.c<CR>, finding no matches and
failing to apply the desired reordering. Note: this is true regardless of
whether running on Linux or Windows.
Convert the file to LF-only to make it work as expected.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add definition of EFI_SERIAL_TERMINAL_DEVICE_TYPE_GUID.
It was miseed in "Extend SERIAL_IO with DeviceTypeGuid" patch.
(UEFI 2.8, mantis 1832)
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
On Debian 10 (Buster), when running PatchCheck.py with python2, a
backtrace is printed, starting from:
File "../edk2/BaseTools/Scripts/PatchCheck.py", line 595,
in find_patch_pieces
parts = email.header.decode_header(pmail.get('subject'))
AttributeError: 'module' object has no attribute 'header'
When using python3, this backtrace does not appear.
Explicitly importing email.header resolves this for python2 and does not
appear to cause any issues with python3.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
SetupGit.py adds BaseTools/Conf/diff.order as a diff orderfile, but that
file currently has CRLF line endings, which causes all pattern matches
to fail and the ordering remaining unaffected.
Add an exception to PatchCheck.py (to the existing .gitmodules clause),
so that we can merge the fix to the config file.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Using Python 3.7.2 on win32, when printing a FileBuildRule
instance, the following error occurs:
File "edk2\BaseTools\Source\Python\AutoGen\BuildEngine.py",
line 177, in __str__
DestString = ", ".join(self.DestFileList)
TypeError: sequence item 0: expected str instance, PathClass found
This patch converts each PathClass element of the list to a string
instance before concatenating them.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.
The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.
This patch modifies the AmlToC script to generate a C file
instead of a ".hex" file.
It also adds the generation of an intermediate ".amli" file
when compiling an ASL file, and adds a rule to convert this
".amli" to a C file.
This allows to generate a C file containing the AML bytecode
from an ASL file. This C file will then be handled by the EDK2
build system to generate an object file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.
To summarize, the flow goes as:
-1. ASL file is compiled to AML;
-2. AML file is copied to a ".amli" intermediate file;
-3. EDK2 build system applies the rule relevant to ".amli"
files. This is, calling the "AmlToC" script, generating
a C file from the ".amli" file;
-4. EDK2 build system applies the rule relevant to C files.
This is creating an object file.
-5. EDK2 build system links the object file containing the
AML bytecode with the object file requiring it.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.
The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.
This patch renames the script as AmlToC. It is posted as
a separate patch to prevent git from seeing the renaming
as a deletion plus addition of a new file.
The ending line of the posix-like bin-wrapper script has
also been corrected.
This is a first step toward generating a C file containing
the AML bytecode from an ASL file. This C file will then
be handled by the EDK2 build system to generate an object
file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.
To summarize, the flow goes as:
-1. ASL file is compiled to AML;
-2. AML file is copied to a ".amli" intermediate file;
-3. EDK2 build system applies the rule relevant to ".amli"
files. This is, calling the "AmlToC" script, generating
a C file from the ".amli" file;
-4. EDK2 build system applies the rule relevant to C files.
This is creating an object file.
-5. EDK2 build system links the object file containing the
AML bytecode with the object file requiring it.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch modifies the Makefile generation not to stop
adding Makfile rules when the first final target is found.
E.g.:
If the following rules are described in build_rule.txt:
-[Rule1]: .X files generate .Y and .Z files;
-[Rule2]: .Z files generate .Z1 files.
Currently, if a File1.X file was part of the sources of a
module, only [Rule1] would be generated in the Makefile.
Indeed, there are no rules to apply to .Y files: .Y files
are a final target. However, there is still [Rule2] to
apply to .Z files.
This patch also adds a dependency between the first
ouput file of a rule and the other output files.
For instance, with the same example as above, File1.Y
and File1.Z are generated by the following rule:
File1.Y: File1.X
<Generate File1.Y>
<Generate File1.Z>
and the new dependency is:
File1.Z: File1.Y
This is necessary to keep a dependency order during the
execution of the Makefile. Indeed, .Y and .Z files are
generated by the execution of a common set of commands,
and without this rule, there is no explicit dependency
relation between them.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Bash scripts require LF line endings to work.
PatchCheck.py checks that the files added in a patch have CRLF
line endings. It excludes files ending with the ".sh" extension
from this check.
Some bash script don't have a ".sh" extension. Most of them are
located in:
- BaseTools/BinWrappers/PosixLike/
- BaseTools/Bin/CYGWIN_NT-5.1-i686/
This patch excludes these folder plus BaseTools/BuildEnv from
this CRLF check.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
PL011UartLib determines its FIFO depth based on the PID2 value but
the register PID2 is not mandatory as per the SBSA spec.
This change won't check PID2 if PcdUartDefaultReceiveFifoDepth is set
to a value > 0.
Signed-off-by: Irene Park <ipark@nvidia.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Simple application wrapper that invokes the shell
command wrapper for 'acpiview'.
This allows the AcpiView functionality to be used
on platforms with older specifications of the UEFI
shell or where the 'acpiview' command is not built in
due to platform build configuration.
Furthermore, this app can be integrated into more comprehensive
testing frameworks as a single component of a more thorough
specification compliance validation strategy.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
The UefiShellAcpiViewCommandLib is converted from NULL library to a
named library so that it may be used in modules other than shell.
The library interface exposes the main method for to AcpiView
functionality as well as a helper method to dump a buffer to a file.
The Shell module is still built by pulling UefiShellAcpiViewCommandLib
as a NULL library to preserve the modularity of shell builds.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
Method is refactored into two parts. A new method is
created that dumps arbitrary buffers into a newly created
file. This method is called from core code after the core code
determined the appropriate filename to be used.
This improves the modular design.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
A new file and header (AcpiViewConfig.[ch]) is created
that houses the user configuration. This declutters the
core code and improves modularity of the design.
The module level symbols for verbosity, table selection, and
highlighting are refactored into the new file.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
While building with the following command line:
build -b DEBUG -a AARCH64 -t VS2017 -p MdeModulePkg\MdeModulePkg.dsc
A missing cast triggers the following warning, then triggering an error:
ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c(652):
warning C4152: nonstandard extension, function/data pointer
conversion in expression
This patch first casts the function pointer to (UINTN), then to (VOID *),
followowing the C99 standard s6.3.2.3 "Pointer", paragraphs 5 and 6.
This suppresses the warning.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Our UEFI guest firmware takes ownership of the emulated NOR flash in
order to support the variable runtime services, and it does not expect
the OS to interfere with the underlying storage directly. So disable
the NOR flash DT nodes as we discover them, in a way similar to how we
disable the PL031 RTC in the device tree when we attach our RTC runtime
driver to it.
Note that this also hides the NOR flash bank that carries the UEFI
executable code, but this is not intended to be updatable from inside
the guest anyway, and if it was, we should use capsule update to do so.
Also, the first -pflash argument that defines the backing for this flash
bank is often issued with the 'readonly' modifier, in order to prevent
any changes whatsoever to be made to the executable firmware image by
the guest.
This issue has become relevant due to the following Linux changes,
which enable the flash driver stack for default build configurations
targetting arm64 and 32-bit ARM.
ce693fc2a877
("arm64: defconfig: Enable flash device drivers for QorIQ boards", 2020-03-16).
5f068190cc10
("ARM: multi_v7_defconfig: Enable support for CFI NOR FLASH", 2019-04-03)
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Today's UefiPayloadPkg always uses 0xE0000000 as the PCIE base address
and ignores the value set in AcpiBoardInfo HOB created by the boot
loader. This makes the payload binary cannot work in environment
where the PCIE base address set by boot loader doesn't equal to
0xE0000000.
The patch enhances UefiPayloadPkg so that the PCIE base address
set by boot loader in the AcpiBoardInfo HOB is used.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
All public APIs should have EFIAPI modifier. Somehow PciSegmentInfoLib
missed the EFIAPI modifier.
The patch updates the library header file and NULL instance in MdePkg
to add the missing EFIAPI.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2776
Add a vector at 0xFF000 (0xFFFFF000) that can be used by Init-SIPI-SIPI
to start an AP before memory is initialized. This vector jumps into the
same SEC entry point as the ordinary reset vector, with a special value
of "AP" in the DI register. The platform-specific SEC code is expected
to check for that value and take a different path for APs, if this
feature is supported by the platform.
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Deric Cole <deric.cole@intel.com>
RestoreTPL called while at TPL_HIGH_LEVEL unconditionally enables
interrupts even if called in interrupt handler. That opens a window while
interrupt is not completely handled but another interrupt could be
accepted.
If a VM starts on a heavily loaded host hundreds of periodic timer
interrupts might be queued while vCPU is descheduled (the behavior is
typical for a Xen host). The next time vCPU is scheduled again all of them
get delivered back to back causing OVMF to accept each one without
finishing a previous one and cleaning up the stack. That quickly results
in stack overflow and a triple fault.
Fix it by postponing sending EOI until we finished processing the current
tick giving interrupt handler opportunity to clean up the stack before
accepting the next tick.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: add BZ ref; rewrap msg to silence PatchCheck.py]
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786
In order to support enable/disable report status code through memory
or serial dynamic, change the following PCDs from [PcdsFeatureFlag] to
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]:
PcdStatusCodeUseSerial
PcdStatusCodeUseMemory
The original plaforms can use PcdsFixedAtBuild in .dsc files to save size.
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the UiApp will instantiate the autogenerated
boot options that we used to rely on as before, but since we are already
sitting idle in the root UiApp menu at that point, it does break the
unattended boot case where devices are expected to attempt a network
boot on the very first power on.
Let's work around this by refreshing all boot options explicitly in
the UnableToBoot() handler, and rebooting the system if doing so
resulted in a change to the total number of configured boot options.
This way, we ultimately end up in the UiApp as before if no boot
options could be started, but only after all the autogenerated ones
have been attempted as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
This reverts commit ced77332ca.
The command
virt-install --location NETWORK-URL
downloads the vmlinuz and initrd files from the remote OS tree, and passes
them to the guest firmware via fw_cfg.
When used with IA32 / X64 guests, virt-install expects the guest firmware
to do two things, at the same time:
- launch the fw_cfg kernel image even if the latter does not pass SB
verification (SB checking is supposed to be bypassed entirely in favor
of the Linux/x86 Boot Protocol),
- still let the guest kernel perceive SB as enabled.
Commit ced77332ca prevented this, by removing the Linux/x86 Boot
Protocol from such an OVMF image that was built with SECURE_BOOT_ENALBE.
While that's the right thing in theory, in practice "virt-install
--location NETWORK-URL" is entrenched, and we shouldn't break it.
We can tolerate the Linux/x86 Boot Protocol as a one-of-a-kind SB bypass
for direct-booted kernels, because:
- the fw_cfg content comes from QEMU, and the guest is already at QEMU's
mercy,
- in the guest, OS boots after the initial installation will use "shim"
rather than an fw_cfg kernel, which we can consider somewhat similar to
"Audit Mode / Deployed Mode" (~ trust for install, lock down after).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20200615144514.24597-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[lersek@redhat.com: truncate the subject line, originally auto-generated
by git-revert, to pacify PatchCheck.py]
Apply PE/COFF fixups when starting up the standalone MM core, so that
it can execute at any address regardless of the link time address.
Note that this requires the PE/COFF image to be emitted with its
relocation section preserved. Special care is taken to ensure that
TE images are dealt with correctly as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The standalone MM core runs in a restricted environment that is set
up by a higher privilege level, and which may not allow memory regions
to be writable and executable at the same time.
This means that making the StMM core self-relocatable requires that
all the targets of the relocation fixups are outside of the executable
region of the image, given that we cannot remap the executable code
writable from the executable code itself without losing those execute
permissions.
So instead, use the existing toolchain support to ensure that position
independent code is used where possible, and that all the remaining
relocated quantities are emitted into the data section. (Note that
staticallly initialized const pointers will be emitted into the
.data.rel.ro section, which gets pulled into the .data section by
our linker script)
To ensure that we don't pick up any absolute references in executable
code inadvertently (e.g., in assembler code), add the '-z text' linker
option which will force the build to fail in this case.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
FvIsBeingProcessed () emits a DEBUG print with the intent to print
the memory address of the FV that is being processed, but instead,
it prints the contents of an uninitialized stack variable.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The mStatusString[] array is constructed as an array of pointer-to-char,
which means that on X64 or AARCH64, it is emitted as a single linear list
of 64-bit quantities, each containing the absolute address of one of the
string literals in memory.
This means that each string takes up 8 bytes of additional space, along
with 2 bytes of relocation data. It also means that extra work needs to
be done at runtime to process these relocations, every time a module is
loaded that incorporates this library.
So fix both issues, by splitting mStatusString into two arrays of char
arrays. The memory footprint decreases from 955 to 843 bytes, and given
that in the latter case, the overhead consists of 278 NUL characters rather
than 390 bytes worth of absolute addresses and relocation records, the size
of a compressed image is reduced even further. For example, when building
ArmVirtQemu.dsc in RELEASE mode for AARCH64 with the GCC5 profile, I get:
Before
FV Space Information
FVMAIN [100%Full] 5329920 total, 5329920 used, 0 free
FVMAIN_COMPACT [38%Full] 2093056 total, 811840 used, 1281216 free
After
FV Space Information
FVMAIN [100%Full] 5321728 total, 5321728 used, 0 free
FVMAIN_COMPACT [38%Full] 2093056 total, 809696 used, 1283360 free
So the uncompressed contents of the compressed image are 8 KB smaller,
whereas the resulting flash image (consisting of the compressed image
along with SEC, PEI_CORE and a set of PEIMs that execute in place) is
2 KB smaller.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
We no longer use ELF PIE executables to implement the self-relocating
PrePi so drop the custom linker script and visibility override header
file.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
Instead of having a GCC specific routine to perform self-relocation
based on ELF metadata, use the PE/COFF metadata and the existing
PeCoff library routines. This reduces the amount of bespoke assembler
code that is a burden to maintain, and is not portable across the set
of toolchains we support.
This does require some special care, as we have no control over how
the C code references global symbols, so we need to emit these
references from the calling assembler code. Otherwise, they may be
emitted as absolute references, in which case they need to be fixed
up themselves, leading to a circular dependency.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
In preparation for making the self-relocating PrePi use the ordinary
BasePeCoffLib routines for relocating the image in place in memory
at start, add a special FDF rule that builds SEC modules as PE32
images with the relocation metadata preserved.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
Moved BlockCount calculation below BufferSize Validation checks.
First Ensure Buffersize is Not Zero and multiple of Media BlockSize.
then calculate BlockCount and perform Block checks.
Corrected BlockCount calculation, as BufferSize is multiple of BlockSize,
So adding (BlockSize-1) bytes to BufferSize and
then divide by BlockSize will have no impact on BlockCount.
Reading Large Images from MMC causes errors.
As per SD Host Controller Spec version 4.20,
Restriction of 16-bit Block Count transfer is 65535.
Max block transfer limit in single cmd is 65535 blocks.
Added Max Block check that can be processed is 0xFFFF.
then Update BlockCount on the basis of MaxBlock.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: "Loh, Tien Hock" <tien.hock.loh@intel.com>
The exception library is also used in DxeMain before memory services
are available, and AllocatePages() will fail in this case and cause
sp_el0 remains 0. Then if any exception occurs before CpuDxe driver is
loaded, a recursive exception will be trigged by page translation
fault for sp = 0 - 0x130.
Use static buffer instead to fix this issue.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2701
Recording to the spec, the reconnect is activated upon exiting of the
formset or the browser. Exiting is by user but form-browser internal
logic. That means the reconnection is only happened when user press
ESC or _EXIT action to exit form.
Driver callback may update HII form dynamically so form-browser needs
to refresh its internal data. It's not exiting formset for user
exactly and they didn't know what happened. So use a flag to record
that and do not reconnect driver if updated by callback.
Signed-off-by: Walon Li <walon.li@hpe.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Its been observed that in MenuManagerMenuApp when user
selects a different BootOption using Up/Down key, the
current Cursor position is not chaning.
Still points to the old BootOption.
This changes first dispalys/redraws the old BootOption
followed by new BootOption. Doing so will make current
cursor pointing to the user selected BootOption.
Signed-off-by: Abdul Lateef Attar <abdul@marvell.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
The following two section titles in "Maintainers.txt" are not in
(case-sensitive) lexicographical order:
> MdeModulePkg: ACPI modules
> MdeModulePkg: ACPI S3 modules
However, if we simply sorted them, we'd have another problem: the specific
"ACPI S3 modules" line would precede the generic "ACPI modules" line.
Therefore, slightly reformulate the title on the second section, in order
to establish both lexicographical and hierarchical order.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2778
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603160627.3594-2-lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Commit 045e4b84c1 ("ArmPkg/ArmPkg.dsc: Add missing components")
adds some components to the ArmPkg.dsc build config, but it adds
them to Components.common, and MmCommunicationDxe is AArch64 only.
Move it to Components.AARCH64 to stop the ARM build breaking.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
AutoGen manager/workers halt the progress when an error occurs but
doesn't propagate the error code to main and allows main exit with 0
and gets the build system unable to catch the occurrence of an error.
This change informs main with an error when a progress is halted and
helps main exit with 1.
Signed-off-by: Irene Park <ipark@nvidia.com>
Reviewed-by: Bob Feng<bob.c.feng@intel.com>
In order to avoid boot delays from devices such as network controllers
that may not even be involved in booting at all, drop the call to
EfiBootManagerConnectAll () from the boot path. It will be called by
UiApp, so when going through the menu, all devices will be connected
as usual, but for the default boot, it is really not necessary so
let's get rid of this.
Enumerating all possible boot options and creating Boot#### variables
for them is equally unnecessary in the default case, and also happens
automatically in UiApp, so drop that as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Without ConnectAll() being called on the boot path, the UEFI shell will
be entered with no block devices or anything else connected, and so for
the novice user, this is not a very accommodating environment. Now that
we have made the UiApp the last resort on boot failure, and made the
UEFI Shell accessible directly via the 's' hotkey if you really need
it, let's hide it as an ordinary boot option.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
UEFI boot options may exist but have the LOAD_OPTION_ACTIVE flag
cleared. This means that the boot option should not be selected
by default, but it does not mean it should be omitted from the
boot selection presented by the boot manager: for this purpose,
another flag LOAD_OPTION_HIDDEN exists.
Given that the latter flag exists solely for the purpose of omitting
boot options from the boot selection menu, and LOAD_OPTION_XXX flags
can be combined if desired, hiding inactive boot options as well is
a mistake, and violates the intent of paragraph 3.1.3 of the UEFI
specification (revision 2.8 errata A). Let's fix this by dropping
the LOAD_OPTION_ACTIVE check from the code that populates the boot
selection menu.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
As a last resort, drop into the UiApp application when no active boot
options could be started. Doing so will connect all devices, and so
it will allow the user to enter the Boot Manager submenu and pick a
network or removable disk option.
Note that this only occurs if even the default removable filepath
could not be booted (e.g., \EFI\BOOT\BOOTAA64.EFI on AArch64)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In preparation of hiding the UEFI Shell boot option as an ordinary
boot option, make sure we can invoke it directly using the 's'
hotkey. Without ConnectAll() having been called, this results in
a shell that may have no block devices or other things connected,
so don't advertise the 's' in the console string that is printed
at boot - for novice users, we will go through the UiApp which
connects everything first. For advanced use, having the ability
to invoke the UEFI shell without any devices connected may be an
advantage, so let's keep this behavior as is for now.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The way the BDS handles the short-form USB device path of the console
keyboard relies on USB host controllers to be locatable via their PCI
metadata, which implies that these controllers already have a PCI I/O
protocol installed on their handle.
This is not the case for non-discoverable USB host controllers that are
supported by the NonDiscoverable PCI device driver. These controllers
must be connected first, or the BDS will never notice their existence,
and will not enable any USB keyboards connected through them.
Let's work around this by connecting these handles explicitly. This is
a bit of a stopgap, but it is the cleanest way of dealing with this
without violating the UEFI driver model entirely. This ensures that
platforms that do not rely on ConnectAll() will keep working as
expected.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Supervisor Call instruction (SVC) is used by the Arm Standalone MM
environment to request services from the privileged software (such as
ARM Trusted Firmware running in EL3) and also return back to the
non-secure caller via EL3. Some Arm CPUs speculatively executes the
instructions after the SVC instruction without crossing the privilege
level (S-EL0). Although the results of this execution are
architecturally discarded, adversary running on the non-secure side can
manipulate the contents of the general purpose registers to leak the
secure work memory through spectre like micro-architectural side channel
attacks. This behavior is demonstrated by the SafeSide project [1] and
[2]. Add barrier instructions after SVC to prevent speculative execution
to mitigate such attacks.
[1]: https://github.com/google/safeside/blob/master/demos/eret_hvc_smc_wrapper.cc
[2]: https://github.com/google/safeside/blob/master/kernel_modules/kmod_eret_hvc_smc/eret_hvc_smc_module.c
Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Follow the implementation from Unix host to implement SNP
EMU_IO_THUNK_PROTOCOL and EMU_SNP_PROTOCOL. The network IO driver is the
same one as Nt32. Please refer to NETWORK-IO Subproject for network Io
driver(SnpNt32Io.dll).
Signed-off-by: Nickle Wang <nickle.wang@hpe.com>
Signed-off-by: Derek Lin <derek.lin2@hpe.com>
Acked-by: Ray Ni <ray.ni@intel.com>
PlatformBootManagerLib now asserts at build time that the correct
terminal type is used, and so leaving it unset breaks the ArmPkg
DSC build. So fix that.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In the ArmPkg version of PlatformBootManagerLib, we construct a
serial device path based on the default settings for baud rate,
parity and the number of stop bits, to ensure that a serial console
is available even on the very first boot.
This assumes that PcdUartDefaultParity or PcdUartDefaultStopBits are
not set to '0', meaning 'the default', as there is no default for
these when constructing a device path.
So add a couple of STATIC_ASSERT()s to make sure that we catch this
condition, since it otherwise ignores the bogus device path silently,
which is rather tedious to debug,.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the runtime ASSERT with the build time STATIC_ASSERT on the
check that ensures that the terminal type we use for the serial
console matches the one we explicitly add to the ConIn/ConOut/StdErr
variables.
This helps catch serial console issues early, even in RELEASE builds,
reducing the risk of ending up with no console at all, which can be
tricky to debug on bare metal.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Sami Mujawar <Sami.Mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-06-03 14:04:59 +00:00
857 changed files with 87178 additions and 9962 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.