Dionna Glaze [Thu, 26 Jan 2023 21:17:40 +0000 (21:17 +0000)]
OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted
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>
Dionna Glaze [Thu, 26 Jan 2023 21:17:38 +0000 (21:17 +0000)]
OvmfPkg: Introduce the OvmfSevMemoryAcceptance protocol
The default behavior for unaccepted memory in SEV-SNP is to accept all
memory when ExitBootServices is called. An OS loader can use this
protocol to disable this behavior to assume responsibility for memory
acceptance and to affirm that the OS can handle the unaccepted memory
type.
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> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Dionna Glaze [Thu, 26 Jan 2023 21:17:37 +0000 (21:17 +0000)]
OvmfPkg: Add memory acceptance event in AmdSevDxe
The added behavior is to accept all unaccepted memory at
ExitBootServices if the behavior is not disabled. This allows safe
upgrades for OS loaders to affirm their support for the unaccepted
memory type.
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> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Ard Biesheuvel [Tue, 24 Jan 2023 15:45:02 +0000 (15:45 +0000)]
ArmVirtPkg/PlatformCI: Add CI coverage for ArmVirtQemuKernel
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.
Ard Biesheuvel [Tue, 24 Jan 2023 15:34:24 +0000 (15:34 +0000)]
ArmVirtPkg/PlatformCI: factor out reusable PlatformBuildLib.py
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.
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.
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>
Tomas Pilar [Tue, 3 Jan 2023 17:02:29 +0000 (09:02 -0800)]
ShellPkg: Export default shell delay as PCD
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>
Laszlo Ersek [Thu, 19 Jan 2023 11:01:31 +0000 (12:01 +0100)]
OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression
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
(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.
[2] IO port write width clamping differs between TCG and KVM
http://mid.mail-archive.com/aaedee84-d3ed-a4f9-21e7-d221a28d1683@redhat.com
https://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.com
https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00278.html
NOTE: PlatformInitLib is used in the following platform DSCs:
Ard Biesheuvel [Thu, 19 Jan 2023 13:43:02 +0000 (14:43 +0100)]
OvmfPkg/PlatformCI VS2019: Enable temporary workaround for cpuhp bugfix
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>
Min M Xu [Thu, 19 Jan 2023 01:51:08 +0000 (09:51 +0800)]
EmbeddedPkg: Add back FfsFindSectionData
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>
Min M Xu [Thu, 19 Jan 2023 01:51:07 +0000 (09:51 +0800)]
EmbeddedPkg: Rename FfsFindSectionData as FfsFindSectionDataWithHook
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>
Abner Chang [Fri, 23 Dec 2022 06:40:15 +0000 (14:40 +0800)]
RedfishPkg/Include: Redfish USB Interface V2 update
Support USB_INTERFACE_DEVICE_DESCRIPTOR_V2 which
is updated in Redfish Host Interface spec v1.3.
Signed-off-by: Abner Chang <abner.chang@amd.com> Cc: Nickle Wang <nicklew@nvidia.com> Cc: Igor Kulchytskyy <igork@ami.com> Reviewed-by: Igor Kulchytskyy <igork@ami.com> Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Abner Chang [Fri, 23 Dec 2022 06:33:48 +0000 (14:33 +0800)]
RedfishPkg/Include: Add Redfish IPMI definitions
Add the definitions of Redfish Host Interface
credential bootstrapping IPMI commands.
Signed-off-by: Nickle Wang <nicklew@nvidia.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Igor Kulchytskyy <igork@ami.com> Reviewed-by: Igor Kulchytskyy<igork@ami.com> Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>
Abner Chang [Fri, 23 Dec 2022 06:20:06 +0000 (14:20 +0800)]
MdePkg/IndustryStandard: Update IPMI definitions
This change updates IPMI header files to support
build up SMBIOS 42 Redfish Host Interface record
using the information retrieved via IPMI App/Net
Function.
In IpmiNetFnApp.h, we also remove the duplicate
definition of IPMI_APP_GET_CHANNEL_INFO.
Signed-off-by: Abner Chang <abner.chang@amd.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> 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: Liming Gao <gaoliming@byosoft.com.cn>
Min M Xu [Tue, 17 Jan 2023 23:52:32 +0000 (07:52 +0800)]
OvmfPkg/BaseMemEncryptTdxLib: Refactor error handle of SetOrClearSharedBit
The previous implementation of SetOrClearSharedBit doesn't handle the
error correctly. In this patch SetOrClearSharedBit is changed to return
error code so that the caller can handle it.
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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
Min M Xu [Tue, 17 Jan 2023 23:53:26 +0000 (07:53 +0800)]
SecurityPkg/TdTcg2Dxe: Extend EFI boot variable to PCR[1]
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>
Move common X86 instruction codes from CcExitVcHandler.c to separate
files (CcInstruction.h / CcInstruction.c) so that these codes can be
re-used in TDX.
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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
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>
NCCFV refers to Non-Confidential-Computing-FV. It includes the DXE phase
drivers which are only loaded/started in non-cc guest. Hence the
PCDs / GUID for NCCFV are defined in OvmfPkg.dec.
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>
EmbeddedPkg/PrePiLib provides the service of finding sections based on
the input SectionType. But sometimes there maybe multiple sections
with the same SectionType. FFS_CHECK_SECTION_HOOK is a hook which can
be called to do additional check.
Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Abner Chang <abner.chang@amd.com> Cc: Daniel Schaefer <git@danielschaefer.me> 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> Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Prakash.K [Thu, 24 Nov 2022 05:12:13 +0000 (10:42 +0530)]
ShellPkg: Display SMBIOS Type38 fields in smbiosview in formatted view
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".
Oliver Steffen [Mon, 16 Jan 2023 17:40:39 +0000 (18:40 +0100)]
BaseTools: remove ext_dep files for gcc
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:38 +0000 (18:40 +0100)]
.pytool: CISettings.py: don't add scopes for GCC
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:37 +0000 (18:40 +0100)]
OvmfPkg: CI: Use Fedora 35 container (Linux only)
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:36 +0000 (18:40 +0100)]
EmulatorPkg: CI: Use Fedora 35 container (Linux only)
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:35 +0000 (18:40 +0100)]
ArmVirtPkg: CI: Use Fedora 35 container (Linux only)
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>
Ard Biesheuvel [Tue, 17 Jan 2023 18:09:09 +0000 (19:09 +0100)]
CI: Use Fedora 35 container (Linux only)
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:33 +0000 (18:40 +0100)]
CI: Allow running in a container.
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:32 +0000 (18:40 +0100)]
CI: add ~/.local/bin to PATH (Linux only)
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>
Oliver Steffen [Mon, 16 Jan 2023 17:40:28 +0000 (18:40 +0100)]
CI: make Python version configurable
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,
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.
Gerd Hoffmann [Tue, 17 Jan 2023 12:16:27 +0000 (13:16 +0100)]
OvmfPkg/PlatformInitLib: Add PlatformAddHobCB
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.
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.
Gerd Hoffmann [Tue, 17 Jan 2023 12:16:25 +0000 (13:16 +0100)]
OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB
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.
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.
Ard Biesheuvel [Thu, 5 Jan 2023 15:43:54 +0000 (16:43 +0100)]
BaseTools/tools_def ARM: Make choice for soft float ABI explicit
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.
Ard Biesheuvel [Thu, 5 Jan 2023 14:29:39 +0000 (15:29 +0100)]
BaseTools/tools_def RISCV: Make OpenSBI references RISCV-only
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 d372ab585a2cdc5348af5f701c56c631235fe698
("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>
Gerd Hoffmann [Mon, 16 Jan 2023 09:46:39 +0000 (10:46 +0100)]
ArmVirt: don't use unaligned CopyMem () on NOR flash
Commit 789a72328553 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: 789a72328553 ("OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and drop AlignedCopyMem()") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Unlink the XhciPei memory block when it has been freed.
Signed-off-by: Jiangang He <jiangang.he@amd.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Garrett Kirkendall <garrett.kirkendall@amd.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Kuei-Hung Lin <Kuei-Hung.Lin@amd.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Abner Chang [Wed, 11 Jan 2023 03:10:07 +0000 (11:10 +0800)]
MdeModulePkg/Usb: Read a large number of blocks
Changes to allow reading blocks that greater than 65535 sectors.
Signed-off-by: Jiangang He <jiangang.he@amd.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Garrett Kirkendall <garrett.kirkendall@amd.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Kuei-Hung Lin <Kuei-Hung.Lin@amd.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Abner Chang [Wed, 11 Jan 2023 03:10:06 +0000 (11:10 +0800)]
MdeModulePkg/Xhci: Initial XHCI DCI slot's Context value
Initialize XHCI DCI slot's context entries value.
Signed-off-by: Jiangang He <jiangang.he@amd.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Garrett Kirkendall <garrett.kirkendall@amd.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Kuei-Hung Lin <Kuei-Hung.Lin@amd.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Commit 9fdc70af6ba8 install the QemuAcpiTableNotifyProtocol at a
wrong positioin. It should be called before TransferS3ContextToBootScript
because TransferS3ContextToBootScript is the last operation in
InstallQemuFwCfgTables(). Another error is that we should check the
returned value after installing the QemuAcpiTableNotifyProtocol.
This patch refactors the installation and error handling of
QemuAcpiTableNotifyProtocol in InstallQemuFwCfgTables ().
Cc: Laszlo Ersek <lersek@redhat.com> 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> Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
Message-Id: <20230111012235.189-6-min.m.xu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Commit 9fdc70af6ba8 wrongly removed the log from InstallQemuFwCfgTables
after ACPI tables are successfully installed. This patch add the log
back after all operations succeed.
Cc: Laszlo Ersek <lersek@redhat.com> 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> Reported-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
Message-Id: <20230111012235.189-5-min.m.xu@intel.com>
The handle of mQemuAcpiHandle is not needed for anything, beyond the
scope of the InstallQemuFwCfgTables(). So a local variable will
suffice for storing the handle.
Cc: Laszlo Ersek <lersek@redhat.com> 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> Reported-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
Message-Id: <20230111012235.189-4-min.m.xu@intel.com>
The handle of mChAcpiHandle is not needed for anything, beyond the
scope of the InstallCloudHvTablesTdx (). A local variable (ChAcpiHandle)
suffices for storing the handle.
The QEMU_ACPI_TABLE_NOTIFY_PROTOCOL structure is superfluous because NULL
protocol interfaces have been used in edk2 repeatedly. A protocol instance
can exist in the protocol database with a NULL associated interface.
Therefore the QEMU_ACPI_TABLE_NOTIFY_PROTOCOL type, the
"QemuAcpiTableNotify.h" header, and the "mAcpiNotifyProtocol" global
variable can be removed.
Dionna Glaze [Tue, 8 Nov 2022 16:46:16 +0000 (16:46 +0000)]
MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices
Location of notification is has been specified in UEFI v2.9.
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> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Cc: Ray Ni <ray.ni@intel.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Message-Id: <20221108164616.3251967-4-dionnaglaze@google.com>
Gerd Hoffmann [Wed, 11 Jan 2023 18:00:23 +0000 (19:00 +0100)]
OvmfPkg/VirtNorFlashDxe: map flash memory as uncacheable
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.
Laszlo Ersek [Thu, 12 Jan 2023 07:45:29 +0000 (08:45 +0100)]
OvmfPkg/PlatformInitLib: fix comment about uncacheable MTRRs
In commit 49edde15230a ("OvmfPkg/PlatformPei: set 32-bit UC area at
PciBase / PciExBarBase (pc/q35)", 2019-06-03), I forgot to update the
comment. Do it now.
Enables KVM and One Click Recovery WLAN capability with WiFi Profile
Sync feature and protocol. Adding WiFiProfileSyncProtocol, which
supports the profilesync driver operations for transferring WiFi profiles
from AMT to the Supplicant. WiFiConnectionManager will check for the
WifiProfileSyncProtocol and if found will operate on the premise of a
One Click Recovery, or KVM flow with a Wifi profile provided by AMT.
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Zachary Clark-Williams <zachary.clark-williams@intel.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Ard Biesheuvel [Wed, 4 Jan 2023 15:51:35 +0000 (16:51 +0100)]
ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX
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.
Ard Biesheuvel [Thu, 5 Jan 2023 13:43:14 +0000 (14:43 +0100)]
ArmVirtPkg/ArmPlatformLibQemu: Ensure that VFP is on before running C code
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>
Ning Feng [Mon, 9 Jan 2023 12:28:09 +0000 (07:28 -0500)]
UefiPayloadPkg: Fix debug print error level hob not save correct
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4264
Fix debug print error level hob not save correct DebugPrintErrorlevel
Should cover the case:
Header.Length == UNIVERSAL_PAYLOAD_SIZEOF_THROUGH_FIELD () 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: Ning Feng <ning.feng@intel.com> Reviewed-by: Gua Guo <gua.guo@intel.com>
In order to remove RTC_INDEX/RTC_TARGET from
the UplBuild macro list,change the RTC_INDEX
/RTC_TARGET type from PcdsFixedAtBuild to PcdsDynamicEx
Reviewed-by: 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: KasimX Liu <kasimx.liu@intel.com>
The TdTcg2Dxe lives in the OvmfPkg instead of the SecurityPkg. Having
the TdTcg2Dxe at the same place as Tcg2Dxe will be easier for platforms to
consume.
Definition of PcdCcEventlogAcpiTableLaml and PcdCcEventlogAcpiTableLasa
are also moved from OvmfPkg.dec to SecurityPkg.dec.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Arti Gupta <ARGU@microsoft.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Laszlo Ersek [Tue, 3 Jan 2023 16:05:39 +0000 (17:05 +0100)]
Maintainers.txt: designate Gerd Hoffmann as UefiCpuPkg reviewer
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>
Wu, Jiaxin [Thu, 15 Dec 2022 09:41:00 +0000 (17:41 +0800)]
Maintainers.txt: Update NetworkPkg & MM modules Reviewer
This is to change NetworkPkg & MM modules Reviewer.
Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Laszlo Ersek [Tue, 3 Jan 2023 15:02:44 +0000 (16:02 +0100)]
OvmfPkg/SmmCpuFeaturesLib: drop obsolete API implementation
Commit 0426115b6738 ("UefiCpuPkg: Remove unused API in
SmmCpuFeaturesLib.h", 2022-12-21) removed the declaration of the function
SmmCpuFeaturesAllocatePageTableMemory() from the "SmmCpuFeaturesLib.h"
library class header.
Remove the API's (null-)implementation from OvmfPkg/SmmCpuFeaturesLib as
well.
Testing: OVMF builds, boots, and suspends/resumes (see earlier in this
series).
Laszlo Ersek [Tue, 3 Jan 2023 15:02:43 +0000 (16:02 +0100)]
UefiCpuPkg/SmmCpuFeaturesLib: drop obsolete API implementation
Commit 0426115b6738 ("UefiCpuPkg: Remove unused API in
SmmCpuFeaturesLib.h", 2022-12-21) removed the declaration of the function
SmmCpuFeaturesAllocatePageTableMemory() from the "SmmCpuFeaturesLib.h"
library class header.
Remove the API's (null-)implementation from UefiCpuPkg/SmmCpuFeaturesLib
as well.
Build-tested with:
build -a IA32 -a X64 -b NOOPT -p UefiCpuPkg/UefiCpuPkg.dsc -t GCC5
Cc: Eric Dong <eric.dong@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Ray Ni <ray.ni@intel.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4235 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Dun Tan <dun.tan@intel.com>
Laszlo Ersek [Tue, 3 Jan 2023 15:02:42 +0000 (16:02 +0100)]
OvmfPkg: raise DXEFV size to 13 MB in the traditional platform FDFs
Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since
commit 5e75c4d1fe4f ("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>
Laszlo Ersek [Tue, 3 Jan 2023 15:02:41 +0000 (16:02 +0100)]
OvmfPkg/QemuVideoDxe/VbeShim.sh: remove end-of-options delimiter for nasm
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).
projects / mirror_edk2.git / log