summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)AuthorFilesLines
2023-12-07OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presenceLaszlo Ersek2-140/+6
The UEFI protocol database cannot contain gEfiLegacyBiosProtocolGuid any longer, after excluding LegacyBiosDxe from the OVMF platforms. Therefore, instruct PciBusDxe from IncompatiblePciDeviceSupportDxe to allocate 64-bit BARs above 4 GB regardless of a CSM. Regression test: in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25), where we introduced IncompatiblePciDeviceSupportDxe, we said, "By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space". Therefore it suffices to verify the 64-bit BARs of a device for which QEMU provides an option ROM. The simplest case is the virtio-net-pci device. And indeed, with this patch applied, the log contains: > PciBus: Discovered PCI @ [04|00|00] [VID = 0x1AF4, DID = 0x1041] > BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x14 > BAR[4]: Type = PMem64; Alignment = 0x3FFF; Length = 0x4000; Offset = 0x20 This portion shows that Bus|Device|Function 04|00|00 is a (modern) virito-net-pci device [VID = 0x1AF4, DID = 0x1041]. > PciBus: Resource Map for Bridge [00|01|03] > Type = Mem32; Base = 0x81200000; Length = 0x200000; Alignment = 0x1FFFFF > Base = Padding; Length = 0x200000; Alignment = 0x1FFFFF > Base = 0x81200000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [04|00|00:14] > Type = Mem32; Base = 0x81A43000; Length = 0x1000; Alignment = 0xFFF > Type = PMem64; Base = 0x800200000; Length = 0x100000; Alignment = 0xFFFFF > Base = 0x800200000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [04|00|00:20] This quote shows that 04|00|00 has a BAR at 0x8_0020_0000. (It also shows that the device is behind a bridge (PCIe root port) whose own BDF is 00|01|03.) > [Security] 3rd party image[7CEEB418] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/Offset(0x10E00,0x273FF). > None of Tcg2Protocol/CcMeasurementProtocol is installed. > InstallProtocolInterface: [EfiLoadedImageProtocol] 7D2E5140 > Loading driver at 0x0007CA9F000 EntryPoint=0x0007CAA5447 1af41000.efi > InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7D5B2198 And this part finally shows that the iPXE option ROM for the device (1af41000.efi) was detected and is loaded. (Same PCIe root port, and PCIe root ports can only host a single device.) 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-14-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>
2023-12-07OvmfPkg: exclude LegacyBiosDxeLaszlo Ersek10-10/+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>
2023-12-07OvmfPkg: remove Bios Video PCDsLaszlo Ersek1-20/+0
PcdBiosVideoSetTextVgaModeEnable, PcdBiosVideoCheckVbeEnable and PcdBiosVideoCheckVgaEnable are unused at this point, remove them. This shrinks the list of resources scheduled for removal to: - GUIDs (protocols or otherwise): - gEfiLegacyBiosGuid - gEfiLegacyBiosProtocolGuid - headers: - FrameworkDxe.h - Guid/LegacyBios.h - Protocol/LegacyBios.h 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-12-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>
2023-12-07OvmfPkg: remove gEfiVgaMiniPortProtocolGuidLaszlo Ersek2-89/+0
At this point, gEfiVgaMiniPortProtocolGuid is unused; remove it. This shrinks the list of resources scheduled for removal to: - GUIDs (protocols or otherwise): - gEfiLegacyBiosGuid - gEfiLegacyBiosProtocolGuid - headers: - FrameworkDxe.h - Guid/LegacyBios.h - Protocol/LegacyBios.h - PCDs: - PcdBiosVideoCheckVbeEnable - PcdBiosVideoCheckVgaEnable - PcdBiosVideoSetTextVgaModeEnable 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-11-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>
2023-12-07OvmfPkg: remove Csm/BiosThunk/VideoDxeLaszlo Ersek7-4753/+0
Csm/BiosThunk/VideoDxe is not used by any platform at this point, remove it. This patch removes mentions of the following CSM resources from the source code: - GUIDs (protocols or otherwise): - gEfiLegacyBiosGuid - gEfiLegacyBiosProtocolGuid - gEfiVgaMiniPortProtocolGuid - headers: - FrameworkDxe.h - Guid/LegacyBios.h - Protocol/LegacyBios.h - Protocol/VgaMiniPort.h - PCDs: - PcdBiosVideoCheckVbeEnable - PcdBiosVideoCheckVgaEnable - PcdBiosVideoSetTextVgaModeEnable which extends the list of resources scheduled for removal to: - GUIDs (protocols or otherwise): - gEfiLegacyBiosGuid - gEfiLegacyBiosProtocolGuid - gEfiVgaMiniPortProtocolGuid - headers: - FrameworkDxe.h - Guid/LegacyBios.h - Protocol/LegacyBios.h - Protocol/VgaMiniPort.h - PCDs: - PcdBiosVideoCheckVbeEnable - PcdBiosVideoCheckVgaEnable - PcdBiosVideoSetTextVgaModeEnable 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-10-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>
2023-12-07OvmfPkg: exclude the CSM-based VideoDxe driverLaszlo Ersek12-45/+3
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>
2023-12-07OvmfPkg: remove gEfiLegacyDevOrderVariableGuidLaszlo Ersek2-40/+0
At this point, gEfiLegacyDevOrderVariableGuid is unused; remove it. This shrinks the list of resources scheduled for removal to: - GUIDs (protocols or otherwise): - gEfiLegacyBiosProtocolGuid - headers: - Protocol/LegacyBios.h 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-8-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>
2023-12-07OvmfPkg: remove LegacyBootMaintUiLibLaszlo Ersek7-2007/+0
LegacyBootMaintUiLib is not used by any platform at this point, remove it. This patch removes mentions of the following CSM resources from the source code: - GUIDs (protocols or otherwise): - gEfiLegacyBiosProtocolGuid - gEfiLegacyDevOrderVariableGuid - headers: - Guid/LegacyDevOrder.h - Protocol/LegacyBios.h which extends the list of resources scheduled for removal to: - GUIDs (protocols or otherwise): - gEfiLegacyBiosProtocolGuid - gEfiLegacyDevOrderVariableGuid - headers: - Guid/LegacyDevOrder.h - Protocol/LegacyBios.h 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-7-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>
2023-12-07OvmfPkg: unplug LegacyBootMaintUiLib from UiAppLaszlo Ersek5-15/+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>
2023-12-07OvmfPkg: remove LegacyBootManagerLibLaszlo Ersek4-1710/+0
LegacyBootManagerLib is not used by any platform at this point, remove it. This patch removes mentions of the following CSM resources from the source code: - GUIDs (protocols or otherwise): - gEfiLegacyBiosProtocolGuid - gEfiLegacyDevOrderVariableGuid - headers: - Guid/LegacyDevOrder.h - Protocol/LegacyBios.h which extends the list of resources scheduled for removal to: - GUIDs (protocols or otherwise): - gEfiLegacyBiosProtocolGuid - gEfiLegacyDevOrderVariableGuid - headers: - Guid/LegacyDevOrder.h - Protocol/LegacyBios.h 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-5-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>
2023-12-07OvmfPkg: unplug LegacyBootManagerLib from BdsDxe and UiAppLaszlo Ersek5-10/+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>
2023-12-07OvmfPkg: remove PcdCsmEnableLaszlo Ersek8-34/+13
PcdCsmEnable was introduced in commits 50f911d25d39 ("OvmfPkg: introduce PcdCsmEnable feature flag", 2020-02-05) and 75839f977d37 ("OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)", 2020-02-05). Remove it, and substitute constant FALSE wherever it has been evaluated thus far. Regression test: after building OVMF IA32X64 with -D SMM_REQUIRE, and booting it on Q35, the log still contains > Q35SmramAtDefaultSmbaseInitialization: SMRAM at default SMBASE found Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-3-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>
2023-12-07OvmfPkg: cripple CSM_ENABLE macroLaszlo Ersek6-0/+6
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>
2023-12-07OvmfPkg/Bhyve: use a proper PCI IO rangeCorvin Köhne1-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>
2023-11-28OvmfPkg/ResetVector: Define SNP metadata for kernel hashesDov Murik2-1/+21
In order to allow the VMM (such as QEMU) to add a page with hashes of kernel/initrd/cmdline for measured direct boot on SNP, add it explicitly to the SNP metadata list report to the VMM. In such case, VMM should fill the page with the hashes content, or explicitly update it as a zero page (if kernel hashes are not used). Note that for SNP, the launch secret part of the page (lower 3KB) are not relevant and will remain zero. The last 1KB is used for the hashes. This should have no effect on OvmfPkgX64 targets (which don't define PcdSevLaunchSecretBase). Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2023-11-28OvmfPkg/AmdSev: Reorder MEMFD pages to match the order in OvmfPkgX64.fdfDov Murik1-13/+14
Resize the MEMFD section of AmdSevX64.fdf and reorder its pages so that it matches the same size and order used in OvmfPkgX64.fdf. After this change, this is the difference in the MEMFD of the two targets: $ diff -u \ <(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/OvmfPkgX64.fdf) \ <(sed -ne '/FD.MEMFD/,/FV.SECFV/p' OvmfPkg/AmdSev/AmdSevX64.fdf) --- /dev/fd/63 2023-02-16 07:06:15.365308683 +0000 +++ /dev/fd/62 2023-02-16 07:06:15.365308683 +0000 @@ -32,6 +32,12 @@ 0x00E000|0x001000 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize +0x00F000|0x000C00 +gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize + +0x00FC00|0x000400 +gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize + 0x010000|0x010000 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2023-11-27OvmfPkg: Format with Uncrustify 73.0.8Michael Kubacki4-18/+18
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> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2023-11-27OvmfPkg: Add ImagePropertiesRecordLib InstanceTaylor Beebe10-0/+10
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>
2023-11-09OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPACeping Sun1-1/+40
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572 According to section 3.2 of the [GHCI] document, if the return status of MapGPA is "TDG.VP.VMCALL_RETRY", TD must retry this operation for the pages in the region starting at the GPA specified in R11. In this patch, when a retry state is detected, TDVF needs to retry the mapping with the specified address from the output results of TdVmCall. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.0 https://cdrdv2.intel.com/v1/dl/getContent/726790 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: Michael Roth <michael.roth@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: Ceping Sun <cepingx.sun@intel.com>
2023-10-31OvmfPkg: Add varpolicy shell commandMichael Kubacki6-0/+24
Adds the varpolicy EFI shell command to all DSC files that currently include other dynamic shell commands from ShellPkg. This command allows variable policies to be dumped in the EFI shell for convenient auditing and debug. Use the command in QEMU EFI shell as follows: - `"varpolicy"` dumps platform variables - `"varpolicy -?"` shows help text - `"varpolicy -b"` pages output as expected - `"varpolicy -s"` shows accurate variable statistic information - `"varpolicy -p"` shows accurate UEFI variable policy information - `"varpolicy-v -b"` dumps all information including variable data hex dump Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Message-Id: <20231030203112.736-4-mikuback@linux.microsoft.com>
2023-10-25OvmfPkg/AcpiPlatformDxe: Fix Coverity report issuesCeping Sun1-1/+7
v1 -> v2 Changed list: 1:Since both commits are intended to fix coverity issues, they are merged into one 2:Changed the debug info level to debug error when "DsdtTable == NULL" 3:Add the Cc member as below Erdem Aktas erdemaktas@google.com James Bottomley jejb@linux.ibm.com Tom Lendacky thomas.lendacky@amd.com Michael Roth michael.roth@amd.com REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4568 The function InstallCloudHvTablesTdx had an Assert when "DsdtTable == NULL", but this comes into play only in DEBUG mode. In Release mode , there is no handling if the pointer is NULL. To avoid the possible null pointer dereference, it is better to handle it when the pointer is null. In addition, the status of "AcpiProtocol->InstallAcpiTable" is overwritten before it can be used in the function, it is better to check it before overwriting. code: https://github.com/sunceping/edk2/tree/fixcoverityerrors.v2 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: Michael Roth <michael.roth@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> Message-Id: <20231023090539.1003-1-cepingx.sun@intel.com> Reviewed-by: Min Xu <min.m.xu@intel.com> [lersek@redhat.com: rewrap commit message to placate PatchCheck.py]
2023-10-19OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. fileLaszlo Ersek1-3/+14
Referring to a file relative to a regular file makes no sense (or at least it cannot be implemented consistently with how a file is referred to relative to a directory). VirtioFsSimpleFileOpen() has enforced this strictly since the beginning, and a few months ago I reported USWG Mantis ticket #2367 [1] too, for clearing up the related confusion in the UEFI spec. Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't believe the shim bug is ever going to be fixed. We can however relax the check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being opened relative to a regular file is absolute, then the base file is going to be ignored anyway, so we can let the caller's bug slide. This happens to make shim work. Why this matters: UEFI-bootable Linux installer ISOs tend to come with shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you want to build upstream shim/grub binaries, but boot the same ISO otherwise. The fastest way for overriding the ESP for this purpose is to copy its original contents to a virtio filesystem, then overwrite the shim and grub binaries from the host side. Note that this is different from direct-booting a kernel (via fw_cfg); the point is to check whether the just-built shim and grub are able to boot the rest of the ISO. [1] https://mantis.uefi.org/mantis/view.php?id=2367 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973 [3] https://github.com/rhboot/shim/issues/382 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> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231018172434.91280-1-lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com>
2023-09-19OvmfPkg/PlatformCI: Disable DebugMacroCheckMichael Kubacki1-0/+1
Disables the DebugMacroCheck CI plugin to reduce CI checks performed in the package. 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: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
2023-09-18OvmfPkg: Remove applicationProcessorEntryPointZhiguang Liu2-25/+6
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494 Current reset vector uses 0xffffffe0 as AP waking vector, and expects GenFv generates code aligned on a 4k boundary which will jump to this location. However, some issues are listed below 1. GenFV doesn't generate code as the comment expects, because GenFv assumes no modifications are required to the VTF-0 'Volume Top File'. 2. Even if removing VFT0 signature and let GenFv to modify, Genfv is hard-code using another flash address 0xffffffd0. 3. In the same patch series, AP waking vector code is removed from GenFv, because no such usage anymore. The existing of first two issues also approve the usage is not available for a long time. Therefore, remove AP waking vector related code. 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: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
2023-09-14OvmfPkg/RiscVVirt/README: document direct kernel bootLaszlo Ersek1-1/+32
Direct (fw_cfg) kernel boot works on the RiscVVirt firmware platform too; I've tested it after extracting the kernel, initrd, and kernel command line from "openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw". Document this type of boot, because at least historically, fw_cfg kernel boot was implemented differently between OVMF and ArmVirtQemu. Thanks: Drew, Sunil. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Andrew Jones <ajones@ventanamicro.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: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
2023-09-14OvmfPkg/RiscVVirt/README: explain the "acpi=off" machine propertyLaszlo Ersek1-0/+5
"acpi=off" is arguably unusual with UEFI guest OSes; add a note to explain it. Original explanation by Drew Jones. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Andrew Jones <ajones@ventanamicro.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: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
2023-09-14OvmfPkg/RiscVVirt/README: explain that "-bios" is only useful with TCGLaszlo Ersek1-0/+5
Riscv64 KVM services SBI calls internally, so OpenSBI is not used in such setups. Restrict the "-bios" flag accordingly. Thanks: Andrei, Drew. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Andrew Jones <ajones@ventanamicro.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: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: '-bios' is rejected with KVM accel (Drew)] Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
2023-09-13OvmfPkg/TdxDxe: Change MadtMpWk->MailBoxVersion from 1 to 0Min M Xu1-1/+1
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4527 According to ACPI 6.5 (https://uefi.org/specs/ACPI/6.5/05_ACPI_Software _Programming_Model.html?highlight=mailboxversion#multiprocessor-wakeup- structure) the MailBoxVersion is 0. This patch changed MadtMpWk->MailBoxVersion from 1 to 0 to fix the error. 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> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2023-09-12OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFsLaszlo Ersek3-9/+9
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>
2023-09-12OvmfPkg/PlatformBootManagerLib: refer to virtio console subsys symbolicallyLaszlo Ersek1-1/+1
"OvmfPkg/Include/IndustryStandard/Virtio095.h" defines the macro VIRTIO_SUBSYSTEM_CONSOLE with value 3; other locations in the tree already use it (such as ArmVirtPkg/PlatformBootManagerLib, OvmfPkg/VirtioSerialDxe). We should use it in OvmfPkg/PlatformBootManagerLib too, rather than the naked constant 3. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
2023-09-12OvmfPkg/RiscVVirt/README.md: bring your own OpenSBILaszlo Ersek1-0/+17
Explain how users can compose their pre-OS environment purely from binaries they've built themselves. Cc: Andrei Warkentin <andrei.warkentin@intel.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: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
2023-09-08OvmfPkg/Bhyve: don't exit early if RSDP is not found in memoryCorvin Köhne1-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>
2023-09-08MdeModulePkg: Duplicate BaseRngLibTimerLib to MdeModulePkgPierre Gondois10-10/+10
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>
2023-09-07OvmfPkg/Include: remove QemuSmramSaveStateMap.hGerd Hoffmann3-191/+12
The qemu/kvm SMM emulation uses the AMD SaveState layout. So, now that we have AMD SaveState support merged we can just use Amd/SmramSaveStateMap.h, QemuSmramSaveStateMap.h is not needed any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
2023-09-07OvmfPkg/PlatformBootManagerLib: setup virtio-mmio devices.Gerd Hoffmann2-0/+32
Add DetectAndPreparePlatformVirtioDevicePath() helper function to setup virtio-mmio devices. Start with virtio-serial support. This makes virtio console usable with microvm. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
2023-09-07OvmfPkg/README: Document Secure BootJoursoir1-0/+40
Add the new section for Secure Boot. Signed-off-by: Alexander Goncharov <chat@joursoir.net> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2023-09-06OvmfPkg: Revert "Update build.sh to allow building OVMF then running QEMU"Mike Beaton1-4/+11
This reverts commit 173a7a7daaad560cd69e1000faca1d2b91774c46 Fixes https://bugzilla.tianocore.org/show_bug.cgi?id=4528 The build.sh qemu option starts the correct qemu executable for the selected architecture (build.sh -a option, or implicit) and uses the correct previously built OVMF image for the selected architecture and build target (build.sh -b option, or implicit). With this revert, the above step will fail if there is no matching previously built OVMF image. This is advantageous over rebuilding each time the build.sh qemu option is used (as in the reverted commit), because it provides a quick way to run a just-built OVMF image in place, while: a) Starting immediately (saving the time required for a rebuild on each usage, if the VM is started multiple times) b) Preserving the NVRAM contents between multiple runs (i.e. until the image is next rebuilt) Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
2023-09-06OvmfPkg: Fix Hii form name mismatch with EFI variableYin Wang1-1/+1
The Hii form is named "MainFormState" while the EFI variable is named "PlatformConfig". This discrepancy in names causes the following SCT cases to fail on RiscVVirtQemu: ExtractConfigConformance ExtractConfigFunction ExtractConfig_Func Previous commit 16acacf addressed two of these issues, and this patch fixes the remaining one. Signed-off-by: Yin Wang <yin.wang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
2023-09-05OvmfPkg/AmdSev: fix BdsPlatform.c assertion failure during bootRoth, Michael via groups.io2-0/+5
Booting an SEV guest with AmdSev OVMF package currently triggers the following assertion with QEMU: InstallQemuFwCfgTables: installed 7 tables PcRtc: Write 0x20 to CMOS location 0x32 [Variable]END_OF_DXE is signaled Initialize variable error flag (FF) ASSERT_EFI_ERROR (Status = Not Found) ASSERT [BdsDxe] /home/VT_BUILD/ovmf/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c(1711): !(((INTN)(RETURN_STATUS)(Status)) < 0) This seems to be due to commit 81dc0d8b4c, which switched to using PlatformBootManagerLib instead of PlatformBootManagerLibGrub. That pulls in a dependency on gEfiS3SaveStateProtocolGuid provider being available (which is asserted for in BdsPlatform.c:PlatformBootManagerBeforeConsole()/SaveS3BootScript()), but the libraries that provide it aren't currently included in the build. Add them similarly to what's done for OvmfPkg. Fixes: 81dc0d8b4c ("OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrub") Signed-off-by: Michael Roth <michael.roth@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
2023-09-05OvmfPkg/AmdSev: Disable PcdFirstTimeWakeUpAPsBySipiMichael Roth1-0/+8
PcdFirstTimeWakeUpAPsBySipi was recently introduced to indicate when the full INIT-SIPI-SIPI sequence can be skipped for AP bringup. It is true by default, but needs to be disabled for QEMU/OVMF where early INIT is not simulated. Commit 1d76560146 ("OvmfPkg: Disable PcdFirstTimeWakeUpAPsBySipi.") added changes to disable it by default for OvmfPkg, but a similar change was not made for the AmdSev package. This breaks booting of SEV and SNP guests. Fix this defaulting PcdFirstTimeWakeUpAPsBySipi to false for AmdSev package, as was previously done for OvmfPkg variants. Fixes: eaffa1d7ff ("UefiCpuPkg:Wake up APs after power-up or RESET through SIPI.") Signed-off-by: Michael Roth <michael.roth@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2023-09-02OvmfPkg/IoMmuDxe: don't rely on TPLs to manage concurrencyArd Biesheuvel2-41/+60
Instead of relying on raising the TPL to protect the critical sections that manipulate the global bitmask that keeps track of bounce buffer allocations, use compare-and-exchange to manage the global variable, and tweak the logic to line up with that. Given that IoMmuDxe implements a singleton protocol that is shared between multiple drivers, and considering the elaborate and confusing requirements in the UEFP spec regarding TPL levels at which protocol methods may be invoked, not relying on TPL levels at all is a more robust approach in this case. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2211060 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
2023-08-29OvmfPkg: Disable PcdFirstTimeWakeUpAPsBySipiYuanhaoXie3-0/+24
Disable PcdFirstTimeWakeUpAPsBySipi for IntelTdx, Microvm, and Xen to preserve the original execution of INIT-SIPI-SIPI. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2023-08-25OvmfPkg/RiscVVirt: Fix issues in VarStore Blockmap configedk2-stable202308Qingyu Shang1-3/+3
The block size configuration of Blockmap does not match that in Qemu VirtNorFlash, which causes variable data to be written into FtwWorkBlock by mistake, resulting in data loss during reboot. Fix it and update new checksum value. Signed-off-by: Qingyu Shang <2931013282@sjtu.edu.cn> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
2023-08-18OvmfPkg/Bhyve: build platform info HOBCorvin Köhne2-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>
2023-08-14OvmfPkg: Disable PcdFirstTimeWakeUpAPsBySipi.YuanhaoXie3-1/+22
Disable PcdFirstTimeWakeUpAPsBySipi for OVMF to let BSP wake up APs by INIT-SIPI-SIPI. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
2023-08-04OvmfPkg/PlatformCI: Boot OVMF in SMP mode.Gerd Hoffmann1-0/+2
Increase the chance that CI finds bugs in MP changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit f92a9dce10281c103b04d6b38283e0ff1d677b91) Reapplying, since the CI (Windows and Linux) use Qemu 8 now, which works with SMP again. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324 Signed-off-by: Oliver Steffen <osteffen@redhat.com> [ardb: use single-threaded TCG for SMM]
2023-08-04OvmfPkg/PlatformCI VS2019: Disable workaround for cpuhp bugfixOliver Steffen2-13/+1
This reverts commit 3beb8c965455f4c1cc3184e36c627ef1d9bfe5f9. Both Windows and Linux CI jobs are now using Qemu 8, this workaround is no longer needed. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324 Signed-off-by: Oliver Steffen <osteffen@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
2023-08-04OvmfPkg/PlatformCI: Use recent Qemu on WindowsOliver Steffen1-1/+1
Bump the version of the Qemu chocolatey package up to 2023.7.25. The Linux CI is already using Qemu 8. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4324 Signed-off-by: Oliver Steffen <osteffen@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
2023-07-31OvmfPkg/RiscVVirt: Update README for CLANGDWARF supportSunil V L1-3/+25
Update the README with instruction to build using CLANGDWARF toolchain. 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: Andrei Warkentin <andrei.warkentin@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # Debian clang version 14.0.6
2023-07-31OvmfPkg/RiscVVirt: SecEntry: Remove unnecessary assembly directivesSunil V L1-3/+0
llvm fails to resolve _ModuleEntry when these extra directives are present. ASM_FUNC already takes care what is required. 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: Andrei Warkentin <andrei.warkentin@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # Debian clang version 14.0.6
generated by cgit v1.1 at 2024-07-03 11:20:25 +0000