summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: use generic QEMU image loader for secure boot enabled buildsArd Biesheuvel2020-03-053-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QemuLoadImageLib implementation we currently use for all OVMF builds copies the behavior of the QEMU loader code that precedes it, which is to disregard UEFI secure boot policies entirely when it comes to loading kernel images that have been specified on the QEMU command line. This behavior deviates from ArmVirtQemu based builds, which do take UEFI secure boot policies into account, and refuse to load images from the command line that cannot be authenticated. The disparity was originally due to the fact that the QEMU command line kernel loader did not use LoadImage and StartImage at all, but this changed recently, and now, there are only a couple of reasons left to stick with the legacy loader: - it permits loading images that lack a valid PE/COFF header, - it permits loading X64 kernels on IA32 firmware running on a X64 capable system. Since every non-authentic PE/COFF image can trivially be converted into an image that lacks a valid PE/COFF header, the former case can simply not be supported in a UEFI secure boot context. The latter case is highly theoretical, given that one could easily switch to native X64 firmware in a VM scenario. That leaves us with little justification to use the legacy loader at all when UEFI secure boot policies are in effect, so let's switch to the generic loader for UEFI secure boot enabled builds. 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/QemuKernelLoaderFsDxe: add support for new Linux initrd device pathArd Biesheuvel2020-03-052-0/+81
| | | | | | | | | | | | Linux v5.7 will introduce a new method to load the initial ramdisk (initrd) from the loader, using the LoadFile2 protocol installed on a special vendor GUIDed media device path. Add support for this to our QEMU command line kernel/initrd loader. 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: 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: add new QEMU kernel image loader componentsArd Biesheuvel2020-03-056-0/+9
| | | | | | | | | | Add the components that expose the QEMU abstract loader file system so that we can switch over our PlatformBmLib over to it in a subsequent patch. 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: create protocol and GUID header for loaded x86 Linux kernelsArd Biesheuvel2020-03-052-26/+59
| | | | | | | | | | In preparation of moving the legacy x86 loading to an implementation of the QEMU load image library class, introduce a protocol header and GUID that we will use to identify legacy loaded x86 Linux kernels in the protocol database. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup blockArd Biesheuvel2020-03-051-21/+53
| | | | | | | | | | | | | | | | On x86, the kernel image consists of a setup block and the actual kernel, and QEMU presents these as separate blobs, whereas on disk (and in terms of PE/COFF image signing), they consist of a single image. So add support to our FS loader driver to expose files via the abstract file system that consist of up to two concatenated blobs, and redefine the kernel file so it consists of the setup and kernel blobs, on every architecture (on non-x86, the setup block is simply 0 bytes and is therefore ignored implicitly) 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/QemuKernelLoaderFsDxe: don't expose kernel command lineArd Biesheuvel2020-03-051-4/+3
| | | | | | | | | | | We have no need for exposing the kernel command line as a file, so remove support for that. Since the remaining blobs (kernel and initrd) are typically much larger than a page, switch to the page based allocator for blobs at the same time. 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>
* ArmVirtPkg/PlatformBootManagerLib: switch to separate QEMU loaderArd Biesheuvel2020-03-052-1063/+7
| | | | | | | | | | Drop the QEMU loader file system implementation inside this library, and switch to the separate QemuLoadImageLib library and the associated driver to expose the kernel and initrd passed via the QEMU command line. 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>
* ArmVirtPkg: incorporate the new QEMU kernel loader driver and libraryArd Biesheuvel2020-03-053-0/+5
| | | | | | | | | Add the QEMU loader DXE driver and client library to the build for our QEMU targeted implementations in ArmVirtPkg. 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: introduce QemuLoadImageLib library classArd Biesheuvel2020-03-052-0/+89
| | | | | | | | | | Introduce the QemuLoadImageLib library class that we will instantiate to load the kernel image passed via the QEMU command line using the standard LoadImage boot service. 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: export abstract QEMU blob filesystem in standalone driverArd Biesheuvel2020-03-052-0/+1027
| | | | | | | | | | | | | | | | | Expose the existing implementation of an abstract filesystem exposing the blobs passed to QEMU via the command line via a standalone DXE driver. Notable difference with the original code is the switch to a new vendor GUIDed media device path, as opposed to a vendor GUID hardware device path, which is not entirely appropriate for pure software constructs. Since we are using the GetTime() runtime service in a DXE_DRIVER type module, we need to DEPEX explicitly on gEfiRealTimeClockArchProtocolGuid. 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: add GUID for the QEMU kernel loader fs media device pathArd Biesheuvel2020-03-052-0/+19
| | | | | | | | | | | | | | | In an upcoming patch, we will introduce a separate DXE driver that exposes the virtual SimpleFileSystem implementation that carries the kernel and initrd passed via the QEMU command line, and a separate library that consumes it, to be incorporated into the boot manager. Since the GUID used for the SimpleFileSystem implementation's device path will no longer be for internal use only, create a well defined GUID to identify the media device path. 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>
* ArmVirtPkg/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: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200304094413.19462-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@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>
* MdeModulePkg/Pci: Fixed Asserts in SCT PCIIO Protocol Test.Gaurav Jain2020-03-052-3/+155
| | | | | | | | | | | | | | ASSERT in PollMem_Conf, CopyMem_Conf, SetBarAttributes_Conf Conformance Test. SCT Test expect return as Invalid Parameter or Unsupported. Added Checks for Function Parameters. return Invalid or Unsupported if Check fails. Added Checks in PciIoPollIo(), PciIoIoRead() PciIoIoWrite() Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Fix PIO transfer modeAlbecki, Mateusz2020-03-052-21/+114
| | | | | | | | | | | | | | | Current driver does not support PIO transfer mode for commands other then tuning. This change adds the code to transfer PIO data. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Do not map memory for non DMA transferAlbecki, Mateusz2020-03-051-27/+61
| | | | | | | | | | | | | | | | Driver code used to map memory for DMA transfer even if host doesn't support DMA. This is causing memory corruption when driver transfers data using PIO. This change refactors the code to skip call to PciIo->Map for non DMA transfers. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completionAlbecki, Mateusz2020-03-051-69/+112
| | | | | | | | | | | | | | | This patch refactors the way in which the driver will check the data transfer completion. Data transfer related functionalities have been moved to separate function. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Read response on command completionAlbecki, Mateusz2020-03-052-58/+144
| | | | | | | | | | | | | | | | | | SdMmcPciHcDxe driver used to read response only after command and data transfer completed. According to SDHCI specification response data is ready after the command complete status is set by the host controller. Getting the response data early will help debugging the cases when command completed but data transfer timed out. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Enhance driver tracesAlbecki, Mateusz2020-03-051-0/+87
| | | | | | | | | | | | | | | | | | | To allow for easier debug of failing commands we have added a capability to print TRB and command packet when we start execution of the TRB(on DEBUG_VERBOSE level) and when the TRB failed to execute correctly(on DEBUG_ERROR level). Additionally we will also print error interrupt status and interrupt status register on failed SD command. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Send SEND_STATUS at lower frequencyAlbecki, Mateusz2020-03-054-24/+69
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140 To avoid stability issues on some designs the driver will now send SEND_STATUS at previous, lower, frequency when upgrading the bus timing. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Marcin Wojtas <mw@semihalf.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* ArmPlatformPkg/PrePeiCore: replace set/way cache ops with by-VA onesArd Biesheuvel2020-03-043-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cache maintenance operations by set/way are only intended to be used in the context of on/offlining a core, while it has been taken out of the coherency domain. Any use intended to ensure that the contents of the cache have made it to main memory is unreliable, since cacheline migration and non-architected system caches may cause these contents to linger elsewhere, without being visible in main memory once the MMU and caches are disabled. In KVM on Linux, there are horrid hacks in place to ensure that such set/way operations are trapped, and replaced with a single by-VA clean/invalidate of the entire guest VA space once the MMU state changes, which can be costly, and is unnecessary if we manage the caches a bit more carefully, and perform maintenance by virtual address only. So let's get rid of the call to ArmInvalidateDataCache () in the PrePeiCore startup code, and instead, invalidate the temporary RAM region by virtual address, which is the only memory region we will be touching with the caches and MMU both disabled and enabled, which will lead to data corruption if data written with the MMU off is shadowed by clean, stale cachelines that stick around when the MMU is enabled again. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* ArmPlatformPkg/LcdGraphicsOutputDxe: add missing protocol dependencyArd Biesheuvel2020-03-041-0/+1
| | | | | | | | | | This driver depends on the gEfiCpuArchProtocolGuid protocol but does not declare it, and so this dependency gets satisfied transitively via ArmLib. However, ArmLib will drop this dependency as it does not actually use it, so declare it for LcdGraphicsOutputDxe instead. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/LinuxInitrdDynamicShellCommand: fix uninitialized status returnArd Biesheuvel2020-03-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linaro CI reports: OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7: error: variable 'Status' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (mInitrdLoadFile2Handle != NULL) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:141:10: note: uninitialized use occurs here return Status; ^~~~~~ OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:3: note: remove the 'if' if its condition is always true if (mInitrdLoadFile2Handle != NULL) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:130:23: note: initialize the variable 'Status' to silence this warning EFI_STATUS Status; ^ = 0 Fix this by pulling the return of Status into the conditional block where it is assigned, and return EFI_SUCCESS otherwise. Fixes: 2632178bc683f1f28f9dbe269f85d6b26b1800de Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* ArmPkg/MmCommunicationDxe: fix logic bug in DXE driver entrypointArd Biesheuvel2020-03-041-0/+8
| | | | | | | | | | | | | | | Commit 2fe25a74d6fee3c2 ("ArmPkg/MmCommunicationDxe: relay architected PI events to MM context") update the ARM specific standalone MM client driver to register for certain events in the entrypoint code, but did so in a way that makes the entrypoint always return with an error. Instead, return EFI_SUCCESS if registering for those events succeeds, and back out the registrations that did succeed if one fails, and return an error. Fixes: 2fe25a74d6fee3c2 ("ArmPkg/MmCommunicationDxe: relay architected PI events to MM context") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPlatformPkg: convert LFs to CRLF, expand hard TABsLaszlo Ersek2020-03-041-328/+328
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to switch the internal line terminators globally to LF at some point, but until then, let's use CRLF consistently. Convert source files with LFs in them to CRLF, using "unix2dos". "git show -b" prints no code changes for this patch. (I collected all the file name suffixes in this package, with: $ git ls-files -- $PACKAGE | rev | cut -f 1 -d . | sort -u | rev I eliminated those suffixes that didn't stand for text files, then blanket-converted the rest with unix2dos. Finally, picked up the actual changes with git-add.) At the same time, the following file had to undergo TAB expansion: ArmPlatformPkg/Scripts/Ds5/profile.py I used "expand -t 4", conforming to the Indentation section of PEP-8 <https://www.python.org/dev/peps/pep-0008/#indentation>. Both the CRLF conversion and the TAB expansion are motivated by "PatchCheck.py". "PatchCheck.py" is also the reason why CRLF conversion and TAB expansion have to happen in the same patch. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1659 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200227213903.13884-4-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* ArmVirtPkg: convert LFs to CRLFLaszlo Ersek2020-03-041-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to switch the internal line terminators globally to LF at some point, but until then, let's use CRLF consistently. Convert source files with LFs in them to CRLF, using "unix2dos". "git show -b" prints no code changes for this patch. (I collected all the file name suffixes in this package, with: $ git ls-files -- $PACKAGE | rev | cut -f 1 -d . | sort -u | rev I eliminated those suffixes that didn't stand for text files, then blanket-converted the rest with unix2dos. Finally, picked up the actual changes with git-add.) The CRLF conversion is motivated by "PatchCheck.py". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1659 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200227213903.13884-3-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* ArmPkg: convert LFs to CRLF, expand hard TABsLaszlo Ersek2020-03-045-430/+430
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're going to switch the internal line terminators globally to LF at some point, but until then, let's use CRLF consistently. Convert source files with LFs in them to CRLF, using "unix2dos". "git show -b" prints no code changes for this patch. (I collected all the file name suffixes in this package, with: $ git ls-files -- $PACKAGE | rev | cut -f 1 -d . | sort -u | rev I eliminated those suffixes that didn't stand for text files, then blanket-converted the rest with unix2dos. Finally, picked up the actual changes with git-add.) At the same time, the following three files had to undergo TAB expansion: ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.c ArmPkg/Library/GccLto/liblto-aarch64.s ArmPkg/Library/GccLto/liblto-arm.s I used "expand -t 2", in order to stay close to the edk2 coding style (which uses two spaces for indentation.) Both the CRLF conversion and the TAB expansion are motivated by "PatchCheck.py". "PatchCheck.py" is also the reason why CRLF conversion and TAB expansion have to happen in the same patch. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1659 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200227213903.13884-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/CpuS3DataDxe: enable S3 resume after CPU hotplugLaszlo Ersek2020-03-042-26/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During normal boot, CpuS3DataDxe allocates - an empty CPU_REGISTER_TABLE entry in the "ACPI_CPU_DATA.PreSmmInitRegisterTable" array, and - an empty CPU_REGISTER_TABLE entry in the "ACPI_CPU_DATA.RegisterTable" array, for every CPU whose APIC ID CpuS3DataDxe can learn. Currently EFI_MP_SERVICES_PROTOCOL is used for both determining the number of CPUs -- the protocol reports the present-at-boot CPU count --, and for retrieving the APIC IDs of those CPUs. Consequently, if a CPU is hot-plugged at OS runtime, then S3 resume breaks. That's because PiSmmCpuDxeSmm will not find the hot-added CPU's APIC ID associated with any CPU_REGISTER_TABLE object, in the SMRAM copies of either of the "RegisterTable" and "PreSmmInitRegisterTable" arrays. The failure to match the hot-added CPU's APIC ID trips the ASSERT() in SetRegister() [UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c]. If "PcdQ35SmramAtDefaultSmbase" is TRUE, then: - prepare CPU_REGISTER_TABLE objects for all possible CPUs, not just the present-at-boot CPUs (PlatformPei stored the possible CPU count to "PcdCpuMaxLogicalProcessorNumber"); - use QEMU_CPUHP_CMD_GET_ARCH_ID for filling in the "InitialApicId" fields of the CPU_REGISTER_TABLE objects. This provides full APIC ID coverage for PiSmmCpuDxeSmm during S3 resume, accommodating CPUs hot-added at OS runtime. This patch is best reviewed with $ git show -b 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-17-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuS3DataDxe: superficial cleanupsLaszlo Ersek2020-03-042-10/+10
| | | | | | | | | | | | | | | | | | | | | | Sort the [Packages], [LibraryClasses], and [Pcd] sections in the INF file. Pad the usage notes (CONSUMES, PRODUCES) in the [Pcd] section. Sort the Library #includes in the C file. This patch is functionally a no-op. 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-16-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: clone CpuS3DataDxe from UefiCpuPkgLaszlo Ersek2020-03-048-6/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The @file comments in UefiCpuPkg/CpuS3DataDxe say, [...] It also only supports the number of CPUs reported by the MP Services Protocol, so this module does not support hot plug CPUs. This module can be copied into a CPU specific package and customized if these additional features are required. [...] The driver is so small that the simplest way to extend it with hotplug support is indeed to clone it at first. In this patch, customize the driver only with the following no-op steps: - Update copyright notices. - Update INF_VERSION to the latest INF spec version (1.29). - Update FILE_GUID. - Drop the UNI files. - Replace EFI_D_VERBOSE with DEBUG_VERBOSE, to appease "PatchCheck.py". This patch is best reviewed with: $ git show --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-15-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/CpuHotplugSmm: complete root MMI handler for CPU hotplugLaszlo Ersek2020-03-041-2/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the help of the Post-SMM Pen and the SMBASE relocation functions added in the previous patches, we can now complete the root MMI handler for CPU hotplug. In the driver's entry point function: - allocate the pen (in a reserved page in normal RAM), - install the default ("first") SMI handler for hot-added CPUs (which includes priming the exchange area between the MM Monarch and the hot-added CPUs, i.e., shutting the APIC ID gate). In the root MMI handler, for each hot-added CPU: - record the APIC ID of the new CPU in CPU_HOT_PLUG_DATA, - relocate the SMBASE of the new CPU, - inform PiSmmCpuDxeSmm by calling EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor(). 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-14-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: introduce First SMI Handler for hot-added CPUsLaszlo Ersek2020-03-045-0/+376
| | | | | | | | | | | | | | | | | | | Implement the First SMI Handler for hot-added CPUs, in NASM. Add the interfacing C-language function that the SMM Monarch calls. This function launches and coordinates SMBASE relocation for a hot-added CPU. 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-13-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: introduce Post-SMM Pen for hot-added CPUsLaszlo Ersek2020-03-044-0/+297
| | | | | | | | | | | | | | | | | | | Once a hot-added CPU finishes the SMBASE relocation, we need to pen it in a HLT loop. Add the NASM implementation (with just a handful of instructions, but much documentation), and some C language helper functions. 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-12-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: collect CPUs with eventsLaszlo Ersek2020-03-042-3/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call QemuCpuhpCollectApicIds() in the root MMI handler. The APIC IDs of the hotplugged CPUs will be used for several purposes in subsequent patches. For calling QemuCpuhpCollectApicIds(), pre-allocate both of its output arrays "PluggedApicIds" and "ToUnplugApicIds" in the driver's entry point function. The allocation size is dictated by the possible CPU count, which we fetch from "CPU_HOT_PLUG_DATA.ArrayLength". The CPU_HOT_PLUG_DATA structure in SMRAM is an out-of-band information channel between this driver and PiSmmCpuDxeSmm, underlying EFI_SMM_CPU_SERVICE_PROTOCOL. In order to consume "CPU_HOT_PLUG_DATA.ArrayLength", extend the driver's DEPEX to EFI_SMM_CPU_SERVICE_PROTOCOL. PiSmmCpuDxeSmm stores the address of CPU_HOT_PLUG_DATA to "PcdCpuHotPlugDataAddress", before it produces EFI_SMM_CPU_SERVICE_PROTOCOL. Stash the protocol at once, as it will be needed later. 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-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: add function for collecting CPUs with eventsLaszlo Ersek2020-03-045-6/+211
| | | | | | | | | | | | | | | | | | | | | Add a function that collects the APIC IDs of CPUs that have just been hot-plugged, or are about to be hot-unplugged. Pending events are only located and never cleared; QEMU's AML needs the firmware to leave the status bits intact in the hotplug register block. 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-10-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/CpuHotplugSmm: define the QEMU_CPUHP_CMD_GET_ARCH_ID macroLaszlo Ersek2020-03-042-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | QEMU commit 3a61c8db9d25 ("acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command", 2020-01-22) introduced a new command in the modern CPU hotplug register block that lets the firmware query the arch-specific IDs (on IA32/X64: the APIC IDs) of CPUs. Add a macro for this command value, because we'll need it later. At the same time, add a sanity check for the modern hotplug interface to CpuHotplugSmm. 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-9-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/CpuHotplugSmm: add hotplug register block helper functionsLaszlo Ersek2020-03-043-0/+185
| | | | | | | | | | | | | | | | | | | | Add a handful of simple functions for accessing QEMU's hotplug registers more conveniently. These functions thinly wrap some of the registers described in "docs/specs/acpi_cpu_hotplug.txt" in the QEMU tree. The functions hang (by design) if they encounter an internal failure. 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-8-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/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driverLaszlo Ersek2020-03-049-2/+248
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new SMM driver skeleton that registers a root SMI handler, and checks if the SMI control value (written to 0xB2) indicates a CPU hotplug SMI. QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other words, control value 4 is now allocated for this purpose; introduce the ICH9_APM_CNT_CPU_HOTPLUG macro for it. The standard identifiers in this driver use the new MM (Management Mode) terminology from the PI spec, not the earlier SMM (System Management Mode) terms. 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-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmmLaszlo Ersek2020-03-043-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set "PcdCpuHotPlugSupport" to TRUE, when OVMF is built with SMM_REQUIRE. Consequences: (1) In PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c], resources are allocated and populated in advance for all possible (i.e., potentially hot-added) processors, rather than only the processors present at boot. The possible count (called "mMaxNumberOfCpus") is set from "PcdCpuMaxLogicalProcessorNumber"; we set the latter in OvmfPkg/PlatformPei. (Refer to commit 83357313dd67, "OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug", 2020-01-29). (2) The AddProcessor() and RemoveProcessor() member functions of EFI_SMM_CPU_SERVICE_PROTOCOL, implemented in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c", are no longer short-circuited to EFI_UNSUPPORTED. We'll rely on these functions in the CPU hotplug SMI handler, in a subsequent patch. (3) In PiCpuSmmEntry(), the address of the CPU_HOT_PLUG_DATA structure (in SMRAM) is exposed via the dynamic-only "PcdCpuHotPlugDataAddress". This structure is an information channel between the CPU hotplug SMI handler, and EFI_SMM_CPU_SERVICE_PROTOCOL. Namely, at the first "Index" where the following equality holds: CPU_HOT_PLUG_DATA.ApicId[Index] == INVALID_APIC_ID a hot-plugged CPU can be accepted, with the steps below: (3.1) The hotplug SMI handler has to overwrite INVALID_APIC_ID with the new CPU's APIC ID. (3.2) The new CPU's SMBASE has to be relocated to: CPU_HOT_PLUG_DATA.SmBase[Index] (which was precomputed in step (1) above). (3.3) The hotplug SMI handler is supposed to call EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor(). Note: we need not spell out "PcdCpuHotPlugDataAddress" in the [PcdsDynamicDefault] sections of the OVMF DSC files, just so the PCD become dynamically settable. That's because "UefiCpuPkg.dec" declares this PCD with [PcdsDynamic, PcdsDynamicEx] access methods *only*. 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-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmmLaszlo Ersek2020-03-045-4/+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-045-3/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* UefiCpuPkg/PiSmmCpuDxeSmm: fix S3 Resume for CPU hotplugLaszlo Ersek2020-03-041-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "ACPI_CPU_DATA.NumberOfCpus" field is specified as follows, in "UefiCpuPkg/Include/AcpiCpuData.h" (rewrapped for this commit message): // // The number of CPUs. If a platform does not support hot plug CPUs, // then this is the number of CPUs detected when the platform is booted, // regardless of being enabled or disabled. If a platform does support // hot plug CPUs, then this is the maximum number of CPUs that the // platform supports. // The InitializeCpuBeforeRebase() and InitializeCpuAfterRebase() functions in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c" try to restore CPU configuration on the S3 Resume path for *all* CPUs accounted for in "ACPI_CPU_DATA.NumberOfCpus". This is wrong, as with CPU hotplug, not all of the possible CPUs may be present at the time of S3 Suspend / Resume. The symptom is an infinite wait. Instead, the "mNumberOfCpus" variable should be used, which is properly maintained through the EFI_SMM_CPU_SERVICE_PROTOCOL implementation (see SmmAddProcessor(), SmmRemoveProcessor(), SmmCpuUpdate() in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c"). When CPU hotplug is disabled, "mNumberOfCpus" is constant, and equals "ACPI_CPU_DATA.NumberOfCpus" at all times. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> 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> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-3-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Eric Dong <eric.dong@intel.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> [lersek@redhat.com: shut up UINTN->UINT32 warning from Windows VS2019 PR]
* MdeModulePkg/PiSmmCore: log SMM image start failureLaszlo Ersek2020-03-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the CoreStartImage() function [MdeModulePkg/Core/Dxe/Image/Image.c], if the image entry point returns a failure code, then the DXE Core logs a helpful DEBUG_ERROR message, with the following format string: "Error: Image at %11p start failed: %r\n" Do similarly in the SMM Core (update the message slightly). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jian J Wang <jian.j.wang@intel.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> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-2-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: plug DxeTpmMeasureBootLib into SecurityStubDxeMarc-André Lureau2020-03-043-0/+3
| | | | | | | | | | Mirrors TPM 2.0 commit d5a002aba0aa ("OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe", 2018-03-09) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-6-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: include TcgDxe moduleMarc-André Lureau2020-03-046-0/+18
| | | | | | | | | | Mirrors TPM 2.0 commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module", 2018-03-09). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-5-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: include TcgPei moduleMarc-André Lureau2020-03-046-0/+6
| | | | | | | | | | Mirrors TPM 2.0 commit 4672a4892867 ("OvmfPkg: include Tcg2Pei module", 2018-03-09). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-4-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg: detect TPM 1.2 in Tcg2ConfigPeiMarc-André Lureau2020-03-045-15/+76
| | | | | | | | | | | | | | | | Complement commit 6cf1880fb5b ("OvmfPkg: add customized Tcg2ConfigPei clone", 2018-03-09) by detecting TPM 1.2 devices. Since Tpm12RequestUseTpm() returns success on any TPM interface, (including FIFO & CRB which are TPM 2.0), try to send a GetTicks TPM 1.2 command to probe the version. In case of failure, fallback on TPM 2.0 path. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Message-Id: <20200226152433.1295789-3-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-12 09:29:43 +0000