summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/CpuHotplugSmm
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/CpuHotplugSmm: delay SMM exitGerd Hoffmann2024-09-131-0/+5
| | | | | | | | | | | | | Let APs wait until the BSP has completed the register updates to remove the CPU. This makes sure all APs stay in SMM mode until the CPU hot-unplug operation is complete, which in turn makes sure the ACPI lock is released only after the CPU hot-unplug operation is complete. Some background: The CPU hotplug SMI is triggered from an ACPI function which is protected by an ACPI lock. The ACPI function is in the ACPI tables generated by qemu. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-103-41/+41
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-077-245/+424
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* OvmfPkg/CpuHotplugSmm: do actual CPU hot-ejectAnkur Arora2021-03-161-6/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add logic in EjectCpu() to do the actual the CPU ejection. On the BSP, ejection happens by first selecting the CPU via its QemuSelector and then sending the QEMU "eject" command. QEMU in-turn signals the remote VCPU thread which context-switches the CPU out of the SMI handler. Meanwhile the CPU being ejected, waits around in its holding area until it is context-switched out. Note that it is possible that a slow CPU gets ejected before it reaches the wait loop. However, this would never happen before it has executed the "AllCpusInSync" loop in SmiRendezvous(). It can mean that an ejected CPU does not execute code after that point but given that the CPU state will be destroyed by QEMU, the missed cleanup is no great loss. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Message-Id: <20210312062656.2477515-10-ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: unneeded inner QemuSelector declaration in EjectCpu() triggers VS warning #4456 (local variable shadowed); remove it]
* OvmfPkg/CpuHotplugSmm: add EjectCpu()Ankur Arora2021-03-162-8/+148
| | | | | | | | | | | | | | | | | | | | | Add EjectCpu(), which handles the CPU ejection, and provides a holding area for said CPUs. It is called via SmmCpuFeaturesRendezvousExit(), at the tail end of the SMI handling. Also UnplugCpus() now stashes QEMU Selectors of CPUs which need to be ejected in CPU_HOT_EJECT_DATA.QemuSelectorMap. This is used by EjectCpu() to identify CPUs marked for ejection. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Message-Id: <20210312062656.2477515-9-ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/CpuHotplugSmm: introduce UnplugCpus()Ankur Arora2021-03-161-0/+84
| | | | | | | | | | | | | | | | | | | | | Introduce UnplugCpus() which maps each APIC ID being unplugged onto the hardware ID of the processor and informs PiSmmCpuDxeSmm of removal by calling EFI_SMM_CPU_SERVICE_PROTOCOL.RemoveProcessor(). With this change we handle the first phase of unplug where we collect the CPUs that need to be unplugged and mark them for removal in SMM data structures. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210312062656.2477515-5-ankur.a.arora@oracle.com>
* OvmfPkg/CpuHotplugSmm: add Qemu Cpu Status helperAnkur Arora2021-03-162-0/+28
| | | | | | | | | | | | | | | | | Add QemuCpuhpWriteCpuStatus() which will be used to update the QEMU CPU status register. On error, it hangs in a similar fashion as other helper functions. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210312062656.2477515-4-ankur.a.arora@oracle.com>
* OvmfPkg/CpuHotplugSmm: collect hot-unplug eventsAnkur Arora2021-03-163-39/+92
| | | | | | | | | | | | | | | | | | | | | | Process fw_remove events in QemuCpuhpCollectApicIds(), and collect APIC IDs and QEMU CPU Selectors for CPUs being hot-unplugged. In addition, we now ignore CPUs which only have remove set. These CPUs haven't been processed by OSPM yet. This is based on the QEMU hot-unplug protocol documented here: https://lore.kernel.org/qemu-devel/20201204170939.1815522-3-imammedo@redhat.com/ Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Message-Id: <20210312062656.2477515-3-ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/CpuHotplugSmm: refactor hotplug logicAnkur Arora2021-03-161-84/+126
| | | | | | | | | | | | | | | | | Refactor CpuHotplugMmi() to pull out the CPU hotplug logic into ProcessHotAddedCpus(). This is in preparation for supporting CPU hot-unplug. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Aaron Young <aaron.young@oracle.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132 Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210312062656.2477515-2-ankur.a.arora@oracle.com>
* OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcastLaszlo Ersek2020-08-271-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then: - the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the SMI pending for the new CPU -- at that time, the new CPU doesn't even exist yet, - OVMF will find the new CPU however (in the CPU hotplug register block), in QemuCpuhpCollectApicIds(). As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI), the new CPU instead boots straight into the post-RSM (normal mode) "pen", skipping its initial SMI handler. The CPU halts nicely in the pen, but its SMBASE is never relocated, and the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck in the following loop: // // Wait until the hot-added CPU is just about to execute RSM. // while (Context->AboutToLeaveSmm == 0) { CpuPause (); } because the new CPU's initial SMI handler never sets the flag to nonzero. Fix this by sending a directed SMI to the new CPU just before sending it the INIT-SIPI-SIPI. The various scenarios are documented in the code -- the cases affected by the patch are documented under point (2). Note that this is not considered a security patch, as for a malicious guest OS, the issue is not exploitable -- the symptom is a hang on the BSP, in the above-noted loop in SmbaseRelocate(). Instead, the patch fixes behavior for a benign guest OS. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 51a6fb41181529e4b50ea13377425bda6bb69ba6 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200826222129.25798-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just before SMI broadcastLaszlo Ersek2020-08-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just before* ACPI raises the broadcast SMI, then: - OVMF processes the hot-added CPU well. - However, QEMU's post-SMI ACPI loop -- which clears the pending events for the hot-added CPUs that were collected before raising the SMI -- is unaware of the stray CPU. Thus, the pending event is not cleared for it. As a result of the stuck event, at the next hot-plug, OVMF tries to re-add (relocate for the 2nd time) the already-known CPU. At that time, the AP is already in the normal edk2 SMM busy-wait however, so it doesn't respond to the exchange that the BSP intends to do in SmbaseRelocate(). Thus the VM gets stuck in SMM. (Because of the above symptom, this is not considered a security patch; it doesn't seem exploitable by a malicious guest OS.) In CpuHotplugMmi(), skip the supposedly hot-added CPU if it's already known. The post-SMI ACPI loop will clear the pending event for it this time. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: bc498ac4ca7590479cfd91ad1bb8a36286b0dc21 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200826222129.25798-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.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-044-6/+209
| | | | | | | | | | | | | | | | | | | | | 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-041-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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-042-0/+239
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 20:20:46 +0000