public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: "Ard Biesheuvel" <ard.biesheuvel@arm.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Jordan Justen" <jordan.l.justen@intel.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [PATCH 1/2] OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just before SMI broadcast
Date: Thu, 27 Aug 2020 00:21:28 +0200	[thread overview]
Message-ID: <20200826222129.25798-2-lersek@redhat.com> (raw)
In-Reply-To: <20200826222129.25798-1-lersek@redhat.com>

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>
---
 OvmfPkg/CpuHotplugSmm/CpuHotplug.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
index 20e6bec04f41..cfe698ed2b5e 100644
--- a/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
+++ b/OvmfPkg/CpuHotplugSmm/CpuHotplug.c
@@ -193,9 +193,28 @@ CpuHotplugMmi (
   NewSlot = 0;
   while (PluggedIdx < PluggedCount) {
     APIC_ID NewApicId;
+    UINT32  CheckSlot;
     UINTN   NewProcessorNumberByProtocol;
 
     NewApicId = mPluggedApicIds[PluggedIdx];
+
+    //
+    // Check if the supposedly hot-added CPU is already known to us.
+    //
+    for (CheckSlot = 0;
+         CheckSlot < mCpuHotPlugData->ArrayLength;
+         CheckSlot++) {
+      if (mCpuHotPlugData->ApicId[CheckSlot] == NewApicId) {
+        break;
+      }
+    }
+    if (CheckSlot < mCpuHotPlugData->ArrayLength) {
+      DEBUG ((DEBUG_VERBOSE, "%a: APIC ID " FMT_APIC_ID " was hot-plugged "
+        "before; ignoring it\n", __FUNCTION__, NewApicId));
+      PluggedIdx++;
+      continue;
+    }
+
     //
     // Find the first empty slot in CPU_HOT_PLUG_DATA.
     //
-- 
2.19.1.3.g30247aa5d201



  reply	other threads:[~2020-08-26 22:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-26 22:21 [PATCH 0/2] OvmfPkg: fix race conditions in VCPU hotplug (for edk2-stable202008) Laszlo Ersek
2020-08-26 22:21 ` Laszlo Ersek [this message]
2020-08-26 22:21 ` [PATCH 2/2] OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcast Laszlo Ersek
2020-08-27  7:50 ` [PATCH 0/2] OvmfPkg: fix race conditions in VCPU hotplug (for edk2-stable202008) Ard Biesheuvel
2020-08-27 18:14   ` [edk2-devel] " Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200826222129.25798-2-lersek@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox