From nobody Mon May 11 00:45:10 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 60DF9C433FE for ; Wed, 20 Apr 2022 01:37:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358780AbiDTBkY (ORCPT ); Tue, 19 Apr 2022 21:40:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358765AbiDTBkU (ORCPT ); Tue, 19 Apr 2022 21:40:20 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1DEB3467E for ; Tue, 19 Apr 2022 18:37:36 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id ij17-20020a170902ab5100b00158f6f83068so135049plb.19 for ; Tue, 19 Apr 2022 18:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=7XDJ2YAUSUHcgoV3YPLSl5Gau4y2D+i+qP4k1W8uuo0=; b=Kzq671IMXGcPz9IKQMcDM3US3HjfGCUincXTuSeb8zoQ5g9zspDa+oftBodD+68BA0 ASknvWT3y3/2tm1pFvOJJf03UDGsxHlo9HiJfajn1z86XFO8VOYNgeJSfcldOjJttKL6 u4iQvkpiuIkouUmlKxAkJZjsKSp4mgT8LCkPtIuNgcc2wJgdk6U7HVc6zawUrxFqpmSh cJMdz7quOHZhIjj/TZfU2uKppIHeoeY4vyOXo7g77A40z8OFTcPn3la8QqxicZn1Y0I2 coWmIbo0WusRrVIVoc6e2zWzddbvtftv+F4nVGPrWzvz4itxs6rqqz4CFy1AZrhnF+s1 VKiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=7XDJ2YAUSUHcgoV3YPLSl5Gau4y2D+i+qP4k1W8uuo0=; b=kDQEts+GWQydUA2WWWsWmBrOz5YBaUR/2Mlr9fFZjqj9cBDJex4i3JtNF9kydN7SE0 rIkBJNqRfVxFgzmQ8Fq4djG+zedM5rFuKFlz1YJ7tAl2og7PYeQ9biDDb1uv++9mDY1g QfZggTKGpp08fQGJlJ4548jyMj9szvuEQo2bIt7QXYXLPp0uQY63uHwyi1xEtYOGf2cc 2a/6YMdJ12vE//6yQa2OdRW/C2CAjpXGS9VSH/yAdxfq6IZViK3IPhkwFO41Z8gbfOZJ GNz+eLd4MbHgvIO1zdfQ/jb8gR5LDmt8u+cXnBULxukMV5jVpfgHla62tJmZk3d2XkA+ OQLw== X-Gm-Message-State: AOAM532cG7dbPvW/d5D0ZPimRIRBf7HCyad/D4VGRyCIqPqDVQUkoxD4 0R+PaPnzuCx6X2p2pICGG8Lm6ofuyTk= X-Google-Smtp-Source: ABdhPJxuyNZSwYUgGu63fLJ8gbeXdplf35syAz3Hcvk6YC/6aaKdyYPIGOcMr0sABs2XFp+PY2pmPdIXT+g= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:90a:9105:b0:1d2:9e98:7e1e with SMTP id k5-20020a17090a910500b001d29e987e1emr198610pjo.0.1650418655862; Tue, 19 Apr 2022 18:37:35 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 20 Apr 2022 01:37:29 +0000 In-Reply-To: <20220420013732.3308816-1-seanjc@google.com> Message-Id: <20220420013732.3308816-2-seanjc@google.com> Mime-Version: 1.0 References: <20220420013732.3308816-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH v2 1/4] KVM: x86: Tag APICv DISABLE inhibit, not ABSENT, if APICv is disabled From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky , Gaoning Pan , Yongkang Jia Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Set the DISABLE inhibit, not the ABSENT inhibit, if APICv is disabled via module param. A recent refactoring to add a wrapper for setting/clearing inhibits unintentionally changed the flag, probably due to a copy+paste goof. Fixes: 4f4c4a3ee53c ("KVM: x86: Trace all APICv inhibit changes and capture= overall status") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ab336f7c82e4..753296902535 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9159,7 +9159,7 @@ static void kvm_apicv_init(struct kvm *kvm) =20 if (!enable_apicv) set_or_clear_apicv_inhibit(inhibits, - APICV_INHIBIT_REASON_ABSENT, true); + APICV_INHIBIT_REASON_DISABLE, true); } =20 static void kvm_sched_yield(struct kvm_vcpu *vcpu, unsigned long dest_id) --=20 2.36.0.rc0.470.gd361397f0d-goog From nobody Mon May 11 00:45:10 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 28CAFC433FE for ; Wed, 20 Apr 2022 01:37:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358793AbiDTBk1 (ORCPT ); Tue, 19 Apr 2022 21:40:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358774AbiDTBkW (ORCPT ); Tue, 19 Apr 2022 21:40:22 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CA8636314 for ; Tue, 19 Apr 2022 18:37:38 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id v14-20020a17090a0c8e00b001cb778cc439so266942pja.3 for ; Tue, 19 Apr 2022 18:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=TxoVH8jqumoBwLE1c1wDjm4U/jMWUAAXwwPe08KhaNQ=; b=pgUid2ZDi4d44G/4li3vBbWVhssPqbGi1gqwGGH+CK49KWK01tUWd+OSwKoVoHxzpb KRuMdZBrKjpj/qaUlRmeWQ587hra3MxjcU6sKGqnq5xvYhRD1mDZIOm+2tguZZrYVxru TPCKqDMU5gvgdFZVh3TSTh4J8Vbfphme53XyZ6brp373vhABZpeOz7TUjL356Uf/fGir k4kr4v0pQlJuvsy8uvj/awI4+RPP2Qx/HXgWgc1gsF73SfNfi+FinOo7y0NomKgv+Ws+ oCDUcohG+RfB01zHH4XNgqQ7+CHibj3Cz8u5A/kLSV53Se+cvxYVhi50hT1nlLoc+n+S w8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=TxoVH8jqumoBwLE1c1wDjm4U/jMWUAAXwwPe08KhaNQ=; b=fMBuyCSFUht6B0MwZn7sgt9HVZt7t4HtRpyXM1KKH/sX8XjXY3W3QcrO2Hf7b7wCc2 jydwmJqitjbXNzS4dHChFnF70IPhcqbzA5PePo+xasM24hhy0O3lZtq1nPjzeB66RH/l TN3TZ0EWT+s+t6WM3e18JvyO8p6NVH5pHa4kIjdDZI9jDKVYi3oZqyTMgsLg72vqo8G6 quIieeCJ34W1I+rrtCCXlfnW4Yt+xpvlKjOscCK9179ooQOEP3Mv/OtWTcJQI0MmbgFI wOYMfvIgc/tzdc4LAgG95ot4t7jz3e/1m3kJ58TkKlXgSeoxIFffuxPMNcBHzZFEuonp /yFg== X-Gm-Message-State: AOAM532RXyJFWIra49N9X+lq8U2mVLenprR69sBL9q457g32b2705oU1 BThsJhbAmXKouh0wlEIAM9B+Te1RXjw= X-Google-Smtp-Source: ABdhPJwdSECB7MRDEUGbmw+G3pthHK/0y010kvGOeNArAgHP6vfv5vQHsKabV3zq18cVCQP57bsrRTVT8EU= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:864c:b0:158:c459:ab45 with SMTP id y12-20020a170902864c00b00158c459ab45mr18807314plt.123.1650418657553; Tue, 19 Apr 2022 18:37:37 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 20 Apr 2022 01:37:30 +0000 In-Reply-To: <20220420013732.3308816-1-seanjc@google.com> Message-Id: <20220420013732.3308816-3-seanjc@google.com> Mime-Version: 1.0 References: <20220420013732.3308816-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH v2 2/4] KVM: nVMX: Defer APICv updates while L2 is active until L1 is active From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky , Gaoning Pan , Yongkang Jia Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Defer APICv updates that occur while L2 is active until nested VM-Exit, i.e. until L1 regains control. vmx_refresh_apicv_exec_ctrl() assumes L1 is active and (a) stomps all over vmcs02 and (b) neglects to ever updated vmcs01. E.g. if vmcs12 doesn't enable the TPR shadow for L2 (and thus no APICv controls), L1 performs nested VM-Enter APICv inhibited, and APICv becomes unhibited while L2 is active, KVM will set various APICv controls in vmcs02 and trigger a failed VM-Entry. The kicker is that, unless running with nested_early_check=3D1, KVM blames L1 and chaos ensues. In all cases, ignoring vmcs02 and always deferring the inhibition change to vmcs01 is correct (or at least acceptable). The ABSENT and DISABLE inhibitions cannot truly change while L2 is active (see below). IRQ_BLOCKING can change, but it is firmly a best effort debug feature. Furthermore, only L2's APIC is accelerated/virtualized to the full extent possible, e.g. even if L1 passes through its APIC to L2, normal MMIO/MSR interception will apply to the virtual APIC managed by KVM. The exception is the SELF_IPI register when x2APIC is enabled, but that's an acceptable hole. Lastly, Hyper-V's Auto EOI can technically be toggled if L1 exposes the MSRs to L2, but for that to work in any sane capacity, L1 would need to pass through IRQs to L2 as well, and IRQs must be intercepted to enable virtual interrupt delivery. I.e. exposing Auto EOI to L2 and enabling VID for L2 are, for all intents and purposes, mutually exclusive. Lack of dynamic toggling is also why this scenario is all but impossible to encounter in KVM's current form. But a future patch will pend an APICv update request _during_ vCPU creation to plug a race where a vCPU that's being created doesn't get included in the "all vCPUs request" because it's not yet visible to other vCPUs. If userspaces restores L2 after VM creation (hello, KVM selftests), the first KVM_RUN will occur while L2 is active and thus service the APICv update request made during VM creation. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson --- arch/x86/kvm/vmx/nested.c | 5 +++++ arch/x86/kvm/vmx/vmx.c | 5 +++++ arch/x86/kvm/vmx/vmx.h | 1 + 3 files changed, 11 insertions(+) diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index a6688663da4d..f5cb18e00e78 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4640,6 +4640,11 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm= _exit_reason, kvm_make_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu); } =20 + if (vmx->nested.update_vmcs01_apicv_status) { + vmx->nested.update_vmcs01_apicv_status =3D false; + kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu); + } + if ((vm_exit_reason !=3D -1) && (enable_shadow_vmcs || evmptr_is_valid(vmx->nested.hv_evmcs_vmptr))) vmx->nested.need_vmcs12_to_shadow_sync =3D true; diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index cf8581978bce..4c407a34b11e 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -4174,6 +4174,11 @@ static void vmx_refresh_apicv_exec_ctrl(struct kvm_v= cpu *vcpu) { struct vcpu_vmx *vmx =3D to_vmx(vcpu); =20 + if (is_guest_mode(vcpu)) { + vmx->nested.update_vmcs01_apicv_status =3D true; + return; + } + pin_controls_set(vmx, vmx_pin_based_exec_ctrl(vmx)); if (cpu_has_secondary_exec_ctrls()) { if (kvm_vcpu_apicv_active(vcpu)) diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h index 9c6bfcd84008..b98c7e96697a 100644 --- a/arch/x86/kvm/vmx/vmx.h +++ b/arch/x86/kvm/vmx/vmx.h @@ -183,6 +183,7 @@ struct nested_vmx { bool change_vmcs01_virtual_apic_mode; bool reload_vmcs01_apic_access_page; bool update_vmcs01_cpu_dirty_logging; + bool update_vmcs01_apicv_status; =20 /* * Enlightened VMCS has been enabled. It does not mean that L1 has to --=20 2.36.0.rc0.470.gd361397f0d-goog From nobody Mon May 11 00:45:10 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 5E55DC433EF for ; Wed, 20 Apr 2022 01:37:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358807AbiDTBka (ORCPT ); Tue, 19 Apr 2022 21:40:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358781AbiDTBkY (ORCPT ); Tue, 19 Apr 2022 21:40:24 -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 C6DA537A01 for ; Tue, 19 Apr 2022 18:37:39 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id z18-20020a631912000000b003a392265b64so120443pgl.2 for ; Tue, 19 Apr 2022 18:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=L1stsYTq2+o/6GoWODILUnSJjjIl65dFiA+39DN8K4w=; b=ZMA4b3z5Kp6xkhw0yjW/G39Dez/b7Qemsfz+FioG2pKkA3z2jwQ3Iwn190Ta8xbdP6 Ll4Dky1fhRre8DqfzA51Lgk0kxknA0hpq8t130a2RWlu+uaxVbQu8bI0BKxFGFoIgUoY 0j4gPkCN6uYWLLqHNZ7PEyZLMVfeBJXWPMJoxk5P0x9PLsV3BCHZI/YcaF5FEmnnIjsl o6Wx1dhwMmyJ019aiCOSZ+sce3LdwmlXmYoFOH8uGYMIA0S42XMD9pmtS7er1qrxn+jQ ROoBkApqvFpxFBU/p/Q98xFIlyFGgXAWBYvXjf0AGN2e63I7Upf3T/alg4TfuAE4hGZn vMmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=L1stsYTq2+o/6GoWODILUnSJjjIl65dFiA+39DN8K4w=; b=6j87O5bwZkiGIlnmAWtYaULEkws58zwRqGN97PHtxkX1anwf4TOkAHQa1Pov72sAoQ r/j71tiORcya+WSxi6iuwtW3OuR/wPAnXrWRqxvyn5pejLnjfVfCLEzOxMThWuNoHU3d xLeHISn5dq6gySD7uF8fZ1/VBxmgK2k6zwwYZ3hymVqFEhKCsJtePytJ/Pxa/lFDClPP Je9eXePqvh5/4NAg+n0G5O7XINAieWsUxjgkmvYpZ+UdgcQuP9b2ujURDUc2GdqnKkch SHvbQaqkbe0iPwqnVQJKdw2xcIP8JqdDVCoZhxo61qpZMQlFqX/ENKQVuGmTskMCTa+b MQCA== X-Gm-Message-State: AOAM532dbe6SwcPn8FRpWEmAJIKXlsPiibMRA1laxuSt4DfjS1OhX9jh 4sgF8dx8/bpu+io76DXHcrKYx/4RL1w= X-Google-Smtp-Source: ABdhPJzGw3h6ARA9+CPHD3Vzsl9+lRkjgJdWEettAnhoScwY554OuC5PnW5lIQmpCPuIWYJQ+Q+wRnGFffg= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a62:1c8d:0:b0:4fa:8dcb:6da2 with SMTP id c135-20020a621c8d000000b004fa8dcb6da2mr20533553pfc.19.1650418659302; Tue, 19 Apr 2022 18:37:39 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 20 Apr 2022 01:37:31 +0000 In-Reply-To: <20220420013732.3308816-1-seanjc@google.com> Message-Id: <20220420013732.3308816-4-seanjc@google.com> Mime-Version: 1.0 References: <20220420013732.3308816-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH v2 3/4] KVM: x86: Pend KVM_REQ_APICV_UPDATE during vCPU creation to fix a race From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky , Gaoning Pan , Yongkang Jia Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Make a KVM_REQ_APICV_UPDATE request when creating a vCPU with an in-kernel local APIC and APICv enabled at the module level. Consuming kvm_apicv_activated() and stuffing vcpu->arch.apicv_active directly can race with __kvm_set_or_clear_apicv_inhibit(), as vCPU creation happens before the vCPU is fully onlined, i.e. it won't get the request made to "all" vCPUs. If APICv is globally inhibited between setting apicv_active and onlining the vCPU, the vCPU will end up running with APICv enabled and trigger KVM's sanity check. Mark APICv as active during vCPU creation if APICv is enabled at the module level, both to be optimistic about it's final state, e.g. to avoid additional VMWRITEs on VMX, and because there are likely bugs lurking since KVM checks apicv_active in multiple vCPU creation paths. While keeping the current behavior of consuming kvm_apicv_activated() is arguably safer from a regression perspective, force apicv_active so that vCPU creation runs with deterministic state and so that if there are bugs, they are found sooner than later, i.e. not when some crazy race condition is hit. WARNING: CPU: 0 PID: 484 at arch/x86/kvm/x86.c:9877 vcpu_enter_guest+0x2a= e3/0x3ee0 arch/x86/kvm/x86.c:9877 Modules linked in: CPU: 0 PID: 484 Comm: syz-executor361 Not tainted 5.16.13 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubunt= u1~cloud0 04/01/2014 RIP: 0010:vcpu_enter_guest+0x2ae3/0x3ee0 arch/x86/kvm/x86.c:9877 Call Trace: vcpu_run arch/x86/kvm/x86.c:10039 [inline] kvm_arch_vcpu_ioctl_run+0x337/0x15e0 arch/x86/kvm/x86.c:10234 kvm_vcpu_ioctl+0x4d2/0xc80 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3727 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x16d/0x1d0 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The bug was hit by a syzkaller spamming VM creation with 2 vCPUs and a call to KVM_SET_GUEST_DEBUG. r0 =3D openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x0, 0x0) r1 =3D ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) ioctl$KVM_CAP_SPLIT_IRQCHIP(r1, 0x4068aea3, &(0x7f0000000000)) (async) r2 =3D ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x0) (async) r3 =3D ioctl$KVM_CREATE_VCPU(r1, 0xae41, 0x400000000000002) ioctl$KVM_SET_GUEST_DEBUG(r3, 0x4048ae9b, &(0x7f00000000c0)=3D{0x5dda9c14= aa95f5c5}) ioctl$KVM_RUN(r2, 0xae80, 0x0) Reported-by: Gaoning Pan Reported-by: Yongkang Jia Fixes: 8df14af42f00 ("kvm: x86: Add support for dynamic APICv activation") Cc: stable@vger.kernel.org Cc: Maxim Levitsky Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/x86.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 753296902535..09a270cc1c8f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11259,8 +11259,21 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) r =3D kvm_create_lapic(vcpu, lapic_timer_advance_ns); if (r < 0) goto fail_mmu_destroy; - if (kvm_apicv_activated(vcpu->kvm)) + + /* + * Defer evaluating inhibits until the vCPU is first run, as + * this vCPU will not get notified of any changes until this + * vCPU is visible to other vCPUs (marked online and added to + * the set of vCPUs). Opportunistically mark APICv active as + * VMX in particularly is highly unlikely to have inhibits. + * Ignore the current per-VM APICv state so that vCPU creation + * is guaranteed to run with a deterministic value, the request + * will ensure the vCPU gets the correct state before VM-Entry. + */ + if (enable_apicv) { vcpu->arch.apicv_active =3D true; + kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu); + } } else static_branch_inc(&kvm_has_noapic_vcpu); =20 --=20 2.36.0.rc0.470.gd361397f0d-goog From nobody Mon May 11 00:45:10 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 12F46C433F5 for ; Wed, 20 Apr 2022 01:37:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358813AbiDTBke (ORCPT ); Tue, 19 Apr 2022 21:40:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358787AbiDTBk0 (ORCPT ); Tue, 19 Apr 2022 21:40:26 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96FCE377C3 for ; Tue, 19 Apr 2022 18:37:41 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id z11-20020a62d10b000000b00507258043e7so300742pfg.16 for ; Tue, 19 Apr 2022 18:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=YggvXc76kD9hmqmKWmhy8VV9X8fOiVEtam3hP4xSjGM=; b=maxPT6Mp0MgvU206GcEL0romWQqaLaog8y/UrpuifwgoME9aLjLO4W/X8VprbMLDY/ GCSQlblwz0+h33sONAnLzlWMj/r58kxHJad6WpW/6XBcaaatIvts2ncRNxYLCqBJWpUr ImtXvtRkpsHVKpb5ik7Sk63AW8Lt5YOldBjgPgWy8Rz/Q6hppA8iI0lOXtEo4Ro4bBSw GAmva/jjL32/Z9oBcosfTomF6CKA4cQhGQsyAn+2g0racOBoXBAL9cd7IRXXaUgWzGoY tjB4OS9UP7vgxAY43mpIA/Vb4eqHyVhaHglyhi9LD29Ul0kOA+7DG2iA7Dq6ZRAdXaVn ZzSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=YggvXc76kD9hmqmKWmhy8VV9X8fOiVEtam3hP4xSjGM=; b=cSu+ZlhwTssCRmwYX2guZzQHeeAHWnQcyWfHudbgRRs1vyYtfU9e6HUkeyPcDq5CQh qmWju3YNckYv7naqRVJYNygDYZ/ywa1RkZlxOZuGrZF3UdlZWsm9gfKmC7b2jGpYGbRS 4ujdS7ANKpyXRgqlI68L6IXtGJVbO2zx9lODynE0T9vudCSdAigqqA91/cR+bieGtIGy Yy5T+LGV5BxxmbRrc3B0rdqhOdRNiy64hmYwSYgqY2+xTIvlZcD8I3mXjfr7Uzxciw3E 7zax3g5p+BdUfMdG0XznVP/Zm22BG/clTmUas0O5wxEff6yfyaCLKhlSBOJwmopuG3IG 4SXg== X-Gm-Message-State: AOAM532ADZxdUwikL1OMlbHyzty9YYvjK+/K5O9iwvbY5uagzL5U/CY8 2yfJu2RbjrOl3XJN2pWekGPpWfloSeE= X-Google-Smtp-Source: ABdhPJxmdbTe3X4Jl9yDGni826ymwia/p9HVgg/n6ca6j5LdEaWE5XZFyQ+yI2r9ValnG5yrTGpnbVg5h+U= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:7448:b0:158:f93f:bc0c with SMTP id e8-20020a170902744800b00158f93fbc0cmr12947007plt.8.1650418661056; Tue, 19 Apr 2022 18:37:41 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 20 Apr 2022 01:37:32 +0000 In-Reply-To: <20220420013732.3308816-1-seanjc@google.com> Message-Id: <20220420013732.3308816-5-seanjc@google.com> Mime-Version: 1.0 References: <20220420013732.3308816-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH v2 4/4] KVM: x86: Skip KVM_GUESTDBG_BLOCKIRQ APICv update if APICv is disabled From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Maxim Levitsky , Gaoning Pan , Yongkang Jia Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Skip the APICv inhibit update for KVM_GUESTDBG_BLOCKIRQ if APICv is disabled at the module level to avoid having to acquire the mutex and potentially process all vCPUs. The DISABLE inhibit will (barring bugs) never be lifted, so piling on more inhibits is unnecessary. Fixes: cae72dcc3b21 ("KVM: x86: inhibit APICv when KVM_GUESTDBG_BLOCKIRQ ac= tive") Cc: Maxim Levitsky Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/x86.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 09a270cc1c8f..16c5fa7d165d 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11048,6 +11048,9 @@ static void kvm_arch_vcpu_guestdbg_update_apicv_inh= ibit(struct kvm *kvm) struct kvm_vcpu *vcpu; unsigned long i; =20 + if (!enable_apicv) + return; + down_write(&kvm->arch.apicv_update_lock); =20 kvm_for_each_vcpu(i, vcpu, kvm) { --=20 2.36.0.rc0.470.gd361397f0d-goog