summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* OvmfPkg/Xen: Fix a typoPhilippe Mathieu-Daudé2020-02-101-1/+1
| | | | | | | | | | | | | | Fix a typo in a comment. 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> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-60-philmd@redhat.com>
* OvmfPkg/Virtio: Fix few typosAntoine Coeur2020-02-106-6/+6
| | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-59-philmd@redhat.com>
* OvmfPkg/Qemu: Fix various typosAntoine Coeur2020-02-1011-25/+25
| | | | | | | | | | | | | | | | | | | | Fix various typos in comments and documentation. When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh" to update "VbeShim.h". The string modified by this patch is only used when the DEBUG macro (at the top of the file) is commented out. Since the string is not referenced, NASM eliminates it, resulting in the same byte array content in "VbeShim.h". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-58-philmd@redhat.com>
* OvmfPkg/Csm/LegacyBios: Fix a typoPhilippe Mathieu-Daudé2020-02-101-1/+1
| | | | | | | | Fix a typo in the header documentation. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-57-philmd@redhat.com>
* OvmfPkg/Csm: Fix various typosAntoine Coeur2020-02-1021-62/+62
| | | | | | | | | | | | | | Fix various typos in documentation, comments and strings. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-56-philmd@redhat.com>
* OvmfPkg/Acpi: Fix few typosAntoine Coeur2020-02-105-8/+8
| | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-55-philmd@redhat.com>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)Laszlo Ersek2020-02-052-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the SMRAM at the default SMBASE is honored everywhere necessary, implement the actual detection. The (simple) steps are described in previous patch "OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros". Regarding CSM_ENABLE builds: according to the discussion with Jiewen at https://edk2.groups.io/g/devel/message/48082 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F7C9D2F@shsmsx102.ccr.corp.intel.com if the platform has SMRAM at the default SMBASE, then we have to (a) either punch a hole in the legacy E820 map as well, in LegacyBiosBuildE820() [OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c], (b) or document, or programmatically catch, the incompatibility between the "SMRAM at default SMBASE" and "CSM" features. Because CSM is out of scope for the larger "VCPU hotplug with SMM" feature, option (b) applies. Therefore, if the CSM is enabled in the OVMF build, then PlatformPei will not attempt to detect SMRAM at the default SMBASE, at all. This is approach (4) -- the most flexible one, for end-users -- from: http://mid.mail-archive.com/868dcff2-ecaa-e1c6-f018-abe7087d640c@redhat.com https://edk2.groups.io/g/devel/message/48348 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-12-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek2020-02-055-0/+17
| | | | | | | | | | | | | | | | | | | | | In the DXE phase and later, it is possible for a module to dynamically determine whether a CSM is enabled. An example can be seen in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25). SEC and PEI phase modules cannot check the Legacy BIOS Protocol however. For their sake, introduce a new feature PCD that simply reflects the CSM_ENABLE build flag. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASELaszlo Ersek2020-02-056-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During normal boot, when EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by platform BDS, the SMM IPL locks SMRAM (TSEG) through EFI_SMM_ACCESS2_PROTOCOL.Lock(). See SmmIplReadyToLockEventNotify() in "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c". During S3 resume, S3Resume2Pei locks SMRAM (TSEG) through PEI_SMM_ACCESS_PPI.Lock(), before executing the boot script. See S3ResumeExecuteBootScript() in "UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c". Those are precisely the places where the SMRAM at the default SMBASE should be locked too. Add such an action to SmramAccessLock(). Notes: - The SMRAM at the default SMBASE doesn't support the "closed and unlocked" state (and so it can't be closed without locking it, and it cannot be opened after closing it). - The SMRAM at the default SMBASE isn't (and shouldn't) be exposed with another EFI_SMRAM_DESCRIPTOR in the GetCapabilities() members of EFI_SMM_ACCESS2_PROTOCOL / PEI_SMM_ACCESS_PPI. That's because the SMRAM in question is not "general purpose"; it's only QEMU's solution to protect the initial SMI handler from the OS, when a VCPU is hot-plugged. Consequently, the state of the SMRAM at the default SMBASE is not reflected in the "OpenState" / "LockState" fields of the protocol and PPI. - An alternative to extending SmramAccessLock() would be to register an EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL notify in SmmAccess2Dxe (for locking at normal boot), and an EDKII_S3_SMM_INIT_DONE_GUID PPI notify in SmmAccessPei (for locking at S3 resume). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-10-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASELaszlo Ersek2020-02-053-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OVMF runs in a SEV guest, the initial SMM Save State Map is (1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei, function AmdSevInitialize(), for preventing unintended information sharing with the hypervisor; (2) decrypted in AmdSevDxe; (3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function SmmCpuFeaturesSmmRelocationComplete(), which is called by PiSmmCpuDxeSmm right after initial SMBASE relocation; (4) released to DXE at the same location. The SMRAM at the default SMBASE is a superset of the initial Save State Map. The reserved memory allocation in InitializeRamRegions(), from the previous patch, must override the allocating and freeing in (1) and (4), respectively. (Note: the decrypting and re-encrypting in (2) and (3) are unaffected.) In AmdSevInitialize(), only assert the containment of the initial Save State Map, in the larger area already allocated by InitializeRamRegions(). In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the initial Save State Map into OS runtime, as part of the allocation done by InitializeRamRegions(). Only assert containment. These changes only affect the normal boot path (the UEFI memory map is untouched during S3 resume). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it existsLaszlo Ersek2020-02-051-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 128KB SMRAM at the default SMBASE will be used for protecting the initial SMI handler for hot-plugged VCPUs. After platform reset, the SMRAM in question is open (and looks just like RAM). When BDS signals EFI_DXE_MM_READY_TO_LOCK_PROTOCOL (and so TSEG is locked down), we're going to lock the SMRAM at the default SMBASE too. For this, we have to reserve said SMRAM area as early as possible, from components in PEI, DXE, and OS runtime. * QemuInitializeRam() currently produces a single resource descriptor HOB, for exposing the system RAM available under 1GB. This occurs during both normal boot and S3 resume identically (the latter only for the sake of CpuMpPei borrowing low RAM for the AP startup vector). But, the SMRAM at the default SMBASE falls in the middle of the current system RAM HOB. Split the HOB, and cover the SMRAM with a reserved memory HOB in the middle. CpuMpPei (via MpInitLib) skips reserved memory HOBs. * InitializeRamRegions() is responsible for producing memory allocation HOBs, carving out parts of the resource descriptor HOBs produced in QemuInitializeRam(). Allocate the above-introduced reserved memory region in full, similarly to how we treat TSEG, so that DXE and the OS avoid the locked SMRAM (black hole) in this area. (Note that these allocations only occur on the normal boot path, as they matter for the UEFI memory map, which cannot be changed during S3 resume.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-8-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASELaszlo Ersek2020-02-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | The permanent PEI RAM that is published on the normal boot path starts strictly above MEMFD_BASE_ADDRESS (8 MB -- see the FDF files), regardless of whether PEI decompression will be necessary on S3 resume due to SMM_REQUIRE. Therefore the normal boot permanent PEI RAM never overlaps with the SMRAM at the default SMBASE (192 KB). The S3 resume permanent PEI RAM is strictly above the normal boot one. Therefore the no-overlap statement holds true on the S3 resume path as well. Assert the no-overlap condition commonly for both boot paths in PublishPeiMemory(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)Laszlo Ersek2020-02-054-0/+27
| | | | | | | | | | | | | | | | | Introduce the Q35SmramAtDefaultSmbaseInitialization() function for detecting the "SMRAM at default SMBASE" feature. For now, the function is only a skeleton, so that we can gradually build upon the result while the result is hard-coded as FALSE. The actual detection will occur in a later patch. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: factor out Q35BoardVerification()Laszlo Ersek2020-02-052-12/+24
| | | | | | | | | | | | | | Before adding another SMM-related, and therefore Q35-only, dynamically detectable feature, extract the current board type check from Q35TsegMbytesInitialization() to a standalone function. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macrosLaszlo Ersek2020-02-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller Register Address Map (D0:F0)" leaves the byte register at config space offset 0x9C unused. On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature, firmware is expected to write MCH_DEFAULT_SMBASE_QUERY (0xFF) to offset MCH_DEFAULT_SMBASE_CTL (0x9C), and read back the register. If the value is MCH_DEFAULT_SMBASE_IN_RAM (0x01), then the feature is available, and the range mentioned below is open (accessible to code running outside of SMM). Then, once firmware writes MCH_DEFAULT_SMBASE_LCK (0x02) to the register, the MCH_DEFAULT_SMBASE_SIZE (128KB) range at 0x3_0000 (SMM_DEFAULT_SMBASE) gets closed and locked down, and the register becomes read-only. The area is reopened, and the register becomes read/write, at platform reset. Add the above-listed macros to "Q35MchIch9.h". (There are some other unused offsets in Table 5-1; for example we had scavenged 0x50 for implementing the extended TSEG feature. 0x9C is the first byte-wide register standing in isolation after 0x50.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defsLaszlo Ersek2020-02-051-50/+50
| | | | | | | | | | | | | | | | | In a subsequent patch, we'll introduce new DRAM controller macros in "Q35MchIch9.h". Their names are too long for the currently available vertical whitespace, so increase the latter first. There is no functional change in this patch ("git show -b" displays nothing). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PcdQ35SmramAtDefaultSmbaseLaszlo Ersek2020-02-054-0/+9
| | | | | | | | | | | | | | | | | | | | | For supporting VCPU hotplug with SMM enabled/required, QEMU offers the (dynamically detectable) feature called "SMRAM at default SMBASE". When the feature is enabled, the firmware can lock down the 128 KB range starting at the default SMBASE; that is, the [0x3_0000, 0x4_FFFF] interval. The goal is to shield the very first SMI handler of the hotplugged VCPU from OS influence. Multiple modules in OVMF will have to inter-operate for locking down this range. Introduce a dynamic PCD that will reflect the feature (to be negotiated by PlatformPei), for coordination between drivers. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplugLaszlo Ersek2020-01-295-28/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MaxCpuCountInitialization() currently handles the following options: (1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0) In this case, PlatformPei makes MpInitLib enumerate APs up to the default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses. (Whichever is reached first.) Time-limited AP enumeration had never been reliable on QEMU/KVM, which is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF. (2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero) In this case, PlatformPei sets - PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count (FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"), - and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity" (MAX_UINT32, ~71 minutes). That causes MpInitLib to enumerate exactly the present (boot) APs. With CPU hotplug in mind, this method is not good enough. Because, using QEMU terminology, UefiCpuPkg expects PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count ("MachineState.smp.max_cpus"), which includes present and not present CPUs both (with not present CPUs being subject for hot-plugging). FW_CFG_NB_CPUS does not include not present CPUs. Rewrite MaxCpuCountInitialization() for handling the following cases: (1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set to values different from the defaults.) (2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via FW_CFG_NB_CPUS), but not the possible CPUs count ("MachineState.smp.max_cpus"). In this case, the behavior remains unchanged. The way MpInitLib is instructed to do the same differs however: we now set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count (while continuing to set PcdCpuMaxLogicalProcessorNumber identically). PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant. (3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via FW_CFG_NB_CPUS), and the possible CPUs count ("MachineState.smp.max_cpus"). We tell UefiCpuPkg about the possible CPUs count through PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU count for precise and quick AP enumeration, via PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is irrelevant again. This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE. As a side effect, the patch also enables S3 to work with CPU hotplug at once, *without* SMM_REQUIRE. (Without the patch, S3 resume fails, if a CPU is hot-plugged at OS runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not permitted. With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely "MachineState.smp.max_cpus". Therefore, the CPU structures allocated during normal boot can accommodate the CPUs at S3 resume that have been hotplugged prior to S3 suspend.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20191022221554.14963-4-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: define macros for QEMU's CPU hotplug registersLaszlo Ersek2020-01-293-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | In v1.5.0, QEMU's "pc" (i440fx) board gained a "CPU present bitmap" register block. In v2.0.0, this was extended to the "q35" board. In v2.7.0, a new (read/write) register interface was laid over the "CPU present bitmap", with an option for the guest to switch the register block to the new (a.k.a. modern) interface. Both interfaces are documented in "docs/specs/acpi_cpu_hotplug.txt" in the QEMU tree. Add macros for a minimal subset of the modern interface, just so we can count the possible CPUs (as opposed to boot CPUs) in a later patch in this series. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20191022221554.14963-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaultsLaszlo Ersek2020-01-291-4/+0
| | | | | | | | | | | | | | | | | | | PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds are only referenced in "OvmfPkg/PlatformPei/PlatformPei.inf", and OvmfXen does not include that module. Remove the unnecessary dynamic PCD defaults from "OvmfXen.dsc". Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Message-Id: <20191022221554.14963-2-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: remove EnterS3WithImmediateWake () from ResetSystemLibArd Biesheuvel2020-01-101-18/+0
| | | | | | | | EnterS3WithImmediateWake () no longer has any callers, so remove it from ResetSystemLib. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: use HII type PCDs for TPM2 config related variablesArd Biesheuvel2020-01-093-0/+18
| | | | | | | | | | | | | | | The HII pages that are part of Tcg2ConfigDxe expect the following PCDs to be of dynamic HII type, so declare them as such. gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev Currently, the TPM2 ACPI table is not produced, since we do not incorporate the Tcg2Smm module, which implements the SMI based physical presence interface exposed to the OS. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-08 20:59:13 +0000