Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2918650pxb; Fri, 8 Oct 2021 19:16:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzacGHZDd20aJthJYGdfrIW46xV8t+CNUanXTx7tRPe9ktTtRdrNH8HTVlrh5OfyeCu5DWX X-Received: by 2002:a05:6402:1d52:: with SMTP id dz18mr8331720edb.49.1633745790762; Fri, 08 Oct 2021 19:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633745790; cv=none; d=google.com; s=arc-20160816; b=UJoxdX640Gaif3wBBpwMs4XRoyIm7zWVb29B6vDZQTt6RJ7MX566x9YhMLOKiSQywD 8hNNY3uXr8xUYW9jrU55AxQYrgUkfJoFD5EUC8fapHPTVANMmt33AUkJp544kONsjGOe RYVb+s0DrCce6O+/RissAbddWzJGwMB6AmSck4PBlTu7tGX/0/pHlVf8wVa29nE1g93Q tSlAjV3rAMjGiMUXkbr8DnSqUKuaXNuHflDLWAhpEsV1G10NehfsUf1yvZZAZwKjc/ht A609R8AU5BMMFw9fEcmPpEvT9nsuDRd7FTjqSzlnJ4dWcl3kcuKxuZy3BoOIEe6U9wWh pj3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:reply-to:dkim-signature; bh=qbaTmooIqpw2scwWIPvYnbgTG8gkipCw/gcnfpltSGY=; b=aFIleiQc2pk3tUQaZ5o2HtYwNQGAyIQU6g4lY9AP4RcODKd0sWtuHbZy85FE0+VBW3 S5nJM/PvjF3dFCRKBgZz2CqBpjA6+/guMfJTL5VW9AYEjkhtmTomipi7R/1xVvg1rW2V ujlyWDCS2y2P+EP3rE+KwQ29R3L+/y087jkVgiUd9MENFAYpDdxLshAIEvkVfrNZU2VR 5QX/oFS7I/TqIKZP9BTvW8AAusrOrzQlI5DTvOqFKdjpT5YEz4LZvAfu6ynCNnKYY+YX +/yoKANXtGZqrJZ5xUoxzDwHsC13Hv5uv9rDOaCiwfnzHNUQ3uQJyOqpd3rhihVJ2JD3 y08A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FuJT0BM9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb8si2384610edb.154.2021.10.08.19.16.07; Fri, 08 Oct 2021 19:16:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FuJT0BM9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244505AbhJICQN (ORCPT + 99 others); Fri, 8 Oct 2021 22:16:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244409AbhJICPt (ORCPT ); Fri, 8 Oct 2021 22:15:49 -0400 Received: from mail-qk1-x749.google.com (mail-qk1-x749.google.com [IPv6:2607:f8b0:4864:20::749]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BB80C06176E for ; Fri, 8 Oct 2021 19:13:26 -0700 (PDT) Received: by mail-qk1-x749.google.com with SMTP id m6-20020a05620a24c600b004338e8a5a3cso9785498qkn.10 for ; Fri, 08 Oct 2021 19:13:26 -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=qbaTmooIqpw2scwWIPvYnbgTG8gkipCw/gcnfpltSGY=; b=FuJT0BM9dDnYucltpEKN/3PIbfdvyXmexJqecK3YzG4d74UzCBAUJzNpfna5d3hhf9 CThoB+q3zbECmvBpsVwSPC65vqE3PC/pyRXG3MptW0vOaTjGmTNfFzi4I7G//ciy+nJL p2SrF4m156i96jaV+xzdhT+w6QkXcy0HHxtm4YS01i3rZ/GAWxIlxZ4cG090KNqUoG+F MZ7IfesCmYwBPSKodHNoD1ZFOQvtV8bnYcdLR84ii1K0oqwvG/i2DqC+H4C9C8AdNE7S NtI/ovPQV920bh3qJxqxqTJF2XHwSs9PcFYmvUBVFETjJlGAhfkCawm/pDGPWqba98m2 bBYQ== 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=qbaTmooIqpw2scwWIPvYnbgTG8gkipCw/gcnfpltSGY=; b=nUY37XebaoDIN80wD6z96DXuUzdh1zfFfyblSvipih1jUQOWyQrUPWIlpq233/X6Aw e6ePF9LTvfdGCp90TepsmreHgqcisN5FGSuknSvzUfq6JmE82YpFQzc24ac2x/sW71FQ Hklr8q2YAh6Z19hmrMmRcG5F4GG6z5sW5txDCc6vR6FoYUb6mztd35qTIAqqYT4aHeSf dMybGcnQXmgptkvNXTeJlNIikdWanNT0VZRBVJ1AHYCNvGA85HaCqz6kt5vYJa5j6x4c pu7OHWUPJel5w/jLRchtzALTZo+ILnAxefhmZUlNThzRK4B4tBjZWMSeZvukkLgRizaZ OCRQ== X-Gm-Message-State: AOAM533kyWGB5E6z01KMWbmX+wi7nxDeocd838maQp/Yng1jk0mgQhQ0 XnpkSjNsUIX/SoVWSUoV2oIwHgRszYY= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:90:200:e39b:6333:b001:cb]) (user=seanjc job=sendgmr) by 2002:ac8:4e11:: with SMTP id c17mr1903866qtw.400.1633745605808; Fri, 08 Oct 2021 19:13:25 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 8 Oct 2021 19:12:11 -0700 In-Reply-To: <20211009021236.4122790-1-seanjc@google.com> Message-Id: <20211009021236.4122790-19-seanjc@google.com> Mime-Version: 1.0 References: <20211009021236.4122790-1-seanjc@google.com> X-Mailer: git-send-email 2.33.0.882.g93a45727a2-goog Subject: [PATCH v2 18/43] KVM: x86: Invoke kvm_vcpu_block() directly for non-HALTED wait states From: Sean Christopherson To: Marc Zyngier , Huacai Chen , Aleksandar Markovic , Paul Mackerras , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Paolo Bonzini Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Atish Patra , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, David Matlack , Oliver Upton , Jing Zhang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Call kvm_vcpu_block() directly for all wait states except HALTED so that kvm_vcpu_halt() is no longer a misnomer on x86. Functionally, this means KVM will never attempt halt-polling or adjust vcpu->halt_poll_ns for INIT_RECEIVED (a.k.a. Wait-For-SIPI (WFS)) or AP_RESET_HOLD; UNINITIALIZED is handled in kvm_arch_vcpu_ioctl_run(), and x86 doesn't use any other "wait" states. As mentioned above, the motivation of this is purely so that "halt" isn't overloaded on x86, e.g. in KVM's stats. Skipping halt-polling for WFS (and RESET_HOLD) has no meaningful effect on guest performance as there are typically single-digit numbers of INIT-SIPI sequences per AP vCPU, per boot, versus thousands of HLTs just to boot to console. Reviewed-by: David Matlack Signed-off-by: Sean Christopherson --- arch/x86/kvm/x86.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index cd51f100e906..e0219acfd9cf 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9899,7 +9899,10 @@ static inline int vcpu_block(struct kvm *kvm, struct kvm_vcpu *vcpu) if (!kvm_arch_vcpu_runnable(vcpu) && (!kvm_x86_ops.pre_block || static_call(kvm_x86_pre_block)(vcpu) == 0)) { srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx); - kvm_vcpu_halt(vcpu); + if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED) + kvm_vcpu_halt(vcpu); + else + kvm_vcpu_block(vcpu); vcpu->srcu_idx = srcu_read_lock(&kvm->srcu); if (kvm_x86_ops.post_block) -- 2.33.0.882.g93a45727a2-goog