From nobody Tue Feb 10 02:59:14 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 816C7C77B75 for ; Fri, 12 May 2023 23:31:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240858AbjELXbp (ORCPT ); Fri, 12 May 2023 19:31:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240782AbjELXbf (ORCPT ); Fri, 12 May 2023 19:31:35 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C9F130F1 for ; Fri, 12 May 2023 16:31:34 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-518d6f87a47so5257044a12.3 for ; Fri, 12 May 2023 16:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683934293; x=1686526293; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=wcH/IZQt2fpKxWmdOflRc9OWLwVhjYgy+bCX1XDE93g=; b=4v83TGIas+wfJjaWLCOjPTDFSf5eI0rTg2hOJnaAcwUhGubuB/XMefrzo/70cdPHs7 2qaVG9FFRFrrWuA1ch2mD8R4vANQ3Jz3nCMrzvZL0iWOP4dnahrvsSnasp3AStseMnli rgmbk09ghFEHQUAHCkGmU4u7FWympmB7VW8JOn548sLMsS9hGc7lp6VtWMLlA0tgQ2Kz NUo3Hp2V0aQJU/fe5wxt9V43OBF9EodvkmL7m7XGnUC0Z3cqtyVB9kmSoK8AJVw5WF7Z gLH0mc1P5/CzJt6NLPLOzREmR25cB3/2DNJss8i8VU9bLcWJ8eQ9iPX/k78+NRi1c9yG QLRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683934293; x=1686526293; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wcH/IZQt2fpKxWmdOflRc9OWLwVhjYgy+bCX1XDE93g=; b=YI4tH48XeOTf5Slez16KqLwCl1W9NkIBDLYz3LXpaUc5l41a2e12N9YGyxYMXqX0gq RlORo9yN9aBq4ZaJWd7Yynzl0xVyE5rJ0fZ0QM0f1hvLLxzqDStNvvgyVlatFSfvD4Oq MW46J0/NrA+gjRUSpN72PVng48XJnJB5+ls7DE91xbSq64D72uLmCGfmNuKSGtd3ou2b 9CEE3Ma5aIMFw7MdTsRvKrfBfhJxBEEELIWLUP0ybnRRDHrykMHiERhbwDEuarfo+so5 avW9prU3vKoe8EtTPvim7tH3btEclNv4AFT1U0TqnIhO6841qEp+bO1oO63/a4qgs2Fn Qprw== X-Gm-Message-State: AC+VfDw3ZD0Sk4rVLFi3j1phr94aGPgQ+8CRmjvKsxbNse3e7VgsuiyJ ZZF6yJewxOZ4Bs0vZXmLu+UbVpjWKxM= X-Google-Smtp-Source: ACHHUZ5UNjKC3Mr05CVuFrOytcZXmJ4jNvPP0Z/3ZNzFBXbNdnsGA19Lumkans0gS6XeDtr0V3XVeltLARk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:2b04:0:b0:521:62ef:9b38 with SMTP id r4-20020a632b04000000b0052162ef9b38mr7261719pgr.3.1683934293773; Fri, 12 May 2023 16:31:33 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 12 May 2023 16:31:27 -0700 In-Reply-To: <20230512233127.804012-1-seanjc@google.com> Mime-Version: 1.0 References: <20230512233127.804012-1-seanjc@google.com> X-Mailer: git-send-email 2.40.1.606.ga4b1b128d6-goog Message-ID: <20230512233127.804012-3-seanjc@google.com> Subject: [PATCH v2 2/2] KVM: Don't enable hardware after a restart/shutdown is initiated From: Sean Christopherson To: Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , kvmarm@lists.linux.dev, Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , kvm-riscv@lists.infradead.org, Sean Christopherson Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Reject hardware enabling, i.e. VM creation, if a restart/shutdown has been initiated to avoid re-enabling hardware between kvm_reboot() and machine_{halt,power_off,restart}(). The restart case is especially problematic (for x86) as enabling VMX (or clearing GIF in KVM_RUN on SVM) blocks INIT, which results in the restart/reboot hanging as BIOS is unable to wake and rendezvous with APs. Note, this bug, and the original issue that motivated the addition of kvm_reboot(), is effectively limited to a forced reboot, e.g. `reboot -f`. In a "normal" reboot, userspace will gracefully teardown userspace before triggering the kernel reboot (modulo bugs, errors, etc), i.e. any process that might do ioctl(KVM_CREATE_VM) is long gone. Fixes: 8e1c18157d87 ("KVM: VMX: Disable VMX when system shutdown") Signed-off-by: Sean Christopherson --- virt/kvm/kvm_main.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e771b6a013c9..cc36a7fc8a86 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5182,7 +5182,20 @@ static void hardware_disable_all(void) static int hardware_enable_all(void) { atomic_t failed =3D ATOMIC_INIT(0); - int r =3D 0; + int r; + + /* + * Do not enable hardware virtualization if the system is going down. + * If userspace initiated a forced reboot, e.g. reboot -f, then it's + * possible for an in-flight KVM_CREATE_VM to trigger hardware enabling + * after kvm_reboot() is called. Note, this relies on system_state + * being set _before_ kvm_reboot(), which is why KVM uses a syscore ops + * hook instead of registering a dedicated reboot notifier (the latter + * runs before system_state is updated). + */ + if (system_state =3D=3D SYSTEM_HALT || system_state =3D=3D SYSTEM_POWER_O= FF || + system_state =3D=3D SYSTEM_RESTART) + return -EBUSY; =20 /* * When onlining a CPU, cpu_online_mask is set before kvm_online_cpu() @@ -5195,6 +5208,8 @@ static int hardware_enable_all(void) cpus_read_lock(); mutex_lock(&kvm_lock); =20 + r =3D 0; + kvm_usage_count++; if (kvm_usage_count =3D=3D 1) { on_each_cpu(hardware_enable_nolock, &failed, 1); --=20 2.40.1.606.ga4b1b128d6-goog