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>
Corvin Köhne
Sunil V L
Mikolaj Lisik via groups.io
Ard Biesheuvel
Pedro Falcato
Gerd Hoffmann
Jiaxin Wu
Michael D Kinney
Andrei Warkentin
Michael Brown
Oliver Steffen
Roth, Michael via groups.io
Michael Roth
Jeff Brasen
Rebecca Cran
Michael Kubacki
Yu Pu
Zhiguang Liu
Yuanhao Xie
Dionna Glaze
Rebecca Cran
Min M Xu
Jan Bobek
Laszlo Ersek
Sophia Wolf
Anthony PERARD