[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 1/2] x86/vmx: Fix IRQ handling for EXIT_REASON_INIT


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Wed, 1 Nov 2023 19:20:57 +0000
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Reima ISHII <ishiir@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, "Takahiro Shinagawa" <shina@xxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 01 Nov 2023 19:21:18 +0000
  • Ironport-data: A9a23:zh75Aa9pgIP2QHgt6eYoDrUDcH6TJUtcMsCJ2f8bNWPcYEJGY0x3m 2sWDGnXO/bbN2Lyfd5+PY6/8B8HuZDUmt9kSQU+rCA8E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjVAOK6UKidYnwZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ird7ks01BjOkGlA5AdnPKgS5AS2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklh6 PhFFwA1cyzEguStx5u7EvBXmNoaeZyD0IM34hmMzBncBPciB5vCX7/L9ZlT2zJYasJmRKiEI ZBDMHw2MUWGPEUn1lQ/UfrSmM+BgHXlfiIeg1WSvactuEDYzRBr0airO93QEjCPbZwOxh7I/ TKYpAwVBDk9P9OWkSedw06JucuRtn/nXNM9Bf6Ro6sCbFq7mTVIVUx+uUGAiem0jAuyVsxSL 2QQ+zEytu4i+UqzVN7/Uhak5nmesXY0WsFQEuwgwA7Lx6HfpRvcGm8HXzkHYddgttdebR4A2 0KNntjpLSdyq7DTQnWYnp+LqRuiNC5TKnUNDQcGUA1D5dDgqYMyixvnT9B/HarzhdrwcRnzz i6Lqm4ihrwVpc8Ny6i/u1vAhlqEupHMRxUd+gbTU2Sq/w59IoWiYuSA8lja6/9oIY2SCETEo H8His/Y5etID4nlqcCWaLxTRvfzva/DaWCNxwE3d3U8y9iz01G+ed1v0AljGABsNN0DUD+xe XTNpzoEsfe/I0CWgb9Lj5OZUpp7nfi5TYy/Bpg4ffIUPMItKlXvEDVGIB7IhT6wyiDAhIlmY c/DGftAG0r2HkiOINCebOAH2Ltj/TgkxGXcXvgXJDz8iuLBPRZ5pVofWWZij9zVD4ve+205C /4Fa6O3J+x3CYUSmBX//48JNkwtJnMmH53woME/Xrfdc1o2Rjp/VaGBmONJl2lZc0N9z7mgw 51AchYFkwSXaYPvcm1mlUyPmJuwBM0i/BrXzAQnPEqy2mhLXLtDGJw3LsNtFZF+rbwL8BKBZ 6VdEyl2KqgVG2uvFvV0RcWVkbGOgzzx1VzRZHf5MWRjF3OiLiSQkuLZksLU3HFmJkKKWQEW+ tVMCiuzrUI/ejlf
  • Ironport-hdrordr: A9a23:pLFJka5eB7qgJqGoMgPXwP7XdLJyesId70hD6qm+c20zTiX+rb HXoB17726MtN91YhodcL+7VJVoLUmyyXcX2/hzAV7BZmjbUQKTRekJgLcKpQeQeREWndQy6U 4PSdkbNPTASXR8kMbm8E2ZPr8bsb+6GdiT5ds2Fk0dKD1XVw==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

When receiving an INIT, a prior bugfix tried to ignore the INIT and continue
onwards.

Unfortunately it's not safe to return at that point in vmx_vmexit_handler().
Just out of context in the first hunk is a local_irqs_enabled() which is
depended-upon by the return-to-guest path, causing the following checklock
failure in debug builds:

  (XEN) Error: INIT received - ignoring
  (XEN) CHECKLOCK FAILURE: prev irqsafe: 0, curr irqsafe 1
  (XEN) Xen BUG at common/spinlock.c:132
  (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y  Tainted:     H  ]----
  ...
  (XEN) Xen call trace:
  (XEN)    [<ffff82d040238e10>] R check_lock+0xcd/0xe1
  (XEN)    [<ffff82d040238fe3>] F _spin_lock+0x1b/0x60
  (XEN)    [<ffff82d0402ed6a8>] F pt_update_irq+0x32/0x3bb
  (XEN)    [<ffff82d0402b9632>] F vmx_intr_assist+0x3b/0x51d
  (XEN)    [<ffff82d040206447>] F vmx_asm_vmexit_handler+0xf7/0x210

Luckily, this is benign in release builds.  Accidentally having IRQs disabled
when trying to take an IRQs-on lock isn't a deadlock-vulnerable pattern.

Move the INIT handling into the main switch statement.  In hindsight, it's
wrong to skip other normal VMExit steps.

Fixes: b1f11273d5a7 ("x86/vmx: Don't spuriously crash the domain when INIT is 
received")
Reported-by: Reima ISHII <ishiir@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
CC: Wei Liu <wl@xxxxxxx>
CC: Jun Nakajima <jun.nakajima@xxxxxxxxx>
CC: Kevin Tian <kevin.tian@xxxxxxxxx>
CC: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
CC: Reima ISHII <ishiir@xxxxxxxxxxxxxxxxxxx>
CC: Takahiro Shinagawa <shina@xxxxxxxxxxxxxxxxx>

With this patch in place, the INIT is ignored and the guest continues:

  (XEN) HVM1 restore: CPU 0
  (d1) --- Xen Test Framework ---
  (d1) Environment: HVM 64bit (Long mode 4 levels)
  (XEN) Error: INIT received - ignoring
  (d1) Test result: SUCCESS
---
 xen/arch/x86/hvm/vmx/vmx.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 1edc7f1e919f..d26920d03bbc 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4097,10 +4097,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
     case EXIT_REASON_MCE_DURING_VMENTRY:
         do_machine_check(regs);
         break;
-
-    case EXIT_REASON_INIT:
-        printk(XENLOG_ERR "Error: INIT received - ignoring\n");
-        return; /* Renter the guest without further processing */
     }
 
     /* Now enable interrupts so it's safe to take locks. */
@@ -4390,6 +4386,12 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
     case EXIT_REASON_TRIPLE_FAULT:
         hvm_triple_fault();
         break;
+
+    case EXIT_REASON_INIT:
+        /* TODO: Turn into graceful shutdown. */
+        printk(XENLOG_ERR "Error: INIT received - ignoring\n");
+        break;
+
     case EXIT_REASON_PENDING_VIRT_INTR:
         /* Disable the interrupt window. */
         v->arch.hvm.vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
-- 
2.30.2




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.