Large multi-GPU passthrough configurations can exhaust the current
MMIO window sizing rule (1/8 of guest physical address space),
especially with newer GPUs that have very large BAR requirements and
alignment overhead.
With 46-bit guest physical addressing, the 1/8 rule provides an 8TB
MMIO window. Newer GPUs with 512GB VRAM can exhaust an 8TB window
when passing through up to 8 devices.
Increase the MMIO window size to 1/4 of guest physical address space.
This provides a 16TB MMIO window on a 46-bit setup.
Tested with 8-GPU passthrough (512GB VRAM per GPU). With this
change, all GPUs are visible and functional in the VM; without it,
one GPU was unusable.
Signed-off-by: ramkumar.s <ramkumar.s@nutanix.com>
OVMF already supports MemDebugLogLib for capturing firmware debug
output in a runtime memory buffer. Align the TDX peiless boot path
with OVMF by integrating the same library, so that TDX guests can
use memory-based debug logging.
In PeilessStartupLib, allocate a runtime buffer for the debug log
during PeilessStartup() and copy any early SEC-phase logs from
the pre-allocated FDF region into it.
Register the early debug log memory region in the TDX metadata as
TEMP_MEM so the TDX module accepts it during guest initialization.
Move PlatformDxe/Platform.inf from NCCFV to DXEFV because it
exposes the memory debug log HOB to the guest.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
The Null instance of MemDebugLogLib only provides MemDebugLogWrite(),
MemDebugLogPages(), and MemDebugLogEnabled(). Any module that
references MemDebugLogInit() or MemDebugLogCopy() cannot link against
the Null instance, forcing the feature to be gated at the build-system
level rather than at runtime.
Add no-op stubs for MemDebugLogInit() and MemDebugLogCopy().
This will be used by the following commit to add memory debug log
support in TDX.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
Introduce a Virtio MMIO probe library that discovers virtio-mmio
nodes from the FDT and maps their MMIO ranges before the virtio
transport driver creates virtio devices and accesses the device
MMIO regions.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Allow MapMmioLib to be consumed by DXE_RUNTIME_DRIVER modules.
MapMmioMemory() depends on DXE services, so it cannot map new
ranges after ExitBootServices(). Return EFI_ACCESS_DENIED when
called at runtime.
This allows runtime drivers such as
ArmVirtPkg/Library/KvmtoolRtcFdtClientLib to use MapMmioLib for
boot-time MMIO setup.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Introduce MapMmioLib to add MMIO regions to the GCD memory map.
MapMmioMemory() normalizes the requested range to page boundaries, adds
missing MMIO descriptors, and updates attributes for new and existing MMIO
descriptors. Existing descriptors of any other type are reported as
conflicts.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Make QemuFwCfgGetAsString() a public EFIAPI entry point instead of
a STATIC helper, so it can be used by consumers that need the raw
fw_cfg string value rather than a parsed boolean or integer.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
The virtio input device can be used to create virtual human interface
devices such as mice and tablets, not just keyboards. Rename
VirtioKeyboardDxe to VirtioInputDxe for adding virtio-mouse and
virtio-tablet support in following commits.
No functional change.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
The BaseAcpiTimerLib instance contains a static global variable,
'mAcpiTimerIoAddr', that caches the ACPI timer IO base address. As this
library executes during PEI phase prior to the PEIFV measurement into
PCR0, the value of the variable is included into the measurement. This
causes the PEIFV binary footprint to change, preventing a precomputation
of the expected value needed for remote attestation.
Fix this by using the BaseRomAcpiTimerLib in the PEI phase instead of
the BaseAcpiTimerLib. This library dynamically computes the required
address and does not introduce global variables, keeping the PEIFV
binary unchanged.
Co-authored-by: Simon Ott <simon.ott@aisec.fraunhofer.de>
Signed-off-by: Jakov Zauzolkov <jakov.zauzolkov@aisec.fraunhofer.de>
Commit 0a0919607c ("OvmfPkg/PlatformInitLib: redefine low memory") narrowed
PlatformGetLowMemoryCB() to consider only the first below-4G memory block
whose base address is zero. The change was intended to fix SVSM guests,
where SVSM caves a chunk out of below-4G RAM and OVMF must not stray into
that hole.
TDVF, however, reports its below-4G RAM through the TdHob as two adjacent
resource descriptors:
[0, 0x800000) EFI_RESOURCE_SYSTEM_MEMORY (pre-accepted)
[0x800000, ~4G) EFI_RESOURCE_MEMORY_UNACCEPTED
PlatformScanE820Tdx() surfaces both as EfiAcpiAddressRangeMemory E820
entries. After 0a0919607c only the first, tiny 8 MiB block is picked up,
so PlatformInfoHob->LowMemory becomes 0x800000.
In OvmfPkg/PlatformPei/MemDetect.c PublishPeiMemory() this drives:
LowerMemorySize = 0x00800000 // LowMemory
PeiMemoryCap = 0x04F82000 // ~81 MiB
MemoryBase = LowerMemorySize - PeiMemoryCap // UINT32 underflow
= 0xFB87E000
Permanent PEI memory is then published at 0xFB87E000, which is not backed
by RAM. TemporaryRamMigration()'s first CopyMem into that phantom range
(observed as 0xFB898000 in the failing log) faults, tearing down the TD.
Fold adjacent below-4G memory blocks into the low-memory span: accept an
entry whose base equals the current LowMemory and advance LowMemory by
its length. LowMemory starts at zero, so the first accepted block at
address 0 still starts the sequence; non-adjacent above-4G or SVSM-carved
blocks continue to be skipped (their base does not match LowMemory); and
the TDVF accepted+unaccepted pair, which is contiguous, is now grouped
correctly.
Co-authored-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stanislaw Grams <stanislaw.grams@intel.com>
EmbeddedPkg's PrePiLib and OvmfPkg's PeilessStartupLib (which
uses PrePiLib) only produce FV2 HOBs for extracted FVs. However,
FV3 HOBs have superceded FV2 HOBs for describing extracted FVs.
This commit updates both of these libs to also produce FV3 HOBs,
following PEI's pattern of producing an FV, FV2, and FV3 HOB for
each extracted FV.
Eventually, only FV3 HOBs will be produced, so this paves the way
for that.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
PeilessStartupLib is incorrectly producing FV2 HOBs.
The FvName field of the FV2 HOB is intended to be the
parent FV's name. This way the HOB consumer phase can
identify when an FV has already been extracted: if the
file name of the extracted FV and the parent FV name
match in the FV2 HOB.
With the incorrect FvName, DXE will re-extract the already
extracted FV, which can be a large performance hit (some platforms
we have seen ~1 second).
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
PrePiLib is incorrectly producing FV2 HOBs. The FvName field of
the FV2 HOB is intended to be the parent FV's name. This way the
HOB consumer phase can identify when an FV has already been
extracted: if the file name of the extracted FV and the parent
FV name match in the FV2 HOB.
With the incorrect FvName, DXE will re-extract the already
extracted FV, which can be a large performance hit (some platforms
we have seen ~1 second).
This requires an update to FfsProcessFvFile to pass the parent
FV handle through so the FV2 HOB can be correctly produced.
OvmfPkg consumers are also updated.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The SVSM_UEFI_MM_PROTOCOL protocol allows to send MM communication buffers to
the SVSM (instead of edk2 MM code) and let SVSM manage EFI variables that way.
This patch implements the helper function to send MM communication buffers to
the SVSM for the OVMF AmdSvsmLib implementation.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
[Sources.X64] and [Sources.AARCH64] appear twice in
XenHypercallLib.inf, remove the redundant ones to make the files more
concise.
Signed-off-by: Qihang Gao <gaoqihang@loongson.cn>
Fix spelling errors in definitions in Pci22.h.
Update consumers in MdeModulePkg, OvmfPkg, ShellPkg,
and SourceLevelDebugPkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Commit 0e6f6c715c removed the use of gEfiXenInfoGuid.
Fixes: 0e6f6c715c ("OvmfPkg/XenHypercallLib: Use direct hypercalls")
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Exclude these ranges in addition to the ranges from the static
mPreValidatedRange array, by checking the IGVM data HOBs in
DetectPreValidatedOverLap().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Traditionally "low memory" is all memory below 4G. The code logic dates
back to the days where OVMF has used the CMOS to figure how much memory
is installed instead of the e820 table provided by qemu.
That approach to memory detection implicitly assumes there is a single
block of memory below 4G. Should that not be the case things fall
apart. This happens in case OVMF runs under SVSM and SVSM caves out a
chunk of memory below 4G for itself, passing the remaining two blocks of
memory below 4G on to OVMF (via igvm memory map).
Fix that by redefining what OVMF considers "low memory". It is the
first block of memory (with base address zero) now. This fixes the SVSM
use case outlined above. For other use cases nothing will change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add support for E820 Soft Reserved Memory regions in OVMF firmware.
This memory type is used by QEMU to expose Specific Purpose Memory (SPM).
Changes:
- Add EfiAcpiAddressRangeSoftReserved to EFI_ACPI_MEMORY_TYPE enum
- Handle SoftReserved in PlatformAddHobCB() by creating Resource HOBs
with standard memory attributes plus EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE
Background:
- E820_TYPE_SOFT_RESERVED (0xEFFFFFFF) is defined in Linux kernel:
include/uapi/linux/e820.h
- SPM (Specific Purpose Memory) is defined in ACPI 6.4+ specification
- Use cases include High Bandwidth Memory (HBM) attached to accelerators/GPUs
The 0xEFFFFFFF value follows the E820 extension convention where values
above 0x7FFFFFFF are reserved for OEM/firmware-specific use. Linux kernel
adopted this value for "soft reserved" memory that should not be used by
the OS for general allocation but can be managed by device drivers.
Signed-off-by: FangSheng Huang <FangSheng.Huang@amd.com>
This follows the update in UefiCpuPkg to use
256 IDT descriptors in SEC and SMM. This is
done to:
- Have a defined action when exceptions are
taken (use the common exception handler)
- Allow processing the stack cookie exception
gracefully instead of generating a #GP fault.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The Uni file standard specifies that comments begin with the
characters "//". The following files contained incorrectly
formatted C-style comments and have been updated:
OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/PhysicalPresenceStrings.uni
The problems were identified during testing of the parser
https://github.com/xpahos/edk2-idea.
Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
Replace traditional `#ifndef`/`#define`/`#endif` include guards with
`#pragma` once.
`#pragma once` is a widely supported preprocessor directive that
prevents header files from being included multiple times. It is
supported by all toolchains used to build edk2: GCC, Clang/LLVM, and
MSVC.
Note: Headers taken directly from external projects, such as those
in OvmfPkg/Include/IndustryStandard/Xen/ were not modified since they
may be periodically re-synced and do not follow other edk2 coding
stadards.
Compared to macro-based include guards, `#pragma once`:
- Eliminates the risk of macro name collisions or copy/paste errors
where two headers inadvertently use the same guard macro.
- Eliminate inconsistency in the way include guard macros are named
(e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.).
- Reduces boilerplate (three lines replaced by one).
- Avoids polluting the macro namespace with guard symbols.
- Can improve build times as the preprocessor can skip re-opening the
file entirely, rather than re-reading it to find the matching
`#endif` ("multiple-include optimization").
- Note that some compilers may already optimize traditional include
guards, by recognzining the idiomatic pattern.
This change is made acknowledging that overall portability of the
code will technically be reduced, as `#pragma once` is not part of the
C/C++ standards.
However, this is considered acceptable given:
1. edk2 already defines a subset of supported compilers in
BaseTools/Conf/tools_def.template, all of which have supported
`#pragma once` for over two decades.
2. There have been concerns raised to the project about inconsistent
include guard naming and potential macro collisions.
Approximate compiler support dates:
- MSVC: Supported since Visual C++ 4.2 (1996)
- GCC: Supported since 3.4 (2004)
(http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html)
- Clang (LLVM based): Since initial release in 2007
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Allow PEIMs use the MemDebugLogPeiCoreLib lib.
The difference between MemDebugLogPeiCoreLib and MemDebugLogPeiLib is
that the latter does additionally provide the MemDebugLogPages()
function, and pulls in QemuFwCfg* libraries as dependency.
Most PEIMs do not need MemDebugLogPages() though, only the ones which
handle the setup of the memory logging buffer do.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The MemDebugLogWrite() function is identical in MemDebugLogPei.c and
MemDebugLogPeiCore.c So drop it from MemDebugLogPei.c and simply add
MemDebugLogPeiCore.c to MemDebugLogPeiLib.inf instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
BaseResetShutdownXen.c relies on XEN_SCHEDOP_SHUTDOWN which is included
in IndustryStandard/Xen/sched.h.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
What happened since commit 1549bf11cc ("OvmfPkg/X86QemuLoadImageLib:
make legacy loader configurable.") ?
First, qemu 10.0 has been released, which brings support for the -shim
command line option so direct kernel boot with secure boot works.
Second, support has been added to libvirt (version v11.2.0 and newer).
Third, we got a bunch of linux distro releases. Latest debian, ubuntu
and fedora releases all have new enough edk2+qemu+libvirt packages to
support direct kernel boot with shim.efi loading and proper secure boot
verification.
Lastly, the edk2 security advisory GHSA-6pp6-cm5h-86g5 and CVE-2025-2296
have been published.
Time for the next step in tightening the screws: Flip the default for
the EnableLegacyLoader config option from true to false. Also update
the documentation accordingly.
The documentation for the config option is here:
https://github.com/tianocore/edk2/blob/master/OvmfPkg/RUNTIME_CONFIG.md#user-content-security-optorgtianocoreenablelegacyloader
Upcoming final step, in a year or two: remove the legacy loader from the
code base (drop X86QemuLoadImageLib, migrade all users to use
GenericQemuLoadImageLib instead).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Logging each and every successful cache lookup is not very useful and
floods the log.
The much better approach is to log everything which gets added to the
cache, so the logfile can tell you what is in the cache with /much/ less
log lines. The cache initialization code already does that. So drop
the lookup message without any replacement.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Drop log lines if we can't get the spin lock. Not nice, but better than
risking a deadlock.
Some background: Most of edk2 runs single-threaded on the BSP, so if
something holds the lock it is rather unlikely that waiting is going to
help. Specifically I think a deadlock can happen if (a) a timer
interrupt arrives while the lock is held, and (b) some higher-TPL timer
handler tries to print something to the debug log.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The original implementation misplaced the base addresses and lengths for
their corresponding resource descriptor HOBs. It was functional because
the size reported was large enough to cover all necessary usages.
This change fixed the misplacement and reports the entire FD flash region
when launching the MM foundation.
Signed-off-by: Kun Qin <kuqin12@gmail.com>
With SEV or SEV-ES being active uninitialized memory is random cipher
text instead of being zero-initialized. So checking against zero to
figure whenever igvm parameters are present or not is not sufficient.
Apply more strict sanity checks.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Do not use the insecure legacy linux loader (which does not
enforce secure boot checks) when running in a confidential VM.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In case HOBs are present in the IGVM data hob area register the memory
regions as bootservice data to avoid them being overwritten. Also copy
over the HOBs so they can easily be found later using standard HobLib
functions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 code from OvmfPkg. This drops irrelevant
VALID_ARCHITECTURES comments from infs that are not arch
specific.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
This commit removes OVMF IA32 from edk2 per RFC
https://edk2.groups.io/g/devel/topic/rfc_remove_ovmf_ia32_and/114152215.
OVMF IA32 is a 32 bit only platform that no longer represents the vast
majority of physical platforms. The RFC details more reasoning in
much more depth.
OVMF IA32 will be kept in a branch off the edk2-stable202508 tag for
any long term consumers; it will receive build break updates only
(e.g. if an upstream submodule changes location).
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
CPUID bit Fn8000001F_EBX[31] defines the COHERNECY_SFW_NO CPUID bit that,
when set, indicates that the software mitigation for this vulnerability is
not needed.
Add support to check for this CPUID bit and avoid the mitigation if set.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
An SNP cache coherency vulnerability may require a mitigation to evict
cache lines after memory has been validated. Perform this mitigation
after having validated memory.
CVE-2024-36331
Signed-off-by: Michael Roth <michael.roth@amd.com>
Co-developed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
There is no good reason to keep QemuFwCfgSimpleParserLib arch-specific.
Move it to the LibraryClasses section.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
In AARCH64, the PEI phase runs from the flash memory, therefore global
variables are not allowed.
Remove this optimization so that this library can be used for this
architecture.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
This check is present for every call to `MemDebugLogWrite` but it is
missing here. This may cause an unwanted write to the
buffer, when the buffer's address is not null and MemDebug is disabled.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
OvmfPkg has copied the MdeModulePkg DxeIpl behavior to
create a memory allocation HOB for page 0. That is being changed
(see that commit for details), so also remove it here.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
