summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgX64.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Disable PcdFirstTimeWakeUpAPsBySipi.YuanhaoXie2023-08-141-0/+7
| | | | | | | | | | | | | | | | 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>
* OvmfPkg: Uses MmSaveStateLib libraryAbdul Lateef Attar2023-07-031-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182 Uses new MmSaveStateLib library instance. Cc: Paul Grimes <paul.grimes@amd.com> Cc: Abner Chang <abner.chang@amd.com> 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: Abdul Lateef Attar <abdattar@amd.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: move PciEncoding into AcpiPlatformLibCorvin Köhne2023-06-231-0/+1
| | | | | | | | | Bhyve supports providing ACPI tables by FwCfg. Therefore, InstallQemuFwCfgTables should be moved to AcpiPlatformLib to reuse the code. As first step, move PciEncoding into AcpiPlatformLib. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Peter Grehan <grehan@freebsd.org>
* OvmfPkg: Replace the OVMF-specific SataControllerDxePedro Falcato2023-06-011-1/+1
| | | | | | | | | | Replace the OVMF-specific SataControllerDxe (to be later removed) with the generic, MdeModulePkg one, for OvmfPkg{Ia32, X64, Ia32X64} platforms. Tested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add CpuPageTableLib required by SecCore & CpuMpPeiJiaxin Wu2023-05-311-2/+1
| | | | | | | | | | | | | Add CpuPageTableLib required by SecCore & CpuMpPei in OvmfPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg/VirtioSerialDxe: wire up in OvmfPkg*Gerd Hoffmann2023-05-041-0/+1
| | | | | | Add the driver to the ovmf builds. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: replace SECURE_BOOT_FEATURE_ENABLED with PcdSecureBootSupportedGerd Hoffmann2023-05-041-9/+1
| | | | | | | Drop the '-D SECURE_BOOT_FEATURE_ENABLED' compile time option, use a new FeaturePcd instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: allow setting Firmware Version from build command lineOliver Steffen2023-05-041-0/+2
| | | | | | | | | | | | | | | | Initialize gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with with the value of the variable "FIRMWARE_VER", if is is defined. Applies to all flavors of OvmfPkg. This behavior is already implemented in ArmVirtXen.dsc. It allows specifying the firmware version string on the build command line with -D FIRMARE_VER=... Introduce a common include file to be used in the .dsc files for the different OVMF flavors, and add the changes there. (ArmVirtPkg already has such a file). Signed-off-by: Oliver Steffen <osteffen@redhat.com>
* OvmfPkg: Drop special Xcode5 version of exception handler libraryArd Biesheuvel2023-04-061-4/+0
| | | | | | | | | The generic and XCODE5 versions of this library are now identical, so drop the special case. The library will be removed entirely in a subsequent patch. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for CLANGDWARFRebecca Cran2023-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | The CLANGDWARF toolchain has the same problem as XCODE5 linking CpuExceptionHandlerLib. So, use the Xcode5SecPeiCpuExceptionHandlerLib.inf when building with the CLANGDWARF toolchain. Since the difference is that the non-Xcode5 version uses `mov` while the Xcode5 version uses `lea`, they can be merged in future with the single version using `lea`. [ardb: the main difference is that the 'mov' instructions result in absolute symbol references, which are necessary because the code in question is copied in memory independently from the code that carries the symbols it refers to. The Xcode5 version has additional runtime handling to fix up the copied code with the correct absolute references.] Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformInitLib: move mmconfig to 0xe0000000Gerd Hoffmann2023-03-281-1/+1
| | | | | | | | | | | | | | | | | Also swap the ordering of 32bit PCI MMIO window on q35, i.e. use the room between end of low memory and the start of the mmconfig bar. With a typical configuration on modern qemu with gigabyte-aligned memory the MMIO window start at 0x8000000, sized 1532 MB. In case there is memory present above 0x80000000 the window will start at 0xc0000000 instead, with 512 MB size. This depends on qemu commit 4a4418369d6d ("q35: fix mmconfig and PCI0._CRS"), so it raises the bar for the lowest supported version to qemu 4.1 (released Aug 2019). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Remove UefiCpuLib from module INFs.Yu Pu2023-03-101-1/+0
| | | | | | | | | | | | Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib, remove the dependency of UefiCpuLib. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Yu Pu <yu.pu@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* OvmfPkg: Add CpuPageTableLib required by MpInitLib.Yuanhao Xie2023-03-071-1/+3
| | | | | | | | | | | | | Add CpuPageTableLib required by MpInitLib in OvmfPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg: require self-signed PK when secure boot is enabledJan Bobek2023-02-041-0/+3
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2506 In all DSC files that define SECURE_BOOT_ENABLE, opt-in into requiring self-signed PK when SECURE_BOOT_ENABLE is TRUE. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Jan Bobek <jbobek@nvidia.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Support Tdx measurement in OvmfPkgX64Min M Xu2023-02-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/PlatformPei: Build GuidHob for Tdx measurementMin M Xu2023-02-041-1/+4
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243 TdxHelperBuildGuidHobForTdxMeasurement is called in PlatformPei to build GuidHob for Tdx measurement. 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: Refactor ProcessHobListMin M Xu2023-02-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243 ProcessHobList once was implemented in PlatformInitLib and it walks thru TdHob list and accept un-accepted memories. This patch moves the codes to SecTdxHelperLib and rename ProcessHobList as TdxHelperProcessTdHob After TdxHelperProcessTdHob is introduced, below changes are applied: - Call TdxHelperProcessTdHob instead of ProcessHobList in SecMain.c (in both OvmfPkgX64/Sec and IntelTdx/Sec). - Delete the duplicated codes in PlatformInitLib Cc: Erdem Aktas <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: fix OvmfTpmSecurityStub.dsc.inc includeGerd Hoffmann2023-01-131-1/+1
| | | | | | | | | | TPM support is independent from secure boot support. Move the TPM include snipped out of the secure boot !if block. Fixes: b47575801e19 ("OvmfPkg: move tcg configuration to dsc and fdf include files") Bugzilla: https://bugzilla.tianocore.org//show_bug.cgi?id=4290 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Revert "OvmfPkg: Add CpuPageTableLib required by MpInitLib."Yuanhao Xie2023-01-091-2/+0
| | | | | | | | | | | | | | This reverts commit 4a8642422460635462d315defe4ca84bf6d33351 as the commit 73ccde8 introduced CpuPageTableLib dependency which resolved for OvmfPkg is to be reverted. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4234 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> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
* OvmfPkg: Use NestedInterruptTplLib in nested interrupt handlersMichael Brown2022-12-231-0/+1
| | | | | | | | | | | | | | | | Prevent stack underrun in the event of a timer interrupt storm in LocalApicTimerDxe and 8254TimerDxe interrupt handlers by using the helper functions provided by NestedInterruptTplLib. This fixes the same problem as addressed in commit 239b50a86 ("OvmfPkg: End timer interrupt later to avoid stack overflow under load"), but does so without breaking nested timer interrupts. Cc: Paolo Bonzini <pbonzini@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4162 Signed-off-by: Michael Brown <mcb30@ipxe.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add CpuPageTableLib required by MpInitLib.Yuanhao Xie2022-12-201-0/+2
| | | | | | | | Add CpuPageTableLib required by MpInitLib in OvmfPkg. Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/DebugLibIoPort: use Rom version for PEIGerd Hoffmann2022-12-141-2/+2
| | | | | | | | This variant does not use global variables. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: move dsc include snippet for Network support to Include/DscGerd Hoffmann2022-12-091-1/+1
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: move dsc and fdf include snippets for TPM support to subdirsGerd Hoffmann2022-12-091-7/+7
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/UefiCpuPkg/UefiPayloadPkg: Rename VmgExitLib to CcExitLibMin M Xu2022-11-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4123 VmgExitLib once was designed to provide interfaces to support #VC handler and issue VMGEXIT instruction. After TDVF (enable TDX feature in OVMF) is introduced, this library is updated to support #VE as well. Now the name of VmgExitLib cannot reflect what the lib does. This patch renames VmgExitLib to CcExitLib (Cc means Confidential Computing). This is a simple renaming and there is no logic changes. After renaming all the VmgExitLib related codes are updated with CcExitLib. These changes are in OvmfPkg/UefiCpuPkg/UefiPayloadPkg. Cc: Guo Dong <guo.dong@intel.com> Cc: Sean Rhodes <sean@starlabs.systems> Cc: James Lu <james.lu@intel.com> Cc: Gua Guo <gua.guo@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: James Lu <james.lu@intel.com> Reviewed-by: Gua Guo <gua.guo@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: gather common NetworkComponents overrides in .dsc.inc fileArd Biesheuvel2022-09-101-11/+1
| | | | | | | | | | | | All QEMU based OVMF platforms override the same set of network components, to specify NULL library class resolutions that modify the behavior of those components in a QEMU specific way. Before adding more occurrences of that, let's drop those definitions in a common include file. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/OvmfPkg*.dsc: Increase ACPI Reclaim memory sizeannie li2022-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | The current ACPI Reclaim memory size is set as 0x10 (64KiB). The ACPI table size will be increased if the memory slots' number of the guest gets increased. In the guest with more memory slots, the ACPI Reclaim memory size may not be sufficient for hibernation. This may cause resume failure of the hibernated guest that was booted up with a fresh copied writable OVMF_VARS file. However, the failure doesn't happen in following hibernation/resume cycles. The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI Reclaim memory. However, due to the 0x10 (16 pages) setting, 2 extra pages will be allocated in other space. This may break the hibernation/resume in the above scenario. This patch increases the ACPI Reclaim memory size to 0x12, i.e. PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12 (18 pages). Signed-off-by: Annie Li <annie.li@oracle.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add build-flag SECURE_BOOT_FEATURE_ENABLEDMin M Xu2022-09-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | SECURE_BOOT_FEATURE_ENABLED is the build-flag defined when secure boot is enabled. Currently this flag is used in below lib: - OvmfPkg/PlatformPei - PeilessStartupLib So it is defined in below 5 .dsc - OvmfPkg/CloudHv/CloudHvX64.dsc - OvmfPkg/IntelTdx/IntelTdxX64.dsc - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Update CcProbeLib to DxeCcProbeLibMin M Xu2022-09-061-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974 CcProbeLib once was designed to probe the Confidential Computing guest type by checking the PcdOvmfWorkArea. But this memory is allocated with either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed after ExitBootService. Please see the detailed analysis in BZ#3974. To fix this issue, CcProbeLib is redesigned as 2 implementation: - SecPeiCcProbeLib - DxeCcProbeLib In SecPeiCcProbeLib we check the CC guest type by reading the PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about the issues in BZ#3974. In DxeCcProbeLib we cache the GuestType in Ovmf work area in a variable. After that the Guest type is returned with the cached value. So that we don't need to worry about the access to Ovmf work area after ExitBootService. The reason why we probe CC guest type in 2 different ways is the global varialbe. Global variable cannot be used in SEC/PEI and CcProbe is called very frequently. Cc: Gerd Hoffmann <kraxel@redhat.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> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-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/+11
| | | | | | | | | | | | | | | | | Add BUILD_SHELL flag, similar to the one in OvmfPkg/AmdSev, to enable/disable building of the UefiShell as part of the firmware image. The UefiShell should not be included for secure production systems (e.g. SecureBoot) because it can be used to circumvent security features. The default value for BUILD_SHELL is TRUE to keep the default behavior of the Ovmf build. Note: the default for AmdSev is FALSE. The BUILD_SHELL flag for AmdSev was introduced in b261a30c900a8. Signed-off-by: Oliver Steffen <osteffen@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Change default to disable MptScsi and PvScsiMichael D Kinney2022-07-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | The email addresses for the reviewers of the MptScsi and PvScsi are no longer valid. Disable the MptScsi and PvScsi drivers in all DSC files until new maintainers/reviewers can be identified. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Pipeline: Resolve SecureBootVariableLib dependencyKun Qin2022-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | The new changes in SecureBootVariableLib brought in a new dependency of PlatformPKProtectionLib. This change added the new library instance from SecurityPkg to resolve pipeline builds. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
* Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous dataNicolas Ojeda Leon2022-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the Hardware Info library, create the DxeHardwareInfoLib which implements the whole API capable of parsing heterogeneous hardware information. The list-like API grants callers a flexible and common pattern to retrieve the data. Moreover, the initial source is a BLOB which generalizes the host-to-guest transmission mechanism. The Hardware Info library main objective is to provide a way to describe non-discoverable hardware so that the host can share the available resources with the guest in Ovmf platforms. This change features and embraces the main idea behind the library by providing an API that parses a BLOB into a linked list to retrieve hardware data from any source. Additionally, list-like APIs are provided so that the hardware info list can be traversed conveniently. Similarly, the capability is provided to filter results by specific hardware types. However, heterogeneous elements can be added to the list, increasing the flexibility. This way, a single source, for example a fw-cfg file, can be used to describe several instances of multiple types of hardware. This part of the Hardware Info library makes use of dynamic memory and is intended for stages in which memory services are available. A motivation example is the PciHostBridgeLib. This library, part of the PCI driver populates the list of PCI root bridges during DXE stage for future steps to discover the resources under them. The hardware info library can be used to obtain the detailed description of available host bridges, for instance in the form of a fw-cfg file, and parse that information into a dynmaic list that allows, first to verify consistency of the data, and second discover the resources availabe for each root bridge. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfgNicolas Ojeda Leon2022-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define the HardwareInfoLib API and create the PeiHardwareInfoLib which implements it, specifically for Pei usage, supporting only static accesses to parse data directly from a fw-cfg file. All list-like APIs are implemented as unsupported and only a fw-cfg wrapper to read hardware info elements is provided. The Hardware Info library is intended to describe non-discoverable hardware information and share that from the host to the guest in Ovmf platforms. The QEMU fw-cfg extension for this library provides a first variation to parse hardware info by reading it directly from a fw-cfg file. This library offers a wrapper function to the plain QmeuFwCfgReadBytes which, specifically, parses header-data pairs out of the binary values in the file. For this purpose, the approach is incremental, reading the file block by block and outputting the values only for a specific known hardware type (e.g. PCI host bridges). One element is returned in each call until the end of the file is reached. Considering fw-cfg as the first means to transport hardware info from the host to the guest, this wrapping library offers the possibility to statically, and in steps, read a specific type of hardware info elements out of the file. This method reads one hardware element of a specific type at a time, without the need to pre-allocate memory and read the whole file or dynamically allocate memory for each new element found. As a usage example, the static approach followed by this library enables early UEFI stages to use and read hardware information supplied by the host. For instance, in early times of the PEI stage, hardware information can be parsed out from a fw-cfg file prescinding from memory services, that may not yet be available, and avoiding dynamic memory allocations. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* OvmfPkg: reduce the number of dsc include files for tpm libsGerd Hoffmann2022-06-221-4/+0
| | | | | | | | We can have multiple [LibraryClasses] sections, so we can place all TPM-related library configuration to a single include file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: fix PcdFSBClockGerd Hoffmann2022-05-251-1/+1
| | | | | | | | | | | | | kvm FSB clock is 1GHz, not 100 MHz. Timings are off by factor 10. Fix all affected build configurations. Not changed: Microvm and Cloudhw (they have already have the correct value), and Xen (has no fixed frequency, the PCD is configured at runtime by platform initialization code). Fixes: c37cbc030d96 ("OvmfPkg: Switch timer in build time for OvmfPkg") Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/OvmfPkgX64: Use different CcProbeLib when SMM is on or offMin Xu2022-05-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3930 CcProbeLib is designed to check the vm guest type. The OvmfPkg/CcProbeLib reads the OvmfWorkArea (0x80B000) to get the vm guest type which is written by each guest (SEV or TDX guest). But in SMM drivers the access to OvmfWorkArea is illegal. PiSmmCpuDxeSmm.inf is an example. It uses IoLib which in OvmfPkgX64 BaseIoLibIntrinsicSev.inf is included. The IoLib probes if the working guest is td guest by calling CcProbe(). So CcProbeLibNull will be included when SMM_REQUIRE is set. Currently only TDVF uses CcProbe to check the guest type, and TDVF doesn't support SMM, so this fix has no side-effect. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Dann Frazier <dann.frazier@canonical.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: Liming Gao <gaoliming@byosoft.com.cn> Tested-by: dann frazier <dann.frazier@canonical.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Add VariableFlashInfoLibMichael Kubacki2022-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479 Adds an instance of VariableFlashInfoLib to the platform build as it is a new library class introduced in MdeModulePkg. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Min Xu <min.m.xu@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: Enable 2 different CpuMpPei and CpuDxe driversMin M Xu2022-05-111-2/+53
| | | | | | | | | | | | | | | | | | | | | | | | | 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: clear PcdConOut{Row,Column}Gerd Hoffmann2022-04-221-0/+2
| | | | | | | | | ConSplitterDxe will pick the highest available resolution then, thereby making better use of the available display space. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add CcProbeLib in *.dscMin Xu2022-04-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902 CcProbeLib is imported in BaseIoLibIntrinsicSev. OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks OvmfWorkArea to return the Cc guest type. It is included in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc. Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest is not supported in those projects. Cc: James Bottomley <jejb@linux.ibm.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Add dependency of VariableSmm driver to make it work normally.Zhihao Li2022-04-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | REF? https://bugzilla.tianocore.org/show_bug.cgi?id=3861 UefiCpuPkg define a new Protocol with the new services SmmWaitForAllProcessor(), which can be used by SMI handler to optionally wait for other APs to complete SMM rendezvous in relaxed AP mode. VariableSmm driver need use SmmCpuRendezvousLib, So add SmmCpuRendezvousLib in OvmfPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Zhihao Li <zhihao.li@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Switch timer in build time for OvmfPkgMin Xu2022-04-021-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711 Discussion in https://bugzilla.tianocore.org/show_bug.cgi?id=1496 shows that 8254TimerDxe was not written for OVMF. It was moved over from PcAtChipsetPkg to OvmfPkg in 2019. Probably because OVMF was the only user left. Most likely the reason OVMF used 8254TimerDxe initially was that it could just use the existing driver in PcAtChipsetPkg. And it simply hasn't been changed ever. CSM support was moved in 2019 too. (CSM support depends on 8254/8259 drivers). So 8254TimerDxe will be used when CSM_ENABLE=TRUE. There are 4 .dsc which include the 8254Timer. - OvmfPkg/AmdSev/AmdSevX64.dsc - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc For the three OvmfPkg* configs using 8254TimerDxe with CSM_ENABLE=TRUE and LapicTimerDxe otherwise. For the AmdSev config it doesn't make sense to support a CSM. So use the lapic timer unconditionally. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Update IoMmuDxe to support TDXMin Xu2022-04-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. The current IoMmuDxe driver supports DMA operations inside SEV guest. To support DMA operation in TDX guest, CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr) is used to determine if it is SEV guest or TDX guest. Due to security reasons all DMA operations inside the SEV/TDX guest must be performed on shared pages. The IOMMU protocol driver for the SEV/TDX guest uses a bounce buffer to map guest DMA buffer to shared pages in order to provide the support for DMA operations inside SEV/TDX guest. The call of SEV or TDX specific function to set/clear EncMask/SharedBit is determined by CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr). Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Add TdxDxe driverMin Xu2022-04-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* MdeModulePkg: Add PcdTdxSharedBitMaskMin Xu2022-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Guest Physical Address (GPA) space in Td guest is divided into private and shared sub-spaces, determined by the SHARED bit of GPA. This PCD holds the shared bit mask. Its default value is 0 and it will be set in PlatformPei driver if it is of Td guest. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Update Sec to support TdxMin Xu2022-04-021-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 There are below major changes in this commit. 1. SecEntry.nasm In TDX BSP and APs goes to the same entry point in SecEntry.nasm. BSP initialize the temporary stack and then jumps to SecMain, just as legacy Ovmf does. APs spin in a modified mailbox loop using initial mailbox structure. Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h. APs wait for command to see if the command is for me. If so execute the command. 2. Sec/SecMain.c When host VMM create the Td guest, the system memory informations are stored in TdHob, which is a memory region described in Tdx metadata. The system memory region in TdHob should be accepted before it can be accessed. So the major task of this patch is to process the TdHobList to accept the memory. After that TDVF follow the standard OVMF flow and jump to PEI phase. PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives no chance for Intel TDX to support 1G page table. To support 1G page table this PCD is set to TRUE in OvmfPkgX64.dsc. TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the Tdx specific code. TDX only works on X64, so the code is only valid in X64 arch. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Create initial version of PlatformInitLibMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 There are 3 variants of PlatformPei in OvmfPkg: - OvmfPkg/PlatformPei - OvmfPkg/XenPlatformPei - OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf These PlatformPeis can share many common codes, such as Cmos / Hob / Memory / Platform related functions. This commit (and its following several patches) are to create a PlatformInitLib which wraps the common code called in above PlatformPeis. In this initial version of PlatformInitLib, below Cmos related functions are introduced: - PlatformCmosRead8 - PlatformCmosWrite8 - PlatformDebugDumpCmos They correspond to the functions in OvmfPkg/PlatformPei: - CmosRead8 - CmosWrite8 - DebugDumpCmos Considering this PlatformInitLib will be used in SEC phase, global variables and dynamic PCDs are avoided. We use PlatformInfoHob to exchange information between functions. EFI_HOB_PLATFORM_INFO is the data struct which contains the platform information, such as HostBridgeDevId, BootMode, S3Supported, SmmSmramRequire, etc. After PlatformInitLib is created, OvmfPkg/PlatformPei is refactored with this library. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/FvbServicesSmm: use the VmgExitLibNullBrijesh Singh2022-02-161-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3835 The commit ade62c18f4742301bbef474ac10518bde5972fba caused a boot failure when OVMF is build with SECURE_BOOT/SMM enabled. This happen because the above commit extended the BaseMemEncryptSevLib.inf to include VmgExitLib. The FvbServicesSmm uses the functions provided by the MemEncryptSevLib to clear the memory encryption mask from the page table. It created a dependency, as shown below OvmfPkg/FvbServicesSmm.inf ---> MemEncryptSevLib class ---> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance ---> VmgExitLib ---> "OvmfPkg/VmgExitLib" instance ---> LocalApicLib class ---> UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf instance ---> TimerLib class ---> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance ---> PciLib class ---> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance The LocalApicLib provides a constructor, execution of the constructor causes an exception. The SEV-ES and SEV-SNP do not support the SMM, so skip including the VmgExitLib chain. Use the module override to use the VmgExitLibNull to avoid the inclusion of unneeded LocalApicLib dependency chain in FvbServicesSmm. We ran similar issue for AmdSevDxe driver, see commit 19914edc5a0202cc7830f819ffac7e7b2368166a After the patch, the dependency look like this: OvmfPkg/FvbServicesSmm.inf ---> MemEncryptSevLib class ---> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance ---> VmgExitLib ---> "UefiCpuPkg/Library/VmgExitLibNull" instance Fixes: ade62c18f4742301bbef474ac10518bde5972fba Reported-by: Aaron Young <aaron.young@oracle.com> Cc: Dann Frazier <dann.frazier@canonical.com> Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: dann frazier <dann.frazier@canonical.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: add PcdVideoResolutionSourceGerd Hoffmann2022-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a UINT8 (enum) PCD telling where the PcdVideoHorizontalResolution and PcdVideoVerticalResolution values are coming from. It can be: 0 (unset aka default from dsc file), or 1 (from PlatformConfig), or 2 (set by Video Driver). It will be used by video drivers to avoid overriding PlatformConfig values, or override each others values in case multiple display devices are present. The underlying problem this tries to solve is that the GOP protocol has no way to indicate the preferred video mode. On physical hardware this isn't much of a problem because using the highest resolution available works just fine as that is typically the native display resolution But in a virtual machine you don't want come up with a huge 4k window by default just because the virtual vga is able to handle that. Cutting down the video mode list isn't a great solution either as that would also remove the modes from the platform configuration so the user wouldn't be able to pick a resolution higher than the default any more. So with patch drivers can use use PcdVideoHorizontalResolution and PcdVideoVerticalResolution to indicate what the preferred display resolution is, without overwriting the user preferences from PlatformConfig if present. A possible alternative approach would be to extend the GOP protocol, but I'm not sure this is a good plan given this is mostly a problem for virtual machines and using PCDs allows to keep this local to OvmfPkg. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>