summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
...
* OvmfPkg: include FaultTolerantWritePei and VariablePei with -D SMM_REQUIRELaszlo Ersek2020-03-126-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FaultTolerantWritePei consumes: - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase. VariablePei consumes: - PcdFlashNvStorageVariableBase64. Due to the previous patches in this series, the above PCDs are available in the PEI phase, in the SMM_REQUIRE build. FaultTolerantWritePei produces a GUID-ed HOB with FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB. VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes the HOB (which is safe due to the DEPEX), and produces EFI_PEI_READ_ONLY_VARIABLE2_PPI. This enables read-only access to non-volatile UEFI variables in the PEI phase, in the SMM_REQUIRE build. For now, the DxeLoadCore() function in "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the "MemoryTypeInformation" variable, because OVMF's PlatformPei always produces the MemoryTypeInformation HOB. (Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build the HOB, but that's in sync with DxeLoadCore() also not looking for either the HOB or the UEFI variable.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-5-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRELaszlo Ersek2020-03-126-23/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following flash-related base addresses: - PcdFlashNvStorageVariableBase64, - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase, are always set to constant (invariable) values in the "-D SMM_REQUIRE" build of OVMF. (That's because in the SMM build, actual pflash is a hard requirement, and the RAM-based emulation is never available.) Set said PCDs statically, at build. This will allow us to depend on their values in the PEI phase. When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report file comparison). When SMM_REQUIRE is TRUE, the report file shows the following changes: - "PcdOvmfFlashNvStorageFtwSpareBase" and "PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any module directly, - for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase" and "PcdFlashNvStorageVariableBase64", the access method changes from DYN to FIXED, - for the latter PCDs, the zero (dynamic default) values are replaced with the desired constants. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-4-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/QemuFlashFvbServices: factor out SetPcdFlashNvStorageBaseAddressesLaszlo Ersek2020-03-124-18/+60
| | | | | | | | | | | | | | | | | | | | Extract the dynamic setting of the - PcdFlashNvStorageVariableBase64 - PcdFlashNvStorageFtwWorkingBase - PcdFlashNvStorageFtwSpareBase addresses to a helper function. For now, the helper function is identical (duplicated) between the SMM flash driver and the runtime DXE flash driver. In subsequent patches, this will change. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-3-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: drop unused PCDsLaszlo Ersek2020-03-122-4/+0
| | | | | | | | | | | | | | | | | The only two OvmfPkg references to "PcdFlashNvStorageVariableBase" are the spurious ones in the runtime DXE driver and the SMM driver INF files of the QEMU flash driver. Remove these references. The flash driver does not access "PcdOvmfFlashNvStorageEventLogBase" either, so remove that from the INF files too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-2-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/LinuxInitrdDynamicShellCommand: Cast UNIT64 to UNITN in assignmentBob Feng2020-03-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2580 Ovmf build failed on Windows with VS2017 tool chain. The error message like: OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitr dDynamicShellCommand.c(199): error C2220: warning treated as error - no 'object' file generated OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitrdDynamicShellCommand.c(199): warning C4244: '=': conversion from 'UINT64' to 'UINTN', possible loss of data This patch is to cast UINT64 type to UINTN type when doing the variable assignment. Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: raise DXEFV size to 12 MBLaszlo Ersek2020-03-113-9/+9
| | | | | | | | | | | | | | | | Similarly to the "cadence" mentioned in commit d272449d9e1e ("OvmfPkg: raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've outgrown DXEFV again. Increase the DXEFV size to 12MB now. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2585 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310175025.18849-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* 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/QemuKernelLoaderFsDxe: drop tentative const object definitionArd Biesheuvel2020-03-081-66/+71
| | | | | | | | | | | | | | | | | | | Bob reports that VS2017 chokes on a tentative definition of the const object 'mEfiFileProtocolTemplate', with the following error: OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130): error C2220: warning treated as error - no 'object' file generated OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130): warning C4132: 'mEfiFileProtocolTemplate': const object should be initialized Let's turn the only function that relies on this tentative definition into a forward declaration itself, and move its definition after the external definition of the object. That allows us to drop the tentative definition of the const object, and hopefully make VS2017 happy. Cc: "Feng, Bob C" <bob.c.feng@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfXen: fix build by providing QemuLoadImageLib resolutionArd Biesheuvel2020-03-061-1/+1
| | | | | | | | | | | | | | | | | Commit 859b55443a4253ba ("OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on QemuLoadImageLib in the PlatformBootManagerLib implementation that is shared between all OVMF builds, without taking into account that even the Xen targeted builds incorporate this code, which is only used to load kernels passed via the QEMU command line. Since this is dead code on Xen, we can satisfy the dependency using the generic version of QemuLoadImageLib, which does not rely on LoadLinuxLib, which we can therefore drop from OvmfXen.dsc. Fixes: 859b55443a4253bad8bb618d04a51b2ded67f24b Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* 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>
* 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>
* 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/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>
* 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>
* 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>
* OvmfPkg: rename TPM2 config prefix to TPMMarc-André Lureau2020-03-046-48/+48
| | | | | | | | | | | A following patch is going to use the same configuration for TPM1.2 and TPM2.0, and it's simpler to support both than variable configurations. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226152433.1295789-2-marcandre.lureau@redhat.com> Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
* OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already existsArd Biesheuvel2020-03-042-0/+34
| | | | | | | | | | | Before taking any actions, check if an instance of the LoadFile2 exists already on the Linux initrd media GUID device path, and whether it was provided by this command. If so, abort, since no duplicate instances of the device path should exist. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg IA32: add support for loading X64 imagesArd Biesheuvel2020-03-044-0/+189
| | | | | | | | | | | | | | | | | | | | | | | | | This is the UEFI counterpart to my Linux series which generalizes mixed mode support into a feature that requires very little internal knowledge about the architecture specifics of booting Linux on the part of the bootloader or firmware. Instead, we add a .compat PE/COFF header containing an array of PE_COMPAT nodes containing <machine type, entrypoint> tuples that describe alternate entrypoints into the image for different native machine types, e.g., IA-32 in a 64-bit image so it can be booted from IA-32 firmware. This patch implements the PE/COFF emulator protocol to take this new section into account, so that such images can simply be loaded via LoadImage/StartImage, e.g., straight from the shell. This feature is based on the EDK2 specific PE/COFF emulator protocol that was introduced in commit 57df17fe26cd ("MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images", 2019-04-14). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add the 'initrd' dynamic shell commandArd Biesheuvel2020-03-048-0/+20
| | | | | | | | | | Add the 'initrd' dynamic shell command to the build so we can load Linux initrds straight from the shell using the new generic protocol, which does not rely on initrd= being passed on the command line. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add 'initrd' shell command to expose Linux initrd via device pathArd Biesheuvel2020-03-043-0/+531
| | | | | | | | | | | Add a new 'initrd' command to the UEFI Shell that allows any file that is accessible to the shell to be registered as the initrd that is returned when Linux's EFI stub loader invokes the LoadFile2 protocol on its special vendor media device path. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add definition of LINUX_EFI_INITRD_MEDIA_GUIDArd Biesheuvel2020-03-042-0/+18
| | | | | | | | | | Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions, it can be used in a media device path to specify a Linux style initrd that can be loaded by the OS using the LoadFile2 protocol. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Tcg2ConfigPei: introduce a signalling PPI to depex onArd Biesheuvel2020-03-042-1/+10
| | | | | | | | | | | On ARM systems, the TPM does not live at a fixed address, and so we need the platform to discover it first. So introduce a PPI that signals that the TPM address has been discovered and recorded in the appropriate PCD, and make Tcg2ConfigPei depex on it when built for ARM or AARCH64. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuVideoDxe: unbreak "secondary-vga" and "bochs-display" supportLaszlo Ersek2020-02-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In edk2 commit 333f32ec23dd, QemuVideoDxe gained support for QEMU's "secondary-vga" device model (originally introduced in QEMU commit 63e3e24db2e9). In QEMU commit 765c94290863, the "bochs-display" device was introduced, which would work with QemuVideoDxe out of the box, reusing the "secondary-vga" logic. Support for both models has been broken since edk2 commit 662bd0da7fd7. Said patch ended up requiring VGA IO Ports -- i.e., at least one of EFI_PCI_IO_ATTRIBUTE_VGA_IO and EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 -- even if the device wasn't actually VGA compatible. Restrict the IO Ports requirement to VGA compatible devices. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc W Chen <marc.w.chen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 662bd0da7fd77e4d2cf9ef4a78015af5cad7d9db Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2555 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200224171741.7494-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/Xen: Fix various typosAntoine Coeur2020-02-1018-31/+31
| | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-16 02:56:57 +0000