Tianocore/edk2.git/OvmfPkg/Include/Library/PlatformInitLib.h, branch master

OvmfPkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

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

OvmfPkg/PlatformInitLib: reserve igvm parameter area

2025-12-10T12:35:02+00:00

Signed-off-by: Gerd Hoffmann

OvmfPkg/igvm: add PlatformIgvmVpCount

2025-09-29T14:28:23+00:00

Add support for getting the cpu count via IGVM parameter. Signed-off-by: Gerd Hoffmann

OvmfPkg/igvm: handle igvm data hobs

2025-09-29T14:28:23+00:00

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

OvmfPkg/igvm: add igvm memory map support.

2025-09-29T14:28:23+00:00

In case a IGVM memory map is present in the parameter area use that when detecting guest memory. Signed-off-by: Gerd Hoffmann

OvmfPkg/PlatformPei: record "etc/msr_feature_control" presence explicitly

2025-07-23T10:10:11+00:00

A zero "FeatureControlValue" currently means "no feature control, or feature control with zero value". Distinguish both cases by explicitly recording the presence of the "etc/msr_feature_control" fw_cfg file. This will be helpful later in this series, when we won't want to touch fw_cfg again, but still know if "etc/msr_feature_control" was read OK. Signed-off-by: Laszlo Ersek

OvmfPkg: Refactor QEMU_FW_CFG_CACHE_WORK_AREA

2025-03-20T02:37:31+00:00

Move QemuFwCfgSupported and QemuFwCfgDmaSupported to the struct since they will be used as global variables in the DXE phase along with QEMU_FW_CFG_CACHE_WORK_AREA. Additionally, change its name to QEMU_FW_CFG_WORK_AREA. Cc: Erdem Aktas Cc: Jiewen Yao Cc: Min Xu Cc: Gerd Hoffmann Cc: Elena Reshetova Signed-off-by: Ceping Sun

OvmfPkg/PlatformInitLib.h: Add QEMU_FW_CFG_CACHE_WORK_AREA

2025-03-20T02:37:31+00:00

Add QEMU_FW_CFG_CACHE_WORK_AREA in EFI_HOB_PLATFORM_INFO to support reading from cache in QemuFwCfgLib. Cc: Erdem Aktas Cc: Jiewen Yao Cc: Min Xu Cc: Gerd Hoffmann Cc: Elena Reshetova Signed-off-by: Ceping Sun

OvmfPkg: Use user-specified opt/ovmf/X-PciMmio64Mb value unconditionally

2025-03-14T12:06:11+00:00

Prior to this change, OVMF considers opt/ovmf/X-PciMmio64Mb the minimum aperture size, allowing us to force the window to be larger but not smaller than what PlatformDynamicMmioWindow calculates. Adjust OVMF so that a smaller value for the aperture is honored. Context: Due to an inefficiency in the way older host kernels manage pfnmaps for guest VM memory ranges [0], guests with large-BAR GPUs passed-through have a very long (multiple minutes) initialization time when the MMIO window advertised by OVMF is sufficiently sized for the passed-through BARs (i.e., the correct OVMF behavior). However, on older distro series such as Ubuntu Jammy, users have benefited from fast guest boot times when OVMF advertised an MMIO window that was too small to accommodate the full BAR, since this resulted in the long PCI initialization process being skipped (and retried later, if pci=realloc pci=nocrs were set). While the root cause is being fully addressed in the upstream kernel [1], the solution relies on huge pfnmap support, which is a substantial series with many ABI changes that is unlikely to land in many LTS and legacy distro kernels, including those of Ubuntu Noble. As a result, the only kernel improvement supported on those kernels is this patch [2], which reduces the extra boot time by about half. Unfortunately, that boot time is still an average of 1-3 minutes longer per-VM-boot than what can be achieved when the host is running a version of OVMF without PlatformDynamicMmioWindow (PDMW) support (introduced in [3]) Since there is no way to force the use of the classic MMIO window size[4] in any version of OVMF after [3], and since we have a use case for such functionality on legacy distro kernels that would yield significant, recurring compute time savings across all impacted VMs, this change to this knob's behavior seems appropriate. [0]: https://lore.kernel.org/all/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com/ [1]: https://lore.kernel.org/all/20250205231728.2527186-1-alex.williamson@redhat.com/ [2]: https://lore.kernel.org/all/20250111210652.402845-1-alex.williamson@redhat.com/ [3]: ecb778d [4]: https://edk2.groups.io/g/devel/topic/109651206?p=Created,,,20,1,0,0 Signed-off-by: Mitchell Augustin

OvmfPkg: Refactor ProcessHobList

2023-02-04T03:38:15+00:00

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 Cc: James Bottomley Cc: Jiewen Yao Cc: Gerd Hoffmann Cc: Tom Lendacky Cc: Michael Roth Acked-by: Gerd Hoffmann Reviewed-by: Jiewen Yao Signed-off-by: Min Xu