summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Replace the OVMF-specific SataControllerDxePedro Falcato2023-06-011-1/+1
| | | | | | | | | | 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>
* OvmfPkg: Add CpuPageTableLib required by SecCore & CpuMpPeiJiaxin Wu2023-05-311-0/+1
| | | | | | | | | | | | | 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>
* OvmfPkg/VirtioSerialDxe: wire up in OvmfPkg*Gerd Hoffmann2023-05-041-0/+1
| | | | | | Add the driver to the ovmf builds. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: replace SECURE_BOOT_FEATURE_ENABLED with PcdSecureBootSupportedGerd Hoffmann2023-05-041-9/+1
| | | | | | | Drop the '-D SECURE_BOOT_FEATURE_ENABLED' compile time option, use a new FeaturePcd instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: allow setting Firmware Version from build command lineOliver Steffen2023-05-041-0/+2
| | | | | | | | | | | | | | | | 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>
* OvmfPkg: Drop special Xcode5 version of exception handler libraryArd Biesheuvel2023-04-061-4/+0
| | | | | | | | | 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>
* OvmfPkg/PlatformInitLib: move mmconfig to 0xe0000000Gerd Hoffmann2023-03-281-1/+1
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg: Remove UefiCpuLib from module INFs.Yu Pu2023-03-101-1/+0
| | | | | | | | | | | | 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>
* OvmfPkg: require self-signed PK when secure boot is enabledJan Bobek2023-02-041-0/+3
| | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: Use NestedInterruptTplLib in nested interrupt handlersMichael Brown2022-12-231-0/+1
| | | | | | | | | | | | | | | | 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>
* OvmfPkg: Add TdxMailboxLibNull in some platform dscMin M Xu2022-12-211-0/+1
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg/DebugLibIoPort: use Rom version for PEIGerd Hoffmann2022-12-141-2/+2
| | | | | | | | This variant does not use global variables. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: move dsc include snippet for Network support to Include/DscGerd Hoffmann2022-12-091-1/+1
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: move dsc and fdf include snippets for TPM support to subdirsGerd Hoffmann2022-12-091-7/+7
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/UefiCpuPkg/UefiPayloadPkg: Rename VmgExitLib to CcExitLibMin M Xu2022-11-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4123 VmgExitLib once was designed to provide interfaces to support #VC handler and issue VMGEXIT instruction. After TDVF (enable TDX feature in OVMF) is introduced, this library is updated to support #VE as well. Now the name of VmgExitLib cannot reflect what the lib does. This patch renames VmgExitLib to CcExitLib (Cc means Confidential Computing). This is a simple renaming and there is no logic changes. After renaming all the VmgExitLib related codes are updated with CcExitLib. These changes are in OvmfPkg/UefiCpuPkg/UefiPayloadPkg. Cc: Guo Dong <guo.dong@intel.com> Cc: Sean Rhodes <sean@starlabs.systems> Cc: James Lu <james.lu@intel.com> Cc: Gua Guo <gua.guo@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: James Lu <james.lu@intel.com> Reviewed-by: Gua Guo <gua.guo@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: gather common NetworkComponents overrides in .dsc.inc fileArd Biesheuvel2022-09-101-11/+1
| | | | | | | | | | | | All QEMU based OVMF platforms override the same set of network components, to specify NULL library class resolutions that modify the behavior of those components in a QEMU specific way. Before adding more occurrences of that, let's drop those definitions in a common include file. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/OvmfPkg*.dsc: Increase ACPI Reclaim memory sizeannie li2022-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | The current ACPI Reclaim memory size is set as 0x10 (64KiB). The ACPI table size will be increased if the memory slots' number of the guest gets increased. In the guest with more memory slots, the ACPI Reclaim memory size may not be sufficient for hibernation. This may cause resume failure of the hibernated guest that was booted up with a fresh copied writable OVMF_VARS file. However, the failure doesn't happen in following hibernation/resume cycles. The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI Reclaim memory. However, due to the 0x10 (16 pages) setting, 2 extra pages will be allocated in other space. This may break the hibernation/resume in the above scenario. This patch increases the ACPI Reclaim memory size to 0x12, i.e. PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12 (18 pages). Signed-off-by: Annie Li <annie.li@oracle.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add build-flag SECURE_BOOT_FEATURE_ENABLEDMin M Xu2022-09-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | SECURE_BOOT_FEATURE_ENABLED is the build-flag defined when secure boot is enabled. Currently this flag is used in below lib: - OvmfPkg/PlatformPei - PeilessStartupLib So it is defined in below 5 .dsc - OvmfPkg/CloudHv/CloudHvX64.dsc - OvmfPkg/IntelTdx/IntelTdxX64.dsc - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Add BUILD_SHELL flag for IA32, IA32X64, X64Oliver Steffen2022-09-051-1/+11
| | | | | | | | | | | | | | | | | Add BUILD_SHELL flag, similar to the one in OvmfPkg/AmdSev, to enable/disable building of the UefiShell as part of the firmware image. The UefiShell should not be included for secure production systems (e.g. SecureBoot) because it can be used to circumvent security features. The default value for BUILD_SHELL is TRUE to keep the default behavior of the Ovmf build. Note: the default for AmdSev is FALSE. The BUILD_SHELL flag for AmdSev was introduced in b261a30c900a8. Signed-off-by: Oliver Steffen <osteffen@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Change default to disable MptScsi and PvScsiMichael D Kinney2022-07-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | The email addresses for the reviewers of the MptScsi and PvScsi are no longer valid. Disable the MptScsi and PvScsi drivers in all DSC files until new maintainers/reviewers can be identified. 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: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Brijesh Singh <brijesh.singh@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: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Pipeline: Resolve SecureBootVariableLib dependencyKun Qin2022-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | The new changes in SecureBootVariableLib brought in a new dependency of PlatformPKProtectionLib. This change added the new library instance from SecurityPkg to resolve pipeline builds. 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: Kun Qin <kuqin12@gmail.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
* Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous dataNicolas Ojeda Leon2022-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the Hardware Info library, create the DxeHardwareInfoLib which implements the whole API capable of parsing heterogeneous hardware information. The list-like API grants callers a flexible and common pattern to retrieve the data. Moreover, the initial source is a BLOB which generalizes the host-to-guest transmission mechanism. The Hardware Info library main objective is to provide a way to describe non-discoverable hardware so that the host can share the available resources with the guest in Ovmf platforms. This change features and embraces the main idea behind the library by providing an API that parses a BLOB into a linked list to retrieve hardware data from any source. Additionally, list-like APIs are provided so that the hardware info list can be traversed conveniently. Similarly, the capability is provided to filter results by specific hardware types. However, heterogeneous elements can be added to the list, increasing the flexibility. This way, a single source, for example a fw-cfg file, can be used to describe several instances of multiple types of hardware. This part of the Hardware Info library makes use of dynamic memory and is intended for stages in which memory services are available. A motivation example is the PciHostBridgeLib. This library, part of the PCI driver populates the list of PCI root bridges during DXE stage for future steps to discover the resources under them. The hardware info library can be used to obtain the detailed description of available host bridges, for instance in the form of a fw-cfg file, and parse that information into a dynmaic list that allows, first to verify consistency of the data, and second discover the resources availabe for each root bridge. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfgNicolas Ojeda Leon2022-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define the HardwareInfoLib API and create the PeiHardwareInfoLib which implements it, specifically for Pei usage, supporting only static accesses to parse data directly from a fw-cfg file. All list-like APIs are implemented as unsupported and only a fw-cfg wrapper to read hardware info elements is provided. The Hardware Info library is intended to describe non-discoverable hardware information and share that from the host to the guest in Ovmf platforms. The QEMU fw-cfg extension for this library provides a first variation to parse hardware info by reading it directly from a fw-cfg file. This library offers a wrapper function to the plain QmeuFwCfgReadBytes which, specifically, parses header-data pairs out of the binary values in the file. For this purpose, the approach is incremental, reading the file block by block and outputting the values only for a specific known hardware type (e.g. PCI host bridges). One element is returned in each call until the end of the file is reached. Considering fw-cfg as the first means to transport hardware info from the host to the guest, this wrapping library offers the possibility to statically, and in steps, read a specific type of hardware info elements out of the file. This method reads one hardware element of a specific type at a time, without the need to pre-allocate memory and read the whole file or dynamically allocate memory for each new element found. As a usage example, the static approach followed by this library enables early UEFI stages to use and read hardware information supplied by the host. For instance, in early times of the PEI stage, hardware information can be parsed out from a fw-cfg file prescinding from memory services, that may not yet be available, and avoiding dynamic memory allocations. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* OvmfPkg: reduce the number of dsc include files for tpm libsGerd Hoffmann2022-06-221-4/+0
| | | | | | | | We can have multiple [LibraryClasses] sections, so we can place all TPM-related library configuration to a single include file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: fix PcdFSBClockGerd Hoffmann2022-05-251-1/+1
| | | | | | | | | | | | | kvm FSB clock is 1GHz, not 100 MHz. Timings are off by factor 10. Fix all affected build configurations. Not changed: Microvm and Cloudhw (they have already have the correct value), and Xen (has no fixed frequency, the PCD is configured at runtime by platform initialization code). Fixes: c37cbc030d96 ("OvmfPkg: Switch timer in build time for OvmfPkg") Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Add VariableFlashInfoLibMichael Kubacki2022-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479 Adds an instance of VariableFlashInfoLib to the platform build as it is a new library class introduced in MdeModulePkg. 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> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: restore CompatImageLoaderDxe chunkGerd Hoffmann2022-04-301-0/+3
| | | | | | | Was dropped by accident. Fixes: b47575801e19 ("OvmfPkg: move tcg configuration to dsc and fdf include files") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: clear PcdConOut{Row,Column}Gerd Hoffmann2022-04-221-0/+2
| | | | | | | | | ConSplitterDxe will pick the highest available resolution then, thereby making better use of the available display space. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add CcProbeLib in *.dscMin Xu2022-04-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902 CcProbeLib is imported in BaseIoLibIntrinsicSev. OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks OvmfWorkArea to return the Cc guest type. It is included in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc. Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest is not supported in those projects. Cc: James Bottomley <jejb@linux.ibm.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.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>
* OvmfPkg: Add dependency of VariableSmm driver to make it work normally.Zhihao Li2022-04-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | REF? https://bugzilla.tianocore.org/show_bug.cgi?id=3861 UefiCpuPkg define a new Protocol with the new services SmmWaitForAllProcessor(), which can be used by SMI handler to optionally wait for other APs to complete SMM rendezvous in relaxed AP mode. VariableSmm driver need use SmmCpuRendezvousLib, So add SmmCpuRendezvousLib 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: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Zhihao Li <zhihao.li@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Switch timer in build time for OvmfPkgMin Xu2022-04-021-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711 Discussion in https://bugzilla.tianocore.org/show_bug.cgi?id=1496 shows that 8254TimerDxe was not written for OVMF. It was moved over from PcAtChipsetPkg to OvmfPkg in 2019. Probably because OVMF was the only user left. Most likely the reason OVMF used 8254TimerDxe initially was that it could just use the existing driver in PcAtChipsetPkg. And it simply hasn't been changed ever. CSM support was moved in 2019 too. (CSM support depends on 8254/8259 drivers). So 8254TimerDxe will be used when CSM_ENABLE=TRUE. There are 4 .dsc which include the 8254Timer. - OvmfPkg/AmdSev/AmdSevX64.dsc - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc For the three OvmfPkg* configs using 8254TimerDxe with CSM_ENABLE=TRUE and LapicTimerDxe otherwise. For the AmdSev config it doesn't make sense to support a CSM. So use the lapic timer unconditionally. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.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> Cc: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Gerd Hoffmann <kraxel@redhat.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>
* OvmfPkg/BaseMemEncryptTdxLib: Add TDX helper libraryMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Add Intel Tdx helper library. The library provides the routines to: - set or clear Shared bit for a given memory region. - query whether TDX is enabled. Please be noted, there a lot of duplicated codes for Page Table operations. These codes should be moved to a common library (PageTablesLib) so that it is more friendly for review and maintain. There is a new feature requirement https://bugzilla.tianocore.org/show_bug.cgi?id=847 which is to implement the library. After the lib is introduced, BaseMemEncryptTdxLib will be refactored. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.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> Cc: Gerd Hoffmann <kraxel@redhat.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>
* MdeModulePkg: Add PcdTdxSharedBitMaskMin Xu2022-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Guest Physical Address (GPA) space in Td guest is divided into private and shared sub-spaces, determined by the SHARED bit of GPA. This PCD holds the shared bit mask. Its default value is 0 and it will be set in PlatformPei driver if it is of Td guest. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.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> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Create initial version of PlatformInitLibMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 There are 3 variants of PlatformPei in OvmfPkg: - OvmfPkg/PlatformPei - OvmfPkg/XenPlatformPei - OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf These PlatformPeis can share many common codes, such as Cmos / Hob / Memory / Platform related functions. This commit (and its following several patches) are to create a PlatformInitLib which wraps the common code called in above PlatformPeis. In this initial version of PlatformInitLib, below Cmos related functions are introduced: - PlatformCmosRead8 - PlatformCmosWrite8 - PlatformDebugDumpCmos They correspond to the functions in OvmfPkg/PlatformPei: - CmosRead8 - CmosWrite8 - DebugDumpCmos Considering this PlatformInitLib will be used in SEC phase, global variables and dynamic PCDs are avoided. We use PlatformInfoHob to exchange information between functions. EFI_HOB_PLATFORM_INFO is the data struct which contains the platform information, such as HostBridgeDevId, BootMode, S3Supported, SmmSmramRequire, etc. After PlatformInitLib is created, OvmfPkg/PlatformPei is refactored with this library. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.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> Cc: Gerd Hoffmann <kraxel@redhat.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>
* OvmfPkg/FvbServicesSmm: use the VmgExitLibNullBrijesh Singh2022-02-161-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3835 The commit ade62c18f4742301bbef474ac10518bde5972fba caused a boot failure when OVMF is build with SECURE_BOOT/SMM enabled. This happen because the above commit extended the BaseMemEncryptSevLib.inf to include VmgExitLib. The FvbServicesSmm uses the functions provided by the MemEncryptSevLib to clear the memory encryption mask from the page table. It created a dependency, as shown below OvmfPkg/FvbServicesSmm.inf ---> MemEncryptSevLib class ---> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance ---> VmgExitLib ---> "OvmfPkg/VmgExitLib" instance ---> LocalApicLib class ---> UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf instance ---> TimerLib class ---> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance ---> PciLib class ---> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance The LocalApicLib provides a constructor, execution of the constructor causes an exception. The SEV-ES and SEV-SNP do not support the SMM, so skip including the VmgExitLib chain. Use the module override to use the VmgExitLibNull to avoid the inclusion of unneeded LocalApicLib dependency chain in FvbServicesSmm. We ran similar issue for AmdSevDxe driver, see commit 19914edc5a0202cc7830f819ffac7e7b2368166a After the patch, the dependency look like this: OvmfPkg/FvbServicesSmm.inf ---> MemEncryptSevLib class ---> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance ---> VmgExitLib ---> "UefiCpuPkg/Library/VmgExitLibNull" instance Fixes: ade62c18f4742301bbef474ac10518bde5972fba Reported-by: Aaron Young <aaron.young@oracle.com> Cc: Dann Frazier <dann.frazier@canonical.com> Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: dann frazier <dann.frazier@canonical.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: add PcdVideoResolutionSourceGerd Hoffmann2022-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a UINT8 (enum) PCD telling where the PcdVideoHorizontalResolution and PcdVideoVerticalResolution values are coming from. It can be: 0 (unset aka default from dsc file), or 1 (from PlatformConfig), or 2 (set by Video Driver). It will be used by video drivers to avoid overriding PlatformConfig values, or override each others values in case multiple display devices are present. The underlying problem this tries to solve is that the GOP protocol has no way to indicate the preferred video mode. On physical hardware this isn't much of a problem because using the highest resolution available works just fine as that is typically the native display resolution But in a virtual machine you don't want come up with a huge 4k window by default just because the virtual vga is able to handle that. Cutting down the video mode list isn't a great solution either as that would also remove the modes from the platform configuration so the user wouldn't be able to pick a resolution higher than the default any more. So with patch drivers can use use PcdVideoHorizontalResolution and PcdVideoVerticalResolution to indicate what the preferred display resolution is, without overwriting the user preferences from PlatformConfig if present. A possible alternative approach would be to extend the GOP protocol, but I'm not sure this is a good plan given this is mostly a problem for virtual machines and using PCDs allows to keep this local to OvmfPkg. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: change qemu default resolution to 1280x800Gerd Hoffmann2022-01-291-2/+2
| | | | | | | | | | | | | | ovmf default display resolution is 800x600. This is rather small for modern guests. qemu used 1024x768 as default for a long time and switched the to 1280x800 recently[1] for the upcoming 7.0 release. This patch brings ovmf in sync with the recent qemu update and likewise switches the default to 1280x800. [1] https://gitlab.com/qemu-project/qemu/-/commit/de72c4b7cdf6ec18bfe9fe714aa96e48db6fd895 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: move tcg configuration to dsc and fdf include filesGerd Hoffmann2021-12-151-77/+11
| | | | | | | | | | | With this in place the tpm configuration is not duplicated for each of our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is easier to keep them all in sync when updating the tpm configuration. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
* OvmfPkg-EmuVariableFvbRuntimeDxe: Support Access To Memory Above 4Glixianglai2021-12-111-0/+2
| | | | | | | | | | | | | | | | In FvbInitialize Function, PcdFlashNvStorageVariableBase64 PcdFlashNvStorageFtwWorkingBase PcdFlashNvStorageFtwSpareBase will not exceed 0x100000000, Due to truncation and variable type limitations. That leads to the NV variable cannot be saved to the memory above 4G. Modify as follows: 1.Remove the forced type conversion of UINT32. 2.Use UINT64 type variables. Signed-off-by: xianglai li <lixianglai@loongson.cn> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Generalize AcpiPlatformDxeSebastien Boeuf2021-12-111-1/+1
| | | | | | | | | | | | Don't make the package Qemu centric so that we can introduce some alternative support for other VMMs not using the fw_cfg mechanism. This patch is purely about renaming existing files with no functional change. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Remove unused print service driver (PrintDxe)Philippe Mathieu-Daude2021-12-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | PrintDxe produces gEfiPrint2ProtocolGuid and gEfiPrint2SProtocolGuid, and those are consumed by the following PrintLib instance: MdeModulePkg/Library/DxePrintLibPrint2Protocol/DxePrintLibPrint2Protocol.inf However, none of the OVMF DSC files contain such a PrintLib class resolution, so none of the OVMF platforms need PrintDxe. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3744 Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformPei: set PcdConfidentialComputingAttr when SEV is activeBrijesh Singh2021-12-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MpInitLib uses the ConfidentialComputingAttr PCD to determine whether AMD SEV is active so that it can use the VMGEXITs defined in the GHCB specification to create APs. Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: add support to validate system RAMBrijesh Singh via groups.io2021-12-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Many of the integrity guarantees of SEV-SNP are enforced through the Reverse Map Table (RMP). Each RMP entry contains the GPA at which a particular page of DRAM should be mapped. The guest can request the hypervisor to add pages in the RMP table via the Page State Change VMGEXIT defined in the GHCB specification section 2.5.1 and 4.1.6. Inside each RMP entry is a Validated flag; this flag is automatically cleared to 0 by the CPU hardware when a new RMP entry is created for a guest. Each VM page can be either validated or invalidated, as indicated by the Validated flag in the RMP entry. Memory access to a private page that is not validated generates a #VC. A VM can use the PVALIDATE instruction to validate the private page before using it. During the guest creation, the boot ROM memory is pre-validated by the AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called during the SEC and PEI phase to validate the detected system RAM. One of the fields in the Page State Change NAE is the RMP page size. The page size input parameter indicates that either a 4KB or 2MB page should be used while adding the RMP entry. During the validation, when possible, the MemEncryptSevSnpValidateSystemRam() will use the 2MB entry. A hypervisor backing the memory may choose to use the different page size in the RMP entry. In those cases, the PVALIDATE instruction should return SIZEMISMATCH. If a SIZEMISMATCH is detected, then validate all 512-pages constituting a 2MB region. Upon completion, the PVALIDATE instruction sets the rFLAGS.CF to 0 if instruction changed the RMP entry and to 1 if the instruction did not change the RMP entry. The rFlags.CF will be 1 only when a memory region is already validated. We should not double validate a memory as it could lead to a security compromise. If double validation is detected, terminate the boot. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: Reference new Tcg2PlatformPei in the build systemStefan Berger2021-09-301-0/+4
| | | | | | | | | | | | | | | | | | | Compile the Tcg2PlatformPei related code now to support TPM 2 platform hierachy disablement if the TPM state cannot be resumed upon S3 resume. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Brijesh Singh <brijesh.singh@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: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: Reference new Tcg2PlatformDxe in the build system for compilationStefan Berger2021-09-301-0/+4
| | | | | | | | | | | | | | | | | | Compile the Tcg2PlatformDxe related code now. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Brijesh Singh <brijesh.singh@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: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: add SecureBootVariableLib class resolutionGrzegorz Bernacki2021-08-031-0/+2
| | | | | | | | | | | | | | The edk2 patch SecurityPkg: Create library for setting Secure Boot variables. moves generic functions from SecureBootConfigDxe and places them into SecureBootVariableLib. This patch adds SecureBootVariableLib mapping for OvmfPkg. Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Sunny Wang <sunny.wang@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: add BlobVerifierLibNull to DSCDov Murik2021-07-291-1/+4
| | | | | | | | | | | | | | | | | | | This prepares the ground for calling VerifyBlob() in QemuKernelLoaderFsDxe. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@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: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: restrict XenPlatformLib to BdsDxe in the IA32, IA32X64, X64 DSCsLaszlo Ersek2021-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf" library instance is used in the following platform DSC files in edk2: OvmfPkg/OvmfPkgIa32.dsc OvmfPkg/OvmfPkgIa32X64.dsc OvmfPkg/OvmfPkgX64.dsc OvmfPkg/OvmfXen.dsc The Xen customizations are very light-weight in this PlatformBootManagerLib instance. Isolating them statically, for the sake of the first three DSC files, would save negligible binary code size, and would likely worsen code complexity (by way of introducing new internal interfaces) or blow up source code size (by duplicating almost the entire lib instance source code). So for now, keep this one bit of Xen dynamism even on QEMU. However, because it's only PlatformBootManagerLib now that uses XenPlatformLib (for the above-stated enlightenment), restrict the XenPlatformLib class resolution in the first three DSC files to the only DXE driver that consumes PlatformBootManagerLib (and therefore XenPlatformLib): BdsDxe. This will cause a build failure later if someone attempts to call a XenPlatformLib API (that is, tries to re-introduce Xen enlightenment) in a different module in these non-Xen DSC files. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-44-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: drop PcdPciDisableBusEnumeration from the IA32, IA32X64, X64 DSCsLaszlo Ersek2021-06-041-1/+0
| | | | | | | | | | | | | | | | | | | | With the Xen-dependent PcdSetBoolS() call removed from OvmfPkg/PlatformPei, the "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc", "OvmfPkgX64.dsc" platforms never write "PcdPciDisableBusEnumeration". This means we don't need a dynamic default for the PCD in the DSC files; it could be declared Fixed-at-Build. However, because the PCD's default value in "MdeModulePkg.dec" is FALSE, remove the (same-value) platform defaults altogether. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-23-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: switch IA32, IA32X64, X64 to the fw_cfg-only ACPI platform driverLaszlo Ersek2021-06-041-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch the historical OvmfPkg* platforms from the AcpiPlatformDxe driver to the QemuFwCfgAcpiPlatformDxe driver. (The latter is used by the ArmVirtQemu* platforms as well.) The change effectively replaces the following call tree: InstallAcpiTables [AcpiPlatform.c] XenDetected [XenPlatformLib] * InstallXenTables [Xen.c] * GetXenAcpiRsdp [Xen.c] * InstallQemuFwCfgTables [QemuFwCfgAcpi.c] ... InstallOvmfFvTables [AcpiPlatform.c] * QemuDetected [Qemu.c] * LocateFvInstanceWithTables [AcpiPlatform.c] * QemuInstallAcpiTable [Qemu.c] * QemuInstallAcpiMadtTable [Qemu.c] * CountBits16 [Qemu.c] * QemuInstallAcpiSsdtTable [Qemu.c] * GetSuspendStates [Qemu.c] * PopulateFwData [Qemu.c] * with the one below: InstallAcpiTables [QemuFwCfgAcpiPlatform.c] InstallQemuFwCfgTables [QemuFwCfgAcpi.c] ... eliminating the sub-trees highlighted with "*". There are two consequences: (1) Xen compatibility is removed from the ACPI platform driver of the historical OvmfPkg* platforms. (2) The ACPI tables that are statically built into OVMF (via "OvmfPkg/AcpiTables/AcpiTables.inf") are never installed. In particular, OVMF's own runtime preparation of the MADT and SSDT is eliminated. Because of (2), remove the "OvmfPkg/AcpiTables/AcpiTables.inf" module as well -- and then the ACPITABLE build rule too. Note that (2) only removes effectively dead code; the QEMU ACPI linker-loader has taken priority since QEMU 1.7.1 (2014). References: - https://wiki.qemu.org/Planning/1.7 - https://wiki.qemu.org/Features/ACPITableGeneration - edk2 commit 96bbdbc85693 ("OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMU", 2014-03-31) - edk2 commit 387536e472aa ("OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface", 2014-09-22) Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-27 08:39:07 +0000