LegacyBootMaintUiLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-7-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
LegacyBootManagerLib is not used by any platform at this point, remove it.
This patch removes mentions of the following CSM resources from the source
code:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
which extends the list of resources scheduled for removal to:
- GUIDs (protocols or otherwise):
- gEfiLegacyBiosProtocolGuid
- gEfiLegacyDevOrderVariableGuid
- headers:
- Guid/LegacyDevOrder.h
- Protocol/LegacyBios.h
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-5-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
PcdCsmEnable was introduced in commits 50f911d25d ("OvmfPkg: introduce
PcdCsmEnable feature flag", 2020-02-05) and 75839f977d
("OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)",
2020-02-05). Remove it, and substitute constant FALSE wherever it has been
evaluated thus far.
Regression test: after building OVMF IA32X64 with -D SMM_REQUIRE, and
booting it on Q35, the log still contains
> Q35SmramAtDefaultSmbaseInitialization: SMRAM at default SMBASE found
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-3-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
We're going to gradually tear down and remove the Compatibility Support
Module (CSM) in OvmfPkg (due to it having no maintainer). Start by making
all platforms that have thus far accepted "-D CSM_ENABLE" reject that
macro, so that mid-series, the partially removed infrastructure cannot be
built or booted.
Insert an !error directive in each DSC file's first "!ifdef $(CSM_ENABLE)"
conditional.
At the end of the series, the !error directive introduced in this patch
will be removed.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Corvin Köhne <corvink@freebsd.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231110235820.644381-2-lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Bhyve uses an io port range of [ 0x2000, 0x10000 ] [1]. At the moment,
EDKII is using a subset of this range [ 0xC000, 0x10000 ] [2]. Even
though the EDKII range doesn't exceed the bhyve range, it's causing
issues on some guests like OpenBSD [3]. We don't know why it's causing
issues yet. However, using the same IO port range in EDKII fixes the
issue and is a good idea anyway.
[1] 82ea0132c8/usr.sbin/bhyve/pci_emul.c (L133-L134)
[2] fb044b7fe8/OvmfPkg/Bhyve/PlatformPei/Platform.c (L156-L157)
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274389
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jiewen Yao <jiewen.yao@intel.com>
In order to allow the VMM (such as QEMU) to add a page with hashes of
kernel/initrd/cmdline for measured direct boot on SNP, add it explicitly
to the SNP metadata list report to the VMM.
In such case, VMM should fill the page with the hashes content, or
explicitly update it as a zero page (if kernel hashes are not used).
Note that for SNP, the launch secret part of the page (lower 3KB) are
not relevant and will remain zero. The last 1KB is used for the hashes.
This should have no effect on OvmfPkgX64 targets (which don't define
PcdSevLaunchSecretBase).
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that
it matches the same size and order used in OvmfPkgX64.fdf.
After this change, this is the difference in the MEMFD of the two
targets:
$ diff -u \
<(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/OvmfPkgX64.fdf) \
<(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/AmdSev/AmdSevX64.fdf)
--- /dev/fd/63 2023-02-16 07:06:15.365308683 +0000
+++ /dev/fd/62 2023-02-16 07:06:15.365308683 +0000
@@ -32,6 +32,12 @@
0x00E000|0x001000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
+0x00F000|0x000C00
+gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
+
+0x00FC00|0x000400
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+
0x010000|0x010000
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add an instance of ImagePropertiesRecordLib which will be used by the
DXE Core.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572
According to section 3.2 of the [GHCI] document, if the return status
of MapGPA is "TDG.VP.VMCALL_RETRY", TD must retry this operation for the
pages in the region starting at the GPA specified in R11.
In this patch, when a retry state is detected, TDVF needs to retry the
mapping with the specified address from the output results of TdVmCall.
Reference:
[GHCI]: TDX Guest-Host-Communication Interface v1.0
https://cdrdv2.intel.com/v1/dl/getContent/726790
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Adds the varpolicy EFI shell command to all DSC files that
currently include other dynamic shell commands from ShellPkg.
This command allows variable policies to be dumped in the EFI
shell for convenient auditing and debug.
Use the command in QEMU EFI shell as follows:
- `"varpolicy"` dumps platform variables
- `"varpolicy -?"` shows help text
- `"varpolicy -b"` pages output as expected
- `"varpolicy -s"` shows accurate variable statistic information
- `"varpolicy -p"` shows accurate UEFI variable policy information
- `"varpolicy-v -b"` dumps all information including variable data hex dump
Cc: Anatol Belski <anbelski@linux.microsoft.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jianyong Wu <jianyong.wu@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Message-Id: <20231030203112.736-4-mikuback@linux.microsoft.com>
v1 -> v2 Changed list:
1:Since both commits are intended to fix coverity issues, they are merged
into one
2:Changed the debug info level to debug error when "DsdtTable == NULL"
3:Add the Cc member as below
Erdem Aktas erdemaktas@google.com
James Bottomley jejb@linux.ibm.com
Tom Lendacky thomas.lendacky@amd.com
Michael Roth michael.roth@amd.com
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4568
The function InstallCloudHvTablesTdx had an Assert when "DsdtTable ==
NULL", but this comes into play only in DEBUG mode. In Release mode ,
there is no handling if the pointer is NULL. To avoid the possible null
pointer dereference, it is better to handle it when the pointer is null.
In addition, the status of "AcpiProtocol->InstallAcpiTable" is overwritten
before it can be used in the function, it is better to check it before
overwriting.
code: https://github.com/sunceping/edk2/tree/fixcoverityerrors.v2
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Message-Id: <20231023090539.1003-1-cepingx.sun@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
[lersek@redhat.com: rewrap commit message to placate PatchCheck.py]
Referring to a file relative to a regular file makes no sense (or at least
it cannot be implemented consistently with how a file is referred to
relative to a directory). VirtioFsSimpleFileOpen() has enforced this
strictly since the beginning, and a few months ago I reported USWG Mantis
ticket #2367 [1] too, for clearing up the related confusion in the UEFI
spec.
Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
believe the shim bug is ever going to be fixed. We can however relax the
check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
opened relative to a regular file is absolute, then the base file is going
to be ignored anyway, so we can let the caller's bug slide. This happens
to make shim work.
Why this matters: UEFI-bootable Linux installer ISOs tend to come with
shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
want to build upstream shim/grub binaries, but boot the same ISO
otherwise. The fastest way for overriding the ESP for this purpose is to
copy its original contents to a virtio filesystem, then overwrite the shim
and grub binaries from the host side. Note that this is different from
direct-booting a kernel (via fw_cfg); the point is to check whether the
just-built shim and grub are able to boot the rest of the ISO.
[1] https://mantis.uefi.org/mantis/view.php?id=2367
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973
[3] https://github.com/rhboot/shim/issues/382
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>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231018172434.91280-1-lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Disables the DebugMacroCheck CI plugin to reduce CI checks performed
in the package.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Current reset vector uses 0xffffffe0 as AP waking vector, and expects
GenFv generates code aligned on a 4k boundary which will jump to this
location. However, some issues are listed below
1. GenFV doesn't generate code as the comment expects, because GenFv
assumes no modifications are required to the VTF-0 'Volume Top File'.
2. Even if removing VFT0 signature and let GenFv to modify, Genfv is
hard-code using another flash address 0xffffffd0.
3. In the same patch series, AP waking vector code is removed from
GenFv, because no such usage anymore. The existing of first two issues
also approve the usage is not available for a long time.
Therefore, remove AP waking vector related code.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Direct (fw_cfg) kernel boot works on the RiscVVirt firmware platform too;
I've tested it after extracting the kernel, initrd, and kernel command
line from "openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw". Document this
type of boot, because at least historically, fw_cfg kernel boot was
implemented differently between OVMF and ArmVirtQemu. Thanks: Drew, Sunil.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
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>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
"acpi=off" is arguably unusual with UEFI guest OSes; add a note to explain
it. Original explanation by Drew Jones.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
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>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Riscv64 KVM services SBI calls internally, so OpenSBI is not used in such
setups. Restrict the "-bios" flag accordingly. Thanks: Andrei, Drew.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
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>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: '-bios' is rejected with KVM accel (Drew)]
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4527
According to ACPI 6.5 (https://uefi.org/specs/ACPI/6.5/05_ACPI_Software
_Programming_Model.html?highlight=mailboxversion#multiprocessor-wakeup-
structure) the MailBoxVersion is 0.
This patch changed MadtMpWk->MailBoxVersion from 1 to 0 to fix the error.
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>
"OvmfPkg/Include/IndustryStandard/Virtio095.h" defines the macro
VIRTIO_SUBSYSTEM_CONSOLE with value 3; other locations in the tree already
use it (such as ArmVirtPkg/PlatformBootManagerLib,
OvmfPkg/VirtioSerialDxe). We should use it in
OvmfPkg/PlatformBootManagerLib too, rather than the naked constant 3.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Explain how users can compose their pre-OS environment purely from
binaries they've built themselves.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
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>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
If OVMF fails to find the RSDP in memory, it should fall back installing
the statically provided ACPI tables.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504
The BaseRngLibTimerLib allows to generate number based on a timer.
This mechanism allows to have a basic non-secure implementation
for non-production platforms.
To bind and identify Random Number Generators implementations with
a GUID, an unsafe GUID should be added. This GUID cannot be added
to the MdePkg unless it is also added to a specification.
To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to
the MdeModulePkg. This will allow to define an unsafe Rng GUID
in a later patch in the MdeModulePkg.
The MdePkg implementation will be removed later. This allows to give
some time to platform owners to switch to the MdeModulePkg
implementation.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
The qemu/kvm SMM emulation uses the AMD SaveState layout.
So, now that we have AMD SaveState support merged we can just use
Amd/SmramSaveStateMap.h, QemuSmramSaveStateMap.h is not needed any more.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Add DetectAndPreparePlatformVirtioDevicePath() helper function
to setup virtio-mmio devices. Start with virtio-serial support.
This makes virtio console usable with microvm.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
This reverts commit 173a7a7daa
Fixes https://bugzilla.tianocore.org/show_bug.cgi?id=4528
The build.sh qemu option starts the correct qemu executable for the
selected architecture (build.sh -a option, or implicit) and uses the
correct previously built OVMF image for the selected architecture and
build target (build.sh -b option, or implicit).
With this revert, the above step will fail if there is no matching
previously built OVMF image. This is advantageous over rebuilding each
time the build.sh qemu option is used (as in the reverted commit),
because it provides a quick way to run a just-built OVMF image in place,
while:
a) Starting immediately (saving the time required for a rebuild on each
usage, if the VM is started multiple times)
b) Preserving the NVRAM contents between multiple runs (i.e. until the
image is next rebuilt)
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
The Hii form is named "MainFormState" while the EFI variable is named
"PlatformConfig". This discrepancy in names causes the following SCT
cases to fail on RiscVVirtQemu:
ExtractConfigConformance
ExtractConfigFunction
ExtractConfig_Func
Previous commit 16acacf addressed two of these issues, and this patch
fixes the remaining one.
Signed-off-by: Yin Wang <yin.wang@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Booting an SEV guest with AmdSev OVMF package currently triggers the
following assertion with QEMU:
InstallQemuFwCfgTables: installed 7 tables
PcRtc: Write 0x20 to CMOS location 0x32
[Variable]END_OF_DXE is signaled
Initialize variable error flag (FF)
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT [BdsDxe] /home/VT_BUILD/ovmf/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c(1711): !(((INTN)(RETURN_STATUS)(Status)) < 0)
This seems to be due to commit 81dc0d8b4c, which switched to using
PlatformBootManagerLib instead of PlatformBootManagerLibGrub. That pulls
in a dependency on gEfiS3SaveStateProtocolGuid provider being available
(which is asserted for in
BdsPlatform.c:PlatformBootManagerBeforeConsole()/SaveS3BootScript()),
but the libraries that provide it aren't currently included in the
build. Add them similarly to what's done for OvmfPkg.
Fixes: 81dc0d8b4c ("OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrub")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
PcdFirstTimeWakeUpAPsBySipi was recently introduced to indicate when the
full INIT-SIPI-SIPI sequence can be skipped for AP bringup. It is true
by default, but needs to be disabled for QEMU/OVMF where early INIT is
not simulated. Commit 1d76560146 ("OvmfPkg: Disable
PcdFirstTimeWakeUpAPsBySipi.") added changes to disable it by default
for OvmfPkg, but a similar change was not made for the AmdSev package.
This breaks booting of SEV and SNP guests.
Fix this defaulting PcdFirstTimeWakeUpAPsBySipi to false for AmdSev
package, as was previously done for OvmfPkg variants.
Fixes: eaffa1d7ff ("UefiCpuPkg:Wake up APs after power-up or RESET through SIPI.")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Instead of relying on raising the TPL to protect the critical sections
that manipulate the global bitmask that keeps track of bounce buffer
allocations, use compare-and-exchange to manage the global variable, and
tweak the logic to line up with that.
Given that IoMmuDxe implements a singleton protocol that is shared
between multiple drivers, and considering the elaborate and confusing
requirements in the UEFP spec regarding TPL levels at which protocol
methods may be invoked, not relying on TPL levels at all is a more
robust approach in this case.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2211060
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
Disable PcdFirstTimeWakeUpAPsBySipi for IntelTdx, Microvm, and Xen to
preserve the original execution of INIT-SIPI-SIPI.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The block size configuration of Blockmap does not match that in Qemu
VirtNorFlash, which causes variable data to be written into FtwWorkBlock
by mistake, resulting in data loss during reboot. Fix it and update
new checksum value.
Signed-off-by: Qingyu Shang <2931013282@sjtu.edu.cn>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.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: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Disable PcdFirstTimeWakeUpAPsBySipi for OVMF to let BSP wake up APs by
INIT-SIPI-SIPI.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Increase the chance that CI finds bugs in MP changes.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit f92a9dce10)
Reapplying, since the CI (Windows and Linux) use Qemu 8 now, which works
with SMP again.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
[ardb: use single-threaded TCG for SMM]
This reverts commit 3beb8c9654.
Both Windows and Linux CI jobs are now using Qemu 8, this workaround is
no longer needed.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Bump the version of the Qemu chocolatey package up to 2023.7.25.
The Linux CI is already using Qemu 8.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Update the README with instruction to build using CLANGDWARF
toolchain.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # Debian clang version 14.0.6
llvm fails to resolve _ModuleEntry when these extra directives are
present. ASM_FUNC already takes care what is required.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # Debian clang version 14.0.6
Use auto alignment and FIXED FFS attribute for XIP modules similar
to [1]. Without this change, the CLANGDWARF toolchain will fail to
build with below error.
GenFfs: ERROR 1000: Unknown option
SectionAlign option must be specified with section file.
[1] - 7669f73498
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # Debian clang version 14.0.6
bhyve supports adding a ROM to PCI devices. It was added to support GPU
passthrough of dedicated AMD GPUs. At the moment, this ROM file is
mostly useless as it's not shadowed and executed by firmware. Change
that by enabling bus enumeration.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
We like to enable bus enumeration for bhyve. Therefore, this patch needs
to be reverted.
This reverts commit 8c8f886f27.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
We like to enable bus enumartion for bhyve. Therefore, this patch needs
to be reverted.
This reverts commit c2f24ba321.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
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>
Cc: Rebecca Cran <rebecca@bsdio.com>
Print the timeout value set in the PCD variable instead of
hard coded 10 seconds.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
OpenSBI now marks PMP regions with "no-map" attribute.
So, remove the workaround and add the ReservedMemory only
when no-map is set so that it follows DT spec.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Ranbir Singh <rsingh@ventanamicro.com>
Searching for an unused bounce buffer in mReservedMemBitmap and
reserving the buffer by flipping the bit is a critical section
which must not be interrupted. Raise the TPL level to ensure
that.
Without this fix it can happen that IoMmuDxe hands out the same
bounce buffer twice, causing trouble down the road. Seen happening
in practice with VirtioNetDxe setting up the network interface (and
calling into IoMmuDxe from a polling timer callback) in parallel with
Boot Manager doing some disk I/O. An ASSERT() in VirtioNet caught
the buffer inconsistency.
Full story with lots of details and discussions is available here:
https://bugzilla.redhat.com/show_bug.cgi?id=2211060
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>