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>
SECURE_BOOT_FEATURE_ENABLED was dropped by the commit(92da8a154f), but the
PeilessStartupLib was not updated with PcdSecureBootSupported, that made
SecureBoot no longer work in IntelTdxX64.
Fix this by replacing SECURE_BOOT_FEATURE_ENABLED with
PcdSecureBootSupported 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: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
During CpuDxe initialization, MMU will be setup with the highest
mode that HW supports.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
There is no point to set satp to bare mode as that should be the
default mode when booting edk2.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Make sure VirtNorFlashDxe loaded before VariableRuntimeDxe as it
is the backend flash driver.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Normally, DXE driver would add device resource to GCD before start using.
But some key resources such as uart used for printing info at very early
stage.
Those resources should be populated to HOB in SEC phase so they are
added to GCD before MMU enabled.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
The size should be for single region, not the whole firmware FD.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Commit 63c50d3ff2 changed the check that is
used to determine if SEV-ES is active. Originally, a CMP instruction with
a supporting JZ instruction was used for the check. It was changed to use
the BT instruction but not JZ instruction. The result of a BT instruction
changes the the carry flag (CF) and not the zero flag (ZF). As a result,
the wrong condition is being checked. Update the JZ to a JNC to properly
detect if SEV-ES is active.
Fixes: 63c50d3ff2 ("OvmfPkg/ResetVector: cache the SEV status MSR...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
The effect of LTO is limited with optimization turned off, and blocked
the upgrade of Openssl3.0. We already skipped this build with VS2019,
skip the GCC NOOPT build also.
Signed-off-by: Yi Li <yi1.li@intel.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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Remove code that sets AddressEncMask for non-leaf entries when
modifing smm page table by MemEncryptSevLib. In FvbServicesSmm
driver, it calls MemEncryptSevClearMmioPageEncMask to clear
AddressEncMask bit in page table for a specific range. In AMD
SEV feature, this AddressEncMask bit in page table is used to
indicate if the memory is guest private memory or shared memory.
But all memory accessed by the hardware page table walker is
treated as encrypted, regardless of whether the encryption bit
is present. So remove the code to set the EncMask bit for smm
non-leaf entries doesn't impact AMD SEV feature.
The reason encryption mask should not be set for non-leaf
entries is because CpuPageTableLib doesn't consume encryption
mask PCD. In PiSmmCpuDxeSmm module, it will use CpuPageTableLib
to modify smm page table in next patch. The encryption mask is
overlapped with the PageTableBaseAddress field of non-leaf page
table entries. If the encryption mask is set for smm non-leaf
page table entries, issue happens when CpuPageTableLib code
use the non-leaf entry PageTableBaseAddress field with the
encryption mask set to find the next level page table.
Signed-off-by: Dun Tan <dun.tan@intel.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>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The UEFI driver model invokes the supported() method on every driver
every time a connection attempt is made on any handle, and so doing an
unconditional DEBUG() print inside this method produced a lot of noise.
So let's drop this DEBUG() call from the VirtioSerial driver's
Supported() method.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Bhyve will gain support for TPM emulation in the near future. Therefore,
prepare OVMF by copying all TPM driver used by qemu's OVMF DSC into the
bhyve OVMF DSC.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
This makes the InstallQemuFwcfgTables function reusable by bhyve.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
This is required to move InstallQemuFwCfgTables into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
Bhyve supports providing ACPI tables by FwCfg. Therefore,
InstallQemuFwCfgTables should be moved to AcpiPlatformLib to reuse the
code. As first step, move PciEncoding into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
The definition and declaration of GetAcpiRsdpFromMemory doesn't match.
We don't get a compile error yet because UINTN is the same as UINT64 on
64bit machines. As the function works on memory addresses, UINTN is the
correct type of the input parameters.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Add a readme file which provides information regarding how
to build and test EDK2 on RISC-V qemu virt platform.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.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: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently, RiscVVirtQemu supports unified code and variable store
mainly because only one pflash devices was available in qemu for
EDK2. However, this doesn't allow to map the code part as read-only.
With recent qemu enhancements, it is now possible for EDK2 to make
use of both pflash devices in RISC-V virt machine. So, add support
to create code and vars images separately. This also allows easy
firmware code updates without losing the variable store.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.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: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This library is required to support separate code and
variable store images.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.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: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The size of the FV and the WriteQueueSize is incorrect which causes
the flash to be re-written during boot. Fix them and update the new
checksum value.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.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: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
It's much easier to create configuration dependent ACPI tables for bhyve
than for OVMF. For this reason, don't use the statically created ACPI
tables provided by OVMF. Instead, prefer the dynamically created ACPI
tables of bhyve. If bhyve provides no ACPI tables or we are unable to
detect those, fall back to OVMF tables.
Ideally, we use the qemu fwcfg interface to pass the ACPI tables from
bhyve to OVMF. bhyve will support this in the future. However, current
bhyve executables don't support passing ACPI tables by the qemu fwcfg
interface. They just copy the ACPI into main memory. For that reason,
pick up the ACPI tables from main memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
This makes the function reuseable by bhyve.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Xen and bhyve are placing ACPI tables into system memory. So, they can
share the same code. Therefore, create a new library which searches and
installs ACPI tables from system memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Edk2 was failing, rather than creating more PML4 entries, when they
weren't present in the initial memory acceptance flow. Because of that
VMs with more than 512G memory were crashing. This code fixes that.
This change affects only SEV-SNP VMs.
The code was tested by successfully booting a 512G SEV-SNP VM.
Signed-off-by: Mikolaj Lisik <lisik@google.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
The RISC-V version of the DXE IPL does not implement setting the stack
NX, so before switching to an implementation that will ASSERT() on the
missing support, drop the PCD setting that enables it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Now that OvmfPkg/SataControllerDxe and its MdeModulePkg counterpart have
been unified, and no in-tree uses of the OVMF variant remain, let's
delete it.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the OvmfXen platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the AmdSev platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the IntelTdx platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the CloudHv platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Bhyve platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Corvin Köhne <corvink@FreeBSD.org>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Microvm platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for OvmfPkg{Ia32, X64, Ia32X64} platforms.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Older linux kernels have problems with phys-bits larger than 46,
ubuntu 18.04 (kernel 4.15) has been reported to be affected.
Reduce phys-bits limit from 47 to 46.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Flash can be write-protected in qemu (which is usually the case for
code). In case the variable store flash block is configured read-only
ovmf wouldn't be able to store EFI variables there, so not setting up
fvb in that case (and fallhack to emulation) is the better option.
It'll avoid problems later due to flash writes failing.
The patch tries to write back the original value read earlier, so flash
content doesn't change in case the write succeeds. But the status we
read back after the attempt to write will tell us whenever flash is
writable or not.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Apparently TPL_CALLBACK is too low, code runs into an ASSERT
complaining the new TPL is lower than the old TPL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add CpuPageTableLib required by SecCore & CpuMpPei in OvmfPkg.
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: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
If PcdUse1GPageTable is not enabled restrict the physical address space
used to 1TB, to limit the amount of memory needed for identity mapping
page tables.
The same already happens in case the processor has no support for
gigabyte pages.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Flip the default for IO address space reservations for PCI(e) bridges
and root ports with hotplug support from TRUE to FALSE.
PCI(e) bridges will still get IO address space assigned in case:
(a) Downstream devices actually need IO address space, or
(b) Explicit configuration, using "qemu -device
pcie-root-port,io-reserve=<size>".
In case IO address space is exhausted edk2 will stop assigning resources
to PCI(e) bridges. This is not limited to IO resources, the affected
bridges will not get any memory resources assigned either.
This patch solves this issue by not handing out the scarce IO address
space, which is not needed in most cases anyway. Result is a more
consistent PCI configuration in virtual machine configurations with many
PCie root ports.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Not needed any more, SMM + 64-bit PEI + S3 suspend works now.
Fixed by commits:
- 8bd2028f9a ("MdeModulePkg: Supporting S3 in 64bit PEI")
- 6acf72901a ("UefiCpuPkg: Supporting S3 in 64bit PEI")
See also https://bugzilla.tianocore.org/show_bug.cgi?id=4195
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Move initialization of local variable structure from declaration
to statements to fix VS2015x86 build break.
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 D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
If the SerialPortLib had any initialization needed, this
would be skipped in the RiscVVirt Sec. Follow the example
seen elsewhere (ArmVirtPkg PrePi).
Seen with BaseSerialPortLibRiscVSbiLibRam not using DBCN in Sec,
yet using DBCN elsewhere.
Cc: Daniel Schaefer <git@danielschaefer.me>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Not used any more, remove.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Use PlatformBootManagerLib with PcdBootRestrictToFirmware
set to TRUE instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
In case PcdBootRestrictToFirmware is set, disable loading EFI variables
from NvVars file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add new PCD PcdBootRestrictToFirmware. When set to TRUE restrict
boot options to EFI applications embedded into the firmware image.
Behavior should be identical to the PlatformBootManagerLibGrub
library variant.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL. The specification also
restricts usage of TPL_HIGH_LEVEL to the firmware itself.
However, nothing actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
enabling interrupts via the STI or equivalent instruction. Some
versions of the Microsoft Windows bootloader are known to do this.
NestedInterruptTplLib maintains the invariant that interrupts are
disabled at TPL_HIGH_LEVEL (even when performing the dark art of
deliberately manipulating the stack so that IRET will return with
interrupts still disabled), but does not itself rely on external code
maintaining this invariant.
Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
to an error message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.
Debugged-by: Gerd Hoffmann <kraxel@redhat.com>
Debugged-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
NestedInterruptTplLib relies on CPU interrupts being disabled to
guarantee exclusive (and hence atomic) access to the shared state in
IsrState. Nothing in the calling interrupt handler should have
re-enabled interrupts before calling NestedInterruptRestoreTPL(), and
the loop in NestedInterruptRestoreTPL() itself maintains the invariant
that interrupts are disabled at the start of each iteration.
Add assertions to clarify this invariant, and expand the comments
around the calls to RestoreTPL() and DisableInterrupts() to clarify
the expectations around enabling and disabling interrupts.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Add a driver for the virtio serial device.
The virtio serial device also known as virtio console device because
initially it had only support for a single tty, intended to be used as
console. Support for multiple streams and named data ports has been
added later on.
The driver supports tty ports only, they are registered as SerialIo
UART in the system.
Named ports are detected and logged, but not exposed as devices. They
are usually used by guest agents to communicate with the host. It's not
clear whenever it makes sense for the firmware to run such agents and if
so which efi protocol could be to expose the ports. So leaving that for
another day.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add header files with structs and defines for the virtio serial device.
The virtio serial device also known as virtio console device because
initially it had only support for a single tty, intended to be used as
console. Support for multiple streams and named data ports has been
added later on.
https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-2900003
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Initialize gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with
with the value of the variable "FIRMWARE_VER", if is is defined. Applies
to all flavors of OvmfPkg.
This behavior is already implemented in ArmVirtXen.dsc. It allows
specifying the firmware version string on the build command line with
-D FIRMARE_VER=...
Introduce a common include file to be used in the .dsc files for the
different OVMF flavors, and add the changes there. (ArmVirtPkg already
has such a file).
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Currently OVMF tries to rely on the base size advertised via the CPUID
table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will
generally work for KVM guests, but might not for other SEV-SNP
hypervisor implementations. Make the handling more robust by simply
using the base area size documented by the APM.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the
enabled XSave areas. Those sizes are calculated by tallying up all the
other sub-leafs that contain per-area size information for XSave areas
that are currently enabled in XCr0/XSS. The current check has the logic
inverted. Fix that.
This doesn't seem to cause problems currently, but could in the future
if OVMF made more extensive use of XSave areas. It was noticed while
implementing SNP-related tests for KVM Unit Tests, which re-uses the
OVMF #VC handler in some cases.
Reported-by: Pavan Kumar Paluri <papaluri@amd.com>
Cc: Pavan Kumar Paluri <papaluri@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support for 32-bit compilations, the kernel definition has
since been updated to use explicit padding/reserved fields to avoid
this dependency. Update OVMF to match that definition.
While at it, also fix up the Reserved fields to match the numbering
used in the kernel.
No functional changes (for currently-supported environments, at least).
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
The SEV-SNP Confidential Computing blob contains metadata that should
remain accessible for the life of the guest. Allocate it as
EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest
operating system later.
Reported-by: Dov Murik <dovmurik@linux.ibm.com>
Suggested-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
OvmfPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
The generic and XCODE5 versions of this library are now identical, so
drop the special case. The library will be removed entirely in a
subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
This patch substitutes the macros that were renamed in the second
patch with the new, shared alignment macros.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
This patch is a preparation for the patches that follow. The
subsequent patches will introduce and integrate new alignment-related
macros, which collide with existing definitions in OvmfPkg.
Temporarily rename them to avoid build failure, till they can be
substituted with the new, shared definitions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
This is causing excessive boot times in the VS2019 IA32/X64 Full
run to shell tasks (> 2 minutes) and blocking all edk2 CI.
This patch removes the change so it can be root caused separately
without blocking other patches unrelated to OVMF.
Reverts f92a9dce10
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: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
The CLANGDWARF toolchain has the same problem as XCODE5 linking
CpuExceptionHandlerLib. So, use the
Xcode5SecPeiCpuExceptionHandlerLib.inf when building with the CLANGDWARF
toolchain.
Since the difference is that the non-Xcode5 version uses `mov` while the
Xcode5 version uses `lea`, they can be merged in future with the single
version using `lea`.
[ardb: the main difference is that the 'mov' instructions result in
absolute symbol references, which are necessary because the code
in question is copied in memory independently from the code that
carries the symbols it refers to. The Xcode5 version has
additional runtime handling to fix up the copied code with the
correct absolute references.]
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Replace the static struct initialization with a call to ZeroMem to avoid
generating a call to memset in certain build configurations.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
With the new mmconfig location at 0xe0000000 above the 32-bit PCI MMIO
window we don't have to special-case the mmconfig xbar any more. We'll
just add a mtrr uncachable entry starting at MMIO window base and ending
at 4GB.
Update comments to match reality.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Also swap the ordering of 32bit PCI MMIO window on q35, i.e. use the
room between end of low memory and the start of the mmconfig bar.
With a typical configuration on modern qemu with gigabyte-aligned memory
the MMIO window start at 0x8000000, sized 1532 MB. In case there is
memory present above 0x80000000 the window will start at 0xc0000000
instead, with 512 MB size.
This depends on qemu commit 4a4418369d6d ("q35: fix mmconfig and
PCI0._CRS"), so it raises the bar for the lowest supported version
to qemu 4.1 (released Aug 2019).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Move the commment up so it is placed just before the address space
calculations start. Also add q35 memory layout.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
M-mode firmware ranges should not be used by EDK2/OS.
Currently, we search for mmode_resv0 node in FDT and mark it as the
reserved memory in EFI memory map. However, if there are multiple
M-mode firmware ranges, then this will miss those extra ranges
allowing the OS to access the memory and hit a fault.
This issue is exposed since recent opensbi started creating
two ranges for text and data.
Fix this by searching for all reserved memory nodes and marking
them as reserved in the EFI memory map.
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>
Time to leave behind relics from the last century and arrive in the
modern world. Drop PC-ANSI Terminal Type for the serial console, use
UTF-8 instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add support for building RiscVVirtQemu platform in CI.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib, remove the
dependency of UefiCpuLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and
UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build
failure, add CpuLib dependency to all modules that depend on UefiCpuLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
In case PcdFirmwareReleaseDateString is not set use a valid date
as fallback. Using "unknown" makes Windows unhappy.
Fixes: 4cb94f20b0 ("OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*")
Reported-by: ruifeng.gao@intel.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested with a PCIe pass-thru'd AHCI controller.
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337
This patch is to check SmBase relocation supported or not.
If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array. ASSERT it's not supported in OVMF.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4350
Currently, stack HOB is not created for the stack memory. This causes
stack memory to be treated as free memory and any memory allocation which
happens at this address causes random memory corruption. Fix this by
creating the stack HOB which marks the memory as BS data.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Andrei Warkentin <andrei.warkentin@intel.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>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reported-by: Andrei Warkentin <andrei.warkentin@intel.com>
Tested-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Fix the UEFI memory range calculation by including the correct
stack memory range. Without this fix, SCT hangs in MemoryAllocation
test cases which call AllocateAddress().
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>
Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
Add infrastructure files to build edk2 for RISC-V qemu virt machine.
- It follows PEI less design.
- EDK2 for qemu virt is booted in S-mode as a payload for M-mode FW
- Leveraged from ArmVirtQemu
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Add the SEC module for RISC-V Qemu virt machine support.
It uses the PEI less design.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Add PciCpuIo2Dxe driver to implement EFI_CPU_IO2_PROTOCOL
to add the translation for IO access. This is copied from
ArmPciCpuIo2Dxe driver.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Qemu NOR flash driver needs this library. Add this
library for RISC-V leveraged from SbsaQemu.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
RISC-V Qemu virt uses SBI calls to implement the reset.
Add the base class library.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
RISC-V Qemu Virt platfform needs the PlatformBootManagerLib similar
to the one in ArmVirtPlatform. Add the library in OvmfPkg/RiscVVirt
leveraging the one from Arm.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
This module is required by other architectures like RISC-V.
Hence, move this to OvmfPkg.
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: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
This event should only trigger once. It should be idempotent, but the
allocation of the memory map itself is observable and can cause
ExitBootServices to fail with a modified map key.
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
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: Michael Roth <michael.roth@amd.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
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>
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>
TDVF's README is updated based on the latest feature.
- RTMR based measurement is supported in OvmfPkgX64 (Config-A)
- Features of Config-B have all been implemented, such as removing
unnecessary attack surfaces.
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2506
In all DSC files that define SECURE_BOOT_ENABLE, opt-in into requiring
self-signed PK when SECURE_BOOT_ENABLE is TRUE.
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>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Signed-off-by: Jan Bobek <jbobek@nvidia.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.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
TdxHelperBuildGuidHobForTdxMeasurement is called in PlatformPei to build
GuidHob for Tdx measurement.
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
TdHob and Configuration FV (Cfv) are external inputs from VMM. From the
security perspective, they should be measured before they're consumed.
This patch measures TdHob and Cfv and stores the measurement values in
WorkArea.
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
PeiTdxHelperLib is the PEI instance of TdxHelperLib. It implements 1
function for tdx in PEI phase. Other functions are not supported in
PEI phase.
- TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for tdx
measurement in PEI phase.
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
TdHob and Configuration FV (Cfv) are external inputs from VMM. From the
security perspective, they should be measured before they're consumed.
This patch measures TdHob and Cfv and stores the measurement values in
WorkArea.
After TdHob and Configuration FV (Cfv) are measured in SecMain, the
same measurements in PeilessStartupLib are deleted.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
ProcessHobList once was implemented in PlatformInitLib and it walks thru
TdHob list and accept un-accepted memories.
This patch moves the codes to SecTdxHelperLib and rename ProcessHobList
as TdxHelperProcessTdHob
After TdxHelperProcessTdHob is introduced, below changes are applied:
- Call TdxHelperProcessTdHob instead of ProcessHobList in SecMain.c
(in both OvmfPkgX64/Sec and IntelTdx/Sec).
- Delete the duplicated codes in PlatformInitLib
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
FV_HANDOFF_TABLE_POINTERS2 once was defined in IntelTdx.c. Its structure
is same as PLATFORM_FIRMWARE_BLOB2_STRUCT which is defined in
Library/TcgEventLogRecordLib.h. So this patch reuse the define of
PLATFORM_FIRMWARE_BLOB2_STRUCT as FV_HANDOFF_TABLE_POINTERS2. Furthermore
FV_HANDOFF_TABLE_POINTERS2 is renamed as CFV_HANDOFF_TABLE_POINTERS2
so that the name is more meaningful.
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>
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>
This protocol implementation disables the accept-all-memory behavior
of the BeforeExitBootServices event this driver adds.
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>
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>
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>
BuildResourceDescriptorHob() expects the third parameter be the Length,
not the End address.
Fixes: 328076cfdf ("OvmfPkg/PlatformInitLib: Add PlatformAddHobCB")
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Jiewen Yao <jiewen.yao@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>
Move the QEMU v2.7 reset bug check/workaround to a separate function, as
we'll need to detect further issues.
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-2-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>
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>
Status should be initialized otherwise it may return unexpected value.
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>
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4169
The previous TDX MmioExit doesn't handle the Mmio instructions correctly
in some scenarios. This patch refactors the implementation to fix the
issues.
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: Ryan Afranji <afranji@google.com>
Reported-by: Ryan Afranji <afranji@google.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>
https://bugzilla.tianocore.org/show_bug.cgi?id=4169
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4152
As described in BZ#4152, NCCFV includes the DXE phase drivers for non-cc
guest. PeilessStartupLib is updated to find NCCFV for non-cc guest.
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>
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4152
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>
Switch over to ubuntu-22.04 as the vm_image for Linux CI jobs. The
previously used ubuntu-18.04 which is not available anymore since
Dec 1st 2022.
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>
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>
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>
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
Installation of gQemuAcpiTableNotifyProtocol may fail. The error code
should be returned 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: Sebastien Boeuf <sebastien.boeuf@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Message-Id: <20230111012235.189-7-min.m.xu@intel.com>
Reviewed-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
Commit 9fdc70af6b 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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
Commit 9fdc70af6b 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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
The handle of mChAcpiHandle is not needed for anything, beyond the
scope of the InstallCloudHvTablesTdx (). A local variable (ChAcpiHandle)
suffices 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>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Message-Id: <20230111012235.189-3-min.m.xu@intel.com>
Reviewed-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237
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.
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>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.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-2-min.m.xu@intel.com>
Reviewed-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
TPM support is independent from secure boot support. Move the TPM
include snipped out of the secure boot !if block.
Fixes: b47575801e ("OvmfPkg: move tcg configuration to dsc and fdf include files")
Bugzilla: https://bugzilla.tianocore.org//show_bug.cgi?id=4290
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implemented /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.
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>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Message-Id: <20221108164616.3251967-2-dionnaglaze@google.com>
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>
This reverts commit 4a86424224 as the
commit 73ccde8 introduced CpuPageTableLib dependency which resolved
for OvmfPkg is to be reverted.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4234
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>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4194
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>
Commit 0426115b67 ("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).
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>
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>
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>
Prevent stack underrun in the event of a timer interrupt storm in
LocalApicTimerDxe and 8254TimerDxe interrupt handlers by using the
helper functions provided by NestedInterruptTplLib.
This fixes the same problem as addressed in commit 239b50a86
("OvmfPkg: End timer interrupt later to avoid stack overflow under
load"), but does so without breaking nested timer interrupts.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815
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>
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>
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>
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
TDVF APs once did nothing but spin around to wait for the Wakeup command.
This patch enables APs to handle the AcceptPages command. Once APs find
the AcceptPages command, it set its stack and jump to the function of
ApAcceptMemoryResourceRange (which will be introduced in the following
patch).
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
This patch moves the TDX APs nasm code from SecEntry.nasm to
IntelTdxAPs.nasm. IntelTdxX64 and OvmfPkgX64 use the same nasm so that
it can be easier to be managed. In the following patch there will be
AcceptMemory related changes in IntelTdxAPs.nasm.
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
In the following patches TdxMailboxLib will be included in
PlatformInitLib. While PlatformInitLib is imported by some IA32/X64
platforms (for example AmdSevX64.dsc). So TdxMailboxLibNull is added in
those platforms which don't support TDX feature.
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4172
TdxMailboxLib once was designed to be used in DXE phase. But now it is
going to be used in SEC/PEI phase (in the following patches). Global
variables are not allowed. The library is refactored after those global
variables are deleted.
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>
Add CpuPageTableLib required by MpInitLib in OvmfPkg.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.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>
Add support to use the reserved shared memory within the IoMmu library.
This improves boot times for all SEV guests, with SEV-SNP benefiting the
most as it avoids the page state change call to the hypervisor.
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: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4171
IoMmuDxe once was designed to support DMA operation when SEV is enabled.
After TDX is enabled in IoMmuDxe, some files' name in IoMmuDxe need to
be more general. So this patch rename:
AmdSevIoMmu.h -> CcIoMmu.h
AmdSevIoMmu.c -> CcIoMmu.c
Accordingly there are some udates in IoMmuDxe.c and IoMmuDxe.inf.
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>
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>
Adds a reference to the new build instructions on the TianoCore wiki
that currently describe building with containers and Stuart.
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: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.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>
This is required for passing the ACPI tables from the VMM up to the
guest OS. They are transferred through this GUID extension.
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4184
According to the Uefi spec 2.10 Section 38.2.2.
EFI_CC_MEASUREMENT_PROTOCOL.GetCapability, the minor version of
StructureVersion and ProtocolVersion should be 0.
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>
This variant does not use global variables.
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>
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>
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4123
APIs which are defined in CcExitLib.h are added with the CcExit prefix.
This is to make the APIs' name more meaningful.
This change impacts OvmfPkg/UefiCpuPkg.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
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: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4123
VmgExitLib once was designed to provide interfaces to support #VC handler
and issue VMGEXIT instruction. After TDVF (enable TDX feature in OVMF) is
introduced, this library is updated to support #VE as well. Now the name
of VmgExitLib cannot reflect what the lib does.
This patch renames VmgExitLib to CcExitLib (Cc means Confidential
Computing). This is a simple renaming and there is no logic changes.
After renaming all the VmgExitLib related codes are updated with
CcExitLib. These changes are in OvmfPkg/UefiCpuPkg/UefiPayloadPkg.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
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: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4125
EPT-violation #VE should be always on shared memory, which means the
shared bit of the GuestPA should be set. But in current #VE Handler
it is not checked. When it occurs, stop TD immediately and log out
the error.
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>
Reviewed-by: Guorui Yu <ruogui.ygr@alibaba-inc.com>
Tested-by: Guorui Yu <ruogui.ygr@alibaba-inc.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
After EdkiiMemoryAcceptProtocol is implemented in TdxDxe driver, we can
call it to accept pages in DXE phase.
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>
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>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Memory usage may exceed the amount accepted at the begining (SEC), TDVF
needs to accept memory dynamically when OUT_OF_RESOURCE occurs.
Another usage is in SetOrClearSharedBit. If a memory region is changed from
shared to private, it must be accepted again.
EdkiiMemoryAcceptProtocol is defined in MdePkg and is implementated /
installed in TdxDxe for Intel TDX memory acceptance.
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>
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>
Laszlo Ersek
Corvin Köhne
Dov Murik
Michael Kubacki
Taylor Beebe
Ceping Sun
Zhiguang Liu
Min M Xu
Pierre Gondois
Gerd Hoffmann
Joursoir
Mike Beaton
Yin Wang
Roth, Michael via groups.io
Michael Roth
Ard Biesheuvel
YuanhaoXie
Qingyu Shang
Oliver Steffen
Sunil V L
Tuan Phan
Tom Lendacky
Yi Li
Abdul Lateef Attar
Dun Tan
Mikolaj Lisik via groups.io
Pedro Falcato
Jiaxin Wu
Michael D Kinney
Andrei Warkentin
Michael Brown
Jeff Brasen
Rebecca Cran
Yu Pu
Dionna Glaze
Rebecca Cran
Jan Bobek
Sophia Wolf
Anthony PERARD
Chun-Yi Lee
Sebastien Boeuf
Adam Dunlap
Ryan Afranji