summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfXen.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/Xen: export search of RSDP into a library functionCorvin Köhne2023-06-061-0/+1
| | | | | | | | | | Xen and bhyve are placing ACPI tables into system memory. So, they can share the same code. Therefore, create a new library which searches and installs ACPI tables from system memory. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Xen: 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 the OvmfXen platform. Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Add CpuPageTableLib required by SecCore & CpuMpPeiJiaxin Wu2023-05-311-1/+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: 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: 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/+2
| | | | | | | | | | | | | 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>
* Revert "OvmfPkg: Add CpuPageTableLib required by MpInitLib."Yuanhao Xie2023-01-091-2/+1
| | | | | | | | | | | | | | 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-1/+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/UefiCpuPkg/UefiPayloadPkg: Rename VmgExitLib to CcExitLibMin M Xu2022-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4123 VmgExitLib once was designed to provide interfaces to support #VC handler and issue VMGEXIT instruction. After TDVF (enable TDX feature in OVMF) is introduced, this library is updated to support #VE as well. Now the name of VmgExitLib cannot reflect what the lib does. This patch renames VmgExitLib to CcExitLib (Cc means Confidential Computing). This is a simple renaming and there is no logic changes. After renaming all the VmgExitLib related codes are updated with CcExitLib. These changes are in OvmfPkg/UefiCpuPkg/UefiPayloadPkg. Cc: Guo Dong <guo.dong@intel.com> Cc: Sean Rhodes <sean@starlabs.systems> Cc: James Lu <james.lu@intel.com> Cc: Gua Guo <gua.guo@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: James Lu <james.lu@intel.com> Reviewed-by: Gua Guo <gua.guo@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous dataNicolas Ojeda Leon2022-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the Hardware Info library, create the DxeHardwareInfoLib which implements the whole API capable of parsing heterogeneous hardware information. The list-like API grants callers a flexible and common pattern to retrieve the data. Moreover, the initial source is a BLOB which generalizes the host-to-guest transmission mechanism. The Hardware Info library main objective is to provide a way to describe non-discoverable hardware so that the host can share the available resources with the guest in Ovmf platforms. This change features and embraces the main idea behind the library by providing an API that parses a BLOB into a linked list to retrieve hardware data from any source. Additionally, list-like APIs are provided so that the hardware info list can be traversed conveniently. Similarly, the capability is provided to filter results by specific hardware types. However, heterogeneous elements can be added to the list, increasing the flexibility. This way, a single source, for example a fw-cfg file, can be used to describe several instances of multiple types of hardware. This part of the Hardware Info library makes use of dynamic memory and is intended for stages in which memory services are available. A motivation example is the PciHostBridgeLib. This library, part of the PCI driver populates the list of PCI root bridges during DXE stage for future steps to discover the resources under them. The hardware info library can be used to obtain the detailed description of available host bridges, for instance in the form of a fw-cfg file, and parse that information into a dynmaic list that allows, first to verify consistency of the data, and second discover the resources availabe for each root bridge. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfgNicolas Ojeda Leon2022-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define the HardwareInfoLib API and create the PeiHardwareInfoLib which implements it, specifically for Pei usage, supporting only static accesses to parse data directly from a fw-cfg file. All list-like APIs are implemented as unsupported and only a fw-cfg wrapper to read hardware info elements is provided. The Hardware Info library is intended to describe non-discoverable hardware information and share that from the host to the guest in Ovmf platforms. The QEMU fw-cfg extension for this library provides a first variation to parse hardware info by reading it directly from a fw-cfg file. This library offers a wrapper function to the plain QmeuFwCfgReadBytes which, specifically, parses header-data pairs out of the binary values in the file. For this purpose, the approach is incremental, reading the file block by block and outputting the values only for a specific known hardware type (e.g. PCI host bridges). One element is returned in each call until the end of the file is reached. Considering fw-cfg as the first means to transport hardware info from the host to the guest, this wrapping library offers the possibility to statically, and in steps, read a specific type of hardware info elements out of the file. This method reads one hardware element of a specific type at a time, without the need to pre-allocate memory and read the whole file or dynamically allocate memory for each new element found. As a usage example, the static approach followed by this library enables early UEFI stages to use and read hardware information supplied by the host. For instance, in early times of the PEI stage, hardware information can be parsed out from a fw-cfg file prescinding from memory services, that may not yet be available, and avoiding dynamic memory allocations. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* OvmfPkg: Add VariableFlashInfoLibMichael Kubacki2022-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479 Adds an instance of VariableFlashInfoLib to the platform build as it is a new library class introduced in MdeModulePkg. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Min Xu <min.m.xu@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: 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: Rename XenTimerDxe to LocalApicTimerDxeMin Xu2022-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711 XenTimerDxe is a local Apic timer driver and it has nothing to do with Xen. So rename it to LocalApicTimerDxe. 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> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Acked-by: Anthony PERARD <anthony.perard@citrix.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/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. The current IoMmuDxe driver supports DMA operations inside SEV guest. To support DMA operation in TDX guest, CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr) is used to determine if it is SEV guest or TDX guest. Due to security reasons all DMA operations inside the SEV/TDX guest must be performed on shared pages. The IOMMU protocol driver for the SEV/TDX guest uses a bounce buffer to map guest DMA buffer to shared pages in order to provide the support for DMA operations inside SEV/TDX guest. The call of SEV or TDX specific function to set/clear EncMask/SharedBit is determined by CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr). Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* MdeModulePkg: Add PcdTdxSharedBitMaskMin Xu2022-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Guest Physical Address (GPA) space in Td guest is divided into private and shared sub-spaces, determined by the SHARED bit of GPA. This PCD holds the shared bit mask. Its default value is 0 and it will be set in PlatformPei driver if it is of Td guest. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Update Sec to support TdxMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 There are below major changes in this commit. 1. SecEntry.nasm In TDX BSP and APs goes to the same entry point in SecEntry.nasm. BSP initialize the temporary stack and then jumps to SecMain, just as legacy Ovmf does. APs spin in a modified mailbox loop using initial mailbox structure. Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h. APs wait for command to see if the command is for me. If so execute the command. 2. Sec/SecMain.c When host VMM create the Td guest, the system memory informations are stored in TdHob, which is a memory region described in Tdx metadata. The system memory region in TdHob should be accepted before it can be accessed. So the major task of this patch is to process the TdHobList to accept the memory. After that TDVF follow the standard OVMF flow and jump to PEI phase. PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives no chance for Intel TDX to support 1G page table. To support 1G page table this PCD is set to TRUE in OvmfPkgX64.dsc. TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the Tdx specific code. TDX only works on X64, so the code is only valid in X64 arch. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: 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>
* OvmfPkg: change qemu default resolution to 1280x800Gerd Hoffmann2022-01-291-2/+2
| | | | | | | | | | | | | | ovmf default display resolution is 800x600. This is rather small for modern guests. qemu used 1024x768 as default for a long time and switched the to 1280x800 recently[1] for the upcoming 7.0 release. This patch brings ovmf in sync with the recent qemu update and likewise switches the default to 1280x800. [1] https://gitlab.com/qemu-project/qemu/-/commit/de72c4b7cdf6ec18bfe9fe714aa96e48db6fd895 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg-EmuVariableFvbRuntimeDxe: Support Access To Memory Above 4Glixianglai2021-12-111-0/+2
| | | | | | | | | | | | | | | | In FvbInitialize Function, PcdFlashNvStorageVariableBase64 PcdFlashNvStorageFtwWorkingBase PcdFlashNvStorageFtwSpareBase will not exceed 0x100000000, Due to truncation and variable type limitations. That leads to the NV variable cannot be saved to the memory above 4G. Modify as follows: 1.Remove the forced type conversion of UINT32. 2.Use UINT64 type variables. Signed-off-by: xianglai li <lixianglai@loongson.cn> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/OvmfXen: Fix Xen buildJason Andryuk2021-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | commit 202fb22be6e9 "OvmfPkg/SecMain: validate the memory used for decompressing Fv" broke building OvmfXen with: edk2/OvmfPkg/OvmfXen.dsc(...): error 1001: Module type [SEC] is not supported by library instancer [edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf] consumed by [edk2/OvmfPkg/Sec/SecMain.inf] The above commit added a reference to MemEncryptSevLib into SecMain.inf, but OvmfXen.dsc doesn't have a MemEncryptSevLib entry for SEC. Add one like OvmfPkgX64.dsc has. 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: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
* OvmfPkg: Remove unused print service driver (PrintDxe)Philippe Mathieu-Daude2021-12-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | PrintDxe produces gEfiPrint2ProtocolGuid and gEfiPrint2SProtocolGuid, and those are consumed by the following PrintLib instance: MdeModulePkg/Library/DxePrintLibPrint2Protocol/DxePrintLibPrint2Protocol.inf However, none of the OVMF DSC files contain such a PrintLib class resolution, so none of the OVMF platforms need PrintDxe. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3744 Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/AmdSevDxe: do not use extended PCI config spaceBrijesh Singh via groups.io2021-12-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 added support to ensure that MMIO is only performed against the un-encrypted memory. If MMIO is performed against encrypted memory, a #GP is raised. The AmdSevDxe uses the functions provided by the MemEncryptSevLib to clear the memory encryption mask from the page table. If the MemEncryptSevLib is extended to include VmgExitLib then depedency chain will look like this: OvmfPkg/AmdSevDxe/AmdSevDxe.inf -----> MemEncryptSevLib class -----> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance -----> VmgExitLib class -----> "OvmfPkg/VmgExitLib" instance -----> LocalApicLib class -----> "UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf" instance -----> TimerLib class -----> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance -----> PciLib class -----> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance -----> PciExpressLib class -----> "MdePkg/BasePciExpressLib/BasePciExpressLib.inf" instance The LocalApicLib provides a constructor that gets called before the AmdSevDxe can clear the memory encryption mask from the MMIO regions. When running under the Q35 machine type, the call chain looks like this: AcpiTimerLibConstructor () [AcpiTimerLib] PciRead32 () [DxePciLibI440FxQ35] PciExpressRead32 () [PciExpressLib] The PciExpressRead32 () reads the MMIO region. The MMIO regions are not yet mapped un-encrypted, so the check introduced in the commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 raises a #GP. The AmdSevDxe driver does not require the access to the extended PCI config space. Accessing a normal PCI config space, via IO port should be sufficent. Use the module-scope override to make the AmdSevDxe use the BasePciLib instead of BasePciExpressLib so that PciRead32 () uses the IO ports instead of the extended config space. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/OvmfXen: Fix build with QemuKernelLoaderFsDxeAnthony PERARD2021-09-061-1/+4
| | | | | | | | | | | | VerifyBlob() has been added recently to QemuKernelLoaderFsDxe, also QemuKernelLoaderFsDxe has been added recently to OvmfXen but without an implementation of VerifyBlob(). Fix this by adding the same runes that have been added to OvmfPkgX64.dsc. Fixes: 9f3eda177a4b ("OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxeLin, Gary (HPS OE-Linux)2021-08-311-0/+1
| | | | | | | | | | | | Without QemuKernelLoaderFsDxe, QemuLoadKernelImage() couldn't download the kernel, initrd, and kernel command line from QEMU's fw_cfg. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3574 Signed-off-by: Gary Lin <gary.lin@hpe.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Jim Fehlig <jfehlig@suse.com>
* OvmfPkg/SmbiosPlatformDxe: create Xen-specific module INF fileLaszlo Ersek2021-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | "OvmfPkg/SmbiosPlatformDxe" is structured somewhat differently from the drivers duplicated and trimmed thus far in this series. The final QEMU and Xen versions will share a relatively significant amount of code, therefore duplicating the whole driver is less useful, even temporarily. Instead, duplicate the INF file, in preparation for customizing the entry point function. Because ArmVirtXen doesn't actually include OvmfPkg/SmbiosPlatformDxe [*], there is only one platform that's supposed to consume the new driver: OvmfXen. Switch OvmfXen to the new driver at once. [*] See commit 164cf4038357 ("OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64", 2015-07-26). This patch is best viewed with "git show --find-copies-harder". Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-42-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/OvmfXen: consume PciHostBridgeLibScanLaszlo Ersek2021-06-041-1/+1
| | | | | | | | | | | | | | | | | Switch the OvmfXen platform from the "OvmfPkg/PciHostBridgeLib" instance to the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op functionally; we'll customize the "PciHostBridgeLibScan" instance later. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-32-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/OvmfXen: remove IncompatiblePciDeviceSupport DXE driverLaszlo Ersek2021-06-041-1/+0
| | | | | | | | | | | | | | | | | | | | | The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe", namely DriverInitialize() [OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c], bails out immediately if "PcdPciDisableBusEnumeration" is TRUE. The OvmfXen platform statically assigns this PCD TRUE. Thus, remove the driver from the OvmfXen platform. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-26-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/OvmfXen: make "PcdPciDisableBusEnumeration" Fixed-at-BuildLaszlo Ersek2021-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The OvmfXen platform specifies the dynamic access method for "PcdPciDisableBusEnumeration" needlessly. After the DSC file sets the PCD to TRUE by default, the InitializeXen() function in XenPlatformPei superfluously sets the PCD to TRUE again. There are no other writes to the PCD in the platform. Make the PCD Fixed-At-Build, and remove the access (in fact, the whole InitializeXen() function) from XenPlatformPei. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-20-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/XenAcpiPlatformDxe: remove OVMF's built-in ACPI tablesLaszlo Ersek2021-06-041-1/+0
| | | | | | | | | | | | | | | | | | | Xen is an advanced hypervisor; no Xen guest can function correctly without the hypervisor's dynamically provided ACPI tables. Remove the built-in (fallback) tables from XenAcpiPlatformDxe -- and the OvmfXen platform. Remove any dependencies from XenAcpiPlatformDxe that are no longer needed. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-17-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/XenAcpiPlatformDxe: create from AcpiPlatformDxeLaszlo Ersek2021-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create an almost verbatim copy of the "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" driver for the OvmfXen platform. We're going to trim the driver in subsequent patches. Ultimately, the XenAcpiPlatformDxe driver will duplicate a negligible amount of code that is currently present in the QemuFwCfgAcpiPlatformDxe driver. List the new driver in "Maintainers.txt", in the "OvmfPkg: Xen-related modules" section. Switch the OvmfXen platform to the new driver at once. This patch should be reviewed with "git show --find-copies-harder". Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-12-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/OvmfXen: Set PcdFSBClockAnthony PERARD2021-04-131-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct value when SecPeiDxeTimerLibCpu start to use it for the APIC timer. Currently, nothing appear to use the value in PcdFSBClock before XenPlatformPei had a chance to set it even though TimerLib is included in modules run before XenPlatformPei. XenPlatformPei doesn't use any of the functions that would use that value. No other modules in the PEI phase seems to use the TimerLib before PcdFSBClock is set. There are currently two other modules in the PEI phase that needs the TimerLib: - S3Resume2Pei, but only because LocalApicLib needs it, but nothing is using the value from PcdFSBClock. - CpuMpPei, but I believe it only runs after XenPlatformPei Before the PEI phase, there's the SEC phase, and SecMain needs TimerLib because of LocalApicLib. And it initialise the APIC timers for the debug agent. But I don't think any of the DebugLib that OvmfXen could use are actually using the *Delay functions in TimerLib, and so would not use the value from PcdFSBClock which would be uninitialised. A simple runtime test showed that TimerLib doesn't use PcdFSBClock value before it is set. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210412133003.146438-8-anthony.perard@citrix.com> [lersek@redhat.com: cast Freq to UINT32 for PcdSet32S(), not for ASSERT()]
* OvmfPkg: Add MicrocodeLib in DSC files.Ray Ni2021-04-091-0/+1
| | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3303 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLibDandan Bi2021-03-311-1/+4
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246 MdeLibs.dsc.inc was added for some basic/default library instances provided by MdePkg and RegisterFilterLibNull Library was also added into it as the first version of MdeLibs.dsc.inc. So update platform dsc to consume MdeLibs.dsc.inc for RegisterFilterLibNull which will be consumed by IoLib and BaseLib. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: strip build paths in release buildsRoss Burton2021-03-241-0/+1
| | | | | | | | | | | | GenFw will embed a NB10 section which contains the path to the input file, which means the output files have build paths embedded in them. To reduce information leakage and ensure reproducible builds, pass --zero in release builds to remove this information. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256 Signed-off-by: Ross Burton <ross.burton@arm.com> Message-Id: <20210324115819.605436-1-ross.burton@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io2021-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Introduce a new PciHostBridgeUtilityLib class to share duplicate code between OvmfPkg and ArmVirtPkg. Extract function PciHostBridgeUtilityResourceConflict from PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
* OvmfPkg: disable list length checks in NOOPT and DEBUG buildsLaszlo Ersek2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero, then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list length against the PCD. This turns the time complexity of node-level APIs from constant to linear, and that of full-list manipulations from linear to quadratic. As an example, consider the EFI_SHELL_FILE_INFO list, which is a data structure that's widely used in the UEFI shell. I randomly extracted 5000 files from "/usr/include" on my laptop, spanning 1095 subdirectories out of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are the wall-clock times: PcdMaximumLinkedListLength PcdMaximumLinkedListLength =1,000,000 =0 -------------------------- --------------------------- FAT 4 min 31 s 18 s virtio-fs 5 min 13 s 1 min 33 s Checking list lengths against an arbitrary maximum (default: 1,000,000) seems useless even in NOOPT and DEBUG builds, while the cost is significant; so set the PCD to 0. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20210113085453.10168-10-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on XenIgor Druzhinin2021-01-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We faced a problem with passing through a PCI device with 64GB BAR to UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G address which pushes physical address space to 37 bits. That is above 36-bit width that OVMF exposes currently to a guest without tweaking PcdPciMmio64Size knob. The reverse calculation using this knob was inhereted from QEMU-KVM platform code where it serves the purpose of finding max accessible physical address without necessary trusting emulated CPUID physbits value (that could be different from host physbits). On Xen we expect to use CPUID policy to level the data correctly to prevent situations with guest physbits > host physbits e.g. across migrations. The next aspect raising concern - resource consumption for DXE IPL page tables and time required to map the whole address space in case of using CPUID bits directly. That could be mitigated by enabling support for 1G pages in DXE IPL configuration. 1G pages are available on most CPUs produced in the last 10 years and those without don't have many phys bits. Remove all the redundant code now (including PcdPciMmio64.. handling that's not used on Xen anyway) and grab physbits directly from CPUID that should be what baremetal UEFI systems do. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> [lersek@redhat.com: fix up authorship from groups.io-mangled From line] [lersek@redhat.com: wrap commit message at 74 characters]
* OvmfPkg: add TimeBaseLib resolution for OvmfXenLeif Lindholm2021-01-081-0/+1
| | | | | | | | | | | | | | | | Commit 55ee36b0c490 ("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib") added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks build of OvmfXen.dsc. Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky2021-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To ensure that we always use a validated encryption mask for an SEV-ES guest, create a new interface in the MemEncryptSevLib library to return the encryption mask. This can be used in place of the multiple locations where CPUID is used to retrieve the value (which would require validation again) and allows the validated mask to be returned. The PEI phase will use the value from the SEV-ES work area. Since the SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/OvmfXen.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-11-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VariablePolicy engine to OvmfPkg platformBret Barkelew2020-11-171-0/+4
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Signed-off-by: Bret Barkelew <brbarkel@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: enable HttpDynamicCommandVladimir Olovyannikov2020-10-011-0/+4
| | | | | | | | | | | Enable HttpDynamicCommand (Shell command "http") for OvmfPkg platforms. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2857 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Message-Id: <20200722205434.4348-3-vladimir.olovyannikov@broadcom.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove groups.io corruption from Author meta-datum]
* OvmfPkg: Add RngLib based on TimerLib for CryptoMatthew Carlson2020-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | Updates the DSC's for Ovmf based platforms to add a RngLib that uses the TimerLib. This is due to a later change that adds TimerLib as a dependency for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL previously and it is recommended to switch to a better source of entropy than the system's performance counter. Ref: https://github.com/tianocore/edk2/pull/845 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
* OvmfPkg: Prepare OvmfPkg to use the VmgExitLib libraryTom Lendacky2020-08-161-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Various CpuExceptionHandlerLib libraries will updated to use the new VmgExitLib library. To prevent any build breakage, update the OvmfPkg DSC files that use a form of the CpuExceptionHandlerLib library to include the VmgExitLib library. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkg*.dsc: Change PCDs type about status codeTan, Ming2020-06-181-3/+3
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786 Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory in MdeModulePkg.dec are changed, so change them from PcdsFeatureFlag to PcdsFixedAtBuild in dsc files. Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
* OvmfPkg: Skip initrd command on Xcode toolchainRoman Bolshakov2020-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF booting stops with the assert if built with Xcode on macOS: Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398 ProtectUefiImageCommon - 0x1F218140 - 0x000000001FAB8000 - 0x0000000000008A60 ASSERT_EFI_ERROR (Status = Unsupported) ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status) The assert comes from InitializeHiiPackage() after an attempt to retrieve HII package list from ImageHandle. Xcode still doesn't support HII resource section and LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a ("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"), disable initrd command if built with Xcode toolchain Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-24 03:42:39 +0000