Some platforms don't support S3 with PcdAcpiS3Enable set as False.
Debug mode bios will ASSERT at this time as Follows.
ASSERT_RETURN_ERROR (Status = Out of Resources)
DXE_ASSERT!: Edk2\MdePkg\Library\BaseS3PciSegmentLib\S3PciSegmentLib.c
(61): !(((INTN)(RETURN_STATUS)(Status)) < 0)
Steps to reproduce the issue:
1.Set PcdAcpiS3Enable to FALSE.
2.Build the bios in debug mode.
3.Power on and Check the serial log.
Note: Prerequisite is that S3PciSegmentLib is Called and
the caller's code is run.
Root Cause:
S3PciSegmentLib call S3BootScriptLib controlled by PcdAcpiS3Enable.
If PcdAcpiS3Enable set as false, S3BootScriptLib will return error
status(Out of Resources).
S3PciSegmentLib will ASSERT if S3BootScriptLib return error.
Solution:
Make S3BootScriptLib return success if PcdAcpiS3Enable was disabled,
which behave as a null S3BootScriptLib instance which just return success
for no action is required to do.
Signed-off-by: JunX1 Li <junx1.li@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sunny Wang <sunny.wang@arm.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: G Edhaya Chandran <edhaya.chandran@arm.com>
Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Skip error check if HardwareInstance is 0 as this either means that
FmpVersion < 3 and not supported or,
"A zero means the FMP provider is not able to determine a
unique hardware instance number or a hardware instance number
is not needed." per UEFI specification.
As the FmpInstances are merged and HardwareInstance is not used
remove error check in this case.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The hard-coded attributes for the re-added memory space should instead
forward the replaced descriptor's capabilities.
Tested on Linux with efi=debug. Prior to this change, an 8GiB VM running
a kernel without unaccepted memory support shows this entry
efi: mem94: [Conventional| | |CC| | | | | | | | | | | ]
range=[0x0000000100000000-0x000000023fffffff] (5120MB)
This does not have the cache capabilities one would expect for system
memory, UC|WC|WT|WB.
After this change, the same entry becomes
efi: mem94: [Conventional| | |CC| | | | | | | |WB|WT|WC|UC]
range=[0x0000000100000000-0x000000023fffffff] (5120MB)
This has all the expected attributes.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
[ardb: drop the EFI_MEMORY_CPU_CRYPTO flag - it isn't used anywhere else
in EDK2 or Linux so it doesn't actually do anything, and it is
unclear whether it is intended for use by the guest in the first
place]
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tianocore maintains container images in the tianocore/containers repo
and stores container images within the GitHub container registry.
https://github.com/tianocore/containers
This change adds a devcontainer.json file to the edk2 repo. This
file's metadata and settings to configurate a development container
for a given well-defined tool and runtime stack.
More information about the devcontainer.json file is available here:
https://containers.dev/implementors/json_reference/
This file is recognized by popular tools such as GitHub Codespaces
and VS Code. In VS Code in particular, it makes it much easier for
a user to be aware a dev container exists (via UI notifications)
and to load the container.
A minimal number of VS Code extensions are specified that are useful
for edk2 development or to assist in complying with CI checks in
place in edk2.
Cc: Andrew Fish <afish@apple.com>
Cc: Chris Fernald <chris.fernald@outlook.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
PR builds and CI are currently broken due to a mergify brownout
today because edk2 uses the `rebase_fallback` attribute of the
`queue` action.
Message from Mergify/Summary:
```
The configuration uses the deprecated rebase_fallback attribute
of the queue action.
A brownout is planned on February 13th, 2023.
This option will be removed on March 13th, 2023.
For more information: https://docs.mergify.com/actions/queue/
```
Therefore, this change removes the attribute per the guidance in
the following changelog message to retain existing behavior.
https://changelog.mergify.com/changelog/rebasefallback-is-deprecated
```
The option rebase_fallback is now deprecated and should not be
used anymore.
Mergify will always report errors in the future if a rebase merge
is impossible.
```
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Since BIOS should work with different BMC implementation chunked requests
as well as Expect header should be optional.
- One PCD is used to enable/disable Expect header.
- Another PCD is used to enable/disable chunked requests.
Reviewed-by: Abner Chang <abner.chang@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Currently the standalonemmlibinternal assumes the max physical bits
to be 36 which is causing issues on v8 architectures.
Instead use the MAX_ALLOC_ADDRESS macro to determine the maximum
allowed address rather than recomputing it locally.
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Allow users to build OVMF then run QEMU by moving the build block above
the run block and removing the exit line.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The IO Remapping Table, Platform Design Document, Revision E.e,
Sept 2022 (https://developer.arm.com/documentation/den0049/ee)
added flags in SMMUv3 node for validity of ID mappings for MSIs
related to control interrupts.
Therefore, update the IORT header file to:
- increment IORT table revision to 6
- add support for DeviceId valid flag
Signed-off-by: Swatisri Kantamsetti <swatisrik@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Literally, the meaning of PcdDxeIplSwitchToLongMode is clear, indicating
whether need switch to long mode when loading DxeCore.
However, the comments in dec are confusing for the case where PEI core and
DXE core are both in 64-bit. This patch makes it clear.
PcdDxeIplSwitchToLongMode is true only when PEI core is 32-bit, and switch
to long mode to load 64-bit DXE core. In other cases, this PCD is false.
This also aligns with current usage in OvmfPkg.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
RedfishHostInterfaceDxe does not close protocol notify event in
event callback function. This could cause multiple version of
type 42 records issue if the protocol is installed more than once.
Close the event in callback function so we only create one type 42
record.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
As per the SCMI specification, section CLOCK_DESCRIBE_RATES mentions
that the value of num_rates_flags[11:0] in the response must be 3 if
the return format is the triplet. Due to the buggy firmware, this was
not noticed for long time. The firmware is now fixed resulting in
ClockDescribeRates() to fail with "Buffer Too Small" error as the
RequiredArraySize gets miscalculated as 72 instead of 24.
Fix the issue by reusing the logic for both the return format which
must work if num_rates_flags has correct value as expected from the
specification.
Cc: Girish Pathak <girish.pathak@arm.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Pierre Gondois <pierre.gondois@arm.com>
Reported-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
This patch enables Tdx measurement in OvmfPkgX64 with below changes:
1) CC_MEASUREMENT_ENABLE is introduced in OvmfPkgX64.dsc. This flag
indicates if Intel TDX measurement is enabled in OvmfPkgX64. Its
default value is FALSE.
2) Include TdTcg2Dxe in OvmfPkgX64 so that CC_MEASUREMENT_PROTOCOL
is installed in a Td-guest. TdTcg2Dxe is controlled by
TDX_MEASUREMENT_ENABLE because it is only valid when Intel TDX
measurement is enabled.
3) OvmfTpmLibs.dsc.inc and OvmfTpmSecurityStub.dsc.inc are updated
because DxeTpm2MeasureBootLib.inf and DxeTpmMeasurementLib.inf
should be included to support CC_MEASUREMENT_PROTOCOL.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
MeasureFvImage once was implemented in PeilessStartupLib and it does
measurement and logging for Configuration FV (Cfv) image in one go,
using TpmMeasureAndLogData(). But it doesn't work in SEC.
This patch splits MeasureFvImage into 2 functions and implement them in
SecTdxHelperLib.
- TdxHelperMeasureCfvImage
- TdxHelperBuildGuidHobForTdxMeasurement
TdxHelperMeasureCfvImage measures the Cfv image and stores the hash value
in WorkArea. TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for the
measurement based on the hash value in WorkArea.
After these 2 functions are introduced, PeilessStartupLib should also be
updated:
- Call these 2 functions instead of the MeasureFvImage
- Delete the duplicated codes in PeilessStartupLib
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
MeasureHobList once was implemented in PeilessStartupLib and it does
measurement and logging for TdHob in one go, using TpmMeasureAndLogData().
But it doesn't work in SEC.
This patch splits MeasureHobList into 2 functions and implement them in
SecTdxHelperLib.
- TdxHelperMeasureTdHob
- TdxHelperBuildGuidHobForTdxMeasurement
TdxHelperMeasureTdHob measures the TdHob and stores the hash value in
WorkArea. TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for the
measurement based on the hash value in WorkArea.
After these 2 functions are introduced, PeilessStartupLib should also be
updated:
- Call these 2 functions instead of the MeasureHobList
- Delete the duplicated codes in PeilessStartupLib
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
TdxHelperLib provides below helper functions for a td-guest.
- TdxHelperProcessTdHob
- TdxHelperMeasureTdHob
- TdxHelperMeasureCfvImage
- TdxHelperBuildGuidHobForTdxMeasurement
SecTdxHelperLib is the SEC instance of TdxHelperLib. It implements 4
functions for tdx in SEC phase:
- TdxHelperProcessTdHob consumes TdHob to accept un-accepted memories.
Before the TdHob is consumed, it is first validated.
- TdxHelperMeasureTdHob measure/extend TdHob and store the measurement
value in workarea.
- TdxHelperMeasureCfvImage measure/extend the Configuration FV image and
store the measurement value in workarea.
- TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for tdx
measurement.
This patch implements the stubs of the functions. The actual
implementations are in the following patches. Because they are moved from
other files.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
From the perspective of security any external input should be measured
and extended to some registers (TPM PCRs or TDX RTMR registers).
There are below 2 external input in a Td guest:
- TdHob
- Configuration FV (CFV)
TdHob contains the resource information passed from VMM, such as
unaccepted memory region. CFV contains the configurations, such as
secure boot variables.
TdHob and CFV should be measured and extended to RTMRs before they're
consumed. TdHob is consumed in the very early stage of boot process.
At that moment the memory service is not ready. Cfv is consumed in
PlatformPei to initialize the EmuVariableNvStore. To make the
implementation simple and clean, these 2 external input are measured
and extended to RTMRs in SEC phase. That is to say the tdx measurement
is only supported in SEC phase.
After the measurement the hash values are stored in WorkArea. Then after
the Hob service is available, these 2 measurement values are retrieved
and GuidHobs for these 2 tdx measurements are generated.
This patch defines the structure of TDX_MEASUREMENTS_DATA in
SEC_TDX_WORK_AREA to store above 2 tdx measurements. It can be extended
to store more tdx measurements if needed in the future.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4245
QEMU provides the following three files for guest to install the ACPI
tables:
- etc/acpi/rsdp
- etc/acpi/tables
- etc/table-loader
"etc/acpi/rsdp" and "etc/acpi/tables" are similar, they are only kept
separate because they have different allocation requirements in SeaBIOS.
Both of these fw_cfg files contain preformatted ACPI payload.
"etc/acpi/rsdp" contains only the RSDP table, while "etc/acpi/tables"
contains all other tables, concatenated. To be noted, the tables in these
two files have been filled in by qemu, but two kinds of fields are
incomplete: pointers to other tables and checksums (which depend on the
pointers).
"/etc/table-loader" is a linker/loader which provides the commands to
"patch" the tables in "etc/acpi/tables" and then install them. "Patch"
means to fill the pointers and compute the checksum.
From the security perspective these 3 files are the raw data downloaded
from qemu. They should be measured and extended before they're consumed.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
According to the UEFI 2.10 Specification, the EFI_BOOT_SERVICES_TABLE
CreateEvent function has the following signature:
typedef
EFI_STATUS
(EFIAPI *EFI_CREATE_EVENT) (
IN UINT32 Type,
IN EFI_TPL NotifyTpl,
IN EFI_EVENT_NOTIFY NotifyFunction, OPTIONAL
IN VOID *NotifyContext, OPTIONAL
OUT EFI_EVENT *Event
);
Fix the prototype in UefiSpec.h to match, by labeling the NotifyFunction
and NotifyContext parameters as OPTIONAL.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add a new parser for the Error Record Serialization Table.
The ERST table describes how an OS can save and retrieve
hardware error information to and from a persistent store.
Signed-off-by: Jeshua Smith <jeshuas@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Currently DiscoverScsiDevice() returns a boolean which cannot
distinguish a "not found" situation from a real problem like
memory allocation failures.
This patch changes the return value to an EFI_STATUS so that when
memory allocation fails, it will return EFI_OUT_OF_RESOURCES.
Without this change, any FALSE returned by DiscoverScsiDevice()
will result in EFI_OUT_OF_RESOURCES being returned by
ScsiScanCreateDevice(), which will cause a while loop in
SCSIBusDriverBindingStart() to abort before other possible Puns in
the SCSI channel are scanned, which means good devices may not have
a chance to be discovered. If this good device is the boot device,
boot will fail.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sivaparvathi chellaiah <sivaparvathic@ami.com>
Signed-off-by: Yuan Yu <yuanyu@google.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Since RvdPeCoffExtraActionLib has been deleted, remove lines referencing
it and the RealView Debugger from ArmVirtPkg.dsc.inc.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
The RealView Debugger is related to RVCT, which is no longer supported.
Given that, remove RvdPeCoffExtraActionLib and code from
RvdPeCoffExtraActionLib which prints lines for use with the RealView
Debugger.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
With the removal of RVCT support and the related Bin/CYGWIN_NT-5.1-i686
and Darwin-i386 directories, remove a leftover reference to
CYGWIN_NT-5.1-i686 from Scripts/PatchCheck.py.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
The enumeration in MdePkg/Include/Pi/PiDxeCis.h has a duplicated entry,
so the 8th position in the list doesn't count as index 7. The value
EfiGcdMemoryTypeUnaccepted will have when added before
EfiGcdMemoryTypeMaximum will be 6.
Cc: Min M Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2928
commit 17bd834eb5 ("BaseTools: Factorize GCC flags")
makes GCC48_ALL_CC_FLAGS inherit from GCC_ALL_CC_FLAGS.
GCC_ALL_CC_FLAGS contains the '-Os' flag.
The latest flag in a command line overrides the previous
optimization option. This allows more specific build
configuration to override the inherited '-Os' flag.
If a build configuration includes GCC48_ALL_CC_FLAGS,
hard-coded '-Os' options are not necessary anymore.
Remove them.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under
AArch64.
PSCI_CPU_ON is called to power on the core, the supplied procedure is
executed and PSCI_CPU_OFF is called to power off the core.
Fixes contributed by Ard Biesheuvel.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
MEMORY_ACCEPTANCE_PROTOCOL to disable the accept behavior and indicate
that it can interpret the memory type accordingly.
This classification is safe since ExitBootServices will accept and
reclassify the memory as conventional if the disable protocol is not
used.
Cc: Ard Biescheuvel <ardb@kernel.org>
Cc: "Min M. Xu" <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
ArmVirtQemuKernel.dsc describes a firmware build that is loadable at
arbitrary address and can be invoked using the Linux/arm64 kernel boot
protocol. The early code deviates significantly from ArmVirtQemu, and so
it makes sense to cover this platform in CI even if it is not widely
used. This ensures that the relocatable PrePi and other components in
EmbeddedPkg don't regress on ARM as they are being updated for use on
TDVF.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
To increase the CI coverage, enable secure boot, TPM2 support and HTTPS
boot on ArmVirtQemu builds used in CI.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
In order to reduce the amount of code duplication, refactor the
PlatformBuild.py script that builds ArmVirtQemu.dsc into a reusable
PlatformBuildLib.py containing most of the bits and pieces, and a small
QemuBuild.py which is specific to the DSC in question.
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
The initial ID map used by ArmVirtQemu only covers 2 MiB of NOR flash,
while the NOOPT build can be up to 3 MiB in size, resulting in a crash
if the unmapped 1 MiB is accessed before the real page tables are up.
So increate the initial flash mapping to 4 MiB.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
PrePi has a bare metal entry point, and so it is in charge of calling
the library constructors once the C runtime has been initialized
sufficiently.
However, we are now relying on a HOB to have been constructed by the
time the MMU code runs, and so the constructors should be run before
that.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4305
Based on whether the DER-encoded ContentInfo structure is present in
authenticated SetVariable payload or not, the SHA-256 OID can be
located at different places.
UEFI specification explicitly states the driver shall support both
cases, but the old code assumed ContentInfo was not present and
incorrectly rejected authenticated variable updates when it were
present.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Jan Bobek <jbobek@nvidia.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Create PcdShellDefaultDelay to configure the default
delay the shell provides for the user at the start time
if the user wishes to cancel the execution of a potential
startup script.
The shell application already allows the user to override
the delay default value by specifying the -delay cmdline
argument. This however cannot be used when loading the
shell application using direct boot or when integrating
the shell into the platform firmware build.
Thus, a PCD can be easily configured by the developer
either at build time, or even at runtime.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
protocol is (effectively) broken such that it suggests that switching from
the legacy interface to the modern interface works, but in reality the
switch never happens. The symptom has been witnessed when using TCG
acceleration; KVM seems to mask the issue. The issue persists with the
following (latest) stable QEMU releases: v5.2.0, v6.2.0, v7.2.0. Currently
there is no stable release that addresses the problem.
The QEMU bug confuses the Present and Possible counting in function
PlatformMaxCpuCountInitialization(), in
"OvmfPkg/Library/PlatformInitLib/Platform.c". OVMF ends up with Present=0
Possible=1. This in turn further confuses MpInitLib in UefiCpuPkg (hence
firmware-time multiprocessing will be broken). Worse, CPU hot(un)plug with
SMI will be summarily broken in OvmfPkg/CpuHotplugSmm, which (considering
the privilege level of SMM) is not that great.
Detect the issue in PlatformCpuCountBugCheck(), and print an error message
and *hang* if the issue is present.
Users willing to take risks can override the hang with the experimental
QEMU command line option
-fw_cfg name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes
(The "-fw_cfg" QEMU option itself is not experimental; its above argument,
as far it concerns the firmware, is experimental.)
The problem was originally reported by Ard [0]. We analyzed it at [1] and
[2]. A QEMU patch was sent at [3]; now merged as commit dab30fbef389
("acpi: cpuhp: fix guest-visible maximum access size to the legacy reg
block", 2023-01-08), to be included in QEMU v8.0.0.
[0] https://bugzilla.tianocore.org/show_bug.cgi?id=4234#c2
[1] https://bugzilla.tianocore.org/show_bug.cgi?id=4234#c3
[2] IO port write width clamping differs between TCG and KVM
http://mid.mail-archive.com/aaedee84-d3ed-a4f9-21e7-d221a28d1683@redhat.comhttps://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00199.html
[3] acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block
http://mid.mail-archive.com/20230104090138.214862-1-lersek@redhat.comhttps://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00278.html
NOTE: PlatformInitLib is used in the following platform DSCs:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/CloudHv/CloudHvX64.dsc
OvmfPkg/IntelTdx/IntelTdxX64.dsc
OvmfPkg/Microvm/MicrovmX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
but I can only test this change with the last three platforms, running on
QEMU.
Test results:
TCG QEMU OVMF override result
patched patched
--- ------- ------- -------- --------------------------------------
0 0 0 0 CPU counts OK (KVM masks the QEMU bug)
0 0 1 0 CPU counts OK (KVM masks the QEMU bug)
0 1 0 0 CPU counts OK (QEMU fix, but KVM masks
the QEMU bug anyway)
0 1 1 0 CPU counts OK (QEMU fix, but KVM masks
the QEMU bug anyway)
1 0 0 0 boot with broken CPU counts (original
QEMU bug)
1 0 1 0 broken CPU count caught (boot hangs)
1 0 1 1 broken CPU count caught, bug check
overridden, boot continues
1 1 0 0 CPU counts OK (QEMU fix)
1 1 1 0 CPU counts OK (QEMU fix)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Brown <mcb30@ipxe.org>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230119110131.91923-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Hugely-appreciated-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
QEMU for x86 has a nasty CPU hotplug bug of which the ramifications are
difficult to oversee, even though KVM acceleration seems to be
unaffected. This has been addressed in QEMU mainline, and will percolate
through the ecosystem at its usual pace. In the mean time, due to the
potential impact on production workloads, we will be updating OVMF to
abort the boot when it detects a QEMU build that is affected.
Tiancore's platform CI uses QEMU in TCG mode, and is therefore impacted
by this mitigation, unless its QEMU builds are updated. This has been
done for Ubuntu-GCC5, but Windows-VS2019 still uses a QEMU build that is
affected.
Aborting the boot upon detecting the QEMU issue will render all boot
tests carried out on Windows-VS2019 broken unless we implement the
'escape hatch' that enables proceed-at-your-own-risk mode, and permits
the boot to proceed even if the QEMU issue is detected.
So let's enable this for Windows-VS2019, and remove it again once it is
no longer needed.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Brown <mcb30@ipxe.org>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Message-Id: <20230119134302.1524569-1-ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Jiewen Yao <Jiewen.yao@Intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In commit c673216f53 a new input parameter is added in FfsFindSectionData.
That change breaks the build of ArmVirtPkg. In this patch
FfsFindSectionData is added back. It calls FfsFindSectionDataWithHook with
a NULL hook.
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Commit c673216f53 introduces FFS_CHECK_SECTION_HOOK and add it as the
second input parameter in FfsFindSectionData. This change breaks the build
of ArmVirtPkg. To fix this issue, the new version of FfsFindSectionData
is renamed as FfsFindSectionDataWithHook in this patch. In the following
patch the original FfsFindSectionData will be added back.
FfsFindSectionData is renamed as FfsFindSectionDataWithHook. Accordingly
PeilessStartupLib in OvmfPkg should be updated as well. To prevent the
build from being broken, the changes in OvmfPkg are in this patch.
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add IpmiCommandLib to MdeModulePkg. This header file is
copied from edk2-platforms/Features/Intel/OutOfBandManagement/
IpmiFeaturePkg\Include\Library. Having this header file in
edk2 to avoid the dependence of edk2 module with edk2-platfrom.
The NULL instance of IpmiCommandLib under MdeModulePkg has
to be implemented for the same reason.
IpmiCommandLib.h in edk2-platforms should be removed once
this patch set is merged. Expect no impacts on edk2-platforms
because MdeModulePkg is referred in INF file by all edk2
modules under edk2-platforms that use IpmiCommandLib.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
According to TCG PC Client PFP spec 0021 Section 2.4.4.2 EFI boot variable
should be measured and extended to PCR[1], not PCR[5]. This patch is
proposed to fix this error.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4152
In current DXE FV there are 100+ drivers. Some of the drivers are not
used in Td guest. (Such as USB support drivers, network related drivers,
etc).
From the security perspective if a driver is not used, we'd should prevent
it from being loaded / started. There are 2 benefits:
1. Reduce the attack surface
2. Improve the boot performance
So we separate DXEFV into 2 FVs: DXEFV and NCCFV. All the drivers which
are not needed by a Confidential Computing guest are moved from DXEFV
to NCCFV.
The following patch will find NCCFV for non-cc guest and build FVHob
so that NCCFV drivers can be loaded / started in DXE phase.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In smbiosview command in shell, below are the fields of SMBIOS
Type38 table which can be displayed in formatted manner.
1. Base Address
1. IPMI Specification Version.
2. NV Storage Device Address.
Base Address:
As per spec, the value in Base Address field of SMBIOS type38 table
should be right shifted by 1 if the interface type is SSIF.
IPMI Specification Version:
If the value in IPMI Specification Version field is 15H,
it should be displayed 1.5.
NV Storage Device Address:
If the value in NV Storage Device Address field is 0xFF,
it should be displayed as "No storage device is Present".
Cc: Vasudevan Sambandan <vasudevans@ami.com>
Cc: Sundaresan Selvaraj <sundaresans@ami.com>
Cc: Gayathri Thunuguntla <gayathrit@ami.com>
Signed-off-by: Prakash K <prakashk@ami.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Remove BaseTools/Bin/gcc_*_ext_dep.yaml to stop downloading gcc from
external locations; use the gcc provided by the container image instead.
The container image sets the variable GCC5_*_PREFIX accordingly.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
All ext_dep.yml files for gcc have been removed and gcc is expected to
be installed on the system (GCC5_*_PREFIX may indicate the location).
No need to adjust the toolchain scopes for Linux builds anymore.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run the Linux jobs of the OvmfPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.
Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run the Linux jobs of the EmulatorPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run the Linux jobs of the ArmVirtPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.
Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run all Linux based jobs in a container, using a custom Fedora 35 image
(gcc 11). The image URL specified in the defaults.yml template, so that
all CI jobs can use it. The image is hosted on ghcr.io and the
Dockerfiles are here: https://github.com/tianocore/containers The
version numbers of gcc, iasl, and nasm are pinned to avoid unintended
upgrades during image rebuild.
Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Add a parameter of the pr-gate-build-job template to specify a
container image URL. If the value is not '' (default), then the
jobs will be run inside a container based on that image.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Without adding ~/.local/bin to PATH, `pip install` will throw
an error when running inside a container.
Containers will be introduced to the CI in the following commits.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.
Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.
Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.
Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Add a new parameter "usePythonVersion" to the CI job templates.
This makes it possible to specify the version of Python to use.
The default value is '', in which case Python will not be downloaded
at runtime and the one provided by the VM/container image will be used.
Additionally, add a template .azurepipelines/templates/defaults.yml,
from which the default Pyhton version string can be obtained.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
First handle the cases which do not need know the value of
PlatformInfoHob->LowMemory (microvm and cloudhv). Then call
PlatformGetSystemMemorySizeBelow4gb() to get LowMemory. Finally handle
the cases (q35 and pc) which need to look at LowMemory,
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add PlatformReservationConflictCB() callback function for use with
PlatformScanE820(). It checks whenever the 64bit PCI MMIO window
overlaps with a reservation from qemu. If so move down the MMIO window
to resolve the conflict.
Write any actions done (moving mmio window) to the firmware log with
INFO loglevel.
This happens on (virtual) AMD machines with 1TB address space,
because the AMD IOMMU uses an address window just below 1TB.
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4251
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add PlatformAddHobCB() callback function for use with
PlatformScanE820(). It adds HOBs for high memory and reservations (low
memory is handled elsewhere because there are some special cases to
consider). This replaces calls to PlatformScanOrAdd64BitE820Ram() with
AddHighHobs = TRUE.
Write any actions done (adding HOBs, skip unknown types) to the firmware
log with INFO loglevel.
Also remove PlatformScanOrAdd64BitE820Ram() which is not used any more.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add PlatformGetLowMemoryCB() callback function for use with
PlatformScanE820(). It stores the low memory size in
PlatformInfoHob->LowMemory. This replaces calls to
PlatformScanOrAdd64BitE820Ram() with non-NULL LowMemory.
Write any actions done (setting LowMemory) to the firmware log
with INFO loglevel.
Also change PlatformGetSystemMemorySizeBelow4gb() to likewise set
PlatformInfoHob->LowMemory instead of returning the value. Update
all Callers to the new convention.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
First step replacing the PlatformScanOrAdd64BitE820Ram() function.
Add a PlatformScanE820() function which loops over the e280 entries
from FwCfg and calls a callback for each of them.
Add a GetFirstNonAddressCB() function which will store the first free
address (right after the last RAM block) in
PlatformInfoHob->FirstNonAddress. This replaces calls to
PlatformScanOrAdd64BitE820Ram() with non-NULL MaxAddress.
Write any actions done (setting FirstNonAddress) to the firmware log
with INFO loglevel.
Also drop local FirstNonAddress variables and use
PlatformInfoHob->FirstNonAddress instead everywhere.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Even though the presence of the 'packed' pragma should be a strong hint
that the misaligned placement of a GUID in a struct is intentional,
recent Clang versions will object nonetheless, and break the build due
to the presence of such GUIDs in the FPDT ACPI tables.
This is obviously not something we can fix in the code, so let's just
suppress the warning/error instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Recent GCC for ARM will complain when selecting the hard float ABI
without specifying the FPU implementation, even when just running the
preprocessor.
This all happens under the hood, and we never bothered in the past,
given that we don't emit floating point code anyway. However, to placate
newer compilers, make it explicit that the floating point ABI is always the
softfloat one, by moving the -msoft-float compiler option to
PLATFORM_FLAGS.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ARCHCC_FLAGS and ARCHASM_FLAGS no longer serve a useful purpose so drop
all the definitions and references.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The global GCC_PP_FLAGS tools_def variable now contains a reference to
OpenSBI specific C preprocessor variables, which means they are added to
the command line on every architecture, not just RISC-V.
This does not currently result in any issues, but it is a bit sloppy so
let's clean this up. Given that the GCC_PP_FLAGS definition appears
twice, drop the one that carries the OpenSBI reference, and move that
reference to a new RISC-V specific variable.
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
EDKII build system supports OptionROM generation if particular PCI_*
defines are present in the module INF file:
```
[Defines]
...
PCI_VENDOR_ID = <...>
PCI_DEVICE_ID = <...>
PCI_CLASS_CODE = <...>
PCI_REVISION = <...>
```
Although after the commit d372ab585a
("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
possible.
The build system fails with the error:
```
Cyclic dependency detected while generating rule for
"<...>/DEBUG/<...>.efi" file
```
Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
to fix the cyclic dependency.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Commit 789a723285 reclassified the NOR flash region as EFI_MEMORY_WC
in the OS visible EFI memory map, and dropped the explicit aligned
CopyMem() implementation, in the assumption that EFI_MEMORY_WC will be
honored by the OS, and that the region will be mapped in a way that
tolerates misaligned accesseses. However, Linux today uses device
attributes for all EFI MMIO regions, in spite of the memory type
attributes, and so using misaligned accesses is never safe.
So instead, switch to the generic CopyMem() implementation entirely,
just like we already did for VariableRuntimeDxe.
Fixes: 789a723285 ("OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and drop AlignedCopyMem()")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Switching from the ArmPlatformPkg/NorFlashDxe driver to the
OvmfPkg/VirtNorFlashDxe driver had the side effect that flash address
space got registered as EFI_MEMORY_WC instead of EFI_MEMORY_UC.
That confuses the linux kernel's numa code, seems this makes kernel
consider the flash being node memory. "lsmem" changes from ...
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000040000000-0x000000013fffffff 4G online yes 8-39
... to ...
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x0000000007ffffff 128M online yes 0
0x0000000040000000-0x000000013fffffff 4G online yes 8-39
... and in the kernel log got new error lines:
NUMA: Warning: invalid memblk node 512 [mem 0x0000000004000000-0x0000000007ffffff]
NUMA: Faking a node at [mem 0x0000000004000000-0x000000013fffffff]
Changing the attributes back to EFI_MEMORY_UC fixes this.
Fixes: b92298af82 ("ArmVirtPkg/ArmVirtQemu: migrate to OVMF's VirtNorFlashDxe")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In commit 49edde1523 ("OvmfPkg/PlatformPei: set 32-bit UC area at
PciBase / PciExBarBase (pc/q35)", 2019-06-03), I forgot to update the
comment. Do it now.
Fixes: 49edde1523
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The early ID map used by ArmVirtQemu uses ASID scoped non-global
mappings, as this allows us to switch to the permanent ID map seamlessly
without the need for explicit TLB maintenance.
However, this triggers a known erratum on ThunderX, which does not
tolerate non-global mappings that are executable at EL1, as this appears
to result in I-cache corruption. (Linux disables the KPTI based Meltdown
mitigation on ThunderX for the same reason)
So work around this, by detecting the CPU implementor and part number,
and proceeding without the early ID map if a ThunderX CPU is detected.
Note that this requires the C code to be built with strict alignment
again, as we may end up executing it with the MMU and caches off.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Now that we build the early code without strict alignment and without
suppressing the use of SIMD registers, ensure that the VFP unit is on
before entering C code.
While at it, simplyify the mov_i macro, which is only used for 32-bit
quantities.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: dann frazier <dann.frazier@canonical.com>
Linux's cpu DT bindings call out arm,armv8 while the code previously
used arm,arm-v8, add second entry to support the arm,armv8 case.
Cc: Sami Mujawar <sami.mujawar@arm.com>
Fixes: e366a41ef0 ("DynamicTablesPkg: FdtHwInfoParser: Add GICC parser")
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add myself as a reviewer for OVMF/Confidential Computing patches.
Remove Brijesh while at it, since he is no longer at AMD, and the email
is no longer valid.
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
I suggest that Gerd be notified about all UefiCpuPkg patches, so he may
take a quick look at, or (by his preference) even test, the proposed
change, in a genuine QEMU/KVM environment.
Assuming this patch is accepted -- subsequently, please *wait* for Gerd's
approval on UefiCpuPkg patches, before merging them.
Notes:
- It's perfectly fine for a reviewer to give an A-b just so the review
process be unblocked, if they don't have anything to add, or don't have
time to review or test in detail. The point is that someone outside of
Intel should *consistently get a chance* to raise concerns about
UefiCpuPkg patches before they are merged.
- My A-b's and R-b's on UefiCpuPkg patches were never supposed to be
"sufficient", only "necessary", for merging. The intent is the same
here, with Gerd's designation as a reviewer.
Cc: Andrew Fish <afish@apple.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230103160539.87830-1-lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Similarly to the "cadence" mentioned in commit d272449d9e ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since
commit 5e75c4d1fe ("OvmfPkg: raise DXEFV size to 12 MB", 2020-03-11),
and we've outgrown DXEFV again (with NOOPT builds). Increase the DXEFV
size to 13MB now.
Do not modify all platform FDF files under OvmfPkg. "BhyveX64.fdf" is
still at 11MB, "OvmfXen.fdf" at 10MB. The "AmdSevX64.fdf",
"CloudHvX64.fdf", "IntelTdxX64.fdf" and "MicrovmX64.fdf" flash devices
could be modified similarly (from 12MB to 13MB), but I don't use or build
those platforms.
Tested on:
- IA32, q35, SMM_REQUIRE, Fedora 30 guest
- X64, pc (i440fx), no SMM, RHEL-7.9 guest
- IA32X64, q35, SMM_REQUIRE, RHEL-7.9 guest
Test steps:
- configure 3 VCPUs
- boot
- run "taskset -c $I efibootmgr" with $I covering 0..2
- systemctl suspend
- resume from virt-manager
- run "taskset -c $I efibootmgr" with $I covering 0..2
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4236
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Per my bisection: nasm broke the parsing of the "--" end-of-options
delimiter in commit 55568c1193df ("nasm: scan the command line twice",
2016-10-03), part of the nasm-2.13 release. The parsing remains broken in
at least nasm-2.15.03. The (invalid) error message is: "more than one
input file specified". I've filed the following ticket for upstream nasm
(and ndisasm): <https://bugzilla.nasm.us/show_bug.cgi?id=3392829>.
Since the delimiter is not necessary in practice (due to $STEM being
"VbeShim", i.e., not starting with a hyphen), simply remove the delimiter.
Tested by enabling DEBUG in "VbeShim.asm", running the script, building
OVMF, booting Windows 7, and checking the firmware log (debug console).
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3876
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Force resetting the port by clearing the USB_PORT_STAT_C_RESET bit in
PortChangeStatus when XhcPollPortStatusChange fails
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
For Windows add below tool for code coverage
1. OpenCppCoverage: parsing pdb file to generate coverage
data
2. pycobertura: show up html format data for coverage data
For Linux add below tool for code coverage
1. lcov: parsing gcda gcno file to generate coverage data
2. lcov-cobertura: convert coverage data to cobertura format
3. pycobertura: show up html format data for coverage data
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
When setting new page table pool to RO, only disable/enable WP when
Cr0.WP has been set to 1 to fix potential PF caused by b822be1a20
(UefiCpuPkg/PiSmmCpuDxeSmm: Introduce page table pool mechanism).
With previous code, if someone want to modify the page table and
Cr0.WP has been cleared before modify page table, Cr0.WP may be set
to 1 again since new pool may be generated during this process
Then PF fault may happens.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Prior to this change, deps were not generated for Arm and AARCH64
libraries when MODULE_TYPE was BASE, SEC, PEI_CORE, or PIEM. That
resulted in bad incremental builds.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
When checking the version in DevicePath's Makefile, use BUILD_CC instead
of assuming "gcc". BUILD_CC is set in header.makefile and is the
compiler that will actually be used to build DevicePath. It defaults to
"gcc", but may be overridden.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
UEFI requires us to support nested interrupts, but provides no way for
an interrupt handler to call RestoreTPL() without implicitly
re-enabling interrupts. In a virtual machine, it is possible for a
large burst of interrupts to arrive. We must prevent such a burst
from leading to stack underrun, while continuing to allow nested
interrupts to occur.
This can be achieved by allowing, when provably safe to do so, an
inner interrupt handler to return from the interrupt without restoring
the TPL and with interrupts remaining disabled after IRET, with the
deferred call to RestoreTPL() then being issued from the outer
interrupt handler. This is necessarily messy and involves direct
manipulation of the interrupt stack frame, and so should not be
implemented as open-coded logic within each interrupt handler.
Add the Nested Interrupt TPL Library (NestedInterruptTplLib) to
provide helper functions that can be used by nested interrupt handlers
in place of RaiseTPL()/RestoreTPL().
Example call tree for a timer interrupt occurring at TPL_APPLICATION
with a nested timer interrupt that makes its own call to RestoreTPL():
outer TimerInterruptHandler()
InterruptedTPL == TPL_APPLICATION
...
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
gBS->RestoreTPL (TPL_APPLICATION);
EnableInterrupts();
dispatch a TPL_CALLBACK event
gEfiCurrentTpl = TPL_CALLBACK;
nested timer interrupt occurs
inner TimerInterruptHandler()
InterruptedTPL == TPL_CALLBACK
...
IsrState->InProgressRestoreTPL = TPL_CALLBACK;
gBS->RestoreTPL (TPL_CALLBACK);
EnableInterrupts();
DisableInterrupts();
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
IRET re-enables interrupts
... finish dispatching TPL_CALLBACK events ...
gEfiCurrentTpl = TPL_APPLICATION;
DisableInterrupts();
IsrState->InProgressRestoreTPL = 0;
sees IsrState->DeferredRestoreTPL == FALSE and returns
IRET re-enables interrupts
Example call tree for a timer interrupt occurring at TPL_APPLICATION
with a nested timer interrupt that defers its call to RestoreTPL() to
the outer instance of the interrupt handler:
outer TimerInterruptHandler()
InterruptedTPL == TPL_APPLICATION
...
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
gBS->RestoreTPL (TPL_APPLICATION);
EnableInterrupts();
dispatch a TPL_CALLBACK event
... finish dispatching TPL_CALLBACK events ...
gEfiCurrentTpl = TPL_APPLICATION;
nested timer interrupt occurs
inner TimerInterruptHandler()
InterruptedTPL == TPL_APPLICATION;
...
sees InterruptedTPL == IsrState->InProgressRestoreTPL
IsrState->DeferredRestoreTPL = TRUE;
DisableInterruptsOnIret();
IRET returns without re-enabling interrupts
DisableInterrupts();
IsrState->InProgressRestoreTPL = 0;
sees IsrState->DeferredRestoreTPL == TRUE and loops
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
gBS->RestoreTPL (TPL_APPLICATION); <-- deferred call
EnableInterrupts();
DisableInterrupts();
IsrState->InProgressRestoreTPL = 0;
sees IsrState->DeferredRestoreTPL == FALSE and returns
IRET re-enables interrupts
Cc: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4162
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Deferring the EOI until after the call to RestoreTPL() means that any
callbacks invoked by RestoreTPL() will run with timer interrupt
delivery disabled. If any such callbacks themselves rely on timers to
implement timeout loops, then the callbacks will get stuck in an
infinite loop from which the system will never recover.
This reverts commit 239b50a86 ("OvmfPkg: End timer interrupt later to
avoid stack overflow under load").
Cc: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4162
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
qemu uses the etc/e820 fw_cfg file not only for memory, but
also for reservations. Handle reservations by adding resource
descriptor hobs for them.
A typical qemu configuration has a small reservation between
lapic and flash:
# sudo cat /proc/iomem
[ ... ]
fee00000-fee00fff : Local APIC
feffc000-feffffff : Reserved <= HERE
ffc00000-ffffffff : Reserved
[ ... ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The Hii form is named "MainFormState" and the EFI variable is named
"PlatformConfig". Take into account the different names.
Fixes: aefcc91805 ("OvmfPkg/PlatformDxe: Handle all requests in ExtractConfig and RouteConfig")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
BDS module was moved from DXEFV to newly created BDSFV recently.
Non-universal UEFI payload doesn't support multiple FV, so it failed
to boot since BDS module could not be found.
This patch add BDS back to DXEFV when UNIVERSAL_PAYLOAD is not set.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
PcdConfidentialComputingGuestAttr can be used to check the cc guest
type, including td-guest or sev-guest. CcProbe() can do the same
thing but CcProbeLib should be included in the dsc which uses
AcpiPlatformDxe. The difference between PcdConfidentialComputingGuestAttr
and CcProbe() is that PcdConfidentialComputingGuestAttr cannot be used
in multi-processor scenario but CcProbe() can. But there is no such
issue in AcpiPlatformDxe.
So we use PcdConfidentialComputingGuestAttr instead of CcProbeLib so that
it is simpler.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Fixes problems due to code assuming it runs with frame pointers and thus
updates rbp / ebp registers when switching stacks.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Liming Gao <gaoliming@byosoft.com.cn>
Simplify the code to set memory used by smm page table as RO.
Since memory used by smm page table are in PageTablePool list,
we only need to set all PageTablePool as ReadOnly in smm page
table itself. Also, we only need to flush tlb once after
setting all page table pool as Read Only.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Remove SmmCpuFeaturesAllocatePageTableMemory in this headfile.
This API is not used by PiSmmCpuDxeSmm driver any more. Also
no other files use this API.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Introduce page table pool mechanism for smm page table to simplify
page table memory management and protection. This mechanism has been
used in DxeIpl. The basic idea is to allocate a bunch of continuous
pages of memory in advance, and all future page tables consumption
will happen in those pool instead of system memory.
Since we have centralized page tables, we only need to mark all page
table pools as RO, instead of searching page table memory layer by
layer in smm page table. Once current page table pool has been used
up, another memory pool will be allocated and the new pool will also
be set as RO if current page table memory has been marked as RO.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Copy the function BuildPlatformInfoHob() from OvmfPkg/PlatformPei.
QemuFwCfgLib expect this HOB to be present, or fails to do anything.
InternalQemuFwCfgIsAvailable() from QemuFwCfgPeiLib module will not
check if the HOB is actually present for example and try to use a NULL
pointer.
Fixes: cda98df162 ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported + mQemuFwCfgDmaSupported")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4172
TDVF once accepts memory only by BSP. To improve the boot performance
this patch introduce the multi-core accpet memory. Multi-core means
BSP and APs work together to accept memory.
TDVF leverages mailbox to wake up APs. It is not enabled in MpInitLib
(Which requires SIPI). So multi-core accept memory cannot leverages
MpInitLib to coordinate BSP and APs to work together.
So TDVF split the accept memory into 2 phases.
- AcceptMemoryForAPsStack:
BSP accepts a small piece of memory which is then used by APs to setup
stack. We assign a 16KB stack for each AP. So a td-guest with 256 vCPU
requires 255*16KB = 4080KB.
- AcceptMemory:
After above small piece of memory is accepted, BSP commands APs to
accept memory by sending AcceptPages command in td-mailbox. Together
with the command and accpet-function, the APsStack address is send
as well. APs then set the stack and jump to accept-function to accept
memory.
AcceptMemoryForAPsStack accepts as small memory as possible and then jump
to AcceptMemory. It fully takes advantage of BSP/APs to work together.
After accept memory is done, the memory region for APsStack is not used
anymore. It can be used as other private memory. Because accept-memory
is in the very beginning of boot process and it will not impact other
phases.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4172
TdxMailboxLib is designed only for TDX guest which arch is X64. This
patch set the VALID_ARCHITECTURES of TdxMailboxLib as X64.
Because in the following patches TdxMailboxLib will be included in
PlatformInitLib. While PlatformInitLib is imported by some X64 platforms
(for example AmdSevX64.dsc). So we need a NULL instance of TdxMailboxLib
which VALID_ARCHITECTURES is X64 as well. Based on this consideration
we design TdxMailboxLibNull.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
- Fix typos of "disable".
- Fix typos of "performance".
- Fix missing spaces.
- Use comma instead of period when the sentence continues on the next
line.
- Fix typo of "PERF_CORE_LOAD_IMAGE".
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Fix typo of EFI_INVALID_PARAMETER in Protocol/UsbIo.h by adding a
missing 'R'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
Speed ID Value) indices are shared between Protocol Speed ID DWORD' in
the extended capabilities registers for both USB2 (Full Speed) and USB3
(Super Speed).
An example can be found below:
XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248
The result is edk2 detecting USB2 devices as USB3 devices, which
consequently causes enumeration to fail.
To avoid incorrect detection, check the Compatible Port Offset to find
the starting Port of Root Hubs that support the protocol.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
PSID matching relies on comparing the PSIV against the PortSpeed
value. This patch stops edk2 from checking for a PSIV of 0, as it
is not valid; this reduces the number of register access by
approximately 6 per second.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
During the finalization of Mp initialization before booting into the OS,
depending on whether Mwait is supported or not, AsmRelocateApLoop
places Aps in MWAIT-loop or HLT-loop.
Since paging is necessary for long mode, the original implementation of
moving APs to 32-bit was to disable paging to ensure that the booting
does not crash.
The current modification creates a page table in reserved memory,
avoiding switching modes and reclaiming memory by OS. This modification
is only for 64 bit mode.
More specifically, we keep the AMD logic as the original code flow,
extract and update the Intel-related code, where the APs would stay
in 64-bit, and run in a Mwait or Hlt loop until the OS wake them up.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
AsmRelocateApLoop is replicated for future Intel Logic Extraction,
further brings AP into 64-bit, and enables paging.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add condition to return success if mUartCount is greater
than zero in SerialPortInitialize() to avoid filling mUartInfo
with the same hob data when SerialPortInitialize() is called
multiple times. Also add proper conditions in SerialPortRead
function to read the data properly from multiple UART's.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Signed-off-by: Kavya <k.kavyax.sravanthi@intel.com>
For some use cases, Redfish host interface table relies on
the certain EFI protocols installation at the driver connection.
Redfish host interface DXE driver is not able to build the
SMBIOS type 42h record at driver entry point. This patch adds
the mechanism in Redfish host interface DXE driver to listen
to EFI protocol installed by platform library that indicates
the necessary information is ready for building SMBIOS 42h
record.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
In the commit 4f173db8b4 "OvmfPkg/PlatformInitLib: Add functions for
EmuVariableNvStore", it introduced a PlatformValidateNvVarStore() function
for checking the integrity of NvVarStore.
In some cases when the VariableHeader->StartId is VARIABLE_DATA, the
VariableHeader->State is not just one of the four primary states:
VAR_IN_DELETED_TRANSITION, VAR_DELETED, VAR_HEADER_VALID_ONLY, VAR_ADDED.
The state may combined two or three states, e.g.
0x3C = (VAR_IN_DELETED_TRANSITION & VAR_ADDED) & VAR_DELETED
or
0x3D = VAR_ADDED & VAR_DELETED
When the variable store has those variables, system booting/rebooting will
hangs in a ASSERT:
NvVarStore Variable header State was invalid.
ASSERT
/mnt/working/source_code-git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
((BOOLEAN)(0==1))
Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
saw some variables which have 0x3C or 0x3D state in store.
e.g.
UpdateVariable(), VariableName=BootOrder
L1871, State=0000003F <-- VAR_ADDED
State &= VAR_DELETED=0000003D
FlushHobVariableToFlash(), VariableName=BootOrder
...
UpdateVariable(), VariableName=InitialAttemptOrder
L1977, State=0000003F
State &= VAR_IN_DELETED_TRANSITION=0000003E
L2376, State=0000003E
State &= VAR_DELETED=0000003C
FlushHobVariableToFlash(), VariableName=InitialAttemptOrder
...
UpdateVariable(), VariableName=ConIn
L1977, State=0000003F
State &= VAR_IN_DELETED_TRANSITION=0000003E
L2376, State=0000003E
State &= VAR_DELETED=0000003C
FlushHobVariableToFlash(), VariableName=ConIn
...
So, only allowing the four primary states is not enough. This patch changes
the falid states list (Follow Jiewen Yao's suggestion):
1. VAR_HEADER_VALID_ONLY (0x7F)
- Header added (*)
2. VAR_ADDED (0x3F)
- Header + data added
3. VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E)
- marked as deleted, but still valid, before new data is added. (*)
4. VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED (0x3C)
- deleted, after new data is added.
5. VAR_ADDED & VAR_DELETED (0x3D)
- deleted directly, without new data.
(*) means to support surprise shutdown.
And removed (VAR_IN_DELETED_TRANSITION) and (VAR_DELETED) because they are
invalid states.
v2:
Follow Jiewen Yao's suggestion to add the following valid states:
VAR_ADDED & VAR_DELETED (0x3D)
VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E)
VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED (0x3C)
and removed the following invalid states:
VAR_IN_DELETED_TRANSITION
VAR_DELETED
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The following PCDs have no value in UefiPayloadPkg.dsc
and they can not pass the Ecc tool check, so assign
the default values the same as they are in *.dec file.
1. gEfiMdeModulePkgTokenSpaceGuid.PcdAriSupport
2. gEfiMdeModulePkgTokenSpaceGuid.PcdMrIovSupport
3. gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSuppor
4. gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSystemPageSize
5. gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
6. gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode
7. gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress
8. gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize
Reviewed-by: Gua Guo <gua.guo@intel.com>
Signed-off-by: jdzhang <jdzhang@kunluntech.com.cn>
Allow object to specify the name of processor and processor container
nodes and the UID of processor containers.
This allows these to be more accurately referenced from other tables.
For example for the _PSL method or the UID in the APMT table.
The UID and Name for processor container may be different as if the
intention is to set names as the corresponding affinity level the UID
may need to be different if there are multiple levels of containers.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4171
A typical QEMU fw_cfg read bytes with IOMMU for td guest is that:
(QemuFwCfgReadBytes@QemuFwCfgLib.c is the example)
1) Allocate DMA Access buffer
2) Map actual data buffer
3) start the transfer and wait for the transfer to complete
4) Free DMA Access buffer
5) Un-map actual data buffer
In step 1/2, Private memories are allocated, converted to shared memories.
In Step 4/5 the shared memories are converted to private memories and
accepted again. The final step is to free the pages.
This is time-consuming and impacts td guest's boot perf (both direct boot
and grub boot) badly.
In a typical grub boot, there are about 5000 calls of page allocation and
private/share conversion. Most of page size is less than 32KB.
This patch allocates a memory region and initializes it into pieces of
memory with different sizes. A piece of such memory consists of 2 parts:
the first page is of private memory, and the other pages are shared
memory. This is to meet the layout of common buffer.
When allocating bounce buffer in IoMmuMap(), IoMmuAllocateBounceBuffer()
is called to allocate the buffer. Accordingly when freeing bounce buffer
in IoMmuUnmapWorker(), IoMmuFreeBounceBuffer() is called to free the
bounce buffer. CommonBuffer is allocated by IoMmuAllocateCommonBuffer
and accordingly freed by IoMmuFreeCommonBuffer.
This feature is tested in Intel TDX pre-production platform. It saves up
to hundreds of ms in a grub boot.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Rely on CcProbe() to identify when running on TDX so that ACPI tables
can be retrieved differently for Cloud Hypervisor. Instead of relying on
the PVH structure to find the RSDP pointer, the tables are individually
passed through the HOB.
Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Rely on the CcProbe() function to identify when running on TDX. This
allows the firmware to follow a different codepath for Cloud Hypervisor,
which means it doesn't rely on PVH to find out about memory below 4GiB.
instead it falls back onto the CMOS to retrieve that information.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4186
Commit 079a58276b ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret
area as reserved") marked the launch secret area itself (1 page) as
reserved so the guest OS can use it during the lifetime of the OS.
However, the address and size of the secret area held in the
CONFIDENTIAL_COMPUTING_SECRET_LOCATION struct are declared as STATIC in
OVMF (in AmdSev/SecretDxe); therefore there's no guarantee that it will
not be written over by OS data.
Fix this by allocating the memory for the
CONFIDENTIAL_COMPUTING_SECRET_LOCATION struct with the
EfiACPIReclaimMemory memory type to ensure the guest OS will not reuse
this memory.
Fixes: 079a58276b ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret ...")
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
When running under SEV-ES, a page of shared memory is allocated for the
GHCB during the SEC phase at address 0x809000. This page of memory is
eventually passed to the OS as EfiConventionalMemory. When running
SEV-SNP, this page is not PVALIDATE'd in the RMP table, meaning that if
the guest OS tries to access the page, it will think that the host has
voilated the security guarantees and will likely crash.
This patch validates this page immediately after EDK2 switches to using
the GHCB page allocated for the PEI phase.
This was tested by writing a UEFI application that reads to and writes
from one byte of each page of memory and checks to see if a #VC
exception is generated indicating that the page was not validated.
Fixes: 6995a1b79b ("OvmfPkg: Create a GHCB page for use during Sec phase")
Signed-off-by: Adam Dunlap <acdunlap@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4179
According to UEFI Spec 2.10 it is supposed to return the mapping from PCR
index to CC MR index:
//
// In the current version, we use the below mapping for TDX:
//
// TPM PCR Index | CC Measurement Register Index | TDX-measurement register
// -----------------------------------------------------------------------
// 0 | 0 | MRTD
// 1, 7 | 1 | RTMR[0]
// 2~6 | 2 | RTMR[1]
// 8~15 | 3 | RTMR[2]
In the current implementation TdMapPcrToMrIndex returns the index of RTMR,
not the MR index.
After fix the spec unconsistent, other related codes are updated
accordingly.
1) The index of event log uses the input MrIndex.
2) MrIndex is decreated by 1 before it is sent for RTMR extending.
Cc: Erdem Aktas <erdemaktas@google.com> [ruleof2]
Cc: James Bottomley <jejb@linux.ibm.com> [jejb]
Cc: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
Cc: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
Cc: Arti Gupta <ARGU@microsoft.com>
Reported-by: Arti Gupta <ARGU@microsoft.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Remove global variables, store the state in PlatformInfoHob instead.
Probing for fw_cfg happens on first use, at library initialization
time the Hob might not be present yet.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Move the code to a new QemuFwCfgProbe() function. Use direct Io*() calls
instead of indirect QemuFwCfg*() calls to make sure we don't get
recursive calls. Also simplify CC guest detection.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Use PlatformInfoHob->FeatureControlValue instead.
OnMpServicesAvailable() will find PlatformInfoHob using
GetFirstGuidHob() and pass a pointer to the WriteFeatureControl
callback.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable. Let
BuildPlatformInfoHob() allocate and return PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in S3Verification() and
Q35BoardVerification() functions. Pass a pointer to the PlatformInfoHob
instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in NoexecDxeInitialization()
function. Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in MemTypeInfoInitialization()
function. Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in PublishPeiMemory()
and GetPeiMemoryCap() functions. Pass a pointer to the PlatformInfoHob
instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in
Q35TsegMbytesInitialization() and
Q35SmramAtDefaultSmbaseInitialization() ) functions.
Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in PeiFvInitialization()
function. Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in AmdSevInitialize()
and AmdSevEsInitialize() functions. Pass a pointer to the
PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
_LPI Revision should be 0 per the ACPI 6.5 specification.
"The revision number of the _LPI object. Current revision is 0."
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
For different compilers, both IA32 and X64 can use
Ia32/CpuFlushTlbGcc.c, which is C code (no inline assembly code).
To simplify, remove other assemly file for CpuFlushTlb,
and rename Ia32/CpuFlushTlbGcc.c to X86CpuFlushTlb.c.
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Update Shell Protocol EfiShellGetMapFromDevicePath() to not
set the end if the device path if it is already an end of
entire device path. This removes a write operation that can
cause failures if the Device Path Protocol is mapped to
read-only memory. In general Device Path Protocols should not
be modified unless the API explicitly states that the device
path is modified.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Add a new parser for the Arm Performance Monitoring Unit Table.
The APMT table describes the properties of PMU support
implemented by components in an Arm-based system.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Instead of using hard-coded strings ("0.0.0" for BiosVersion etc)
which is mostly useless read the PCDs (PcdFirmwareVendor,
PcdFirmwareVersionString and PcdFirmwareReleaseDateString) and
build the string table dynamuically at runtime.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
According to the Intel GHCI specification document section 2.4.1, the
goal for instructions that do not have a corresponding TDCALL is for the
handler to treat the instruction as a NOP.
INVD does not have a corresponding TDCALL. This patch makes the #VE
handler treat INVD as a NOP.
Signed-off-by: Ryan Afranji <afranji@google.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The page allocator code in CoreFindFreePagesI() uses a mask derived from
its UINTN Alignment argument to align the descriptor end address of a
MEMORY_MAP entry to the requested alignment, in order to check whether
the descriptor covers enough sufficiently aligned area to satisfy the
request.
However, on 32-bit architectures, 'Alignment' is a 32-bit type, whereas
DescEnd is a 64-bit type, and so the resulting operation performed on
the end address comes down to masking with 0xfffff000 instead of the
intended 0xffffffff_fffff000. Given the -1 at the end of the expression,
the resulting address is 0xffffffff_fffffffff for any descriptor that
ends on a 4G aligned boundary, and this is certainly not what was
intended.
So cast Alignment to UINT64 to ensure that the mask has the right size.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Record Argc, Argv and Envp in EmuThunk Ppi so that other modules
can use these fields to change behavior depends on boot parameters
or environment.
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The persistent memory is for PEIM to use, and won't lose during cold
or warm reset. PcdPersistentMemorySize is only used by WinHost.c,
other modules can check the persistent memory size using the field
PersistentMemorySize.
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
When build in DEBUG, the code asserts that 5LPage support is there
when the physical address width is larger than 48.
In a RELEASE build it will just force LA57 to 1 in CR4
even if CPUID(7).ECX[16] says it is not supported.
UefiCpuPkg: Bug fix in 5LPage handling
The hang (in the ASSERT) in DEBUG is not warranted as there are
legal configurations with CPUID(7).ECX[16](==LA57)=0
and with a physical address width of larger than 48 (like 52).
This is also supported by this code:
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c#L221
There (as long as physical address width is smaller or equal to 52)
any address width above 48 will be reduced to 48 and the
system can and will work without 5LPaging.
The forced setting of LA57 in CR4 (in the absence of LA57 in CPUID(7).ECX)
is a spec violation and should not happen.
Hence the proposed fix
a) removes the assert.
b) only returns TRUE from Is5LevelPagingNeeded if 5LPaging is actually
supported by HW.
Signed-off-by: Robert Guenzel <robert.guenzel@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4173
Due to more core count increasement, it's hard to reflect all APs
state via AP bitvector support in the register. Actually, SMM CPU
driver doesn't need to check each AP state to know all CPUs in SMI
or not, one alternative method is to check the SMM Delayed & Blocked
AP Count number:
APs in SMI + Blocked Count + Disabled Count >= All supported Aps
(code comments explained why can be > All supported Aps)
With above change, the returned value of "SmmRegSmmEnable" &
"SmmRegSmmDelayed" & "SmmRegSmmBlocked" from SmmCpuFeaturesLib
should be the AP count number within the existing CPU package.
For register that return the bitvector state, require
SmmCpuFeaturesGetSmmRegister() returns count number of all bit per
logical processor within the same package.
For register that return the AP count, require
SmmCpuFeaturesGetSmmRegister() returns the register value directly.
v3:
- Refine the coding style
v2:
- Rename "mPackageBspInfo" to "mPackageFirstThreadIndex"
- Clarify the expected value of "SmmRegSmmEnable" & "SmmRegSmmDelayed" &
"SmmRegSmmBlocked" returned from SmmCpuFeaturesLib.
- Thread: https://edk2.groups.io/g/devel/message/96722
v1:
- Thread: https://edk2.groups.io/g/devel/message/96671
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
EmulatorPkg/Win calls LoadLibraryEx() when the corresponding DLL file
is found for each PEIM or DXE driver. The module entry point is
changed to point to the entry point from the DLL. This helps to
notify Visual Studio that a new windows module is loaded and
corresponding symbol parsing is performed for source level debugging.
But entry point from the DLL is only executed when the module is not
loaded by AddModHandle().
When reset happens, we need to clear the DLL loading so that in next
boot the module can be loaded again by AddModHandle().
Without this patch, source level debugging doesn't work after reset.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
With the pending commit of UsbNetworkPkg, it will become common for
UsbBulkTransfer calls to timeout, given that the drivers are called from
MnpSystemPoll every MNP_SYS_POLL_INTERVAL milliseconds: the drivers
check for network packets by calling UsbBulkTransfer with a timeout of
1ms.
Avoid console spam by moving DEBUG messages that occur each time a bulk
transfer request times out from DEBUG_ERROR to DEBUG_VERBOSE, for both
EHCI and XHCI drivers.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Update ReadfishPkg.dec to remove PrivateInclude from the
[Includes.Common.Private] section. The PrivateInclude directory
does not contain any include files, and the PrivateInclude/Crt
include path remaining in the [Includes.Common.Private] section
providing the include path required to access the CRT related
include files by components within the RedfishPkg.
Without this update, there are two forms of #include statements
that can be used to include the CRT related include files.
Include files should only be available using one form of
#include statements.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
When shutdown is requested, WinHost exits.
Otherwise, WinHost re-runs from SEC.
Tested no extra memory consumption with multiple resets in PEI.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
In EmulatorPkg/Win, SEC and PEI_CORE are loaded to memory allocated
through VirtualAlloc. Though the corresponding DLL files are loaded
and the entry points in DLL files are executed. The loading to memory
allocated through VirtualAlloc is for the case when the DLL files can
not be loaded.
Actually some PEIMs like PcdPeim which are loaded before
"physical" RAM is discovered, they are executing in the original
location (FV) like XIP module in real platform.
The SEC and PEI_CORE can follow the same mechanism.
So, the VirtualAlloc call is removed.
This is to prepare the "reset" support to avoid additional OS memory
consumption when reset happens.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com
Move the "physical" RAM allocation from WinPeiAutoScan
to main() entrypoint.
This is to prepare the changes for "reset" support.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Fix a typo of "RedfishLibs.dsc.inc" in RedfishLibs.dsc.inc, and correct
the name of the .fdf.inc filename in Redfish.fdf.inc.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
There should be a check that the FV HeaderLength cannot be an odd
number. Otherwise in the following CalculateSum16 there would be an
ASSERT.
In ValidateFvHeader@QemuFlashFvbServicesRuntimeDxe/FwBlockServices.c
there a is similar check to the FwVolHeader->HeaderLength.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
There was previously a lower bound on the value of TickPeriod such that
it couldn't be less than 10 us. However, that was removed from the PI
Specification in the 1.0 errata released in 2007. From the revision
history:
"M171 Remove 10 us lower bound restriction for the TickPeriod in the
Metronome"
Update the documentation of TickPeriod in MetronomeDxe/Metronome.c to
remove mention of the lower bound.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
DP command should be able to parse the FPDT ACPI table and dump
the ResetEnd which was logged at the beginning of the firmware
image execution. So that DP can calculate SEC phase time duration
start from the beginning of firmware image execution.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: zhenhuay <zhenhua.yang@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Enables dependabot in this repo so we can better alerted when
dependency updates are available.
This GitHub action will automatically create pull requests and
summarize the dependency details. Because it is a pull request,
the CI system will validate the dependency update in the pull
request.
Configures dependabot for:
1. PIP module updates
2. GitHub action updates
The maintainers/reviewers of the .github directory were added as
pull request reviewers so they can be notified when the pull request
is available.
Note to Maintainers:
After this change is committed, PRs from dependabot will be
automatically created in the edk2 repo. Never set the 'push' label
directly on these PRs. If a dependency identified by dependedabot
looks like one that should be updated in the edk2 repo, then copy
the PR generated by dependabot to your personal fork and update the
commit message to follow the edk2 commit message requirements and
send as a normal code review.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Remove ASSERTs in ArmTrngLibConstructor() that prevent from
booting on DEBUG builds.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4140
Some implementations may need to keep the initial Reset code to be
separated out from rest of the code.This request is to add padding at
lower 4K region below 4 GB which will result having only few jmp
instructions and data at that region.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Duggapu Chinni B <chinni.b.duggapu@intel.com>
ArmTrngLib crashes when run in DEBUG mode due to the fact that it passed
the [truncated] GUID value to a DEBUG() print statement instead of a
pointer to the GUID which is what the %g conversion expects.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4146
Update edk2-pytool-library to version 0.12.0 that adds support for
the environment variable PYTOOL_TEMPORARILY_IGNORE_NESTED_EDK_PACKAGES
that can be set to true to ignore nested packages instead of breaking
the build with an exception. Nested packages are not allowed by the
edk2 specifications. This environment variable allows pytools to run
with reduced functionality if nested packages are present giving
downstream consumers of edk2 that use pytools time to resolve the use
of nested packages and restore all features of pytools.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
The query cpp/conditionallyuninitializedvariable was initially
enabled with the CodeQL code because work was in progress on those
changes. The results were filtered out so CodeQL passed so we could
verify the CodeQL workflow without impacting CI results.
This change allows error severity messages and substitutes that query
with two queries that do not return failures. This allows these
queries to find future problems and prepares the CodeQL workflow to
catch future failures as queries are enabled.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Fixes issues found with the cpp/wrong-type-format-argument CodeQL
rule in BaseTools.
Reference:
https://cwe.mitre.org/data/definitions/686.html
The following CodeQL errors are resolved:
1. Check failure on line 1115 in
BaseTools/Source/C/EfiRom/EfiRom.c
- This argument should be of type 'int' but is of type 'char *'.
- This argument should be of type 'int' but is of type 'signed
char *'.
2. Check failure on line 359 in
BaseTools/Source/C/GenFw/Elf32Convert.c
- This argument should be of type 'CHAR8 *' but is of type
'unsigned int'.
3. Check failure on line 1841 in
BaseTools/Source/C/GenFw/Elf64Convert.c
- This argument should be of type 'unsigned int' but is of type
'unsigned long long'.
4. Check failure on line 1871 in
BaseTools/Source/C/GenFw/Elf64Convert.c
- This argument should be of type 'unsigned int' but is of type
'unsigned long long'.
5. Check failure on line 2400 in
BaseTools/Source/C/GenFv/GenFvInternalLib.c
- This argument should be of type 'unsigned long long' but is of
type 'unsigned int'.
6. Check failure on line 1099 in
BaseTools/Source/C/GenFw/Elf64Convert.c
- This argument should be of type 'CHAR8 *' but is of type
'unsigned int'.
7. Check failure on line 1098 in
BaseTools/Source/C/GenSec/GenSec.c
- This argument should be of type 'CHAR8 *' but is of type
'char **'.
8. Check failure on line 911 in
BaseTools/Source/C/GenSec/GenSec.c
- This argument should be of type 'CHAR8 *' but is of type
'char **'.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
This library supports a Boot Services table library implementation
that allows code dependent upon UefiBootServicesTableLib to operate
in an isolated execution environment such as within
the context of a host-based unit test framework.
The unit test should initialize the Boot Services database with any
required elements (e.g. protocols, events, handles, etc.) prior to
the services being invoked by code under test.
It is strongly recommended to clean any global databases (e.g.
protocol, event, handles, etc.) after every unit test so the tests
execute in a predictable manner from a clean state.
This library is being moved here from PrmPkg so it can be made more
generally available to other packages and improved upon for others
use.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The EFI_RNG_PROTOCOL published by RngDxe has been updated to
implement the EFI_RNG_ALGORITHM_RAW using the Arm TRNG interface
to provide access to entropy.
Therefore, enable EFI_RNG_PROTOCOL for the Kvmtool guest/virtual
firmware.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
Add RngDxe support for Arm. This implementation uses the ArmTrngLib
to support the RawAlgorithm and doens't support the RNDR instruction.
To re-use the RngGetRNG(), RngGetInfo() and FreeAvailableAlgorithms()
functions, create Arm/AArch64 files which implement the arch specific
function GetAvailableAlgorithms(). Indeed, FEAT_RNG instruction is not
supported on Arm.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
PcdCpuRngSupportedAlgorithm should allow to identify the the algorithm
used by the RNDR CPU instruction to generate a random number.
Add a debug warning if the Pcd is not set.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
RawAlgorithm is used to provide access to entropy that is suitable
for cryptographic applications. Therefore, add RawAlgorithm support
that provides access to entropy using the ArmTrngLib.
Also remove unused UefiBootServicesTableLib library inclusion
and Status variable.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
RngGetBytes() relies on the RngLib. The RngLib might use the RNDR
instruction if the FEAT_RNG feature is present. RngGetInfo and
RngGetRNG both must check that RngGetBytes() is working before
advertising/using it.
To do so, allocate an array storing the available algorithms.
The Rng algorithm at the lowest index will be the default Rng
algorithm. The array is shared between RngGetInfo and RngGetRNG.
This array is allocated when the driver is loaded, and freed
when unloaded.
This patch also prevents from having PcdCpuRngSupportedAlgorithm
let to a zero GUID, but let the possibility to have no valid Rng
algorithm in such case.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
This patch:
-Update RngGetBytes() documentation to align the function
definition and declaration.
-Improve input parameter checking. Even though 'This'
it is not used, the parameter should always point to the
current EFI_RNG_PROTOCOL.
-Removes TimerLib inclusion as unused.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
RngGetInfo() is one of the 2 functions of the EFI_RNG_PROTOCOL.
RngGetInfo() is currently a mere wrapper around
ArchGetSupportedRngAlgorithms() which is implemented differently
depending on the architecture used.
RngGetInfo() does nothing more than calling
ArchGetSupportedRngAlgorithms(). So remove it, and let RngGetInfo()
be implemented differently according to the architecture.
This follows the implementation of the other function of the
EFI_RNG_PROTOCOL, RngGetRNG().
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
gEfiRngAlgorithmSp80090Ctr256Guid was used as the default algorithm
in RngGetRNG(). The commit below set the default algorithm to
PcdCpuRngSupportedAlgorithm, which is a zero GUID by default.
As the Pcd value is not defined for any platform in the edk2-platfoms
repository, assume it was an error and go back to the first version,
using gEfiRngAlgorithmSp80090Ctr256Guid.
Fixes: 4e5ecdbac8 ("SecurityPkg: Add support for RngDxe on AARCH64")
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
Rename RdRandGenerateEntropy() to GenerateEntropy() to provide a
common interface to generate entropy on other architectures.
GenerateEntropy() is intended to generate high quality entropy.
Also move the definition to RngDxeInternals.h
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator Firmware, Interface 1.0,
Platform Design Document
(https://developer.arm.com/documentation/den0098/latest/)
defines an interface between an Operating System (OS) executing
at EL1 and Firmware (FW) exposing a conditioned entropy source
that is provided by a TRNG back end.
The conditioned entropy, that is provided by the Arm TRNG interface,
is commonly used to seed deterministic random number generators.
This patch adds an ArmTrngLib library that implements the Arm TRNG
interface.
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator Firmware, Interface 1.0,
Platform Design Document
(https://developer.arm.com/documentation/den0098/latest/)
defines an interface between an Operating System (OS) executing
at EL1 and Firmware (FW) exposing a conditioned entropy source
that is provided by a TRNG back end.
New function IDs have been defined by the specification for
accessing the TRNG services. Therefore, add these definitions
to the Arm standard SMC header.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The Arm True Random Number Generator (TRNG) library defines an
interface to access the entropy source on a platform. On platforms
that do not have access to an entropy source, a NULL instance of
the TRNG library may be useful to satisfy the build dependency.
Therefore, add a NULL instance of the Arm TRNG library.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The NIST Special Publications 800-90A, 800-90B and 800-90C
provide recommendations for random number generation. The
NIST 800-90C, Recommendation for Random Bit Generator (RBG)
Constructions, defines the GetEntropy() interface that is
used to access the entropy source. The GetEntropy() interface
is further used by Deterministic Random Bit Generators (DRBG)
to generate random numbers.
The Arm True Random Number Generator (TRNG) library defines an
interface to access the entropy source on a platform, following
the 'Arm True Random Number Generator Firmware Interface'
specification.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Sort the section containing HVC/SMC libraries prior to
adding new libraries in this specific section.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
The ArmMonitorLib provides an abstract interface to issue
an HyperVisor Call (HVC) or System Monitor Call (SMC) depending
on the default conduit.
The PcdMonitorConduitHvc PCD allows to select the default conduit.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The ArmMonitorLib provides an abstract interface to issue
an HyperVisor Call (HVC) or System Monitor Call (SMC) depending
on the default conduit.
The PcdMonitorConduitHvc PCD allows to select the default conduit.
The new library relies on the ArmHvcLib and ArmSmcLib libraries.
A Null instance of these libraries can be used for the unused conduit.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Define a PCD 'PcdMonitorConduitHvc' to select the conduit to use for
monitor calls. PcdMonitorConduitHvc is defined as FALSE by default,
meaning the SMC conduit is enabled as default.
Adding PcdMonitorConduitHvc allows selection of HVC conduit to be used
by virtual firmware implementations.
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The NorFlashDxe driver in ArmPlatformPkg was shared between development
platforms built by ARM Ltd, and virtual platforms that were once modeled
after Versatile Express, but have very little in common with actual bare
metal implementations.
Both sides have migrated to a domain specific version of the driver, so
we can retire the old one.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4114
FSP specification supports input UPD as NULL cases which FSP will
use built-in UPD region instead.
FSP should not return INVALID_PARAMETER in such cases.
In FSP-T entry point case, the valid FSP-T UPD region pointer will be
passed to platform FSP code to consume.
In FSP-M and FSP-S cases, valid UPD pointer will be decided when
updating corresponding pointer field in FspGlobalData.
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Ted Kuo <ted.kuo@intel.com>
BZ# 4093: Abstract SmmCpuFeaturesLib for sharing common code
This change stripped away the code that can be
shared with other archs or vendors from Intel
implementation and put in to the common file,
leaves the Intel X86 implementation in the
IntelSmmCpuFeatureLib. Also updates the header
file and INF file.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Abdul Lateef Attar <abdattar@amd.com>
Cc: Garrett Kirkendall <garrett.kirkendall@amd.com>
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
BZ# 4093: Abstract SmmCpuFeaturesLib for sharing common code
Rename SmmCpuFeaturesLiCommon.c to
IntelSmmCpuFeaturesLib, because it was developed
specifically for Intel implementation. The code
that can be shared by other archs or vendors
will be stripped away and put in the common
file in the next patch.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Abdul Lateef Attar <abdattar@amd.com>
Cc: Garrett Kirkendall <garrett.kirkendall@amd.com>
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The following tables can now be generated by the DynamicTablesPkg:
- PCCT
- PPTT
- SRAT
Update the documentation accordingly.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
For Pcc address space, the AccessSize field of a Register is
used to delcare the Pcc Subspace Id. This Id can be up to 256.
Cf. ACPI 6.4, s14.7 Referencing the PCC address space
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Platform Communication Channel Table (PCCT) generator collates
the relevant information required for generating a PCCT table from
configuration manager using the configuration manager protocol.
The DynamicTablesManager then install the PCCT table.
From ACPI 6.4, s14 PLATFORM COMMUNICATIONS CHANNEL (PCC):
The platform communication channel (PCC) is a generic mechanism
for OSPM to communicate with an entity in the platform.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Introduce the following CmObj in the ArmNameSpaceObjects:
- CM_ARM_MAILBOX_REGISTER_INFO
- CM_ARM_PCC_SUBSPACE_CHANNEL_TIMING_INFO
- CM_ARM_PCC_SUBSPACE_GENERIC_INFO
- CM_ARM_PCC_SUBPSACE_TYPE0_INFO
- CM_ARM_PCC_SUBPSACE_TYPE1_INFO
- CM_ARM_PCC_SUBPSACE_TYPE2_INFO
- CM_ARM_PCC_SUBPSACE_TYPE3_INFO
- CM_ARM_PCC_SUBPSACE_TYPE4_INFO
- CM_ARM_PCC_SUBPSACE_TYPE5_INFO
These objects allow to describe mailbox registers, pcc timings
and PCCT subspaces. They prepare the enablement of a PCCT generator.
Also add the CmObjParsers associated to each object.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The second model of the _PRT object is used. Indeed:
- the interrupts described are not re-configurable
- OSes are aware of the polarity of PCI legacy interrupts,
so there is no need to accurately describe the polarity.
Also, fix a comment for the CM_ARM_PCI_INTERRUPT_MAP_INFO obj.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit 13136cc311 ("DynamicTablesPkg: FdtHwInfoParserLib:
Parse Pmu info")
adds support for pmu parsing. Thus, remove the wrong comment.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit 691c5f7762 ("DynamicTablesPkg: Deprecate Crs specific methods
in AmlLib")
deprecates some APIs. Finally remove them.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add missing fields to the following CmObjParser objects:
- EArmObjGicDInfo
- EArmObjCacheInfo
and fix wrong formatting of:
- EArmObjLpiInfo
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The CmObjParsers of the following objects was inverted, probably
due to a wrong ordering placement in the file defining the structures:
-EArmObjGTBlockTimerFrameInfo
-EArmObjPlatformGTBlockInfo
Assign the correct parser for each object, and re-order the
structures in the file defining them.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit 0d23c447d6 ("DynamicTablesPkg: Add support to specify FADT
minor revision")
adds new 'MinorRevision' field to CM_STD_OBJ_ACPI_TABLE_INFO.
Reflect the change in this patch to the CmObjectParser.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
commit de200b7e2c ("DynamicTablesPkg: Update ArmNameSpaceObjects for
IORT Rev E.d")
adds new CmObj structures and fields to the ArmNameSpaceObjects.
Update the CmObjectParser accordingly.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add a PrintString to print strings in the CmObjParser.
String must be NULL terminated and no buffer overrun check
is done by this function.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In C, the 'long long' types are 64-bits. The 'll' printf length
specifier should be used to pring these values. Just '%x' allows to
print values that are on 16-bits or more. Use that instead.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4100
ScsiDiskDxe driver updates ControllerNameTable with common string
"SCSI Disk Device" for all SCSI disks. Due to this, when multiple
SCSI disk devices connected, facing difficulty in identifying correct SCSI
disk device. As per SCSI spec, standard Inquiry Data is having the fields
to know Vendor and Product information. Updated "ControllerNameTable" with
Vendor and Product information. So that, device specific name can be
retrieved using ComponentName protocol.
Cc: Vasudevan Sambandan <vasudevans@ami.com>
Cc: Sundaresan Selvaraj <sundaresans@ami.com>
Signed-off-by: Cheripally Gopi <gopic@ami.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Disable/Restore HpetTimer before and after running the Dxe
CpuExceptionHandlerLib unit test module. During the UnitTest, a
new Idt is initialized for the test. There is no handler for timer
intrrupt in this new idt. After the test module, HpetTimer does
not work any more since the comparator value register and main
counter value register for timer does not match. To fix this issue,
disable/restore HpetTimer before and after Unit Test if HpetTimer
driver has been dispatched. We don't need to send Apic Eoi in this
unit test module.When disabling timer, after RaiseTPL(), if there
is a pending timer interrupt, bit64 of Interrupt Request Register
(IRR) will be set to 1 to indicate there is a pending timer
interrupt. After RestoreTPL(), CPU will handle the pending
interrupt in IRR.Then TimerInterruptHandler calls SendApicEoi().
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Migrate to the virt specific NOR flash driver as the ArmPlatformPkg is
going away.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Switch to the virt specific NorFlashDxe driver implementation that was
added recently.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
NOR flash emulation under KVM involves switching between two modes,
where array mode is backed by a read-only memslot, and programming mode
is fully emulated, i.e., the memory region is not backed by anything,
and the faulting accesses are forwarded to the VMM by the hypervisor,
which translates them into NOR flash programming commands.
Normally, we are limited to the use of device attributes when mapping
such regions, given that the programming mode has MMIO semantics.
However, when running under KVM, the chosen memory attributes only take
effect when in array mode, since no memory mapping exists otherwise.
This means we can tune the memory mapping so it behaves a bit more like
a ROM, by switching to EFI_MEMORY_WC attributes. This means we no longer
need a special CopyMem() implementation that avoids unaligned accesses
at all cost.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Currently, when dealing with small updates that can be written out
directly (i.e., if they only involve clearing bits and not setting bits,
as the latter requires a block level erase), we iterate over the data
one word at a time, read the old value, compare it, write the new value,
and repeat, unless we encountered a value that we cannot write (0->1
transition), in which case we fall back to a block level operation.
This is inefficient for two reasons:
- reading and writing a word at a time involves switching between array
and programming mode for every word of data, which is
disproportionately costly when running under KVM;
- we end up writing some data twice, as we may not notice that a block
erase is needed until after some data has been written to flash.
So replace this sequence with a single read of up to twice the buffered
write maximum size, followed by one or two buffered writes if the data
can be written directly. Otherwise, fall back to the existing block
level sequence, but without writing out part of the data twice.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
NorFlashWriteSingleWord() switches into programming mode and back into
array mode for every single word that it writes. Under KVM, this
involves tearing down the read-only memslot, and setting it up again,
which is costly and unnecessary.
Instead, move the array mode switch into the callers, and only make the
switch when the writing is done.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
We never boot from NOR flash, and generally rely on the firmware volume
PI protocols to expose the contents. So drop the block I/O protocol
implementation from VirtNorFlashDxe.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
We only use NOR flash for firmware volumes, either for executable images
or for the variable store. So we have no need for exposing disk I/O on
top of the NOR flash partitions so let's remove it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
We inherited a feature from the ArmPlatformPkg version of this driver
that never gets enabled. Let's remove it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
QEMU's mach-virt is loosely based on ARM Versatile Express, and inherits
its NOR flash driver, which is now being used on other QEMU emulated
architectures as well.
In order to permit ourselves the freedom to optimize this driver for
use under KVM emulation, let's clone it into OvmfPkg, so we have a
version we can hack without the risk of regressing bare metal platforms.
The cloned version is mostly identical to the original, but it depends
on the newly added VirtNorFlashPlatformLib library class instead of the
original one from ArmPlatformPkg. Beyond that, only cosmetic changes
related to #include order etc were made.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Create a new library class in Ovmf that duplicates the existing
NorFlashPlatformLib, but which will be tied to the VirtNorFlashDxe
driver that will be introduced in a subsequent patch. This allows us to
retire the original from ArmPlatformPkg.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Clang does not support undoing the effects of -mstrict-align by passing
the -mno-strict-align counterpart, so appending the latter to the
compiler's XIPFLAGS does not work. Instead, clear the flags entirely.
This also removes -mgeneral-regs-only, but this is fine - we can
tolerate SIMD codegen in PEIMs or BASE libraries as they run with the
MMU and caches enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The TPM discovery code relies on a dynamic PCD to communicate the TPM
base address to other components. But no other code relies on dynamic
PCDs in the PEI phase so let's drop the PCD PEIM when TPM support is not
enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Due to the way we inherited the formerly fixed PCDs to describe the
system memory base and size from ArmPlatformPkg, we ended up with a
MemoryInit PEIM that relies on dynamic PCDs to communicate the size of
system memory between the constructor of one of its library dependencies
and the core module. This is unnecessary, and forces us to incorporate
the PCD PEIM as well, for no good reason. So instead, let's use a HOB.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Some PEIMs register for shadow execution explicitly, but others exist
that don't care and can happily execute in place. Since the emulated NOR
flash is just RAM, shadowing has no performance benefits so let's only
do this if needed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The variable PEIM is included in the build but its runtime prerequisites
are absent so it is never dispatched. Just drop it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Now that we have all the pieces in place, switch the AArch64 version of
ArmVirtQemu to a mode where the first thing it does out of reset is
enable a preliminary ID map that covers the NOR flash and sufficient
DRAM to create the UEFI page tables as usual.
The advantage of this is that no manipulation of memory occurs any
longer before the MMU is enabled, which removes the need for explicit
coherency management, which is cumbersome and bad for performance.
It also means we no longer need to build all components that may execute
with the MMU off (including BASE libraries) with strict alignment.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
In order to allow booting with the MMU and caches enabled really early,
we need to ensure that the code that populates the page tables can
access those page tables with the statically defined ID map active.
So let's put the permanent PEI RAM in the first 128 MiB of memory, which
we will cover with this initial ID map (as it is the minimum supported
DRAM size for ArmVirtQemu).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
To substantially reduce the amount of processing that takes place with
the MMU and caches off, implement a version of ArmPlatformLib specific
for QEMU/mach-virt in AArch64 mode that carries a statically allocated
and populated ID map that covers the NOR flash and device region, and
128 MiB of DRAM at the base of memory (0x4000_0000).
Note that 128 MiB has always been the minimum amount of DRAM we support
for this configuration, and the existing code already ASSERT()s in DEBUG
mode when booting with less.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Use the appropriate PCD definition in the ArmVirtQemu DSC so that the
boot timeout is taken from the Timeout variable automatically, which is
what Linux tools such as efibootmgr expect.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
When the memory protections were implemented and enabled on ArmVirtQemu
5+ years ago, we had to work around the fact that GRUB at the time
expected EFI_LOADER_DATA to be executable, as that is the memory type it
allocates when loading its modules.
This has been fixed in GRUB in August 2017, so by now, we should be able
to tighten this, and remove execute permissions from EFI_LOADER_DATA
allocations.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Recent model Chromebooks only return ACK, but not
BAT_SUCCESS, which causes hanging and failed ps2k init.
To mitigate this, make the absence of BAT_SUCCESS reply
non-fatal, and reduce the no-reply timeout from 4s to 1s.
Tested on google/dracia and purism/librem_14
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Some platforms may set up a preliminary ID map in flash and enter EFI
with the MMU and caches enabled, as this removes a lot of the complexity
around cache coherency. Let's take this into account, and avoid touching
the MMU controls or perform cache invalidation when the MMU is enabled
at entry.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The iSCSI driver slows down the boot on a pristine variable store flash
image, as it creates a couple of large EFI non-volatile variables to
preserve state between boots.
Since iSCSI boot for VMs is kind of niche anyway, let's default to
disabled. If someone needs it in their build, they can use the -D build
command option to re-enable it on the fly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The EBC interpreter is rarely, if ever, used on ARM, and is especially
pointless on virtual machines. So let's drop it from the builds.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Commit ("2355f0c09c52 BaseTools: Fix check for ${PYTHON_COMMAND} in
Tests/GNUmakefile") fixed a latent issue in the BaseTools/Tests
Makefile, but inadvertently broke the BaseTools build for cases where
PYTHON_COMMAND is not set. As it turns out, running 'command' without a
command argument makes the invocation succeed, causing the empty
variable to be evaluated and called later.
Let's put double quotes around PYTHON_COMMAND in the invocation of
'command' and force it to fail when PYTHON_COMMAND is not set.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Update OpensslLib INF files to match results from running
process_files.pl to auto-generate the INF files.
* OpensslLib.inf
* OpensslLibAccel.inf
* OpensslLibCrypto.inf
* OpensslLibFull.inf
* OpensslLibFullAccel.inf
These INF files are generated by running the following
perl scripts:
* process_files.pl
* process_files.pl X64
* process_files.pl X64Gcc
* process_files.pl IA32
* process_files.pl IA32Gcc
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Yi Li <yi1.li@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Build host-based tests using OpensslLib instance with all services
enabled.
* Build host-based tests using performance optimized OpensslLib instance
with all services enabled.
* Remove unused PCD gEfiCryptoPkgTokenSpaceGuid.PcdOpensslEcEnabled
* Remove redundant and unnecessary [BuildOptions]
* Limit host-based unit tests to only IA32/X64
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
With the addition of EC services and performance optimized versions
of the OpensslLib for IA32/X64, the CryptoPkg.dsc file is updated
to make sure all combinations are covered in CI builds.
* Use different output directory for each CRYPTO_SERVICES profile.
* Add FILE_GUID define names for CryptoPei, CryptoDxe, and CryptoSmm
when they are linked with different OpensslLib instances.
* Update CryptoPei, CryptoDxe, CryptoSmm builds to include all
combinations of OpensslLib library instances supported by each
CPU architecture.
* Add TARGET_UINT_TESTS profile to CryptoPkg.dsc to build only
the target-based unit tests. This reduces the size of CryptoPkg
components not related to unit testing by removing unit test
specific assert handlers. Build target-based unit tests using
OpensslLibFull.inf and OpensslLibFullAccel.inf.
* Remove the PACKAGE profile and instead make the ALL profile
the default for CI testing that enables all services for all
modules.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Update all OpensslLib instances so they produce all the APIs used
by the BaseCryptLib instances. Not producing the same set of APIs
for a library class does not follow the EDK II library class rules
and breaks the assumptions that consumers of the OpensslLib may
make about which services are present.
* Add missing declaration of the private library class OpensslLib
to CryptoPkg.dec.
* Add SslNull.c with NULL implementations of SSL functions
* Add EcSm2Null.c with NULL implementations of EC/SM2 functions.
* Update OpensslLibCrypto.inf to include both SslNull.c and
EcSm2Null.c so this library instance produces all the opensll
APIs used by the BaseCryptLib instances.
* Update OpensslLib.inf and OpensslLibAccel.inf to include
EcSm2Null.c so these library instances produce all the opensll
APIs used by the BaseCryptLib instances.
* Add missing declaration of the private library class IntrinsicLib
to CryptoPkg.dec
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Remove IA32/X64 specific INF files for performance
optimized OpensslLib and combine into OpensslLibAccel.inf
and OpensslLibFullAccel.inf.
* Remove use of PcdOpensslEcEnabled and let the platform
select the EC feature by using either OpensslLibFull.inf
or OpensslLibFullAccel.inf.
* With PcdOpensslEcEnabled removed, roll back style of opensslconf.h
and remove opensslconf_generated.h. Move the choice to disable
EC/SM2 into OpensslLib INF files using OPENSSL_FLAGS define.
* Update OpensslLibContructor() API to be compatible with all
FW phases by using types from Base.h and using RETURN_STATUS
type and values instead of EFI_STATUS type and values.
* Add /wd4718 to VS2015x86 for IA32 and X64 to disable warning
for recursive call with no side effects. This is a false
positive warning that is not produced with VS2017 or VS2019.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib. The functions
in this file are only used by TlsLib instances and not any CryptLib
instances.
* Fix type mismatch in call to FreePool() in TlsConfig.c
* Remove use of gEfiCryptoPkgTokenSpaceGuid.PcdOpensslEcEnabled from
TslLib and CryptLib instances
* Add missing *Null.c files to SecCryptLib.inf and RuntimeCryptLib.inf.
* Remove ARM and AARCH64 sections from SmmCryptLib.inf that does not
support those architectures.
* Add missing PrintLib dependencies to [LibraryClasses] sections of
CryptLib INF files
* Remove extra library classes from [LibraryClasses] sections of
CryptLib INF files
* Remove unnecessary warning disables from [BuildOptions] sections of
TlsLib and CryptLib INF files
* Remove RVCT support from SecCryptLib.inf
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Cc: Rebecca Cran <quic_rcran@quicinc.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Update ImageTimeStampTest to return UNIT_TEST_PASSED instead of
Status. On success Status is TRUE(1), which was returning a unit
test status of UNIT_TEST_ERROR_PREREQUISITE_NOT_MET.
* Update HmacTests to use the *Free() service from the HMAC family
instead of FreePool(). Using FreePool() generates ASSERT() because
the context being freed was not allocated using AllocatePool().
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Christopher Zurcher <christopher.zurcher@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Fix gcc: warning:
-x c after last input file has no effect
These kind of flag can only affect the source code after them.
For the build command in build_rule.template, we have no other source code or object after these two flag.
It seems we don't need them here.
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: JessyX Wu <jessyx.wu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
When checking if $PYTHON_COMMAND exists, curly braces should
be used instead of parentheses.
Also, "1" causes an error on FreeBSD: it's likely supposed to
be 2>&1 like other scripts.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The syntax for Makefiles requires that indented lines s
tart with a tab, but not a space.
This change of PatchCheck.py make the patch for Makefile/GNUmakefile
pass the PatchCheck.py.
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>
According the Xhci Spec, TRB Rings may be larger than a Page, however they
shall not cross a 64K byte boundary, so add a parameter to indicate
whether the memory allocation is for TRB Rings or not. It will ensure the
allocation not crossing 64K boundary in UsbHcAllocMemFromBlock if the
memory is allocated for TRB Rings.
Signed-off-by: jdzhang <jdzhang@kunluntech.com.cn>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
In order to reduce the likelihood that we will need to rely on the logic
that disables and re-enables the MMU for updating a page table entry
safely, expose the XIP version of the helper routine via a HOB and use
it instead of the one that is copied into DRAM. Since the XIP copy is
already clean to the PoC, and will never end up getting unmapped during
a block entry split, we can use it safely without any cache maintenance,
and without running the risk of pulling the rug from under our feet when
updating an entry by going through an invalid mapping.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Permit the use of this library with the MMU and caches already enabled.
This removes the need for any cache maintenance for coherency, and is
generally better for robustness and performance, especially when running
under virtualization.
Note that this means we have to defer assignment of TTBR0 until the
page tables are ready to be used, and so UpdateRegionMapping() can no
longer read back TTBR0 directly to discover the root table address.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
When updating a page table descriptor in a way that requires break
before make, we temporarily disable the MMU to ensure that we don't
unmap the memory region that the code itself is executing from.
However, this is a condition we can check in a straight-forward manner,
and if the regions are disjoint, we don't have to bother with the MMU
controls, and we can just perform an ordinary break before make.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Drop the optimization that replaces table entries with block entries and
frees the page tables in the subhierarchy that is being replaced. This
rarely occurs in practice anyway, and will require more elaborate TLB
maintenance once we switch to a different approach where we no longer
disable the MMU and nuke the TLB entirely every time we update a
descriptor in a way that requires break-before-make (BBM).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Currently the PCD values calculated from the expressions have different
formating from the simple byte arrays in AutoGenC.
Example:
The following definition in DEC:
gTokenSpaceGuid.PcdArray|{0x44, 0x33, 0x22, 0x11}|VOID*|0x55555555
gTokenSpaceGuid.PcdArrayByExpression|{UINT32(0x11223344)}|VOID*|0x66666666
Produces these strings in AutoGenC:
<...> _gPcd_<...>_PcdArray[4] = {0x44, 0x33, 0x22, 0x11};
<...> _gPcd_<...>_PcdArrayByExpression[4] = {0x44,0x33,0x22,0x11};
Add missing space character between the array elements to unify PCD value
formatting.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently it is not possible to initialize all elements in the
array PCD.
For example, this PCD would result to a build failure:
gTokenSpaceGuid.PcdArray|{0x11, 0x22}|UINT8[2]|0x4C4CB9A3
Correct logical operator in the initialization data size checks to
fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Corrently the set of file types for the PIC section contains two
duplicate values.
Replace the duplicate value with the correct one to fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently COMPAT16 section type is not recognized and GenSec is called
without the "-s [SectionType]" argument.
Add COMPAT16 type to the SectionType dictionary to fix the issue.
Now this syntax works correctly:
```
FILE FREEFORM = <GUID> {
SECTION COMPAT16 = <FILE>
}
```
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
EFI_SECTION_FREEFORM_SUBTYPE_GUID is a leaf section type that contains
a single EFI_GUID in the header to describe the raw data.
Currently is is not possible to generate such section.
This patch adds initial support for the generation of such sections.
The added syntax for this type of section corresponds to EDKII
"[FV] section" documentation from the FDF Specification:
```
SECTION SUBTYPE_GUID <GUID> = <File>
```
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Popen communication returns bytestrings. It is necessary to perform
decode on these strings before passing them to the EdkLogger that
works with ordinary strings.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The code changes add unit tests based on current UnitTestFramework.
EdkiiPeiMpServices2PpiPeiUnitTest PEI module is used to test
EdkiiPeiMpServices2Ppi and EfiMpServiceProtocolDxeUnitTest DXE driver is
used to test EfiMpServiceProtocol.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add GENERAL_REGISTER.R8/R9 etc in EccCheck ExceptionList
of UefiCpuPkg/UefiCpuPkg.ci.yaml to pass CI EccCheck.R8/R9
in structure GENERAL_REGISTER of CpuExceptionHandlerTest.h
lead to EccCheck failure since no lower case characters in
R8/R9/R10 etc.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
The previous change adds unit test for DxeCpuExeptionHandlerLib
in 64bit mode. This change create a PEIM to add unit test for
PeiCpuExceptionHandlerLib based on previous change.It can run
in both 32bit and 64bit modes.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add target based unit tests for the DxeCpuExceptionHandlerLib.
A DXE driver is created to test DxeCpuExceptionHandlerLib.
Four test cases are created in this Unit Test module:
a.Test if exception handler can be registered/unregistered
for no error code exception.In the test case, only no error
code exception is triggered and tested by INTn instruction.
b.Test if exception handler can be registered/unregistered
for GP and PF. In the test case, GP exception is triggered
and tested by setting CR4_RESERVED_BIT to 1. PF exception
is triggered by writting to not-present or RO address.
c.Test if CpuContext is consistent before and after exception.
In this test case:
1.Set Cpu register to mExpectedContextInHandler before
exception. 2.Trigger exception specified by ExceptionType.
3.Store SystemContext in mActualContextInHandler and set
SystemContext to mExpectedContextAfterException in handler.
4.After return from exception, store Cpu registers in
mActualContextAfterException.
The expectation is:
1.Register values in mActualContextInHandler are the same
with register values in mExpectedContextInHandler.
2.Register values in mActualContextAfterException are the
same with register values mActualContextAfterException.
d.Test if stack overflow can be captured by CpuStackGuard
in both Bsp and AP. In this test case, stack overflow is
triggered by a funtion which calls itself continuously.
This test case triggers stack overflow in both BSP and AP.
All AP use same Idt with Bsp. The expectation is:
1. PF exception is triggered (leading to a DF if sepereated
stack is not prepared for PF) when Rsp<=StackBase+SIZE_4KB
since [StackBase, StackBase + SIZE_4KB] is marked as not
present in page table when PcdCpuStackGuard is TRUE.
2. Stack for PF/DF exception handler in both Bsp and AP is
succussfully switched by InitializeSeparateExceptionStacks.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
If a device which support both features SR-IOV/ARI has multi
functions, which maybe support 8-255. After enable ARI forwarding in
the root port and ARI Capable Hierarchy in the SR-IOV PF0.
The device will support and expose multi functions(0-255) with ARI ID routing.
In next device loop in below for() code, actually it still be in the
same SR-IOV device, and just some PF which is over 8 or higher
one(n*8), PciAllocateBusNumber() will allocate bus
number(ReservedBusNum - TempReservedBusNum)) for this PF. if reset
TempReservedBusNum as 0 in this case,it will allocate wrong bus number
for this PF because TempReservedBusNum should be total previous PF's
reserved bus numbers.
code:
for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
TempReservedBusNum = 0;
for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
//
// Check to see whether a pci device is present
//
Status = PciDevicePresent (
PciRootBridgeIo,
&Pci,
StartBusNumber,
Device,
Func
);
...
Status = PciAllocateBusNumber (PciDevice, *SubBusNumber,
(UINT8)(PciDevice->ReservedBusNum - TempReservedBusNum), SubBusNumber);
The solution is add a new flag IsAriEnabled to help handle this case.
if ARI is enabled, then TempReservedBusNum will not be reset again
during all functions(1-255) scan with checking flag IsAriEnabled.
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Below code will calculate the reserved bus number for the each PF.
Based on the VF routing ID algorithm, PFRid and LastVF in below code
already sure that "All VFs and PFs must have distinct Routing IDs".
PF will be assigned Routing ID based on secBusNumber, ReservedBusNum
will add into SubBusNumber directly. So the SR-IOV device will be
assigned bus range as SecBusNumber ~ (SubBusNumber=(SecBusNumber +
ReservedBusNum)).
Thus "+1" in below code will cause extra 1 bus, and introduce a bus hole.
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus + 1);
In SR-IOV spec, there is a note in section 2.1.2:
Note: Bus Numbers are a constrained resource. Devices are strongly
encouraged to avoid leaving ?holes? in their Bus Number usage to avoid
wasting Bus Numbers
So the issue can be fixed with below code change.
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus);
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Per the UEFI specification, a device driver implementation should return
EFI_UNSUPPORTED if the ChildHandle argument in
EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName() is not NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3892
1. TlsSetSignatureAlgoList(): Configure the list of TLS signature algorithms
that should be used as part of the TLS session establishment.
This is needed for some WLAN Supplicant connection establishment flows
that allow only specific TLS signature algorithms to be used, e.g.,
Authenticate and Key Managmenet (AKM) suites that are SUITE-B compliant.
2. TlsSetEcCurve(): Configure the Elliptic Curve that should be used for
TLS flows the use cipher suite with EC,
e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
This is needed for some WLAN Supplicant connection establishment flows
that allow only specific TLS signature algorithms to be used,
e.g., Authenticate and Key Managmenet (AKM) suites that are SUITE-B compliant.
3. TlsShutdown():
Shutdown the TLS connection without releasing the resources,
meaning a new connection can be started without calling TlsNew() and
without setting certificates etc.
4. TlsGetExportKey(): Derive keying material from a TLS connection using the
mechanism described in RFC 5705 and export the key material (needed
by EAP methods such as EAP-TTLS and EAP-PEAP).
5. TlsSetHostPrivateKeyEx(): This function adds the local private key
(PEM-encoded or PKCS#8 or DER-encoded private key) into the specified
TLS object for TLS negotiation. There is already a similar function
TlsSetHostPrivateKey(), the new Ex function introduces a new parameter
Password, set Password to NULL when useless.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Signed-off-by: Yi Li <yi1.li@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Per the section 3.3.5 SR-IOV spec v1.1, InitialVFs (0ch).
InitialVFs indicates to SR-PCIM the number of VFs that are initially associated with the PF.
The minimum value of InitialVFs is 0.
Below code is used to calculate SR-IOV reserved bus number,
if InitialVFs =0, it maybe calculate the wrong bus number in this case.
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride
we can fix it with below code:
if (PciIoDevice->InitialVFs == 0) {
PciIoDevice->ReservedBusNum = 0;
} else {
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
//
// Calculate ReservedBusNum for this PF
//
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1);
//
// Calculate ReservedBusNum for this PF
//
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1);
}
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This commit is a code optimization to allow bigger seperate stack size in
ArchSetupExceptionStack. In previous code logic, CPU_STACK_ALIGNMENT bytes
will be wasted if StackTop is already CPU_STACK_ALIGNMENT aligned.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
While the actual implementation (using qemu fw_cfg) is qemu-specific,
the idea to store the boot order as configured by the VMM in EFI
variables is not. So lets give the variables a more neutral name while
we still can (i.e. no stable tag yet with the new feature).
While being at it also fix the NNNN format (use %x instead of %d for
consistency with BootNNNN).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This reverts commit 60d55c4156.
Now that we have stateless secure boot support (which doesn't
need SMM) in OVMF we can enable the build option for MicroVM.
Bring it back by reverting the commit removing it.
Also add the new PlatformPKProtectionLib.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Compiler flag is needed to make (stateless) secure boot be actually
secure, i.e. restore EFI variables from ROM on reset.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In case the 64-bit pci mmio window is larger than the default size
of 32G be generous and hand out larger chunks of address space for
prefetchable mmio bridge windows.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In case we have a reliable PhysMemAddressWidth use that to dynamically
size the 64bit address window. Allocate 1/8 of the physical address
space and place the window at the upper end of the address space.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Try detect physical address space, when successful use it.
Otherwise go continue using the current guesswork code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add some qemu specific quirks to PlatformAddressWidthFromCpuid()
to figure whenever the PhysBits value returned by CPUID is
something real we can work with or not.
See the source code comment for details on the logic.
Also apply some limits to the address space we are going to use:
* Place a hard cap at 47 PhysBits (128 TB) to avoid using addresses
which require 5-level paging support.
* Cap at 40 PhysBits (1 TB) in case the CPU has no support for
gigabyte pages, to avoid excessive amounts of pages being
used for page tables.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Change SMM to MM in naming according to the recent PI specifications.
Remove trailing whitespaces in some strings.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The current string lenght (=60) is not enough for cases where basename
is a path to Build folder.
Drop custom define and use MAX_LINE_LEN from the BaseTools codebase
instead.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently 'PutFileImage' function is called with arguments that are
not advanced on each section parsing. This would lead to an error if
EFI_SECTION_GUID_DEFINED is not the first in a file.
The same mistake is present in the parsing of CRC32 guided section
case.
Use correct arguments to fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
If the guided section was encoded with GenCrc32 tool the resulting
'EFI_GUID_DEFINED_SECTION.DataOffset' field points to the start of
the meaningfull data that follows the CRC32 value.
But if we want to decode the section with GenCrc32 tool we need to
provide a buffer that includes the CRC32 value itself.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add support for partial free of non cached buffers.
If a request for less than the full size is requested new allocations
for the remaining head and tail of the buffer are added to the list.
Added verification that Buffer is EFI_PAGE_SIZE aligned.
The XHCI driver does this if the page size for the controller is >4KB.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
When finding an unsupported entry just skip over and continue
with the next entry instead of stop processing altogether.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
See comment for details. Needed to avoid the parser abort,
so we can continue parsing the bootorder fw_cfg file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Traditional q35 memory layout is 2.75 GB of low memory, leaving room
for the pcie mmconfig at 0xb0000000 and the 32-bit pci mmio window at
0xc0000000. Because of that OVMF tags the memory range above
0xb0000000 as uncachable via mtrr.
A while ago qemu started to gigabyte-align memory by default (to make
huge pages more effective) and q35 uses only 2G of low memory in that
case. Which effectively makes the 32-bit pci mmio window start at
0x80000000.
This patch updates the mtrr setup code accordingly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Update check for enough space to occur prior to alignment offset.
This prevents cases where EfiFreeMemoryTop < EfiFreeMemoryBottom.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
_CPC entries can describe CPU performance information.
The object is described in ACPI 6.4 s8.4.7.1.
"_CPC (Continuous Performance Control)".
Add AmlCreateCpcNode() helper function to add _CPC entries to an
existing CPU object.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Introduce the CM_ARM_CPC_INFO CmObj in the ArmNameSpaceObjects.
This allows to describe CPC information, as described in ACPI 6.4,
s8.4.7.1 "_CPC (Continuous Performance Control)".
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In some scenarios, the information of Bios Version, Bios Release
and Embedded Controller Firmware Release are fetched during UEFI
booting. This patch supports updating those fields dynamically
when the PCDs are empty.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
According to "SMC Calling Convention" specification, section 7.4,
return value of Arm Architecture Calls is stored at first argument of
SMC aguments (ARM_SMC_ARGS). This value can be negative values indicating
error or positive values (including zero) indicating success. Positive
value would contain information of respective Function ID (Section 7.3.4
and 7.4.4).
For that reason, "SMCCC_VERSION" and "SMCCC_ARCH_FEATURES"
Function ID calls read return value from "SmcCallStatus" variable
(Args.Arg0 - first argument of SMC call). But "SMCCC_ARCH_SOC_ID"
Function ID call is reading return value from "SmcParam" variable
(Args.Arg1 - second argument of SMC call) so it leads to unexpected
results of "Jep106Code" and "SocRevision". This patch is to correct it.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
In some scenarios, the processor version may be updated dynamically
from pre-UEFI firmware during booting. But the processor version is
fixed with PCD (PcdProcessorVersion), so it can not be updated it
dynamically. This patch will support setting that value both
statically and dynamically.
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Current implementation of looking up toolchain will _insert_ the findings
from vsvarsall.bat to existing path and potentially stuff the variable to
exceed the length of maximal path length accepted by Windows.
This change updated the logic to use the discovered shell varialbes to
replace the existing path, which is desirable in the specific use case.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Co-authored-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add support for selecting to use index or segment number as UID and name.
This allows the path of the nodes to be well known.
For example, if the PCIe node needs to be notified from by an interrupt
for a Generic Event Device
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4011
AHCI commands are retried internally which prevents platform feature
like drive password to process correctly entered password on subsequent
attempts. PCD allows the platform to determine the number of retries.
Signed-off-by: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Wire up the newly added UefiDriverEntrypoint in a way that ties dispatch
of the Ip4Dxe and Ip6Dxe drivers to QEMU fw_cfg variables
'opt/org.tianocore/IPv4Support' and 'opt/org.tianocore/IPv6Support'
respectively.
Setting both variables to 'n' disables IP based networking entirely,
without the need for additional code changes at the NIC driver or
network boot protocol level.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
All QEMU based OVMF platforms override the same set of network
components, to specify NULL library class resolutions that modify the
behavior of those components in a QEMU specific way.
Before adding more occurrences of that, let's drop those definitions in
a common include file.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add a new library that can be incorporated into any driver built from
source, and which permits loading of the driver to be inhibited based on
the value of a QEMU fw_cfg boolean variable. This will be used in a
subsequent patch to allow dispatch of the IPv4 and IPv6 network protocol
driver to be controlled from the QEMU command line.
This approach is based on the notion that all UEFI and DXE drivers share
a single UefiDriverEntryPoint implementation, which we can easily swap
out at build time with one that will abort execution based on the value
of some QEMU fw_cfg variable.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Don't allow spelling errors to break the CI build and inadvertently
reject pull requests - spelling is important but not that important.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
This debug macro should take one argument based on the number of
print specifiers defined. However, two arguments are given.
It looks like the code may have been refactored such that the
second argument was moved to a new print and this argument was
not removed. In any case, it should not be there now.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
These debug messages are repeated in both NorFlashBlockIoReadBlocks()
and NorFlashBlockIoWriteBlocks():
"NorFlashBlockIoWriteBlocks(MediaId=0x%x, Lba=%ld, BufferSize=0x%x"
"bytes (%d kB), BufferPtr @ 0x%08x)\n"
Although this requires 5 arguments, only 4 are provided. The kilobyte
value was never given.
This change removes that specifier so the 4 arguments match the 4
specifiers in the debug macro.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Rebecca reports that builds of AArch64 DSCs that involve PIE linking
when using ELF based toolchains are failing in some cases, resulting in
an error message like
bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
unsupported symbol type. For example, absolute and undefined symbols
are not supported.
The reason turns out to be that, while GenFw does carry some logic to
convert GOT based symbol references into direct ones (which is always
possible given that our ELF to PE/COFF conversion only supports fully
linked executables), it does not support all possible combinations of
relocations that the linker may emit to load symbol addresses from the
GOT.
In particular, when performing a non-LTO link on object code built with
GCC using -fpie, we may end up with GOT based references such as the one
below, where the address of the GOT itself is taken, and the offset of
the symbol in the GOT is reflected in the immediate offset of the
subsequent LDR instruction.
838: adrp x0, 16000
838: R_AARCH64_ADR_PREL_PG_HI21 _GLOBAL_OFFSET_TABLE_
83c: ldr x0, [x0, #2536]
83c: R_AARCH64_LD64_GOTPAGE_LO15 _gPcd_BinaryPatch_PcdFdBaseAddress
The reason that we omit GOT based symbol references when performing ELF to
PE/COFF conversion is that the GOT is not described by static ELF
relocations, which means that the ELF file lacks the metadata to
generate the PE/COFF relocations covering the GOT table in the PE/COFF
executable. Given that none of the usual motivations for using a GOT
(copy on write footprint, shared libraries) apply to EFI executables in
the first place, the easiest way around this is to convert all GOT based
symbol address loads to PC relative ADR/ADRP instructions.
So implement this handling for R_AARCH64_LD64_GOTPAGE_LO15 and
R_AARCH64_LD64_GOTOFF_LO15 relocations as well, and turn the LDR
instructions in question into ADR instructions that generate the
address immediately.
This leaves the reference to _GLOBAL_OFFSET_TABLE_ itself, which is what
generated the error to begin with. Considering that this symbol is never
referenced (i.e., it doesn't appear anywhere in the code) and is only
meaningful in combination with R_*_GOT_* based relocations that follow
it, we can just disregard any references to it entirely, given that we
convert all of those followup relocations into direct references.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Bob Feng <bob.c.feng@intel.com>
Both ACPI shutdown and ACPI PM timer devices has been moved to different
port addresses in the latest version of Cloud Hypervisor. These changes
need to be reflected on the OVMF firmware.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add VgaInb() helper function to read vga registers. With that in place
fix the unblanking. We need to put the ATT_ADDRESS_REGISTER flip flop
into a known state, which is done by reading the
INPUT_STATUS_1_REGISTER. Reading the INPUT_STATUS_1_REGISTER only works
when the device is in color mode, so make sure that bit (0x01) is set in
MISC_OUTPUT_REGISTER.
Currently the mode setting works more by luck because
ATT_ADDRESS_REGISTER flip flop happens to be in the state we need.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
features and bug fixes:
1. Fix the incremental build issue on Linux @176016387f
2. Fix DSC LibraryClass precedence rule @039bdb4d3e
3. INF should use latest Pcd value instead of default value @a512913
4. Support signtool input subject name to sign capsule @594b795
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
The function reads the boot order from qemu fw_cfg, translates it into
device paths and stores them in 'QemuBootOrderNNNN' variables. In case
there is no boot ordering configured the function will do nothing.
Use case: Allow applications loaded via 'qemu -kernel bootloader.efi'
obey the boot order.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
As Cloud Hypervisor has its own PeiMemLib, change it in dsc file
accordingly.
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Memory layout in CLoud Hypervisor for arm is changed and is different
with Qemu, thus we should build its own PeiMemInfoLib.
The main change in the memory layout is that normal ram may not contiguous
under 4G. The top 64M under 4G is reserved for 32bit device.
What this patch does:
1. get all of the memory node from DT;
2. Init page table for each memory node;
3. Add all of the memory nodes to Hob;
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
The current ACPI Reclaim memory size is set as 0x10 (64KiB). The ACPI
table size will be increased if the memory slots' number of the guest
gets increased. In the guest with more memory slots, the ACPI Reclaim
memory size may not be sufficient for hibernation. This may cause
resume failure of the hibernated guest that was booted up with a fresh
copied writable OVMF_VARS file. However, the failure doesn't happen in
following hibernation/resume cycles.
The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With
ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI
Reclaim memory. However, due to the 0x10 (16 pages) setting, 2 extra
pages will be allocated in other space. This may break the
hibernation/resume in the above scenario.
This patch increases the ACPI Reclaim memory size to 0x12, i.e.
PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12 (18 pages).
Signed-off-by: Annie Li <annie.li@oracle.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reference: https://bugzilla.tianocore.org/show_bug.cgi?id=4031
This patch is similar to the c477b2783f patch for Td guest.
Host VMM may inject OptionRom which is untrusted in Sev guest. So PCI
OptionRom needs to be ignored if it is Sev guest. According to
"Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage"
PI spec 1.7, type-specific flags can be set to 0 when Address
Translation Offset == 6 to skip device option ROM.
Without this patch, Sev guest may shows invalid MMIO opcode error
as following:
Invalid MMIO opcode (F6)
ASSERT /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202202/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c(1041): ((BOOLEAN)(0==1))
The OptionRom must be disabled both on Td and Sev guests, so we direct
use CcProbe().
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
BZ 4037:
Install EFI_DISCOVER_PROTOCOL on each network interface.
This fixes the issue that causes the high-level Redfish driver
on the network interface is stopped when:
1. EFI_DISCOVER_PROTOCOL is reinstalled on a new-found network
interface, or
2. EFI_DISCOVER_PROTOCOL is stopped on the network interface
other than the one which is used to communicate with Redfish
service.
Cc: Nickle Wang <nickle@csie.io>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Nickle Wang <nickle@csie.io>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
SECURE_BOOT_FEATURE_ENABLED is the build-flag defined when secure boot
is enabled. Currently this flag is used in below lib:
- OvmfPkg/PlatformPei
- PeilessStartupLib
So it is defined in below 5 .dsc
- OvmfPkg/CloudHv/CloudHvX64.dsc
- OvmfPkg/IntelTdx/IntelTdxX64.dsc
- OvmfPkg/OvmfPkgIa32.dsc
- OvmfPkg/OvmfPkgIa32X64.dsc
- OvmfPkg/OvmfPkgX64.dsc
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
EmuVariableNvStore is reserved and init with below 2 functions defined in
PlatformInitLib:
- PlatformReserveEmuVariableNvStore
- PlatformInitEmuVariableNvStore
PlatformInitEmuVariableNvStore works when secure boot feature is enabled.
This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc)
and EmuVariableNvStore is cleared when OVMF is launched with -bios
parameter.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
ReserveEmuVariableNvStore is updated with below 2 functions defined in
PlatformInitLib:
- PlatformReserveEmuVariableNvStore
- PlatformInitEmuVariableNvStore
PlatformInitEmuVariableNvStore works when secure boot feature is enabled.
This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc)
and EmuVariableNvStore is cleared when OVMF is launched with -bios
parameter.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
There are 3 functions added for EmuVariableNvStore:
- PlatformReserveEmuVariableNvStore
- PlatformInitEmuVariableNvStore
- PlatformValidateNvVarStore
PlatformReserveEmuVariableNvStore allocate storage for NV variables early
on so it will be at a consistent address.
PlatformInitEmuVariableNvStore copies the content in
PcdOvmfFlashNvStorageVariableBase to the storage allocated by
PlatformReserveEmuVariableNvStore. This is used in the case that OVMF is
launched with -bios parameter. Because in that situation UEFI variables
will be partially emulated, and non-volatile variables may lose their
contents after a reboot. This makes the secure boot feature not working.
PlatformValidateNvVarStore is renamed from TdxValidateCfv and it is used
to validate the integrity of FlashNvVarStore
(PcdOvmfFlashNvStorageVariableBase). It should be called before
PlatformInitEmuVariableNvStore is called to copy over the content.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
TdxValidateCfv is used to validate the integrity of FlashNvVarStore
(PcdOvmfFlashNvStorageVariableBase) and it is not Tdx specific.
So it will be moved to PlatformInitLib and be renamed to
PlatformValidateNvVarStore in the following patch. And it will be called
before EmuVaribleNvStore is initialized with the content in
FlashNvVarStore.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In previous implementation below Pci related PCDs were set based on the
ResourceDescriptor passed in TdHob.
- PcdPciMmio64Base / PcdPciMmio64Size
- PcdPciMmio32Base / PcdPciMmio32Size
- PcdPciIoBase / PcdPciIoSize
The PCDs will not be set if TdHob doesn't include these information. This
patch set the PCDs with the information initialized in PlatformInitLib
by default. Then TdxDxe will check the ResourceDescriptor in TdHob and
reset them if they're included.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974
CcProbeLib once was designed to probe the Confidential Computing guest
type by checking the PcdOvmfWorkArea. But this memory is allocated with
either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed
after ExitBootService. Please see the detailed analysis in BZ#3974.
To fix this issue, CcProbeLib is redesigned as 2 implementation:
- SecPeiCcProbeLib
- DxeCcProbeLib
In SecPeiCcProbeLib we check the CC guest type by reading the
PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about
the issues in BZ#3974.
In DxeCcProbeLib we cache the GuestType in Ovmf work area in a variable.
After that the Guest type is returned with the cached value. So that we
don't need to worry about the access to Ovmf work area after
ExitBootService.
The reason why we probe CC guest type in 2 different ways is the global
varialbe. Global variable cannot be used in SEC/PEI and CcProbe is called
very frequently.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The value of gTimeOut is from PcdGdbMaxPacketRetryCount, and this
PCD is UINT32. So change the declaratrion of gTimeOut to UINT32
to fix compile warning.
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Increase the maximum line length for debug messages.
While log messages should be short, they can still
get quite long, for example when printing device paths
or config strings in HII routing.
512 chars is an empirically good value.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
There's no bhyve specific PlatformSecureLib any more. Use the default
one of OvmfPkg which works too.
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
In an effort to clean the documentation of the above
package, remove duplicated words, and fix a typo while at it.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.muajwar@arm.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In an effort to clean the documentation of the above
package, remove duplicated words.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.muajwar@arm.com>
In an effort to clean the documentation of the above
package, remove duplicated words.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
On platforms that do not have the serial console port pre-initialized
prior to the SEC phase and due to the absence of a call to
"SerialPortInitialize", this results in missing debug logs. So, call
the auto-generated "ProcessLibraryConstructorList" function from SEC
phase to have all the dependent library constructors called
(this includes a call to "SerialPortInitialize").
Signed-off-by: Rohit Mathew <rohit.mathew@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The warm reboot requests from OSPM are mapped to cold reboot. To handle
the warm reboot separately from a cold reboot, update
ArmSmcPsciResetSystemLib and to invoke the PSCI call with parameters
for warm reboot.
Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Per the UEFI specification, if the Request argument in
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() is NULL or does not contain
any request elements, the implementation should return all of the settings
being abstracted for the particular ConfigHdr reference.
The current implementation returns EFI_INVALID_PARAMETER if Request is
NULL or does not contain any request elements. Instead, construct
a new ConfigRequest to handle these cases per the specification.
In addition, per the UEFI specification, if the Configuration argument in
EFI_HII_CONFIG_ACCESS_PROTOCOL.RouteConfig() has a ConfigHdr that
specifies a non-existing target, the implementation should return
EFI_NOT_FOUND.
The current implementation returns EFI_INVALID_PARAMETER if Configuration
has a non-existing target in ConfigHdr. Instead, perform a check and
return EFI_NOT_FOUND in this case.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Per UEFI Spec 2.9, EFI_HII_CONFIG_ROUTING_PROTOCOL.RouteConfig()
should return EFI_INVALID_PARAMETER if caller passes in a NULL for
the Configuration parameter (see 35.4 EFI HII Configuration Routing
Protocol).
Add a check to return EFI_INVALID_PARAMETER when Configuration is NULL.
Signed-off-by: Yuan Yu <yuanyu@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add BUILD_SHELL flag, similar to the one in OvmfPkg/AmdSev,
to enable/disable building of the UefiShell as part of
the firmware image. The UefiShell should not be included for
secure production systems (e.g. SecureBoot) because it can be
used to circumvent security features.
The default value for BUILD_SHELL is TRUE to keep the default
behavior of the Ovmf build.
Note: the default for AmdSev is FALSE.
The BUILD_SHELL flag for AmdSev was introduced in b261a30c90.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Current code will generate duplicate UID if there are nested processor
containers in the topology. For example if there is a
socket/cluster/core layout.
Change references to processor container from cluster to be more
accurate on what is being created.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add APIs needed to build _DSD with different UUIDs.
This is per ACPI specification 6.4 s6.2.5.
Adds support for building data packages with format
Package {"Name", Integer}
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
To remove the dependency of CPU register, 4/8 byte at the top of the
stack is occupied for CpuMpData. BIST information is also taken care
here. This modification is only for PEI phase, since in DXE phase
CpuMpData is accessed via global variable.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
The API of InitializeSeparateExceptionStacks is just changed before, and
makes the struct CPU_EXCEPTION_INIT_DATA an internal definition.
Furthermore, we can even remove the struct to make core simpler.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
When switch bsp, old bsp and new bsp put CR0/CR4 into stack, and put IDT
and GDT register into a structure. After they exchange their stack, they
restore these registers. This logic is now implemented by assembly code.
This patch aims to reuse (Save/Restore)VolatileRegisters function to
replace such assembly code for better code readability.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Currently, when waking up AP, IDT table of AP will be set in 16 bit code,
and assume the IDT table base is 32 bit. However, the IDT table is created
by BSP. Issue will happen if the BSP allocates memory above 4G for BSP's
IDT table. Moreover, even the IDT table location is below 4G, the handler
function inside the IDT table is 64 bit, and it won't take effect until
CPU transfers to 64 bit long mode. There is no benefit to set IDT table in
such an early phase.
To avoid such issue, this patch moves the LIDT instruction into 64 bit
code.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Add host based unit tests for the CpuPageTableLib services.
Unit test focuses on PageTableMap function, containing two kinds of test
cases: manual test case and random test case.
Manual test case creates some corner case to test function PageTableMap.
Random test case generates multiple random memory entries (with random
attribute) as the input of function PageTableMap to get the output
pagetable. Output pagetable will be validated and be parsed to get output
memory entries, and then the input and output memory entries will be
compared to verify the functionality.
The unit test is not perfect yet. There are options for random test, and
some of them control the test coverage, and some option are not ready.
Will enhance in the future.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
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.
