summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Bhyve
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/Sec: Setup MTRR early in the boot process.Gerd Hoffmann2024-06-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically before running lzma uncompress of the main firmware volume. This is needed to make sure caching is enabled, otherwise the uncompress can be extremely slow. Adapt the ASSERTs and MTRR setup in PlatformInitLib to the changes. Background: Depending on virtual machine configuration kvm may uses EPT memory types to apply guest MTRR settings. In case MTRRs are disabled kvm will use the uncachable memory type for all mappings. The vmx_get_mt_mask() function in the linux kernel handles this and can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kvm/vmx/vmx.c?h=v6.7.1#n7580 In most VM configurations kvm uses MTRR_TYPE_WRBACK unconditionally. In case the VM has a mdev device assigned that is not the case though. Before commit e8aa4c6546ad ("UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0") kvm also ended up using MTRR_TYPE_WRBACK due to KVM_X86_QUIRK_CD_NW_CLEARED. After that commit kvm evaluates guest mtrr settings, which why setting up MTRRs early is important now. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/BhyvePkg: honor FwCfg when setting the bootorderCorvin Köhne2024-06-181-0/+1
| | | | | | | | | | | Bhyve has added support for the bootorder FwCfg file some time ago [1][2]. This FwCfg file is currently ignored by the OVMF and has no effect. Copy the relevant code from Qemu to Bhyve to make it usable. [1] https://github.com/freebsd/freebsd-src/commit/6632a0a4e3ab68b0e31b612e8aeca14de3fc8159 [2] https://github.com/freebsd/freebsd-src/commit/480bef9481f0c44b19ac4b2adb09f6c3191acd41 Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
* OvmfPkg: Don't make APIC MMIO accesses with encryption bit setMichael Roth2024-05-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | For the most part, OVMF will clear the encryption bit for MMIO regions, but there is currently one known exception during SEC when the APIC base address is accessed via MMIO with the encryption bit set for SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special handling on the hypervisor side which may not be available in the future[1], so make the necessary changes in the SEC-configured page table to clear the encryption bit for 4K region containing the APIC base address. [1] https://lore.kernel.org/lkml/20240208002420.34mvemnzrwwsaesw@amd.com/#t Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Anatol Belski <anbelski@linux.microsoft.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* Ovmfpkg: Prepare OvmfPkg to use the AmdSvsmLib libraryTom Lendacky2024-04-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 The MpInitLib library will be updated to use the new AmdSvsmLib library. To prevent any build breakage, update the OvmfPkg DSCs file to include the AmdSvsmLib NULL library. Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: remove CSM_ENABLE build macroLaszlo Ersek2023-12-071-6/+1
| | | | | | | | | | | | | | | | | | | | At this point, the CSM_ENABLE conditionals only bracket the !error directives that we added at the front of this series; it's time to remove CSM_ENABLE. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-38-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: remove Rule.Common.USER_DEFINED.CSM from all FDF filesLaszlo Ersek2023-12-071-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We no longer have INF RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf lines in any of the OVMF platform FDF files; remove the CSM rules themselves. (Note that some of the more recent platforms had cargo-culted this rule from the original ones, without ever referencing the rule with RuleOverride=CSM. Remove those rules as well.) Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-30-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: exclude Csm16.inf / Csm16.binLaszlo Ersek2023-12-072-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Csm16 module wraps the CONFIG_CSM build of SeaBIOS. "Csm16.inf" has FILE_GUID 1547B4F3-3E8A-4FEF-81C8-328ED647AB1A, which was previously referenced by the (now removed) CsmSupportLib, under the name SYSTEM_ROM_FILE_GUID. Nothing relies on the SeaBIOS binary any longer, so exclude the Csm16 module from all OVMF platforms. (Note that the "OvmfPkg/Bhyve/Csm/BhyveCsm16/BhyveCsm16.inf" pathname that the BhyveX64 platform refers to is bogus anyway.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-29-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: unplug CsmSupportLib from BdsDxeLaszlo Ersek2023-12-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CsmSupportLib is effectively a hack. It produces the following protocols: - Legacy Bios Platform, - Legacy Interrupt, - Legacy Region2. (Note that the "OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf" file contains an error where it claims that "Legacy Bios Platform" is "consumed" -- it is not; the lib instance produces that protocol). At the same time, the library instance consumes gEfiLegacyBiosProtocolGuid. This *seemingly* creates a circular dependency with LegacyBiosDxe, because that driver has the exact opposite protocol usage patterns. The solution is that LegacyBiosDxe has a DEPEX on the protocols produced by CsmSupportLib, while CsmSupportLib consumes the Legacy Bios Protocol from LegacyBiosDxe only in the member functions of the protocols it produces. Therefore, once BdsDxe is dispatched, and the CsmSupportLib constructor exposes those three protocols, LegacyBiosDxe can also be started by the DXE dispatcher, and then the protocols from CsmSupportLib become functional. But the main reason why CsmSupportLib is a hack is that it should be a normal platform DXE driver (called e.g. "CsmSupportDxe"), and not a NULL class library that's randomly hooked into BdsDxe. Given that we have removed LegacyBiosDxe earlier (so there is no DEPEX we need to satisfy now, conceptually), unhook CsmSupportLib from BdsDxe. --*-- Note that in the BhyveX64 platform, the pathname "OvmfPkg/Bhyve/Csm/CsmSupportLib/CsmSupportLib.inf" is bogus, and has always been, since commit 656419f922c0 ("Add BhyvePkg, to support the bhyve hypervisor", 2020-07-31). Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-22-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: exclude NullMemoryTestDxe driverLaszlo Ersek2023-12-072-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NullMemoryTestDxe was included in the OVMF platforms in historical commit 999a815e9ff3 ("OvmfPkg: Add NullMemoryTestDxe driver", 2011-01-21). It produces gEfiGenericMemTestProtocolGuid. With LegacyBiosDxe gone, the only consumer of this protocol in all of edk2 is "EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c". Thus, exclude NullMemoryTestDxe from all OVMF platforms. (Notably, ArmVirtPkg platforms don't include NullMemoryTestDxe either.) Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-17-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: exclude LegacyBiosDxeLaszlo Ersek2023-12-072-2/+0
| | | | | | | | | | | | | | | | | | | | | | LegacyBiosDxe is the core CSM driver. It procudes gEfiLegacyBiosProtocolGuid, on top of several smaller, more foundational legacy BIOS protocols, whose drivers we've not excluded yet. In the course of tearing down CSM support in (reverse) dependency order, exclude LegacyBiosDxe at this point. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-13-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: exclude the CSM-based VideoDxe driverLaszlo Ersek2023-12-073-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CSM-based VideoDxe driver is a special UEFI_DRIVER module that both follows and doesn't follow the UEFI driver model. Namely, in the Supported and Start members of its Driver Binding Protocol instance, it consumes the Legacy Bios Protocol directly from the UEFI protocol database, as opposed to (only) opening protocols on the handle that it is supposed to bind. Furthermore, the driver "marks" its own image handle with the NULL-interface "Legacy Bios" (pseudo-protocol) GUID, in order to "inform back" the provider of the Legacy Bios Protocol, i.e., LegacyBiosDxe, that VideoDxe is a "BIOS Thunk Driver" in the system. Quoting "OvmfPkg/Csm/Include/Guid/LegacyBios.h", such a driver follows the UEFI Driver Model, but still uses the Int86() or FarCall() services of the Legacy Bios Protocol as the basis for the UEFI protocol it produces. In a sense, there is a circular dependency between VideoDxe and LegacyBiosDxe; each knows about the other. However, VideoDxe is a UEFI_DRIVER, while LegacyBiosDxe is a platform DXE_DRIVER with a very long DEPEX. Therefore, for keeping dependencies conceptually intact, first exclude VideoDxe from the OVMF platforms. Always include the hypervisor-specific real UEFI video driver. --*-- Note that the pathname "IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf" in the bhyve platform DSC and FDF files is bogus anyway. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-9-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: unplug LegacyBootMaintUiLib from UiAppLaszlo Ersek2023-12-071-3/+0
| | | | | | | | | | | | | | | | | | | | LegacyBootMaintUiLib registers a form (HII Config Access Protocol instance) with UiApp, for configuring legacy boot options; stop plugging it into UiApp. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-6-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: unplug LegacyBootManagerLib from BdsDxe and UiAppLaszlo Ersek2023-12-071-2/+0
| | | | | | | | | | | | | | | | | | | Don't register the LegacyBmRefreshAllBootOption() and LegacyBmBoot() functions in BdsDxe and UiApp. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-4-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: cripple CSM_ENABLE macroLaszlo Ersek2023-12-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to gradually tear down and remove the Compatibility Support Module (CSM) in OvmfPkg (due to it having no maintainer). Start by making all platforms that have thus far accepted "-D CSM_ENABLE" reject that macro, so that mid-series, the partially removed infrastructure cannot be built or booted. Insert an !error directive in each DSC file's first "!ifdef $(CSM_ENABLE)" conditional. At the end of the series, the !error directive introduced in this patch will be removed. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-2-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Bhyve: use a proper PCI IO rangeCorvin Köhne2023-12-071-2/+2
| | | | | | | | | | | | | | | | | | | | | Bhyve uses an io port range of [ 0x2000, 0x10000 ] [1]. At the moment, EDKII is using a subset of this range [ 0xC000, 0x10000 ] [2]. Even though the EDKII range doesn't exceed the bhyve range, it's causing issues on some guests like OpenBSD [3]. We don't know why it's causing issues yet. However, using the same IO port range in EDKII fixes the issue and is a good idea anyway. [1] https://github.com/freebsd/freebsd-src/blob/82ea0132c8b17a7a6067c8a36c6434e587ede6de/usr.sbin/bhyve/pci_emul.c#L133-L134 [2] https://github.com/tianocore/edk2/blob/fb044b7fe893a4545995bfe2701fd38e593355d9/OvmfPkg/Bhyve/PlatformPei/Platform.c#L156-L157 [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274389 Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Add ImagePropertiesRecordLib InstanceTaylor Beebe2023-11-271-0/+1
| | | | | | | | | | | | | Add an instance of ImagePropertiesRecordLib which will be used by the DXE Core. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/Bhyve: don't exit early if RSDP is not found in memoryCorvin Köhne2023-09-081-11/+8
| | | | | | | | | | | | | | If OVMF fails to find the RSDP in memory, it should fall back installing the statically provided ACPI tables. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* MdeModulePkg: Duplicate BaseRngLibTimerLib to MdeModulePkgPierre Gondois2023-09-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504 The BaseRngLibTimerLib allows to generate number based on a timer. This mechanism allows to have a basic non-secure implementation for non-production platforms. To bind and identify Random Number Generators implementations with a GUID, an unsafe GUID should be added. This GUID cannot be added to the MdePkg unless it is also added to a specification. To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to the MdeModulePkg. This will allow to define an unsafe Rng GUID in a later patch in the MdeModulePkg. The MdePkg implementation will be removed later. This allows to give some time to platform owners to switch to the MdeModulePkg implementation. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* OvmfPkg/Bhyve: build platform info HOBCorvin Köhne2023-08-182-0/+22
| | | | | | | | | | | | | 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: cda98df16228970dcf9a4ce2af5368219711b4b0 ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported + mQemuFwCfgDmaSupported") Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/BhyvePkg: enable bus enumerationCorvin Köhne2023-07-311-1/+0
| | | | | | | | | | | | | | | | bhyve supports adding a ROM to PCI devices. It was added to support GPU passthrough of dedicated AMD GPUs. At the moment, this ROM file is mostly useless as it's not shadowed and executed by firmware. Change that by enabling bus enumeration. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
* Revert "OvmfPkg/Bhyve: remove IncompatiblePciDeviceSupport DXE driver"Corvin Köhne2023-07-312-0/+2
| | | | | | | | | | | | | | | | We like to enable bus enumeration for bhyve. Therefore, this patch needs to be reverted. This reverts commit 8c8f886f27556f2fb6e8b502d32aa9ccee930acc. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com>
* Revert "OvmfPkg/Bhyve: consume PciHostBridgeLibScan"Corvin Köhne2023-07-311-1/+1
| | | | | | | | | | | | | | | | We like to enable bus enumartion for bhyve. Therefore, this patch needs to be reverted. This reverts commit c2f24ba3218ae91a8d5a1a31c31dad3417850d0c. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/Bhyve: include TPM driverCorvin Köhne2023-06-232-2/+22
| | | | | | | | | | Bhyve will gain support for TPM emulation in the near future. Therefore, prepare OVMF by copying all TPM driver used by qemu's OVMF DSC into the bhyve OVMF DSC. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Bhyve: install Acpi tables provided by FwCfgCorvin Köhne2023-06-231-0/+5
| | | | | Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Peter Grehan <grehan@freebsd.org>
* OvmfPkg: move PciEncoding into AcpiPlatformLibCorvin Köhne2023-06-233-250/+0
| | | | | | | | | Bhyve supports providing ACPI tables by FwCfg. Therefore, InstallQemuFwCfgTables should be moved to AcpiPlatformLib to reuse the code. As first step, move PciEncoding into AcpiPlatformLib. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Peter Grehan <grehan@freebsd.org>
* OvmfPkg/Bhyve: install ACPI tables from memoryCorvin Köhne2023-06-063-1/+38
| | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/Bhyve: Replace the OVMF-specific SataControllerDxePedro Falcato2023-06-012-2/+2
| | | | | | | | | | | | 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>
* OvmfPkg/Bhyve/PlatformPei: drop S3Verification()Gerd Hoffmann2023-05-291-29/+0
| | | | | | | Drop S3Verification () which is dead code. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-106-26/+26
| | | | | | | | | | | | | __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>
* 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/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>
* mv OvmfPkg: move fdf include snippets to Include/FdfGerd Hoffmann2022-12-091-3/+3
| | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/BhyvePkg: use correct PlatformSecureLibCorvin Köhne2022-09-051-1/+1
| | | | | | | | There's no bhyve specific PlatformSecureLib any more. Use the default one of OvmfPkg which works too. Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com> Reviewed-by: Ard Biesheuvel <ardb+tianocore@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: 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/Bhyve: add support for QemuFwCfgCorvin Köhne2022-05-023-6/+40
| | | | | | | | | | | | QemuFwCfg is much more powerful than BhyveFwCtl. Sadly, BhyveFwCtl decided to use the same IO ports as QemuFwCfg. It's not possible to use both interfaces simultaneously. So, prefer QemuFwCfg over BhyveFwCtl. Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* 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: Revert Uncrustify formatting in VbeShim.h filesMichael Kubacki2022-04-041-906/+905
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3875 Reverts changes automatically applied by Uncrustify in commit ac0a286. 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: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg: Update IoMmuDxe to support TDXMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. The current IoMmuDxe driver supports DMA operations inside SEV guest. To support DMA operation in TDX guest, CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr) is used to determine if it is SEV guest or TDX guest. Due to security reasons all DMA operations inside the SEV/TDX guest must be performed on shared pages. The IOMMU protocol driver for the SEV/TDX guest uses a bounce buffer to map guest DMA buffer to shared pages in order to provide the support for DMA operations inside SEV/TDX guest. The call of SEV or TDX specific function to set/clear EncMask/SharedBit is determined by CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr). 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: Update Sec to support TdxMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 There are below major changes in this commit. 1. SecEntry.nasm In TDX BSP and APs goes to the same entry point in SecEntry.nasm. BSP initialize the temporary stack and then jumps to SecMain, just as legacy Ovmf does. APs spin in a modified mailbox loop using initial mailbox structure. Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h. APs wait for command to see if the command is for me. If so execute the command. 2. Sec/SecMain.c When host VMM create the Td guest, the system memory informations are stored in TdHob, which is a memory region described in Tdx metadata. The system memory region in TdHob should be accepted before it can be accessed. So the major task of this patch is to process the TdHobList to accept the memory. After that TDVF follow the standard OVMF flow and jump to PEI phase. PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives no chance for Intel TDX to support 1G page table. To support 1G page table this PCD is set to TRUE in OvmfPkgX64.dsc. TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the Tdx specific code. TDX only works on X64, so the code is only valid in X64 arch. 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: Bhyve: Delete unused AcpiTables/Ssdt.asl fileRebecca Cran2021-12-231-15/+0
| | | | | | | The Ssdt.asl file isn't used, so delete it. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org>
* OvmfPkg/Bhyve: fix tls-enabled buildGerd Hoffmann2021-12-171-1/+1
| | | | | | | | Path doesn't exist below OvmfPkg/Bhyve, use the OvmfPkg version instead. Fixes build with -D NETWORK_TLS_ENABLE. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/Bhyve: add MemEncryptSevLibGerd Hoffmann2021-12-131-0/+1
| | | | | | | | | | Fixes build failure: build.py... /home/kraxel/projects/edk2/OvmfPkg/Bhyve/BhyveX64.dsc(...): error 1001: Module type [SEC] is not supported by library instance [/home/kraxel/projects/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf] consumed by [/home/kraxel/projects/edk2/OvmfPkg/Sec/SecMain.inf] Signed-off-by: Gerd Hoffmann <kraxel@redhat.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: Remove unused print service driver (PrintDxe)Philippe Mathieu-Daude2021-12-102-2/+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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 01:02:47 +0000