From nobody Thu May 14 08:25:46 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 64132C433EF for ; Sat, 16 Apr 2022 03:43:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230221AbiDPDpd (ORCPT ); Fri, 15 Apr 2022 23:45:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230195AbiDPDp1 (ORCPT ); Fri, 15 Apr 2022 23:45:27 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A823A145B for ; Fri, 15 Apr 2022 20:42:57 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id n1-20020a654881000000b003a367d46721so869760pgs.4 for ; Fri, 15 Apr 2022 20:42:57 -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=fTlZCEAeKXElMirgnXEOUiISDvu4kIw+3K3+/YC0tjY=; b=esGDB+uQK+XlvOzeTwh0mtq3egMCIieRH3ZRiipmzTx5/a4pNJQ2RmB2E4uDA2bNdy cnM+1TL1FiXBdKb+jMG/sq91sq/ZAxb3wtrUF1MYxoPD8QdpNqZr1rP1Cx9qI81Q9vX9 0VvWDxR8uRdpFT4pDstEyo/1RsBVBu+4tTPe/vhS0Ny19ZUSiiMUkOYzr4y2Vk7aKc02 YZB6PrlB5kKuiNM/RZ2jeeYKzMdHmYjycfKvMgpJKi5J17GZuRAjL5FMlFZewOu1c2BU +uL+WlGMzWHmlkrJ9FeEzj3aCBMHDlcyIJlegtO1tfNTBXJ2P7X4LWBPyExsQ9DS9nAr Gt7A== 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=fTlZCEAeKXElMirgnXEOUiISDvu4kIw+3K3+/YC0tjY=; b=PpXgiE+YPbfBvJtnNrIjkSrffiQH/uSZ4DksIko7UyiU5yehsMLKqAO+qT4Nl4pYVt qO8C6HYH4PUHJjCqm0WTXrAKv/KjG2lFiw4ZODz5dzX5D0E87ajN0wxXPRbMQhhpdekT geF/4mnHLv4yjZdLbpuxPr2eou9Yod73totXnCBXtliUz2vEc1UpUuptcLEZXf21H+uo zoQCWjBn+kP1YfjKefcHJfYJ77/4reX3GAx9SwYDAq8V2ZCUs4pop7svDsaYwPiJqlH7 OOabDCsFx/hnptl7PX14HvWfzGnY8PDJKn+neAiJqBW4BxAGBRmmNL8+UtKxEUwMS8HC Ic9w== X-Gm-Message-State: AOAM530FHRBAK1gp3ZEFHqkraEMzubR1YXCivlChdzTL7VyZhGDbFUUr VzgcOrsaCU6zx6PjCDnqsKSxI1Lf7Ig= X-Google-Smtp-Source: ABdhPJwEvVzDPrTPEf7YMvmW/Px6daHU99c/ZLJCjUTC4jIXd4UhIM6/elOLB9r2p6vwqsgODRXNCYRQI9g= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a05:6a00:ad0:b0:4e1:2d96:2ab0 with SMTP id c16-20020a056a000ad000b004e12d962ab0mr1879483pfl.3.1650080576657; Fri, 15 Apr 2022 20:42:56 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 16 Apr 2022 03:42:46 +0000 In-Reply-To: <20220416034249.2609491-1-seanjc@google.com> Message-Id: <20220416034249.2609491-2-seanjc@google.com> Mime-Version: 1.0 References: <20220416034249.2609491-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH 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, Gaoning Pan , Yongkang Jia , Maxim Levitsky 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 Thu May 14 08:25:46 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 77806C433EF for ; Sat, 16 Apr 2022 03:43:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230228AbiDPDpi (ORCPT ); Fri, 15 Apr 2022 23:45:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230209AbiDPDp3 (ORCPT ); Fri, 15 Apr 2022 23:45:29 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27CF4AA027 for ; Fri, 15 Apr 2022 20:42:59 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id l11-20020a170902f68b00b00158a978a3a8so2587301plg.19 for ; Fri, 15 Apr 2022 20:42:59 -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=nKPYdcoAR+O0z93CeuVQzqJsKdRmlp95sBm2PZZkh2Q=; b=gxfsYYhxAuJu92KlrKTzzOsteey1Iwag9ncOUwIBdu6vepT/7L+HbG0tu2hmkplbv0 u2Bk7qHGyvgFQMblzFuUAiCL0FEzjvcQq4mTURIjx74rRbAJQkYOLyQDJ6q7Tj/YLoKl 3r6pOxjxcyLPp7bw1UaJ4kh9930VEZ2lLF5rvh0Ykj6nZ2nLI6UcgXDp3KzSIL75f+58 XWz6l6uxqHekehFt1w9GhBJBA+51ArcS0dc4yD9L21cXDWJQPJGw4AnhfDke4z8IGwrW PkyQMADgWjPiXH8zFbMS14nLY2sJmBzzlrNx1I4uI0A7UHTPv30f8nOSZy3NaxJTr0Ua bzRA== 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=nKPYdcoAR+O0z93CeuVQzqJsKdRmlp95sBm2PZZkh2Q=; b=h5/D0/JvBdYR4Er9OdEqsq+FWHpAaXGl3erfuCCK6UZOBWm13xdX2NSFYpyZwEkaGu AqSj5IazXmIknC8otSCPsb9Mj6BcUjqH8l6Cp/cequhcfQxbt3ud22GfuDL0nb1i3oVL Exv2fo9AZQtulUK0Mf/Kj19upVr97ctpYyEO5Sn+VJ4tPmVpo2BmNumjHrsx2rUKI2Lu ajAngd3iqGGscSUv9zTjU8yONpFlavbsR3Xfk2CeWuoU11dk33HnEY1I0suH0OaOqTy0 U4IcPrRmHUJKa7RD+mmUaxSCo9+AU1ACooUglv1Vq4fF4QWU+sjwr96vUFTPVo0Nqrrn RgMw== X-Gm-Message-State: AOAM532UtWEfcB9YK3zKproJndVqYfhQ5WHAFGyCVxWyCbr0/GnGG+9e EL1v7J3Al6851+6Lrx+oaj+iseJSoLc= X-Google-Smtp-Source: ABdhPJx6Tmqfrn+hqTO7IpqMzEhjNCsL12jNPtIcg5YqTq3hIvmM7RkIoPH/ztfkLfsd7cfaVb/eiwDeNRc= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:90a:858b:b0:1c6:5bc8:781a with SMTP id m11-20020a17090a858b00b001c65bc8781amr661086pjn.0.1650080578285; Fri, 15 Apr 2022 20:42:58 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 16 Apr 2022 03:42:47 +0000 In-Reply-To: <20220416034249.2609491-1-seanjc@google.com> Message-Id: <20220416034249.2609491-3-seanjc@google.com> Mime-Version: 1.0 References: <20220416034249.2609491-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH 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, Gaoning Pan , Yongkang Jia , Maxim Levitsky 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. The obvious elephant in the room is whether or not KVM needs to disallow APICv in L2 if it is inhibited in L1. Luckily, that's largely a moot point as the only dynamic inhibit conditions that affect VMX are Hyper-V and IRQ blocking. IRQ blocking is firmly a debug-only feature, and L1 probably deserves whatever mess it gets by enabling AutoEOI while running L2 with APICv enabled. 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 Thu May 14 08:25:46 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 D3F0BC433EF for ; Sat, 16 Apr 2022 03:43:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230232AbiDPDpp (ORCPT ); Fri, 15 Apr 2022 23:45:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230214AbiDPDpb (ORCPT ); Fri, 15 Apr 2022 23:45:31 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4D18AA00E for ; Fri, 15 Apr 2022 20:43:00 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id m8-20020a17090aab0800b001cb1320ef6eso8257343pjq.3 for ; Fri, 15 Apr 2022 20:43:00 -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=caqu0al6aFmQHXaPlReX326/jFRGqosx2auDWDfhBPQ=; b=SwKv8s/c28NnnnbLE/cbqmbLUPgd8fpbH5uKyMCuZB6jBUzNdjU5Y7JqrPWdPom3W3 dRe+5mqjucysqxNnPB8xVHTBekr25NSePYB2y1GgxF5lmnaSmmfTIxNcQXyRPo68hOB0 8T3xf/m+thy6eprcBYl/y+elw1abR6YTvqx8pi/zGLHfJnjPJkxgvN1IIWcLGLaL0d8c pnPNGCNGPTbUEBRqpwZ7eMQd3LvBsH+aR4/GRjVG/HedLCVnj5L7CTH0akGACovLWUM8 LmdGex+yz3gTbS0KFZLJt5mlcQbBhnOT6wFzLvO9S/DgEdYaliuwTtHwEmtEmDvOxngN lTUQ== 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=caqu0al6aFmQHXaPlReX326/jFRGqosx2auDWDfhBPQ=; b=EY/eAtOLgpfV8J6CZHlegeWvfM3noOx6jAg5PYPF9HiXLmd9c4M4wbQU5IO26FBK0F iq6t0AnesF2HBnBfIljw3WUMfoS+IgzbqGVF7gr9Q4JH4PGp5u/joNYGAk0x9SgtzIFL IhiuyGRZH/L6HVwVjzWBe2xNjbgqM91DDNxCxE4c8xL3aW4pfM9Sbwp2tsUtaaWj09I0 tGhRdjGJy4uoVxv0SO1/y88OH7BdQKJrGKh5Ygpug2ISOCyVKS4trGM35mkuEMH0WyLp epcxE3njq+BWa1SVYV+o1lSXOKqaNuj9v6QyBPkhmqjWxl9yZU0W/I2/CwLW2LGNmHbH 4DrA== X-Gm-Message-State: AOAM530dfes/9h/tElNHO9oT1QkrVxggoAAutzBlM52HenJUMzkPqRPm 0Sm/4ulAcLSmFnu4mS0wvuq3HauBDEw= X-Google-Smtp-Source: ABdhPJyHsbFf+EH9ItsYl+BgL1VUszDxaKAtCuTyWv0tlQVgPpMhvXVRP0ykF9P9wQNkqSyzMEbix9lcVkw= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:e74d:b0:156:9d3c:4271 with SMTP id p13-20020a170902e74d00b001569d3c4271mr1691164plf.79.1650080580330; Fri, 15 Apr 2022 20:43:00 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 16 Apr 2022 03:42:48 +0000 In-Reply-To: <20220416034249.2609491-1-seanjc@google.com> Message-Id: <20220416034249.2609491-4-seanjc@google.com> Mime-Version: 1.0 References: <20220416034249.2609491-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH 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, Gaoning Pan , Yongkang Jia , Maxim Levitsky 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 Thu May 14 08:25:46 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 B38A0C433F5 for ; Sat, 16 Apr 2022 03:43:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230199AbiDPDpt (ORCPT ); Fri, 15 Apr 2022 23:45:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230216AbiDPDpc (ORCPT ); Fri, 15 Apr 2022 23:45:32 -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 745765716B for ; Fri, 15 Apr 2022 20:43:02 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id z5-20020a170902ccc500b0015716eaec65so5296976ple.14 for ; Fri, 15 Apr 2022 20:43:02 -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=SmCJkdJ/vwMUfGmNWazGZsDfEc6XkQHjevkhSXAb2Yk=; b=juavA14gxeDUNMBVNDFwrkIewI106flYCwM8f2DzoPuJXlSo9m/7dyuwNeKSJMVzOS ddxnzaXXP8NCtBJCESS6h1KWx0qRdJ7SBopKU0G8uJ6pskNvPqPkTdr8ZDuEjcgjYQ6O vw0jraBFoCDIp+jzX3mrtG0AoFKFq+QY0k5PJcuz6uPwWX/nHnG/aIP493gffDska3VE w4woJJschfQTOpgiNwHlb+jndJnMdU8kjyGd+x0kOgLm74fmqF6sAuLsry7T0aXdhxrK BfivIU3Mmz+ggBito4Ec+NNP5+ohaKNPcNm0+VZLSZXjbDhfKmiVtmxHBdD1I6cAnqkE 6F8g== 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=SmCJkdJ/vwMUfGmNWazGZsDfEc6XkQHjevkhSXAb2Yk=; b=L27OVHsxBteT6qNBWVz3wATFoPXWWcjFAnMNQnDXVtUC+xMlaor/oJGnqPbg2H0MNx rM82QmYItXo30ugXdINmq3PF2BUUliYlz1TjM7CJku4si4z1APYDAXlvkvNl7+GRFfM4 +TmZe8pDnnMvX6iF4JDy26gtdLaKUfiZIuzTBXtP7RpqqlHli3AlMcjbx0gxFhby8v3o 3aCCRzHH7W8uk/LnU59/h5U9XdVEVX/2ocQuh05v6GRAyVqjWzHCSwUe2uBZYaGJcpBV D9KhicNlZri3p3LcngnJiZMrKsHETh6KAjXRtFJHQYJizmruTd/mKrxXqvtqgqAn7zpb Dlpg== X-Gm-Message-State: AOAM530siQCi4GUr9OTh5jwTjV8SYHhwKs73LyRENXqHpwceir0RNcyC eeO8iOkq+Ok1SjNRg1N529QNlzZzAzM= X-Google-Smtp-Source: ABdhPJwp9G55Zfsk1+YnrNMGhIGmdzfZoZ2wR/fGJroCgp1Cvrv38rD0KsQLZIcG0uOnn2j0WI7n9Zqeoik= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:9b87:b0:156:bf3e:9ab5 with SMTP id y7-20020a1709029b8700b00156bf3e9ab5mr1733337plp.119.1650080581878; Fri, 15 Apr 2022 20:43:01 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 16 Apr 2022 03:42:49 +0000 In-Reply-To: <20220416034249.2609491-1-seanjc@google.com> Message-Id: <20220416034249.2609491-5-seanjc@google.com> Mime-Version: 1.0 References: <20220416034249.2609491-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.rc0.470.gd361397f0d-goog Subject: [PATCH 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, Gaoning Pan , Yongkang Jia , Maxim Levitsky 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