summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous dataNicolas Ojeda Leon2022-06-2210-0/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2213-0/+377
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/Library: Create base HardwareInfoLib for PCI Host BridgesNicolas Ojeda Leon2022-06-223-0/+823
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create the Hardware Info library base together with the specifics to describe PCI Host Bridges. The Hardware Info library is intended to be used for disclosing non-discoverable hardware information from the host to the guest in Ovmf platforms. Core functionality will provide the possibility to parse information from a generic BLOB into runtime structures. The library is conceived in a generic way so that further hardware elements can also be described using it. For such purpose the length of the BLOB is not restricted but instead regarded as a sequence of header-info elements that allow the parsing during runtime. The first type of hardware defined will be PCI host bridges, providing the possibility to define multiple and specify the resources each of them can use. This enables the guest firmware to configure PCI resources properly. Having the size of each individual element favors the reuse of a single interface to convey descriptions of an arbitrary number of heterogenous hardware elements. Furthermore, flexible access mechanisms coupled with the size will grant the possibility of interpreting them in a single run. Define the base types of the generic Hardware Info library to parse heterogeneous data. Also provide the specific changes to support PCI host bridges as the first hardware type supported by the library. Additionally, define the HOST_BRIDGE_INFO structure to describe PCI host bridges along with the functionality to parse such information into proper structures used by the PCI driver in a centralized manner and taking care of versioning. As an example and motivation, the library will be used to define multiple PCI host bridges for complex platforms that require it. The first means of transportation that will be used is going to be fw-cfg, over which a stream of bytes will be transferred and later parsed by the hardware info library. Accordingly, the PCI driver will make use of these host bridges definitions to populate the list of Root Bridges and proceed with the configuration and discovery of underlying hardware components. As mentioned before, the binary data to be parsed by the Hardware Info library should be organized as a sequence of Header-element pairs in which the header describes the type and size of the associated element that comes right after it. As an illustration, to provide inforation of 3 host bridges the data, conceptually, would look like this: Header PCI Host Bridge (type and size) # 1 PCI Host Bridge info # 1 Header PCI Host Bridge (type and size) # 2 PCI Host Bridge info # 2 Header PCI Host Bridge (type and size) # 3 PCI Host Bridge info # 3 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-228-41/+18
| | | | | | | | 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: Use PcdOvmfWorkAreaBase instead of PcdSevEsWorkAreaBaseMin M Xu2022-06-162-3/+3
| | | | | | | | | | | | | It is an typo error that HobList pointer should be stored at PcdOvmfWorkAreaBase, not PcdSevEsWorkAreaBase. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Revert "OvmfPkg/Sec: fix stack switch"Gerd Hoffmann2022-06-101-4/+0
| | | | | | | | | This reverts commit ff36b2550f94dc5fac838cf298ae5a23cfddf204. Has no effect because GCC_IA32_CC_FLAGS and GCC_X64_CC_FLAGS are unused. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/Sec: fix stack switchGerd Hoffmann2022-06-081-0/+4
| | | | | | | | | | | | | | | | | | | | The ebp/rbp register can either be used for the frame pointer or as general purpose register. With gcc (and clang) this depends on the -f(no-)omit-frame-pointer switch. This patch updates tools_def.template to explicitly set the compiler option and also add a define to allow conditionally compile code. The new define is used to fix stack switching in TemporaryRamMigration. The ebp/rbp must not be touched when the compiler can use it as general purpose register. With version 12 gcc starts actually using the register, so changing it leads to firmware crashes in some configurations. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3934 Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Delete SecMeasurementLibTdxMin M Xu2022-06-074-420/+0
| | | | | | | | | | The feature of SecMeasurementLibTdx is replaced by SecTpmMeasurementLibTdx (which is in SecurityPkg). So SecMeasurementLibTdx is deleted. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Implement MeasureHobList/MeasureFvImageMin M Xu2022-06-075-3/+224
| | | | | | | | | | | | | | | | | | | | | MeasureHobList and MeasureFvImage once were implemented in SecMeasurementTdxLib. The intention of this patch-set is to refactor SecMeasurementTdxLib to be an instance of TpmMeasurementLib. So these 2 functions (MeasureHobList/MeasureFvImage) are moved to PeilessStartupLib. This is because: 1. RTMR based trusted boot is implemented in Config-B (See below link) 2. PeilessStartupLib is designed for PEI-less boot and it is the right place to do the measurement for Hoblist and Config-FV. Config-B: https://edk2.groups.io/g/devel/message/76367 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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/IntelTdx: Enable RTMR based measurement and measure bootMin Xu2022-06-032-1/+16
| | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853 Enable RTMR based measurement and measure boot for Td guest. 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: Ken Lu <ken.lu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/IntelTdx: Add TdTcg2DxeMin Xu2022-06-033-0/+2997
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853 TdTcg2Dxe mimics the Security/Tcg/Tcg2Dxe. It does below tasks: - Set up and install CC_EVENTLOG ACPI table - Parse the GUIDed HOB (gCcEventEntryHobGuid) and create CC event log - Measure handoff tables, Boot##### variables etc - Measure Exit Boot Service failed - Install CcMeasurement Protocol 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: Ken Lu <ken.lu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: 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 PCDs for LAML/LASA field in CC EVENTLOG ACPI tableMin Xu2022-06-031-0/+6
| | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853 Add PCDs to records LAML/LASA field in CC EVENTLOG ACPI table. 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: Ken Lu <ken.lu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/IntelTdx: Measure Td HobList and Configuration FVMin Xu2022-06-035-2/+221
| | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853 TdHobList and Configuration FV are external data provided by Host VMM. These are not trusted in Td guest. So they should be validated , measured and extended to Td RTMR registers. In the meantime 2 EFI_CC_EVENT_HOB are created. These 2 GUIDed HOBs carry the hash value of TdHobList and Configuration FV. In DXE phase EFI_CC_EVENT can be created based on these 2 GUIDed HOBs. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> 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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Introduce SecMeasurementLibMin Xu2022-06-034-0/+420
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853 SecMeasurementLib is designed to do the measurement in SEC phase. In current stage there are 2 functions introduced: - MeasureHobList: Measure the Hoblist passed from the VMM. - MeasureFvImage: Measure the FV image. SecMeasurementLibTdx is the TDX version of the library. 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: Ken Lu <ken.lu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Don't access A20 gate register on Cloud HypervisorSebastien Boeuf2022-06-031-1/+3
| | | | | | | | | Since Cloud Hypervisor doesn't emulate an A20 gate register on I/O port 0x92, it's better to avoid accessing it when the platform is identified as Cloud Hypervisor. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: CloudHv: Rely on QemuFwCfgLibNull implementationSebastien Boeuf2022-06-031-2/+2
| | | | | | | | | | Since Cloud Hypervisor doesn't support the fw_cfg mechanism, it's more appropriate to rely on QemuFwCfgLibNull implementation of QemuFwCfgLib since it provides a null implementation that will not issue any PIO accesses to ports 0x510 and 0x511. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Check for QemuFwCfg availability before accessing itSebastien Boeuf2022-06-032-6/+11
| | | | | | | | | There are few places in the codebase assuming QemuFwCfg will be present and supported, which can cause some issues when trying to rely on the QemuFwCfgLibNull implementation of QemuFwCfgLib. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: CloudHv: Fix FW_BASE_ADDRESSSebastien Boeuf2022-06-032-1/+66
| | | | | | | | | | | | | | | | The FW_BASE_ADDRESS value provided by OvmfPkgDefines.fdf.inc is incorrect for the CloudHv target. We know the generated firmware contains a PVH ELF header, meaning it will be loaded according to the address provided through this header. And since we know this address isn't going to change as it's part of CloudHvElfHeader.fdf.inc, we can hardcode it through a new include file CloudHvDefines.fdf.inc, which replaces the generic one OvmfPkgDefines.fdf.inc. With this change, we prevent the firmware from accessing MMIO addresses from the address range 0xffc00000-0xffffffff since we know the firmware hasn't been loaded on this address range. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg/Microvm/pcie: add pcie supportGerd Hoffmann2022-06-032-16/+26
| | | | | | | | Link in pcie and host bridge bits. Enables support for PCIe in microvm (qemu-system-x86_64 -M microvm,pcie=on). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3777 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Microvm/pcie: mPhysMemAddressWidth tweakGerd Hoffmann2022-06-032-1/+42
| | | | | | | | | | | | | | microvm places the 64bit mmio space at the end of the physical address space. So mPhysMemAddressWidth must be correct, otherwise the pci host bridge setup throws an error because it thinks the 64bit mmio window is not addressable. On microvm we can simply use standard cpuid to figure the address width because the host-phys-bits option (-cpu ${name},host-phys-bits=on) is forced to be enabled. Side note: For 'pc' and 'q35' this is not the case for backward compatibility reasons. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Microvm/pcie: no vbeshim pleaseGerd Hoffmann2022-06-031-0/+2
| | | | | | | Those old windows versions which need the vbeshim hack will not run on microvm anyway. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Platform: unfix PcdPciExpressBaseAddressGerd Hoffmann2022-06-034-6/+8
| | | | | | | Will be set by FdtPciHostBridgeLib, so it can't be an fixed when we want use that library. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/FdtPciHostBridgeLib: io range is not mandatoryGerd Hoffmann2022-06-031-22/+23
| | | | | | | io range is not mandatory according to pcie spec, so allow host bridges without io address space. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Microvm: drop CODE and VARS filesGerd Hoffmann2022-06-031-26/+0
| | | | | | | | microvm doesn't support pflash and loads the firmware via -bios, so we can't use the separate CODE and VARS files. Remove them. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/AmdSev: remove unused SMM bits from .dsc and .fdf filesGerd Hoffmann2022-06-032-62/+0
| | | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Dov Murik <dovmurik@linux.ibm.com>
* OvmfPkg: Search EFI_RESOURCE_MEMORY_UNACCEPTED for Fw hoblistMin Xu2022-06-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In current TDVF implementation all unaccepted memory passed in Hoblist are tagged as EFI_RESOURCE_MEMORY_UNACCEPTED. They're all accepted before they can be accessed. After accepting memory region, the Hob ResourceType is unchanged (still be EFI_RESOURCE_MEMORY_UNACCEPTED). TDVF Config-B skip PEI phase and it tries to find a memory region which is the largest one below 4GB. Then this memory region will be used as the firmware hoblist. So we should walk thru the input hoblist and search for the memory region with the type of EFI_RESOURCE_MEMORY_UNACCEPTED. Because EFI_RESOURCE_MEMORY_UNACCEPTED has not been officially in PI spec. So it cannot be defined in MdePkg/Include/Pi/PiHob.h. As a temporary solution it is defined in Hob.c. There is a patch-set for lazy-accept very soon. In that patch-set EFI_RESOURCE_MEMORY_UNACCEPTED will be defined in MdeModulePkg. Config-B: https://edk2.groups.io/g/devel/message/76367 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> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Fix TDVMCALL error in ApRunLoop.nasmMin Xu2022-06-021-1/+2
| | | | | | | | | | | | | | | According to GHCI Spec Table 2-1, in TDVMCALL R10 should be cleared to 0 in input operands, and be checked for the return result. https://cdrdv2.intel.com/v1/dl/getContent/726790 Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/ResetVector: Removing SEV-ES CPUID bit checkPeter Gonda2022-06-011-8/+0
| | | | | | | | | | | | | | The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to determine support for running SEV-ES guests. It should not be checked by a guest to determine if it is running under SEV-ES. The guest should use the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled. This check was not part of the original SEV-ES support and was added in a91b700e38. Removing the check makes this code consistent with the Linux kernel Fixes: a91b700e38 ("Ovmf/ResetVector: Simplify and consolidate the SEV features checks") Signed-off-by: Peter Gonda <pgonda@google.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/VirtioGpuDxe: replace struct copy with CopyMem callGerd Hoffmann2022-05-301-1/+1
| | | | | | | | Buildfix for `-t CLANG38 -b NOOPT -p OvmfPkg/OvmfPkgX64.dsc`. Fixes: 5f6ecaa398ba ("OvmfPkg/VirtioGpuDxe: use GopQueryMode in GopSetMode") Reported-by: Rebecca Cran <quic_rcran@quicinc.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* Removed prefix to match AsmRelocateApMailBoxLoopStartedk2-stable202205Theo Jehl2022-05-261-1/+1
| | | | | | | | | | | | | This fixes a compilation issue. 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: Jehl Theo <theojehl76@gmail.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Rebecca Cran <quic_rcran@quicinc.com> Tested-by: Rebecca Cran <quic_rcran@quicinc.com>
* OvmfPkg: fix PcdFSBClockGerd Hoffmann2022-05-255-5/+5
| | | | | | | | | | | | | 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: TdxDxe: Fix AsmRelocateApMailBoxLoopIsaku Yamahata2022-05-251-1/+1
| | | | | | | | | | | | | | | | | | | In TDX, Application Processor busy-loops on Mailbox for OS to issue MpProtectedModeWakeupCommandWakeup command to UEFI. As the AP acking to it, it clears the command member according to ACPI spec 6.4, 5.2.12.19 Multiprocessor Wakeup Structure: "The application processor need clear the command to Noop(0) as the acknowledgement that the command is received." However, AsmRelocateApMailBoxLoop wrongly clears WakeupVector. Correctly clear command instead of WakeupVector. Without this patch, TD guest kernel fails to boot APs. Fixes: fae5c1464d ("OvmfPkg: Add TdxDxe driver") Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Make an Ia32/X64 hybrid build work with SEVTom Lendacky2022-05-206-38/+68
| | | | | | | | | | | | | | | | | | | | | | | | The BaseMemEncryptSevLib functionality was updated to rely on the use of the OVMF/SEV workarea to check for SEV guests. However, this area is only updated when running the X64 OVMF build, not the hybrid Ia32/X64 build. Base SEV support is allowed under the Ia32/X64 build, but it now fails to boot as a result of the change. Update the ResetVector code to check for SEV features when built for 32-bit mode, not just 64-bit mode (requiring updates to both the Ia32 and Ia32X64 fdf files). Fixes: f1d1c337e7c0575da7fd248b2dd9cffc755940df Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/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-199-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Remove RVCT supportRebecca Cran2022-05-131-3/+0
| | | | | | | | RVCT is obsolete and no longer used. Remove support for it. Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Enable 2 different CpuMpPei and CpuDxe driversMin M Xu2022-05-114-3/+89
| | | | | | | | | | | | | | | | | | | | | | | | | 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/TdxDxe: Install MpInitLibDepLib protocolsMin M Xu2022-05-112-1/+23
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3918 In Td guest CpuDxe driver uses the MpInitLibUp, the other guest type use the MpInitLib. So we install different Protocols according to the current working guest type. 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/Sec: Install MpInitLibDepLib PPIs in SecMain.cMin M Xu2022-05-112-2/+34
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3918 Td guest should use MpInitLibUp, other guest use the MpInitLib. So in SecMain.c different PPI is installed according to the working guest type. 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: Add MpInitLibDepLibMin M Xu2022-05-115-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3918 There are 4 MpInitLibDepLib: - PeiMpInitLibMpDepLib: MpInitLib multi-processor dependency - PeiMpInitLibUpDepLib: MpInitLib unique-processor dependency - DxeMpInitLibMpDepLib: MpInitLib multi-processor dependency - DxeMpInitLibUpDepLib MpInitLib unique-processor dependency The Pei libs depend on the corresponding PPI. The Dxe libs depend on the corresponding Protocol. 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: Add MpInitLibDepLib related PPI/Protocol definitionsMin M Xu2022-05-113-0/+61
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3918 MpInitLibDepLib is a set of libraries which depend on PPI/Protocol. This patch defines the related PPI/Protocols in OvmfPkg. 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: Add README for TDVFMin Xu2022-05-061-0/+88
| | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3249 Add README for TDVF. 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> 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 CpuLib to module INFs that depend on UefiCpuLib.Yu Pu2022-05-062-0/+2
| | | | | | | | | | | | | There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build failure, add CpuLib dependency to all modules that depend on UefiCpuLib. 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: Yu Pu <yu.pu@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Bhyve: add support for QemuFwCfgCorvin Köhne2022-05-023-6/+40
| | | | | | | | | | | | QemuFwCfg is much more powerful than BhyveFwCtl. Sadly, BhyveFwCtl decided to use the same IO ports as QemuFwCfg. It's not possible to use both interfaces simultaneously. So, prefer QemuFwCfg over BhyveFwCtl. Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: restore CompatImageLoaderDxe chunkGerd Hoffmann2022-04-301-0/+3
| | | | | | | Was dropped by accident. Fixes: b47575801e19 ("OvmfPkg: move tcg configuration to dsc and fdf include files") Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/VirtioGpuDxe: query native display resolution from hostGerd Hoffmann2022-04-253-5/+99
| | | | | | | | | Try query native display resolution from the host. When successful, setup PcdVideoHorizontalResolution and PcdVideoVerticalResolution accordingly and add the video mode to the GOP mode list if needed. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/VirtioGpuDxe: move code to GopInitializeGerd Hoffmann2022-04-251-15/+32
| | | | | | | | | Add new function to initialize the GOP, move over setup code. Handle initialization first, specifically before calling GopQueryMode(), so GopQueryMode is never called before GopInitialize() did complete. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/VirtioGpuDxe: use GopQueryMode in GopSetModeGerd Hoffmann2022-04-251-29/+31
| | | | | | | | | Call GopQueryMode() in GopSetMode(), use the ModeInfo returned when setting the mode. This is needed to properly handle modes which are not on the static mGopResolutions list. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/VirtioGpuDxe: add VirtioGpuGetDisplayInfoGerd Hoffmann2022-04-252-0/+26
| | | | | | | Add support for sending a GetDisplayInfo command. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/VirtioGpuDxe: add GetDisplayInfo to virtio-gpu spec header.Gerd Hoffmann2022-04-251-1/+18
| | | | | | | | Add GetDisplayInfo command, reply and data struct to the virtio-gpu specification header file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-10 21:45:43 +0000