summaryrefslogtreecommitdiff
path: root/OvmfPkg/Bhyve
AgeCommit message (Collapse)AuthorFilesLines
2022-07-07OvmfPkg: Pipeline: Resolve SecureBootVariableLib dependencyKun Qin1-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>
2022-06-22Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous dataNicolas Ojeda Leon1-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>
2022-06-22Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfgNicolas Ojeda Leon1-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>
2022-05-19OvmfPkg: Add VariableFlashInfoLibMichael Kubacki1-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>
2022-05-02OvmfPkg/Bhyve: add support for QemuFwCfgCorvin Köhne3-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>
2022-04-19OvmfPkg: Add CcProbeLib in *.dscMin Xu1-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>
2022-04-04OvmfPkg: Revert Uncrustify formatting in VbeShim.h filesMichael Kubacki1-906/+905
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3875 Reverts changes automatically applied by Uncrustify in commit ac0a286. 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: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2022-04-02OvmfPkg: Update IoMmuDxe to support TDXMin Xu1-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>
2022-04-02MdeModulePkg: Add PcdTdxSharedBitMaskMin Xu1-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>
2022-04-02OvmfPkg: Update Sec to support TdxMin Xu1-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>
2021-12-23OvmfPkg: Bhyve: Delete unused AcpiTables/Ssdt.asl fileRebecca Cran1-15/+0
The Ssdt.asl file isn't used, so delete it. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org>
2021-12-17OvmfPkg/Bhyve: fix tls-enabled buildGerd Hoffmann1-1/+1
Path doesn't exist below OvmfPkg/Bhyve, use the OvmfPkg version instead. Fixes build with -D NETWORK_TLS_ENABLE. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
2021-12-13OvmfPkg/Bhyve: add MemEncryptSevLibGerd Hoffmann1-0/+1
Fixes build failure: build.py... /home/kraxel/projects/edk2/OvmfPkg/Bhyve/BhyveX64.dsc(...): error 1001: Module type [SEC] is not supported by library instance [/home/kraxel/projects/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf] consumed by [/home/kraxel/projects/edk2/OvmfPkg/Sec/SecMain.inf] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-12-11OvmfPkg-EmuVariableFvbRuntimeDxe: Support Access To Memory Above 4Glixianglai1-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>
2021-12-10OvmfPkg: Remove unused print service driver (PrintDxe)Philippe Mathieu-Daude2-2/+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>
2021-12-09OvmfPkg/AmdSevDxe: do not use extended PCI config spaceBrijesh Singh via groups.io1-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>
2021-12-07OvmfPkg: Apply uncrustify changesMichael Kubacki23-1740/+1848
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
2021-12-07OvmfPkg: Change OPTIONAL keyword usage styleMichael D Kinney1-2/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760 Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
2021-11-11OvmfPkg/Bhyve/PlatformPei: Fix VS2019 X64 NOOPT build issueMichael D Kinney1-1/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3724 Add typecast to fix build error with VS2019 X64 NOOPT converting a UINT64 value to UINT32 value. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org>
2021-08-03OvmfPkg: add SecureBootVariableLib class resolutionGrzegorz Bernacki1-0/+2
The edk2 patch SecurityPkg: Create library for setting Secure Boot variables. moves generic functions from SecureBootConfigDxe and places them into SecureBootVariableLib. This patch adds SecureBootVariableLib mapping for OvmfPkg. Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Sunny Wang <sunny.wang@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
2021-07-05OvmfPkg/Bhyve: use static PCI32Base addressCorvin Köhne2-3/+5
It's neccessary to allocate a Graphics Stolen Memory area to enable GPU-Passthrough for integrated Intel GPUs. Therefore, use a new memory layout with a static Pci32Baseaddress. Old layout: [... , lowmemlimit] RAM [lowmemlimit, 0xE000 0000] PCI Space New layout: [... , lowmemlimit] RAM [lowmemlimit, gsmbase ] Memory hole (may be absent) [gsmbase , 0xC000 0000] GSM (may be absent) [0xC000 0000, 0xE000 0000] PCI Space Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Rebecca Cran <rebecca@bsdio.com> Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com> Message-Id: <20210705110842.14088-2-c.koehne@beckhoff.com>
2021-07-05OvmfPkg/Bhyve: add USB supportCorvin Köhne2-0/+17
An USB driver is required to use a keyboard or mouse while installing an OS or while in a bootloader menu like grub when using GPU + USB Passthrough. Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Rebecca Cran <rebecca@bsdio.com> Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com> Message-Id: <20210705110842.14088-1-c.koehne@beckhoff.com>
2021-06-24OvmfPkg/Bhyve: clean up TPM_ENABLE remnantsRebecca Cran2-79/+0
TPM support hasn't been tested and any lines in the .dsc and .fdf files that appear to show support are bogus. Remove them. This fixes https://bugzilla.tianocore.org/show_bug.cgi?id=3354 . Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20210612204340.52290-1-rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-06-04OvmfPkg/Bhyve: consume PciHostBridgeLibScanLaszlo Ersek1-1/+1
Switch the Bhyve 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: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-31-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
2021-06-04OvmfPkg/Bhyve: remove IncompatiblePciDeviceSupport DXE driverLaszlo Ersek2-2/+0
The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe", namely DriverInitialize() [OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c], bails out immediately if "PcdPciDisableBusEnumeration" is TRUE. The Bhyve platform statically assigns this PCD TRUE. Thus, remove the driver from the Bhyve platform. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-27-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-06-04OvmfPkg/Bhyve: make "PcdPciDisableBusEnumeration" Fixed-at-BuildLaszlo Ersek2-2/+1
The Bhyve platform specifies the dynamic access method for "PcdPciDisableBusEnumeration" needlessly. After the DSC file sets the PCD to TRUE by default, the PCD is never written again. In particular, the "OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf" file references the PCD superfluously. Make the PCD Fixed-At-Build, and remove the PCD reference from the INF file. (Note that further simplifications are possible in "OvmfPkg/Bhyve/AcpiPlatformDxe", but those are out of scope for this patch series.) Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-25-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
2021-06-04OvmfPkg/Bhyve/AcpiPlatformDxe: fix file path typo in commentLaszlo Ersek1-1/+1
The built-in ACPI tables for Bhyve are located in the "OvmfPkg/Bhyve/AcpiTables" module, not in the "OvmfPkg/AcpiTables" module. Correct the typo in a code comment. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-18-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
2021-04-09OvmfPkg: Add MicrocodeLib in DSC files.Ray Ni1-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>
2021-03-31OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLibDandan Bi1-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>
2021-03-24OvmfPkg: strip build paths in release buildsRoss Burton1-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>
2021-01-20OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io1-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>
2021-01-19OvmfPkg: disable list length checks in NOOPT and DEBUG buildsLaszlo Ersek1-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>
2021-01-07OvmfPkg: Obtain SEV encryption mask with the new MemEncryptSevLib APITom Lendacky1-10/+2
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The early assembler code performs validation for some of the SEV-related information, specifically the encryption bit position. The new MemEncryptSevGetEncryptionMask() interface provides access to this validated value. To ensure that we always use a validated encryption mask for an SEV-ES guest, update all locations that use CPUID to calculate the encryption mask to use the new interface. Also, clean up some call areas where extra masking was being performed and where a function call was being used instead of the local variable that was just set using the function. 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: Brijesh Singh <brijesh.singh@amd.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> Message-Id: <9de678c0d66443c6cc33e004a4cac0a0223c2ebc.1610045305.git.thomas.lendacky@amd.com>
2021-01-07OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky1-1/+3
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>
2020-11-30OvmfPkg/Bhyve: Fix various style issuesRebecca Cran15-53/+47
Fix ordering of includes, sources, libraries etc. Remove leading/trailing underscores from include guards. Change INF and DSC version numbers to be decimal. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-6-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-11-27OvmfPkg/Bhyve: Copy Real16ToFlat32.asm and enable cache in CR0Rebecca Cran1-0/+143
Copy UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm to OvmfPkg/Bhyve/ResetVector/Ia16, with one change, as has also been made in XenResetVector: - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0) With the CD bit set to 1, this has the downside on AMD systems of actually running with the cache disabled, which slows the entire system to a crawl. There's no need for this bit to be set in virtualized environments. This patch reapplies the change from the freebsd uefi-edk2 repo at https://github.com/freebsd/uefi-edk2/commit/08c00f4e8d9e3e469bdc2ce92d3aa839cae7cf17 Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-4-rebecca@bsdio.com>
2020-11-27OvmfPkg/Bhyve: Add support for the AMD host bridgeRebecca Cran1-1/+2
On bhyve, either an Intel or AMD host bridge can be specified, with the default being Intel. Both are identical, except the AMD one uses a PCI vendor ID of AMD. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-3-rebecca@bsdio.com>
2020-11-27OvmfPkg/Bhyve: Add VariablePolicy engine to BhyveRebecca Cran1-1/+3
https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-2-rebecca@bsdio.com>
2020-11-17OvmfPkg/BhyveX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao1-1/+4
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-12-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-11-13OvmfPkg/Bhyve: fix build breakage after SEV-ES changesRebecca Cran2-2/+3
Consume the SEV-ES-independent reset vector restored in the previous patch. Use the Null instance of VmgExitLib. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-3-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-11-13OvmfPkg/Bhyve: detach ResetVector from before the SEV-ES changesRebecca Cran3-0/+255
Commits 6995a1b79bab, 8a2732186a53 and 30937f2f98c4 modified all four regular files under "OvmfPkg/ResetVector" with SEV-ES dependencies. These are not relevant for Bhyve. Detach the pre-SEV-ES version of ResetVector for Bhyve. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-2-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-09-18OvmfPkg: Add RngLib based on TimerLib for CryptoMatthew Carlson1-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>
2020-08-24OvmfPkg/Bhyve: rename files to remove 'Pkg' infixRebecca Cran3-2/+2
OvmfPkg is the package, so while there are files to build bhyve separately, they shouldn't have 'Pkg' in the name. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Peter Grehan <grehan@freebsd.org> Message-Id: <20200818021035.6479-1-rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-08-19OvmfPkg: Fix spelling mistake for occurredMichael D Kinney1-1/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2361 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
2020-08-01OvmfPkg: fix DEC spec violation introduced by Bhyve additionLaszlo Ersek13-2787/+7
Sean reports that having two DEC files under OvmfPkg violates the DEC spec: > An EDK II Package (directory) is a directory that contains an EDK II > package declaration (DEC) file. Only one DEC file is permitted per > directory. EDK II Packages cannot be nested within other EDK II > Packages. This issue originates from commit 656419f922c0 ("Add BhyvePkg, to support the bhyve hypervisor", 2020-07-31). Remedy the problem as follows. (Note that these steps are not split to multiple patches in order to keep Bhyve buildable across the transition.) (1) Delete "OvmfPkg/Bhyve/BhyvePkg.dec". (2) Point the [Packages] sections of the Bhyve-specific AcpiPlatformDxe, BhyveRfbDxe, and BhyveFwCtlLib INF files to "OvmfPkg.dec". (3) Migrate the artifacts that "BhyvePkg.dec" used to have on top of "OvmfPkg.dec" as follows: (3a) Merge the copyright notices from Rebecca Cran and Pluribus Networks into "OvmfPkg.dec". (3b) Merge the "BhyveFwCtlLib" class header definition into "OvmfPkg.dec". (3c) Merge value 0x2F8 for the fixed PcdDebugIoPort into "BhyvePkgX64.dsc". (4) Unnest the the Include/Library/ and Library/ subtrees from under OvmfPkg/Bhyve to the corresponding, preexistent subtrees in OvmfPkg. The goal is to keep the [Includes] section in the "OvmfPkg.dec" file unchanged, plus simplify references in "BhyvePkgX64.dsc". Non-library modules remain under "OvmfPkg/Bhyve/". (4a) The BhyveFwCtlLib class header, and sole instance, are already uniquely named, so their movements need not involve file renames. (4b) Rename the Bhyve-specific PlatformBootManagerLib instance to PlatformBootManagerLibBhyve, in additon to moving it, for distinguishing it from OvmfPkg's preexistent lib instance. Apply the name change to all three of the lib instance directory name, the INF file, and the BASE_NAME define in the INF file. (4c) Update lib class resolutions in "BhyvePkgX64.dsc" accordingly. (5) Replace the "ACPI table storage" FILE_GUID in "OvmfPkg/Bhyve/AcpiTables/AcpiTables.inf" with a new GUID, and open-code the "ACPI table storage" GUID in the "ACPITABLE" FDF rule instead, replacing $(NAMED_GUID). This step is necessary because CI requires unique FILE_GUIDs over all INF files, and OVMF's original "AcpiTables.inf" already uses the "ACPI table storage" GUID as FILE_GUID. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sean Brogan <spbrogan@outlook.com> Fixes: 656419f922c047a3c48bd3f4ecea7d8e87d0b761 Reported-by: Sean Brogan <spbrogan@outlook.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200801155024.16439-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
2020-07-31Add BhyvePkg, to support the bhyve hypervisorRebecca Cran53-0/+12283
BhyvePkg supports the bhyve hypervisor, which is a hypervisor/virtual machine manager available on FreeBSD, macOS and Illumos. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20200713054131.479627-2-rebecca@bsdio.com> Acked-by: Laszlo Ersek <lersek@redhat.com>