summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Library
Commit message (Collapse)AuthorAgeFilesLines
...
* OvmfPkg: Add BaseResetSystemLibBhyveRebecca Cran2020-05-052-0/+74
| | | | | | | | | | | | | | | Introduce BaseResetSystemLibBhyve.inf, to support powering off bhyve guests. 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> Message-Id: <20200504021853.76658-1-rebecca@bsdio.com> [lersek@redhat.com: MODULE_TYPE: replace DXE_DRIVER with BASE] [lersek@redhat.com: replace <OvmfPlatforms.h> with <IndustryStandard/Bhyve.h>] [lersek@redhat.com: strip ".inf" from subject line] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add QemuFwCfgLibNullRebecca Cran2020-05-052-0/+239
| | | | | | | | | | | | | | Add a null implementation library for QemuFwCfgLib, in order to support building PciHostBridgeLib for bhyve. 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: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200503230910.26783-1-rebecca@bsdio.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add bhyve support into AcpiTimerLibRebecca Cran2020-04-302-0/+62
| | | | | | | | | | | | | On bhyve, the ACPI timer is located at a fixed IO address; it need not be programmed into, nor fetched from, the PMBA -- power management base address -- register of the PCI host bridge. 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> Message-Id: <20200430011212.612386-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-3017-60/+60
| | | | | | | | | | | | | Generated mechanically with: find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \; Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200429215327.606467-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: control PXEv4 / PXEv6 boot support from the QEMU command lineLaszlo Ersek2020-04-282-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from fw_cfg. These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6 boot. If a PXE version is disabled, the corresponding LoadFile protocol instance is not produced by UefiPxeBcDxe, and so EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not generate corresponding *new* boot options either. (Existent boot options are not deleted.) Hook the library into the UefiPxeBcDxe driver. (The driver is already included from "NetworkComponents.dsc.inc", but we can list it again in the DSC file, for providing <LibraryClasses> overrides.) In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does not have fw_cfg access in the PEI phase. Hence a NULL class library that can be linked into UefiPxeBcDxe. When listing the PCDs under [PcdsDynamicDefault], stick with the DEC default values. QEMU switches: -fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn] -fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn] The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation from QEMU's "docs/specs/fw_cfg.txt". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/QemuFwCfgDxeLib: allow UEFI_DRIVER modulesLaszlo Ersek2020-04-281-1/+1
| | | | | | | | | | | | | | | | | | | | We don't distribute UEFI_DRIVER modules stand-alone that were built as part of an OVMF platform. OVMF's UEFI_DRIVERs are allowed to inherit platform dependencies. By enabling UEFI_DRIVERs to consume QemuFwCfgDxeLib, we can hook fw_cfg-based NULL class libraries into UEFI drivers, e.g. in order to set dynamic PCDs. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: introduce QemuFwCfgSimpleParserLibLaszlo Ersek2020-04-282-0/+425
| | | | | | | | | | | | | | | | We already parse some boolean and integer values from named fw_cfg files (usually into PCDs), and we're going to cover more. Add a dedicated library for centralizing the parsing logic. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformDebugLibIoPort: Introduce a Nocheck variantAnthony PERARD2020-04-282-0/+73
| | | | | | | | | Introduce PlatformRomDebugLibIoPortNocheck which doesn't try to detect the debug IO port. Instead, debug logs are always written to the IO port. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-5-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformDebugLibIoPort: factor out debug port detectionAnthony PERARD2020-04-285-22/+36
| | | | | | | | | Factor out debug port detection in PlatformDebugLibIoPort. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-4-anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformDebugLibIoPort: Reword QEMU to hypervisorAnthony PERARD2020-04-284-4/+4
| | | | | | | | | | We are going to reuse PlatformDebugLibIoPort to use debug IO port from hypervisors that aren't QEMU, so reword "QEMU" to "hypervisor" in the descriptions. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-3-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instanceLaszlo Ersek2020-04-223-1/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BaseResetSystemLib instance is not suitable for OS runtime, because its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID). On q35, this boils down to a memory-mapped config space access -- but we never ask the OS to map MMCONFIG for runtime. There are at least three alternatives to approach this: (1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers some kind of runtime mapping for MMCONFIG. (2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib. Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port accesses on q35 too, not just on i440fx. IO ports don't depend on page tables. (3) In the lib constructor, cache "mAcpiPmBaseAddress" based on "PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the host bridge type will be known at runtime without PCI config space accesses. This patch follows approach (3), in order to mirror AcpiTimerLib. Notes: * This patch is best viewed with "git show --find-copies-harder -C43". * PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD protocol is not available yet. (The DXE_CORE does consume ResetSystemLib in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.) 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: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-7-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> [lersek@redhat.com: move third Note (with repro info) to BZ comment]
* OvmfPkg/ResetSystemLib: rename to BaseResetSystemLibLaszlo Ersek2020-04-222-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing DxeResetSystemLib, rename the current (only) ResetSystemLib instance to BaseResetSystemLib. In the DSC files, keep the ResetSystemLib resolution in the same [LibraryClasses] section, but move it near the TimerLib resolution, as the differences between the ResetSystemLib instances will mostly follow those seen under OvmfPkg/Library/AcpiTimerLib. (While OvmfXen does not use "OvmfPkg/Library/AcpiTimerLib", perform the same movement there too, for keeping future DSC diffing simple.) 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: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-6-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: factor out ResetShutdown()Laszlo Ersek2020-04-223-49/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the ResetShutdown() definition to its own file. This will help us introduce: - a new library instance that is not broken in runtime modules (the current library instance is broken in runtime modules), - another new library instance for bhyve support. While at it, squash AcpiPmControl() into ResetShutdown(), open-coding SuspendType=0. This is justified because we've had no other callers for AcpiPmControl() since commit 2d9950a2bff8 ("OvmfPkg: remove EnterS3WithImmediateWake () from ResetSystemLib", 2020-01-10). Tested with the "reset -s" UEFI shell command, on both i440fx and q35. 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-5-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: improve coding style in ResetSystem()Laszlo Ersek2020-04-221-3/+3
| | | | | | | | | | | | | | | | | | | The cases under ResetSystem() currently mix "break"s with "return"s for no good reason. Use "break" consistently. (The inconsistency was introduced in commit 84c0b80de716, "OvmfPkg/ResetSystemLib: Add new API ResetSystem", 2019-04-28.) 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: clean up library dependenciesLaszlo Ersek2020-04-222-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Annotate the #include directives with the interfaces that this lib instance needs from the included lib class headers. This will help us keep the #include set minimal, when we move code around later. While at it, synchronize the [LibraryClasses] section with the #include directives -- list BaseLib. Also #include the ResetSystemLib class header, which declares the interfaces that this lib instance implements. This forces us to spell out the "MdeModulePkg.dec" dependency too, under [Packages]. 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: wrap long linesLaszlo Ersek2020-04-222-10/+13
| | | | | | | | | | | | | | | Wrap the source code and the INF file at 79 characters. 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/GenericQemuLoadImageLib: Fix VS2019 UINT32 conversion errorArd Biesheuvel2020-03-301-1/+1
| | | | | | | | | | | | | | | | Building OVMF for X64 with secure boot enabled on VS2019 results in the following error: d:\a\1\s\OvmfPkg\Library\GenericQemuLoadImageLib\GenericQemuLoadImageLib.c(154): error C2220: the following warning is treated as an error d:\a\1\s\OvmfPkg\Library\GenericQemuLoadImageLib\GenericQemuLoadImageLib.c(154): warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data Suppress the error by making the cast explicit. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2636 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/X86QemuLoadImageLib: add dummy assignment to work around GCCArd Biesheuvel2020-03-261-0/+5
| | | | | | | | | | | | | | | | | | | | | GCC 4.8 or 4.9 may throw the following error when building OVMF: Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c: In function ‘QemuLoadKernelImage’: Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c:416:30: error: ‘CommandLine’ may be used uninitialized in this function [-Werror=maybe-uninitialized] UnicodeSPrintAsciiFormat ( cc1: all warnings being treated as errors This is due to the fact that older GCCs fail to infer that CommandLine is never actually used unless it has been assigned. So add a redundant NULL assignment to help these older GCCs understand this. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2630 Fixes: 7c47d89003a6f ("OvmfPkg: implement QEMU loader library for X86 with ...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Fix build failure with VS2015 tool chainLiming Gao2020-03-171-1/+1
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2582 warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/X86QemuLoadImageLib: fix "unused variable" error in X64 DXE buildsLaszlo Ersek2020-03-081-1/+2
| | | | | | | | | | | | | | | | | | | | | When the MDE_CPU_IA32 macro is not defined, there is no access to the "KernelImageHandle" local variable in QemuStartKernelImage(). This breaks the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8. Move the local variable to the inner scope, where declaration and usage are inseparable. (Note that such inner-scope declarations are frowned upon in the wider edk2 codebase, but we use them liberally in ArmVirtPkg and OvmfPkg anyway, because they help us reason about variable lifetime and visibility.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 7c47d89003a6f8f7f6f0ce8ca7d3e87c630d14cc Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2572 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLibArd Biesheuvel2020-03-052-132/+14
| | | | | | | | | | | | Replace the open coded sequence to load Linux on x86 with a short and generic sequence invoking QemuLoadImageLib, which can be provided by a generic version that only supports the LoadImage and StartImage boot services, and one that incorporates the entire legacy loading sequence as well. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: implement QEMU loader library for X86 with legacy fallbackArd Biesheuvel2020-03-052-0/+609
| | | | | | | | | | | | | | | | Implement another version of QemuLoadImageLib that uses LoadImage and StartImage, but falls back to the legacy Linux loader code if that fails. The logic in the legacy fallback routines is identical to the current QEMU linux loader for X64 and IA32. Note the use of the OVMF_LOADED_X86_LINUX_KERNEL protocol for the legacy loaded image: this makes it possible to expose the LoadImage/StartImage abstraction for the legacy loader, using the EFI paradigm of identifying a loaded image solely by a handle. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: provide a generic implementation of QemuLoadImageLibArd Biesheuvel2020-03-052-0/+314
| | | | | | | | | | | Implement QemuLoadImageLib, and make it load the image provided by the QEMU_EFI_LOADER_FS_MEDIA_GUID/kernel device path that we implemented in a preceding patch in a separate DXE driver, using only the standard LoadImage and StartImage boot services. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: sync Timeout with PcdPlatformBootTimeOutLaszlo Ersek2020-03-052-2/+26
| | | | | | | | | | | | | | | | | | Set the Timeout global variable to the same value as PcdPlatformBootTimeOut. This way the "setvar" command in the UEFI shell, and the "efibootmgr" command in a Linux guest, can report the front page timeout that was requested on the QEMU command line (see GetFrontPageTimeoutFromQemu()). A DEBUG_VERBOSE message is logged on success too, for our QE team's sake. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200304094413.19462-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmmLaszlo Ersek2020-03-042-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With "PcdCpuSmmEnableBspElection" set to FALSE, PiSmmCpuDxeSmm always considers the processor with index 0 to be the SMM Monarch (a.k.a. the SMM BSP). The SMM Monarch handles the SMI for real, while the other CPUs wait in their SMM loops. In a subsequent patch, we want to set "PcdCpuHotPlugSupport" to TRUE. For that, PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c] forces us with an ASSERT() to set "PcdCpuSmmEnableBspElection" to TRUE as well. To satisfy that expectation, we can simply remove our current "PcdCpuSmmEnableBspElection|FALSE" setting, and inherit the default TRUE value from "UefiCpuPkg.dec". This causes "mSmmMpSyncData->BspIndex" in PiSmmCpuDxeSmm to lose its static zero value (standing for CPU#0); instead it becomes (-1) in general, and the SMM Monarch is elected anew on every SMI. The default SMM Monarch Election is basically a race -- whichever CPU can flip "mSmmMpSyncData->BspIndex" from (-1) to its own index, becomes king, for handling that SMI. Refer to SmiRendezvous() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]. I consider this non-determinism less than ideal on QEMU/KVM; it would be nice to stick with a "mostly permanent" SMM Monarch even with the Election enabled. We can do that by implementing the PlatformSmmBspElection() API in the SmmCpuPlatformHookLibQemu instance: The IA32 APIC Base MSR can be read on each CPU concurrently, and it will report the BSP bit as set only on the current Boot Service Processor. QEMU marks CPU#0 as the BSP, by default. Elect the current BSP, as reported by QEMU, for the SMM Monarch role. (Note that the QEMU commit history is not entirely consistent on whether QEMU/KVM may mark a CPU with nonzero index as the BSP: - At tag v4.2.0, "target/i386/cpu.c" has a comment saying "We hard-wire the BSP to the first CPU". This comment goes back to commit 6cb2996cef5e ("x86: Extend validity of bsp_to_cpu", 2010-03-04). - Compare commit 9cb11fd7539b ("target-i386: clear bsp bit when designating bsp", 2015-04-02) though, especially considering KVM. Either way, this OvmfPkg patch is *not* dependent on CPU index 0; it just takes the race on every SMI out of the game.) One benefit of using a "mostly permanent" SMM Monarch / BSP is that we can continue testing the SMM CPU synchronization by deterministically entering the firmware on the BSP, vs. on an AP, from Linux guests: $ time taskset -c 0 efibootmgr $ time taskset -c 1 efibootmgr (See <https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#uefi-variable-access-test>.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c5 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkgLaszlo Ersek2020-03-042-0/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clone the Null instance of SmmCpuPlatformHookLib from UefiCpuPkg to OvmfPkg. In this patch, customize the lib instance only with the following no-op steps: - Replace Null/NULL references in filenames and comments with Qemu/QEMU references. - Update copyright notices. - Clean up and rewrap comment blocks. - Update INF_VERSION to the latest INF spec version (1.29). - Update FILE_GUID. - Drop the UNI file. This patch is best reviewed with: $ git show --find-copies=43 --find-copies-harder Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/Xen: Fix various typosAntoine Coeur2020-02-102-5/+5
| | | | | | | | | | | | | | | | Fix various typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-61-philmd@redhat.com>
* OvmfPkg/Virtio: Fix few typosAntoine Coeur2020-02-101-1/+1
| | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-59-philmd@redhat.com>
* OvmfPkg/Qemu: Fix various typosAntoine Coeur2020-02-103-4/+4
| | | | | | | | | | | | | | | | | | | | Fix various typos in comments and documentation. When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh" to update "VbeShim.h". The string modified by this patch is only used when the DEBUG macro (at the top of the file) is commented out. Since the string is not referenced, NASM eliminates it, resulting in the same byte array content in "VbeShim.h". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-58-philmd@redhat.com>
* OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASELaszlo Ersek2020-02-052-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OVMF runs in a SEV guest, the initial SMM Save State Map is (1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei, function AmdSevInitialize(), for preventing unintended information sharing with the hypervisor; (2) decrypted in AmdSevDxe; (3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function SmmCpuFeaturesSmmRelocationComplete(), which is called by PiSmmCpuDxeSmm right after initial SMBASE relocation; (4) released to DXE at the same location. The SMRAM at the default SMBASE is a superset of the initial Save State Map. The reserved memory allocation in InitializeRamRegions(), from the previous patch, must override the allocating and freeing in (1) and (4), respectively. (Note: the decrypting and re-encrypting in (2) and (3) are unaffected.) In AmdSevInitialize(), only assert the containment of the initial Save State Map, in the larger area already allocated by InitializeRamRegions(). In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the initial Save State Map into OS runtime, as part of the allocation done by InitializeRamRegions(). Only assert containment. These changes only affect the normal boot path (the UEFI memory map is untouched during S3 resume). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: remove EnterS3WithImmediateWake () from ResetSystemLibArd Biesheuvel2020-01-101-18/+0
| | | | | | | | EnterS3WithImmediateWake () no longer has any callers, so remove it from ResetSystemLib. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0Pete Batard2019-10-161-3/+12
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266 Independently of how we decide to address other aspects of the regression introduced with commit 2de1f611be06ded3a59726a4052a9039be7d459b, it doesn't make much sense to call for a progress update if PcdPlatformBootTimeOut is zero. PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero) should be considered to indicate that a platform is not interested in displaying a progress report, so we alter PlatformBootManagerWaitCallback to behave that way. We also change one variable name to make the code more explicit. Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20191014150311.16740-2-pete@akeo.ie>
* OvmfPkg: strip trailing whitespaceLeif Lindholm2019-10-047-13/+13
| | | | | | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkgAnthony PERARD2019-08-212-0/+223
| | | | | | | | | | | Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg" Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-35-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConInAnthony PERARD2019-08-214-4/+53
| | | | | | | | | | | | | | | | | | | | On a Xen PVH guest, none of the existing serial or console interface works, so we add a new one, based on XenConsoleSerialPortLib, and implemented via SerialDxe. That is a simple console implementation that can work on both PVH guest and HVM guests, even if it is rarely going to be used on HVM. Have PlatformBootManagerLib look for the new console, when running as a Xen guest. Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding style. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-32-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVHAnthony PERARD2019-08-211-0/+6
| | | | | | | | | | | | When running in a Xen PVH guest, there's nothing to do in PciAcpiInitialization() because there isn't any PCI bus. When the Host Bridge DID isn't recognised, simply continue. (The value of PcdOvmfHostBridgePciDevId would be 0 because it isn't set.) Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-29-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLibAnthony PERARD2019-08-212-34/+2
| | | | | | | | | | Replace the XenDetected() implementation by the one from XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-28-anthony.perard@citrix.com>
* OvmfPkg/XenPlatformLib: Cache result for XenDetectedAnthony PERARD2019-08-211-4/+16
| | | | | | | | | | | | We are going to replace XenDetected() implementation in PlatformBootManagerLib by the one in XenPlatformLib. PlatformBootManagerLib's implementation does cache the result of GetFirstGuidHob(), so we do something similar in XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-27-anthony.perard@citrix.com>
* OvmfPkg/XenHypercallLib: Enable it in PEIMAnthony PERARD2019-08-213-9/+19
| | | | | | | | | | | | | | | Allow to use Xen hypercalls earlier, during the PEIM stage, but XenHypercallLibInit() must be called once the XenInfo HOB is created with the HyperPage setup. Change the return value of XenHypercallLibInit so failure can be detected when the call shouldn't fail, but still have the constructor always succeed. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-17-anthony.perard@citrix.com>
* OvmfPkg/Library/XenPlatformLib: New libraryAnthony PERARD2019-08-212-0/+102
| | | | | | | | | | | The purpose of XenPlatformLib is to regroup the few functions that are used in several places to detect if Xen is detected, and to get the XenInfo HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-14-anthony.perard@citrix.com>
* OvmfPkg/ResetSystemLib: Add missing dependency on PciLibAnthony PERARD2019-08-212-2/+2
| | | | | | | | | Add missing dependency on PciLib and remove extra includes of OvmfPlatforms.h. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-2-anthony.perard@citrix.com>
* OvmfPkg: Refer to Shell app via its declared GUIDHao A Wu2019-06-172-5/+5
| | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843 Currently, the file GUID reference of the UEFI Shell app is indirected via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile, which is set to a fixed value for OvmfPkg. So instead, use the symbolic GUID in ShellPkg for this purpose, and drop the reference to this PCD, and to the IntelFrameworkModulePkg package entirely. Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/XenSupport: turn off address decoding before BAR sizingIgor Druzhinin2019-04-301-0/+21
| | | | | | | | | | | | | | | On Xen, hvmloader firmware leaves address decoding enabled for enumerated PCI device before jumping into OVMF. OVMF seems to expect it to be disabled and tries to size PCI BARs in several places without disabling it which causes BAR64, for example, being incorrectly placed by QEMU. Fix it by disabling PCI address decoding explicitly before the first attempt to size BARs on Xen. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64Igor Druzhinin2019-04-301-1/+5
| | | | | | | | In case BAR64 is placed below 4G choose the correct aperture. This fixes a failed assertion down the code path. Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
* OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge apertureIgor Druzhinin2019-04-301-22/+12
| | | | | | | | | | | | | | | | | | This aperture doesn't exist in QEMU-XEN and hvmloader places BARs in arbitrary order disregarding prefetchable bit. This makes prefetchable and non-prefetchable BARs to follow each other that's quite likely with PCI passthrough devices. In that case, the existing code, that tries to work out aperture boundaries by reading hvmloader BAR placement, will report a bogus prefetchable aperture which overlaps with the regular one. It will eventually trigger an assertion in DXE PCI initialization code. Do the same thing as OVMF on QEMU-KVM and pass a non-existing aperture there. It's not necessary to pass additional allocation flags as we set ResourceAssigned flag on the root bridge which means they will be ignored. Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Remove dependency on Mps.hShenglei Zhang2019-04-281-1/+0
| | | | | | | | | | | | | Mps.h is included in BdsPlatform.h but not actually used. So remove it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* OvmfPkg/ResetSystemLib: Add new API ResetSystemZhichao Gao2019-04-281-1/+44
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460 Add a new API ResetSystem to this ResetSystemLib instance. It only adds the basic functions from ResetSystemRuntimeDxe. Lacking of this interface may cause link error, if some drivers use this new API and link to this library instance. Notes: This library API only provide a basic function of reset. Full function should use the instance in the MdeModulePkg and make sure the depex driver is dispatched. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/BasePciCapLib: suppress invalid "nullptr deref" warningLaszlo Ersek2019-04-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RH covscan reports the following "nullptr deref" warning: > Error: CLANG_WARNING: > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5: > warning: Dereference of null pointer > # InstanceZero->NumInstancesUnion.NumInstances++; > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:509:7: > note: Assuming 'OutCapList' is not equal to NULL > # if (OutCapList == NULL) { > # ^~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:509:3: > note: Taking false branch > # if (OutCapList == NULL) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:518:7: > note: Assuming the condition is false > # if (OutCapList->Capabilities == NULL) { > # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:518:3: > note: Taking false branch > # if (OutCapList->Capabilities == NULL) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:529:7: > note: Assuming 'CapHdrOffsets' is not equal to NULL > # if (CapHdrOffsets == NULL) { > # ^~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:529:3: > note: Taking false branch > # if (CapHdrOffsets == NULL) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:546:3: > note: Taking false branch > # if (RETURN_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:549:7: > note: Assuming the condition is true > # if ((PciStatusReg & EFI_PCI_STATUS_CAPABILITY) != 0) { > # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:549:3: > note: Taking true branch > # if ((PciStatusReg & EFI_PCI_STATUS_CAPABILITY) != 0) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:557:5: > note: Taking false branch > # if (RETURN_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:565:12: > note: Assuming 'NormalCapHdrOffset' is > 0 > # while (NormalCapHdrOffset > 0) { > # ^~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:565:5: > note: Loop condition is true. Entering loop body > # while (NormalCapHdrOffset > 0) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:570:7: > note: Taking false branch > # if (RETURN_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:574:16: > note: Calling 'InsertPciCap' > # Status = InsertPciCap (OutCapList, CapHdrOffsets, PciCapNormal, > # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:235:3: > note: Null pointer value stored to 'InstanceZero' > # InstanceZero = NULL; > # ^~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:243:7: > note: Assuming 'PciCap' is not equal to NULL > # if (PciCap == NULL) { > # ^~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:243:3: > note: Taking false branch > # if (PciCap == NULL) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:259:3: > note: Taking false branch > # if (RETURN_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:297:3: > note: Taking false branch > # if (RETURN_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:311:7: > note: Assuming the condition is true > # if (PciCap->Key.Instance > 0) { > # ^~~~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:311:3: > note: Taking true branch > # if (PciCap->Key.Instance > 0) { > # ^ > edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5: > note: Dereference of null pointer > # InstanceZero->NumInstancesUnion.NumInstances++; > # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # 310| // > # 311| if (PciCap->Key.Instance > 0) { > # 312|-> InstanceZero->NumInstancesUnion.NumInstances++; > # 313| } > # 314| return RETURN_SUCCESS; The warning is invalid: the flagged dereferencing of "InstanceZero" is gated by a condition that is only satisfied if we dereference "InstanceZero" *first*. (Perhaps the analyzer assumes that the OrderedCollectionInsert() call, just before line 259, can change the value of "PciCap->Key.Instance" via the last argument: 254 // 255 // Add PciCap to CapList. 256 // 257 Status = OrderedCollectionInsert (CapList->Capabilities, &PciCapEntry, 258 PciCap); 259 if (RETURN_ERROR (Status)) { That assumption is incorrect.) Add a comment and an ASSERT(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710 Issue: scan-0994.txt Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-09118-822/+118
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformDebugLibIoPort: Add new APIsBret Barkelew2019-04-021-5/+101
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 Add new APIs' implementation (DebugVPrint, DebugBPrint) in the DebugLib instance. These APIs would expose print routines with VaList parameter and BaseList parameter. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-11 11:49:40 +0000