summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgX64.fdf
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Don't make APIC MMIO accesses with encryption bit setMichael Roth2024-05-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Add VirtHstiDxe to OVMF firmware buildKonstantin Kostiuk2024-04-221-0/+1
| | | | | | | | Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: Create a calling area used to communicate with the SVSMTom Lendacky2024-04-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 An SVSM requires a calling area page whose address (CAA) is used by the SVSM to communicate and process the SVSM request. Add a pre-defined page area to the OvmfPkg and AmdSev packages and define corresponding PCDs used to communicate the location and size of the area. Keep the AmdSev package in sync with the OvmfPkg and adjust the AmdSev launch and hash area memory locations. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.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> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg: Update TdTcg2Dxe path in OvmfPkgX64 and IntelTdxX64.dscMin M Xu2024-04-171-1/+1
| | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4752 Previously the TdTcg2Dxe and its corresponding HashLibTdx were in SecurityPkg. This patch updates the paths in OvmfPkgX64.dsc and IntelTdxX64.dsc after TdTcg2Dxe and HashLibTdxLib have been moved to OvmfPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: 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 ShellDxe.fdf.incGerd Hoffmann2024-02-251-9/+2
| | | | | | | | | | Move EFI Shell firmware volume files to the new ShellDxe.fdf.inc file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Message-Id: <20240222101358.67818-4-kraxel@redhat.com>
* OvmfPkg: exclude 8259InterruptControllerDxeLaszlo Ersek2023-12-071-3/+0
| | | | | | | | | | | | | | | | With 8254TimerDxe gone, no module in OVMF consumes gEfiLegacy8259ProtocolGuid; exclude 8259InterruptControllerDxe therefore. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-34-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 8254TimerDxeLaszlo Ersek2023-12-071-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | In the original three OVMF platforms, CSM_ENABLE selects the legacy timer driver; exclude it. Instead, include LocalApicTimerDxe unconditionally (which in turn consumes PcdFSBClock). Background: commits c37cbc030d96 ("OvmfPkg: Switch timer in build time for OvmfPkg", 2022-04-02) and 07c0c2eb0a59 ("OvmfPkg: fix PcdFSBClock", 2022-05-25). Regression test: verified that the BDS progress bar still advanced at normal speed in each platform. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-32-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-071-4/+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: exclude NullMemoryTestDxe driverLaszlo Ersek2023-12-071-1/+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-071-1/+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-071-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: raise DXEFV size to 14.5 MB in the traditional platform FDFsLaszlo Ersek2023-09-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My usual IA32X64 and X64 builds fail for the NOOPT target, using GCC5: - IA32X64: > the required fv image size 0xdef130 exceeds the set fv image size > 0xd00000 - X64: > the required fv image size 0xd8f7b8 exceeds the set fv image size > 0xd00000 NOOPT is important for debugging (less confusing behavior with gdb, and much less confusing disassembly). Raise the DXEFV size to 14.5 MB (14 MB would work, but cut it too close for IA32X64). After this patch: - IA32: > DXEFV [83%Full] 15204352 (0xe80000) total, 12718784 (0xc212c0) used, > 2485568 (0x25ed40) free - IA32X64: > DXEFV [96%Full] 15204352 (0xe80000) total, 14610736 (0xdef130) used, > 593616 (0x90ed0) free - X64: > DXEFV [93%Full] 15204352 (0xe80000) total, 14219192 (0xd8f7b8) used, > 985160 (0xf0848) free Tested with: - IA32, q35, SMM_REQUIRE, Fedora 30 guest - X64, pc (i440fx), no SMM, RHEL-7.9 guest - IA32X64, q35, SMM_REQUIRE, RHEL-7.9 guest Test steps (IA32 and X64): - configure 3 VCPUs - boot - run "taskset -c $I efibootmgr" with $I covering 0..2 - systemctl suspend - resume from virt-manager - run "taskset -c $I efibootmgr" with $I covering 0..2 Test steps (IA32X64): - same, but - start with only 2 cold-plugged CPUs, and - hot-plug the third VCPU after initial (cold) boot, before the first "taskset -c $I efibootmgr" invocation Also compared the verbose IA32 fw log from before the patch vs. the one after (because IA32 builds even without this patch); the changes look sane: > @@ -1,6 +1,6 @@ > SecCoreStartupWithStack(0xFFFCC000, 0x820000) > SEC: Normal boot > -DecompressMemFvs: OutputBuffer@A00000+0xDE0090 ScratchBuffer@1800000+0x10000 PcdOvmfDecompressionScratchEnd=0x1810000 > +DecompressMemFvs: OutputBuffer@A00000+0xF60090 ScratchBuffer@1A00000+0x10000 PcdOvmfDecompressionScratchEnd=0x1A10000 > Register PPI Notify: [EfiPeiSecurity2Ppi] > Install PPI: [EfiFirmwareFileSystem2] > Install PPI: [EfiFirmwareFileSystem3] > @@ -28,7 +28,7 @@ > Loading PEIM at 0x000008490C0 EntryPoint=0x0000085639A PlatformPei.efi > Platform PEIM Loaded > CMOS: > -00: 10 00 30 00 13 00 03 12 09 23 26 02 00 80 00 00 > +00: 20 00 41 00 13 00 03 12 09 23 26 02 00 80 00 00 > 10: 00 00 00 00 06 80 02 FF FF 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: FF FF 20 00 00 7F 00 20 30 00 00 00 00 12 00 00 > @@ -70,7 +70,7 @@ > Platform PEI Firmware Volume Initialization > Install PPI: [EfiPeiFirmwareVolumeInfoPpi] > Notify: PPI Guid: [EfiPeiFirmwareVolumeInfoPpi], Peim notify entry point: 826554 > -The 1th FV start address is 0x00000900000, size is 0x00D00000, handle is 0x900000 > +The 1th FV start address is 0x00000900000, size is 0x00E80000, handle is 0x900000 > Register PPI Notify: [EfiPeiReadOnlyVariable2Ppi] > Select Item: 0x19 > Select Item: 0x26 > @@ -90,8 +90,8 @@ > Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF > Memory Allocation 0x00000000 0x30000 - 0x4FFFF > Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF > -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF > -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF > +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF > +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF > Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF > Old Stack size 32768, New stack size 131072 > Stack Hob: BaseAddress=0x7AF68000 Length=0x20000 > @@ -196,8 +196,8 @@ > Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF > Memory Allocation 0x00000000 0x30000 - 0x4FFFF > Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF > -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF > -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF > +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF > +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF > Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF > Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF > Memory Allocation 0x00000003 0x7EF50000 - 0x7EF67FFF > @@ -219,7 +219,7 @@ > Memory Allocation 0x00000003 0x7EE70000 - 0x7EEB2FFF > Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF > Memory Allocation 0x00000004 0x7AF68000 - 0x7AF87FFF > -FV Hob 0x900000 - 0x15FFFFF > +FV Hob 0x900000 - 0x177FFFF > InstallProtocolInterface: [EfiDecompressProtocol] 7EEAAA54 > InstallProtocolInterface: [EfiFirmwareVolumeBlockProtocol|EfiFirmwareVolumeBlock2Protocol] 7EB3491C > InstallProtocolInterface: [EfiDevicePathProtocol] 7EB34990 > @@ -3259,7 +3259,7 @@ > UefiMemory protection: 0x50000 - 0x9E000 Success > UefiMemory protection: 0x100000 - 0x807000 Success > UefiMemory protection: 0x808000 - 0x810000 Success > -UefiMemory protection: 0x1810000 - 0x7AF88000 Success > +UefiMemory protection: 0x1A10000 - 0x7AF88000 Success > UefiMemory protection: 0x7AF8B000 - 0x7EB3D000 Success > UefiMemory protection: 0x7EDBD000 - 0x7EDCF000 Success > UefiMemory protection: 0x7EE4F000 - 0x7EF68000 Success Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* 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: move OvmfTpmDxe.fdf.inc to Include/FdfGerd Hoffmann2023-05-061-1/+1
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: move OvmfTpmPei.fdf.inc to Include/FdfGerd Hoffmann2023-05-061-1/+1
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@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: Support Tdx measurement in OvmfPkgX64Min M Xu2023-02-041-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243 This patch enables Tdx measurement in OvmfPkgX64 with below changes: 1) CC_MEASUREMENT_ENABLE is introduced in OvmfPkgX64.dsc. This flag indicates if Intel TDX measurement is enabled in OvmfPkgX64. Its default value is FALSE. 2) Include TdTcg2Dxe in OvmfPkgX64 so that CC_MEASUREMENT_PROTOCOL is installed in a Td-guest. TdTcg2Dxe is controlled by TDX_MEASUREMENT_ENABLE because it is only valid when Intel TDX measurement is enabled. 3) OvmfTpmLibs.dsc.inc and OvmfTpmSecurityStub.dsc.inc are updated because DxeTpm2MeasureBootLib.inf and DxeTpmMeasurementLib.inf should be included to support CC_MEASUREMENT_PROTOCOL. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: raise DXEFV size to 13 MB in the traditional platform FDFsLaszlo Ersek2023-01-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since commit 5e75c4d1fe4f ("OvmfPkg: raise DXEFV size to 12 MB", 2020-03-11), and we've outgrown DXEFV again (with NOOPT builds). Increase the DXEFV size to 13MB now. Do not modify all platform FDF files under OvmfPkg. "BhyveX64.fdf" is still at 11MB, "OvmfXen.fdf" at 10MB. The "AmdSevX64.fdf", "CloudHvX64.fdf", "IntelTdxX64.fdf" and "MicrovmX64.fdf" flash devices could be modified similarly (from 12MB to 13MB), but I don't use or build those platforms. Tested on: - IA32, q35, SMM_REQUIRE, Fedora 30 guest - X64, pc (i440fx), no SMM, RHEL-7.9 guest - IA32X64, q35, SMM_REQUIRE, RHEL-7.9 guest Test steps: - configure 3 VCPUs - boot - run "taskset -c $I efibootmgr" with $I covering 0..2 - systemctl suspend - resume from virt-manager - run "taskset -c $I efibootmgr" with $I covering 0..2 Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Min Xu <min.m.xu@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4236 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* mv OvmfPkg: move fdf include snippets to Include/FdfGerd Hoffmann2022-12-091-4/+4
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Add BUILD_SHELL flag for IA32, IA32X64, X64Oliver Steffen2022-09-051-1/+3
| | | | | | | | | | | | | | | | | 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: Make an Ia32/X64 hybrid build work with SEVTom Lendacky2022-05-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | The BaseMemEncryptSevLib functionality was updated to rely on the use of the OVMF/SEV workarea to check for SEV guests. However, this area is only updated when running the X64 OVMF build, not the hybrid Ia32/X64 build. Base SEV support is allowed under the Ia32/X64 build, but it now fails to boot as a result of the change. Update the ResetVector code to check for SEV features when built for 32-bit mode, not just 64-bit mode (requiring updates to both the Ia32 and Ia32X64 fdf files). Fixes: f1d1c337e7c0575da7fd248b2dd9cffc755940df 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: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Enable 2 different CpuMpPei and CpuDxe driversMin M Xu2022-05-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3918 In OvmfPkgX64 we enable 2 different CpuMpPei and CpuDxe drivers. The difference between the drivers is the MpInitLib or MpInitLibUp. This is acomplished by adding a MpInitLibDepLib. In IntelTdxX64 we enable 2 versions of CpuDxe drivers. It is because PEI is skipped in IntelTdxX64. 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: 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> Signed-off-by: Min Xu <min.m.xu@intel.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg/OvmfPkgX64: Adjust load sequence of TdxDxe and AmdSevDxe driverMin Xu2022-04-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3904 TdxDxe driver is introduced for Intel TDX feature. Unfortunately, this driver also breaks boot process in SEV-ES guest. The root cause is in the PciLib which is imported by TdxDxe driver. In a SEV-ES guest the AmdSevDxe driver performs a MemEncryptSevClearMmioPageEncMask() call against the PcdPciExpressBaseAddress range to mark it shared/unencrypted. However, the TdxDxe driver is loaded before the AmdSevDxe driver, and the PciLib in TdxDxe is DxePciLibI440FxQ35 which will access the PcdPciExpressBaseAddress range. Since the range has not been marked shared/unencrypted, the #VC handler terminates the guest for trying to do MMIO to an encrypted region. Adjusting the load sequence of TdxDxe and AmdSevDxe can fix the issue. 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> SEV-Tested-by: Tom Lendacky <thomas.lendacky@amd.com> TDX-Tested-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Switch timer in build time for OvmfPkgMin Xu2022-04-021-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add TdxDxe driverMin Xu2022-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 TdxDxe driver is dispatched early in DXE, due to being list in APRIORI. This module is responsible for below features: - Sets max logical cpus based on TDINFO - Sets PCI PCDs based on resource hobs - Set shared bit in MMIO region - Relocate Td mailbox and set its address in MADT table. 1. Set shared bit in MMIO region Qemu allows a ROM device to set to ROMD mode (default) or MMIO mode. When it is in ROMD mode, the device is mapped to guest memory and satisfies read access directly. In EDK2 Option ROM is treated as MMIO region. So Tdx guest access Option ROM via TDVMCALL(MMIO). But as explained above, since Qemu set the Option ROM to ROMD mode, the call of TDVMCALL(MMIO) always return INVALID_OPERAND. Tdvf then falls back to direct access. This requires to set the shared bit to corresponding PageTable entry. Otherwise it triggers GP fault. TdxDxe's entry point is the right place to set the shared bit in MMIO region because Option ROM has not been discoverd yet. 2. Relocate Td mailbox and set the new address in MADT Mutiprocessor Wakeup Table. In TDX the guest firmware is designed to publish a multiprocessor-wakeup structure to let the guest-bootstrap processor wake up guest-application processors with a mailbox. The mailbox is memory that the guest firmware can reserve so each guest virtual processor can have the guest OS send a message to them. The address of the mailbox is recorded in the MADT table. See [ACPI]. TdxDxe registers for protocol notification (gQemuAcpiTableNotifyProtocolGuid) to call the AlterAcpiTable(), in which MADT table is altered by the above Mailbox address. The protocol will be installed in AcpiPlatformDxe when the MADT table provided by Qemu is ready. This is to maintain the simplicity of the AcpiPlatformDxe. AlterAcpiTable is the registered function which traverses the ACPI table list to find the original MADT from Qemu. After the new MADT is configured and installed, the original one will be uninstalled. [ACPI] https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model /ACPI_Software_Programming_Model.html#multiprocessor-wakeup-structure 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: move tcg configuration to dsc and fdf include filesGerd Hoffmann2021-12-151-15/+2
| | | | | | | | | | | 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: 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: reserve CPUID pageBrijesh Singh via groups.io2021-12-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Platform features and capabilities are traditionally discovered via the CPUID instruction. Hypervisors typically trap and emulate the CPUID instruction for a variety of reasons. There are some cases where incorrect CPUID information can potentially lead to a security issue. The SEV-SNP firmware provides a feature to filter the CPUID results through the PSP. The filtered CPUID values are saved on a special page for the guest to consume. Reserve a page in MEMFD that will contain the results of filtered CPUID values. 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: reserve SNP secrets pageBrijesh Singh via groups.io2021-12-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 During the SNP guest launch sequence, a special secrets page needs to be inserted by the VMM. The PSP will populate the page; it will contain the VM Platform Communication Key (VMPCKs) used by the guest to send and receive secure messages to the PSP. The purpose of the secrets page in the SEV-SNP is different from the one used in SEV guests. In SEV, the secrets page contains the guest owner's private data after the remote attestation. 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/+1
| | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | | | | | | 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: introduce a common work areaBrijesh Singh2021-08-271-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Both the TDX and SEV support needs to reserve a page in MEMFD as a work area. The page will contain meta data specific to the guest type. Currently, the SEV-ES support reserves a page in MEMFD (PcdSevEsWorkArea) for the work area. This page can be reused as a TDX work area when Intel TDX is enabled. Based on the discussion [1], it was agreed to rename the SevEsWorkArea to the OvmfWorkArea, and add a header that can be used to indicate the work area type. [1] https://edk2.groups.io/g/devel/message/78262?p=,,,20,0,0,0::\ created,0,SNP,20,2,0,84476064 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> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: switch IA32, IA32X64, X64 to the fw_cfg-only ACPI platform driverLaszlo Ersek2021-06-041-8/+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>
* OvmfPkg: remove the Xen drivers from the IA32, IA32X64, and X64 platformsLaszlo Ersek2021-06-041-3/+0
| | | | | | | | | | | | | | | | | | Remove the three Xen drivers as the first step for removing Xen support from the historical OvmfPkg* platforms. Xen (HVM and PVH) guests are supported by the dedicated OvmfXen platform. No module remains dependent on XenHypercallLib, so remove the XenHypercallLib class resolutions too, from the 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-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/TpmMmioSevDecryptPei: Mark TPM MMIO range as unencrypted for SEV-ESLendacky, Thomas2021-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3345 During PEI, the MMIO range for the TPM is marked as encrypted when running as an SEV guest. While this isn't an issue for an SEV guest because of the way the nested page fault is handled, it does result in an SEV-ES guest terminating because of a mitigation check in the #VC handler to prevent MMIO to an encrypted address. For an SEV-ES guest, this range must be marked as unencrypted. Create a new x86 PEIM for TPM support that will map the TPM MMIO range as unencrypted when SEV-ES is active. The gOvmfTpmMmioAccessiblePpiGuid PPI will be unconditionally installed before exiting. The PEIM will exit with the EFI_ABORTED status so that the PEIM does not stay resident. This new PEIM will depend on the installation of the permanent PEI RAM, by PlatformPei, so that in case page table splitting is required during the clearing of the encryption bit, the new page table(s) will be allocated from permanent PEI RAM. Update all OVMF Ia32 and X64 build packages to include this new PEIM. Cc: Laszlo Ersek <lersek@redhat.com> 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: Min Xu <min.m.xu@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <42794cec1f9d5bc24cbfb9dcdbe5e281ef259ef5.1619716333.git.thomas.lendacky@amd.com> [lersek@redhat.com: refresh subject line] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/VmgExitLib: Support nested #VCsTom Lendacky2021-01-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In order to be able to issue messages or make interface calls that cause another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support for nested #VCs. In order to support nested #VCs, GHCB backup pages are required. If a #VC is received while currently processing a #VC, a backup of the current GHCB content is made. This allows the #VC handler to continue processing the new #VC. Upon completion of the new #VC, the GHCB is restored from the backup page. The #VC recursion level is tracked in the per-vCPU variable area. Support is added to handle up to one nested #VC (or two #VCs total). If a second nested #VC is encountered, an ASSERT will be issued and the vCPU will enter CpuDeadLoop (). For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory layout, with two new fixed PCDs to provide the address and size of the backup area. For PEI/DXE, the GHCB backup pages are allocated as boot services pages using the memory allocation library. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg: introduce VirtioFsDxeLaszlo Ersek2020-12-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the driver is to ease file exchange (file sharing) between the guest firmware and the virtualization host. The driver is supposed to interoperate with QEMU's "virtiofsd" (Virtio Filesystem Daemon). References: - https://virtio-fs.gitlab.io/ - https://libvirt.org/kbase/virtiofs.html VirtioFsDxe will bind virtio-fs devices, and produce EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them. In the longer term, assuming QEMU will create "bootorder" fw_cfg file entries for virtio-fs devices, booting guest OSes from host-side directories should become possible (dependent on the matching QemuBootOrderLib enhancement). Add the skeleton of the driver. Install EFI_DRIVER_BINDING_PROTOCOL with stub member functions. Install EFI_COMPONENT_NAME2_PROTOCOL with final member functions. This suffices for the DRIVERS command in the UEFI Shell to list the driver with a human-readable name. The file permission model is described immediately in the INF file as a comment block, for future reference. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201216211125.19496-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: enable HttpDynamicCommandVladimir Olovyannikov2020-10-011-0/+1
| | | | | | | | | | | Enable HttpDynamicCommand (Shell command "http") for OvmfPkg platforms. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2857 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Message-Id: <20200722205434.4348-3-vladimir.olovyannikov@broadcom.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove groups.io corruption from Author meta-datum]
* OvmfPkg: Reserve a page in memory for the SEV-ES usageTom Lendacky2020-08-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Reserve a fixed area of memory for SEV-ES use and set a fixed PCD, PcdSevEsWorkAreaBase, to this value. This area will be used by SEV-ES support for two purposes: 1. Communicating the SEV-ES status during BSP boot to SEC: Using a byte of memory from the page, the BSP reset vector code can communicate the SEV-ES status to SEC for use before exception handling can be enabled in SEC. After SEC, this field is no longer valid and the standard way of determine if SEV-ES is active should be used. 2. Establishing an area of memory for AP boot support: A hypervisor is not allowed to update an SEV-ES guest's register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead an SEV-ES AP must be re-directed from within the guest to the actual requested staring location as specified in the INIT-SIPI-SIPI sequence. Use this memory for reset vector code that can be programmed to have the AP jump to the desired RIP location after starting the AP. This is required for only the very first AP reset. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Create a GHCB page for use during Sec phaseTom Lendacky2020-08-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A GHCB page is needed during the Sec phase, so this new page must be created. Since the #VC exception handler routines assume that a per-CPU variable area is immediately after the GHCB, this per-CPU variable area must also be created. Since the GHCB must be marked as an un-encrypted, or shared, page, an additional pagetable page is required to break down the 2MB region where the GHCB page lives into 4K pagetable entries. Create a new entry in the OVMF memory layout for the new page table page and for the SEC GHCB and per-CPU variable pages. After breaking down the 2MB page, update the GHCB page table entry to remove the encryption mask. The GHCB page will be used by the SEC #VC exception handler. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB in order to perform the requested function. Four new fixed PCDs are needed to support the SEC GHCB page: - PcdOvmfSecGhcbBase UINT32 value that is the base address of the GHCB used during the SEC phase. - PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the GHCB area used during the SEC phase. - PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page table page used to break down the 2MB page into 512 4K pages. - PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes, of the page table page. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/LsiScsiDxe: Create the empty driverGary Lin2020-07-171-0/+3
| | | | | | | | | | | | | | Create the driver with only a dummy LsiScsiEntryPoint() for the further implementation of the driver for LSI 53C895A SCSI controller. v2: Fix the mixed-case GUID string Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200717061130.8881-2-glin@suse.com>
* OvmfPkg: Skip initrd command on Xcode toolchainRoman Bolshakov2020-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF booting stops with the assert if built with Xcode on macOS: Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398 ProtectUefiImageCommon - 0x1F218140 - 0x000000001FAB8000 - 0x0000000000008A60 ASSERT_EFI_ERROR (Status = Unsupported) ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status) The assert comes from InitializeHiiPackage() after an attempt to retrieve HII package list from ImageHandle. Xcode still doesn't support HII resource section and LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a ("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"), disable initrd command if built with Xcode toolchain Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MptScsiDxe: Create empty driverNikita Leshenko2020-05-051-0/+3
| | | | | | | | | | | In preparation for implementing LSI Fusion MPT SCSI devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-2-nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Create empty driverLiran Alon2020-03-301-0/+3
| | | | | | | | | | | In preparation for support booting from PvScsi devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-2-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg: give more telling names to some FDF include filesLaszlo Ersek2020-03-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Leif suggested that FDF include files should preferably refer with their names to the FDF file sections from which they are included. Therefore - rename "OvmfPkg.fdf.inc" to "OvmfPkgDefines.fdf.inc" (included from the [Defines] section), - rename "DecomprScratchEnd.fdf.inc" to "FvmainCompactScratchEnd.fdf.inc" (included under the [FV.FVMAIN_COMPACT] section). Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: http://mid.mail-archive.com/20200312142006.GG23627@bivouac.eciton.net Ref: https://edk2.groups.io/g/devel/message/55812 Suggested-by: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200312223555.29267-3-lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: include FaultTolerantWritePei and VariablePei with -D SMM_REQUIRELaszlo Ersek2020-03-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FaultTolerantWritePei consumes: - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase. VariablePei consumes: - PcdFlashNvStorageVariableBase64. Due to the previous patches in this series, the above PCDs are available in the PEI phase, in the SMM_REQUIRE build. FaultTolerantWritePei produces a GUID-ed HOB with FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB. VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes the HOB (which is safe due to the DEPEX), and produces EFI_PEI_READ_ONLY_VARIABLE2_PPI. This enables read-only access to non-volatile UEFI variables in the PEI phase, in the SMM_REQUIRE build. For now, the DxeLoadCore() function in "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the "MemoryTypeInformation" variable, because OVMF's PlatformPei always produces the MemoryTypeInformation HOB. (Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build the HOB, but that's in sync with DxeLoadCore() also not looking for either the HOB or the UEFI variable.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.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=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-5-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: raise DXEFV size to 12 MBLaszlo Ersek2020-03-111-3/+3
| | | | | | | | | | | | | | | | Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've outgrown DXEFV again. Increase the DXEFV size to 12MB now. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2585 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310175025.18849-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: add new QEMU kernel image loader componentsArd Biesheuvel2020-03-051-0/+1
| | | | | | | | | | Add the components that expose the QEMU abstract loader file system so that we can switch over our PlatformBmLib over to it in a subsequent patch. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 19:33:37 +0000