From nobody Sun May 12 15:43:16 2024 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 C74E9C53210 for ; Fri, 6 Jan 2023 01:13:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236837AbjAFBNj (ORCPT ); Thu, 5 Jan 2023 20:13:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236747AbjAFBNR (ORCPT ); Thu, 5 Jan 2023 20:13:17 -0500 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 6585B71FFF for ; Thu, 5 Jan 2023 17:13:16 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id z4-20020a17090ab10400b002195a146546so2085980pjq.9 for ; Thu, 05 Jan 2023 17:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=O/yK9t38GUx7xAC8BnI1OsbEu+wskTkGWc8pHxjCI1M=; b=XC1QRawbtqcuGIvkyZGXfO4dWvKusbHvx7Ceuk2s9f1EDWyGwTXKxmEF/7/RoIyTQl 83ZnpCeWlNJvN0EszGtRNrqExAEYtasediUZNG+ehmTQiMkhoIjKnQhWX+hIoogU83y5 xCHw6f+G8TqjvtBXoV0fhoUCuqOQwLxYgvCx9gO1Yv6C08Kbd4rG0qe2BBVTMw5geDsF YPuiC4gu1ZtesL5MNl+S7dkrBrISA94kw1YYFc7EnChdP1MFnbPrSXyA/2qtyEzjSHcX TfB3JBGQsJtAUeyHu6mN2XX8OUtEzSnJzI4Mv2SeSy55WQ4uXyfv6rzWDVYiIitmKYhS xNBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=O/yK9t38GUx7xAC8BnI1OsbEu+wskTkGWc8pHxjCI1M=; b=7/rzBzGPaR6a+u6jsRU4g0NWZhPtzBdclwvvwUHJVEfxHXsd/XC2o7Syhmd5nAyNJr hMSUpzIeDY2BtEOW3qnF1EfGnnFwlxRVkJhQNWG93VTRDAWdIkbsjVQUcKIJHAe/4/wh j/8iy0FZPSFoDQB9aI+6g5TgZXW9jIx2VtWGkHeZ2G1B2O6bkDP+18jYyus13NW8w5LP QE7QgjBSlTr3lnT8HdkMQplB0iC5b8HQHhuQs0od4S38rArOdQhbNso2Cq9QEvQdhUAY FNJ3f7sWeZ13TXWRlC7wkgvLm5EHq/G0osYx+clYyLSMJLVaX+wMOFbToOzahAWXByFO rDVA== X-Gm-Message-State: AFqh2kqyEbdWGvZYl6p8A6pHRQf4b9NmRx6pxmuJqQuFv6AGrlG752Ui 8GVjB9/BBb3+fZbIMv+5/6vgjKIHLwI= X-Google-Smtp-Source: AMrXdXsgyShRZdisFO/emIevEQAlXI6bCsWIdDxxcLZDMha/PDisLDjL6Hp3/hVg7Q3rpOuUTqoyPIwEZ98= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:40c8:b0:189:7a15:134b with SMTP id t8-20020a17090340c800b001897a15134bmr2814877pld.143.1672967595896; Thu, 05 Jan 2023 17:13:15 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:34 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-2-seanjc@google.com> Subject: [PATCH v5 01/33] KVM: x86: Blindly get current x2APIC reg value on "nodecode write" traps From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When emulating a x2APIC write in response to an APICv/AVIC trap, get the the written value from the vAPIC page without checking that reads are allowed for the target register. AVIC can generate trap-like VM-Exits on writes to EOI, and so KVM needs to get the written value from the backing page without running afoul of EOI's write-only behavior. Alternatively, EOI could be special cased to always write '0', e.g. so that the sanity check could be preserved, but x2APIC on AMD is actually supposed to disallow non-zero writes (not emulated by KVM), and the sanity check was a byproduct of how the KVM code was written, i.e. wasn't added to guard against anything in particular. Fixes: 70c8327c11c6 ("KVM: x86: Bug the VM if an accelerated x2APIC trap oc= curs on a "bad" reg") Fixes: 1bd9dfec9fd4 ("KVM: x86: Do not block APIC write for non ICR registe= rs") Reported-by: Alejandro Jimenez Cc: stable@vger.kernel.org Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 4efdb4a4d72c..5c0f93fc073a 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2284,23 +2284,18 @@ void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu,= u32 offset) struct kvm_lapic *apic =3D vcpu->arch.apic; u64 val; =20 - if (apic_x2apic_mode(apic)) { - if (KVM_BUG_ON(kvm_lapic_msr_read(apic, offset, &val), vcpu->kvm)) - return; - } else { - val =3D kvm_lapic_get_reg(apic, offset); - } - /* * ICR is a single 64-bit register when x2APIC is enabled. For legacy * xAPIC, ICR writes need to go down the common (slightly slower) path * to get the upper half from ICR2. */ if (apic_x2apic_mode(apic) && offset =3D=3D APIC_ICR) { + val =3D kvm_lapic_get_reg64(apic, APIC_ICR); kvm_apic_send_ipi(apic, (u32)val, (u32)(val >> 32)); trace_kvm_apic_write(APIC_ICR, val); } else { /* TODO: optimize to just emulate side effect w/o one more write */ + val =3D kvm_lapic_get_reg(apic, offset); kvm_lapic_reg_write(apic, offset, (u32)val); } } --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 B3DCDC3DA7A for ; Fri, 6 Jan 2023 01:13:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236789AbjAFBNq (ORCPT ); Thu, 5 Jan 2023 20:13:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236749AbjAFBNT (ORCPT ); Thu, 5 Jan 2023 20:13:19 -0500 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7197771FFF for ; Thu, 5 Jan 2023 17:13:18 -0800 (PST) Received: by mail-yb1-xb49.google.com with SMTP id e12-20020a25500c000000b007b48c520262so404740ybb.14 for ; Thu, 05 Jan 2023 17:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=U8maFLX/9emtR9Ry3/JNGkiRA36hfakt5AevFKMRuP8=; b=FDPrant3hMVGIRHqyuyr8ArImAU9GINekaycon8t2xlOdFMNVNZY2cfGp0nNw3dW54 1YV8Mw5cRxet3a+fCY7wJLIyCFO+s+iduPSgPyfflvb4tI3HdFebsvVT/RF4xz+4pSLV y7TOm5efaEc8M6aB8SfVAptefpHTx7ufHNShtJqwyMyfJpJahK5EL2U96+WqZ8FMIgVA kq1odA7Dq6Tu960vucowHuolVI4IKR8t0nCJ5A42s5tnCxEgJYQOG66ZPcBVtw3fOblC DAR7OoG1RW2vUBQAGf7wezgsWKDd2kS64Z/vT8wohB9aNZGcNQqnf2tO3CsF/v7HnCxc BPEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=U8maFLX/9emtR9Ry3/JNGkiRA36hfakt5AevFKMRuP8=; b=yd+RzVMa1EGEijy9r+xt5lKc/ISzB8ztoWkOt5WXzp7piRvrRnRssdlrwlRLeLIoqL msmqbxrssCTVNpFVlatjY2vqJwdvjr7sqZPYYuYK0+mnCSK9B66nWBvqQOoS/jvdtIEB dHgu1i0CA0fiRdwhad2VazilXlo0jbo1N+TT+r70MrhfAxzWVRH95Q1vqzIQFne1PiCL 2bEJKF/HdYRTw7Tefa/cRHN0RwQLiOsIxMIQE7EZJgzCWrFBCXBQIY83j+hXlBrx9hOT nmRpTxw+JOkC8XmSQ+2oFnhh9t0VVJWw6ChxSf+SvoFKmf9BY+Nwis4z5fqXvLQ9DvII g9vA== X-Gm-Message-State: AFqh2kqClANCOTa1HgPrxeRnaTnUJk0ic8YNYekCWCUHTUeiMoCThwEz YFG+XGcGremlKW32x4T8850C/3dMPRs= X-Google-Smtp-Source: AMrXdXso30EpQBw9HhKbz+QwLBHZavS/RwMyrHm/n9ZeG7jc3GA9k1RcV7YYQFH5iQsm0LWp8nlFePh6Z1E= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:a087:0:b0:700:a7b4:1af9 with SMTP id y7-20020a25a087000000b00700a7b41af9mr3497734ybh.227.1672967597770; Thu, 05 Jan 2023 17:13:17 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:35 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-3-seanjc@google.com> Subject: [PATCH v5 02/33] KVM: x86: Purge "highest ISR" cache when updating APICv state From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Purge the "highest ISR" cache when updating APICv state on a vCPU. The cache must not be used when APICv is active as hardware may emulate EOIs (and other operations) without exiting to KVM. This fixes a bug where KVM will effectively block IRQs in perpetuity due to the "highest ISR" never getting reset if APICv is activated on a vCPU while an IRQ is in-service. Hardware emulates the EOI and KVM never gets a chance to update its cache. Fixes: b26a695a1d78 ("kvm: lapic: Introduce APICv update helper function") Cc: stable@vger.kernel.org Cc: Suravee Suthikulpanit Cc: Maxim Levitsky Reviewed-by: Paolo Bonzini Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 5c0f93fc073a..33a661d82da7 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2424,6 +2424,7 @@ void kvm_apic_update_apicv(struct kvm_vcpu *vcpu) */ apic->isr_count =3D count_vectors(apic->regs + APIC_ISR); } + apic->highest_isr_cache =3D -1; } =20 void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) @@ -2479,7 +2480,6 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init= _event) kvm_lapic_set_reg(apic, APIC_TMR + 0x10 * i, 0); } kvm_apic_update_apicv(vcpu); - apic->highest_isr_cache =3D -1; update_divide_count(apic); atomic_set(&apic->lapic_timer.pending, 0); =20 @@ -2767,7 +2767,6 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct = kvm_lapic_state *s) __start_apic_timer(apic, APIC_TMCCT); kvm_lapic_set_reg(apic, APIC_TMCCT, 0); kvm_apic_update_apicv(vcpu); - apic->highest_isr_cache =3D -1; if (apic->apicv_active) { static_call_cond(kvm_x86_apicv_post_state_restore)(vcpu); static_call_cond(kvm_x86_hwapic_irr_update)(vcpu, apic_find_highest_irr(= apic)); --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 D83F1C3DA7A for ; Fri, 6 Jan 2023 01:13:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236777AbjAFBNu (ORCPT ); Thu, 5 Jan 2023 20:13:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236751AbjAFBNV (ORCPT ); Thu, 5 Jan 2023 20:13:21 -0500 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A838571FC2 for ; Thu, 5 Jan 2023 17:13:20 -0800 (PST) Received: by mail-pf1-x449.google.com with SMTP id ca10-20020a056a00418a00b00581dff62bb7so44734pfb.13 for ; Thu, 05 Jan 2023 17:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=u78lWz0VYuMoumoWecLZd2qogPK5CLyQBtm8aEankL8=; b=r72UhPty8x9ytF8Iu0v50uaCclT3TpYbGwsVR9/P8cMx301hLhNCR327Vpg9/8+MKB FZwWPgFTEkCRezgF/NvAylGFY+ZVbioXnCFi5a4Do3aPoA4V1Ftp++44CtX/vg1fIbDY 7F/lyInJV2zTpqirwvtfT9mgRfECdomLHhkVgaa+1zZ2tyWa40y6t/mkrAV6nmFDIBA9 1ZxO8XSBX6fp+ikrFwNcH9mdoqlMFc3kBeyaFkjOK1H3LRw7sw+QMGDSC/6IPCJksiBe ZDtQJmFGPZ2SZEK3y584t36Qvgyw61f4Uv0vX2ffYYxcMdxJEMAIGxxQy4Li2OlOCX5j lHGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=u78lWz0VYuMoumoWecLZd2qogPK5CLyQBtm8aEankL8=; b=LoLr8fB7nLR8oyLSs1hv/JP0W39jFTonpyReB1cSEMph0uRv3Xlj8Ys5OKJ0z2ooeS nGQ8f82dmXHLqlL6GcKNlTGfb84qCIPjqGv3QSC6PlLaP/i5zW/VNpmG49xySrf3nn4z cy9VLxBZpaPEqCQhzp4aLIEhUoMMj/L13hCoxFMam8ycptV/9VAUWpPBIa0ixAavEdyH VRldN6AagUKst/24QaH9t33nVbxcJeaOlfSLoHu3QgfbKmnxih0oBREpfzfDEFzUu28r 4aIxyg4bn8gLgnPllJ6T3k59bQ9VrvlpfhtEnQ6KBVsvk9IxmzUw5wKHOIcgUCWRo3UC me1Q== X-Gm-Message-State: AFqh2kofwVOaP1eNqdH7+jT6pvE2PU+O9nsl/mQI6e+8lSXyIFNRm04q A/QAPtEy/QciVa50M3ruf2T0/NT+SFU= X-Google-Smtp-Source: AMrXdXsJfjaK96Xi6oTG2qgtI86m5NvdBb68nC9Wz65W4q7Uep1k89PqXLVg7qLeQygr32NJ4hzYoqEDR1k= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:378f:b0:219:a032:1760 with SMTP id mz15-20020a17090b378f00b00219a0321760mr3216899pjb.88.1672967599607; Thu, 05 Jan 2023 17:13:19 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:36 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-4-seanjc@google.com> Subject: [PATCH v5 03/33] KVM: SVM: Flush the "current" TLB when activating AVIC From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Flush the TLB when activating AVIC as the CPU can insert into the TLB while AVIC is "locally" disabled. KVM doesn't treat "APIC hardware disabled" as VM-wide AVIC inhibition, and so when a vCPU has its APIC hardware disabled, AVIC is not guaranteed to be inhibited. As a result, KVM may create a valid NPT mapping for the APIC base, which the CPU can cache as a non-AVIC translation. Note, Intel handles this in vmx_set_virtual_apic_mode(). Reviewed-by: Paolo Bonzini Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 6919dee69f18..712330b80891 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -86,6 +86,12 @@ static void avic_activate_vmcb(struct vcpu_svm *svm) /* Disabling MSR intercept for x2APIC registers */ svm_set_x2apic_msr_interception(svm, false); } else { + /* + * Flush the TLB, the guest may have inserted a non-APIC + * mapping into the TLB while AVIC was disabled. + */ + kvm_make_request(KVM_REQ_TLB_FLUSH_CURRENT, &svm->vcpu); + /* For xAVIC and hybrid-xAVIC modes */ vmcb->control.avic_physical_id |=3D AVIC_MAX_PHYSICAL_ID; /* Enabling MSR intercept for x2APIC registers */ --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 175D0C3DA7A for ; Fri, 6 Jan 2023 01:13:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236725AbjAFBN4 (ORCPT ); Thu, 5 Jan 2023 20:13:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236762AbjAFBNX (ORCPT ); Thu, 5 Jan 2023 20:13:23 -0500 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 8A80271FC2 for ; Thu, 5 Jan 2023 17:13:22 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id a11-20020a17090acb8b00b00226d4edae5dso50530pju.2 for ; Thu, 05 Jan 2023 17:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=CYYJmfZ9mNFDGGWa3J2yKpONItWzTZPphAVz+Kbcn3U=; b=KX8XYL9rvgWNlKIscy8mzK0MqUP7L1Eptt11dNZ8Y2gjLSZ2roViegLOvfCmQkXRpm tml1DSPvp1xePvkNESZNRVZ+J0GMlShsFDneY4BlLYyDCUG7XQ5iL1F274CUEEJ1tgKa V8Bmg8gNqLoK/+hlNaN6q/SnxniCnTNq0p+Jzh4HM0ZtHbTvl0U7KvUjA+LpZaAMvbN9 KL/0k8zHeUTiHCcLolVAs7suPaPLUxTiylIKf+h45lufC9nHXuCUKBe9dKVFeUb2gCMK /5yjguwvs7UF6e3mk61i5V/mB5cMIaUnGPfbiZ0dtfjJbOjkt38R2pXpIRo8BAsY9uSA Pe5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=CYYJmfZ9mNFDGGWa3J2yKpONItWzTZPphAVz+Kbcn3U=; b=miVRCUfDAEXE5Wu7IyRwZGHJGBh3f37opFJzp40W/4N3ZH9+CHDPvk9fdakyE/d01f D8CVU4HlFfIwwaqCpVjUUm1KDpk9TZfaUizmfpDTcVsG5Qa52r8s4TkGHQe83clSSa1A P5dTNaooPvnOnOsSKP321IQIbfu3pvTYoa4ms9rpKAkizL8qB3dfhNDQl0LXGqUIZYmB ywJJD7e8ukMa3/6YG7xKnXkZmRgxzPH5ZoKem3SHAHCUSqe15gLCcLDiQNiQ+xMHiuCH Kg58YcIQ21JAdmHhApgdf1zxNNMkDw76w0zxWjuiJRoPB/lL0hn6WUwgjI8YEPUYWtH1 NHkw== X-Gm-Message-State: AFqh2krmCYt0ma6DliLROj8+uPSzDIkvuYI7mRbwCH979KK+ZuvVtyzD XJI/UudbyrF4nr9AhUQhT0rlHUTbXPU= X-Google-Smtp-Source: AMrXdXvZ54jo+YAhl8/uutr0jDuCzf8Ba0wnCowq+Ef3JUXXTxNdYHfjXThpH2Aq33jmQUew7tLvxV7jLNI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:b207:b0:189:5ba2:4907 with SMTP id t7-20020a170902b20700b001895ba24907mr3964708plr.113.1672967602066; Thu, 05 Jan 2023 17:13:22 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:37 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-5-seanjc@google.com> Subject: [PATCH v5 04/33] KVM: SVM: Process ICR on AVIC IPI delivery failure due to invalid target From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Emulate ICR writes on AVIC IPI failures due to invalid targets using the same logic as failures due to invalid types. AVIC acceleration fails if _any_ of the targets are invalid, and crucially VM-Exits before sending IPIs to targets that _are_ valid. In logical mode, the destination is a bitmap, i.e. a single IPI can target multiple logical IDs. Doing nothing causes KVM to drop IPIs if at least one target is valid and at least one target is invalid. Fixes: 18f40c53e10f ("svm: Add VMEXIT handlers for AVIC") Cc: stable@vger.kernel.org Reviewed-by: Paolo Bonzini Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 712330b80891..3b2c88b168ba 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -502,14 +502,18 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu = *vcpu) trace_kvm_avic_incomplete_ipi(vcpu->vcpu_id, icrh, icrl, id, index); =20 switch (id) { + case AVIC_IPI_FAILURE_INVALID_TARGET: case AVIC_IPI_FAILURE_INVALID_INT_TYPE: /* * Emulate IPIs that are not handled by AVIC hardware, which - * only virtualizes Fixed, Edge-Triggered INTRs. The exit is - * a trap, e.g. ICR holds the correct value and RIP has been - * advanced, KVM is responsible only for emulating the IPI. - * Sadly, hardware may sometimes leave the BUSY flag set, in - * which case KVM needs to emulate the ICR write as well in + * only virtualizes Fixed, Edge-Triggered INTRs, and falls over + * if _any_ targets are invalid, e.g. if the logical mode mask + * is a superset of running vCPUs. + * + * The exit is a trap, e.g. ICR holds the correct value and RIP + * has been advanced, KVM is responsible only for emulating the + * IPI. Sadly, hardware may sometimes leave the BUSY flag set, + * in which case KVM needs to emulate the ICR write as well in * order to clear the BUSY flag. */ if (icrl & APIC_ICR_BUSY) @@ -525,8 +529,6 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu *v= cpu) */ avic_kick_target_vcpus(vcpu->kvm, apic, icrl, icrh, index); break; - case AVIC_IPI_FAILURE_INVALID_TARGET: - break; case AVIC_IPI_FAILURE_INVALID_BACKING_PAGE: WARN_ONCE(1, "Invalid backing page\n"); break; --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 5648AC3DA7A for ; Fri, 6 Jan 2023 01:14:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234596AbjAFBOF (ORCPT ); Thu, 5 Jan 2023 20:14:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236642AbjAFBNZ (ORCPT ); Thu, 5 Jan 2023 20:13:25 -0500 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 48F5F71FF6 for ; Thu, 5 Jan 2023 17:13:24 -0800 (PST) Received: by mail-pg1-x549.google.com with SMTP id d10-20020a631d4a000000b00491da16dc44so198549pgm.16 for ; Thu, 05 Jan 2023 17:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=skmNHPbTYLwyxoraHBJpLpuS512+i4UR+d4KzIFrXzo=; b=eHspZ09DmK7JKDuAkYFgw2Tmeu1pkc8IkPzAYI2GCsgpOY4NyVmsDEUKctJkeXrE5G LzYk2RkJgeauHLVZqTm7drTchkyldaitSOOoRqSr/yjfeEX5NiuSamVpMc+U2c7qLwm0 DngxD2loLWSr9XkOBdkVspM0ynT+X312xS8jTpu12DQVxNUrLf2h1jHb9Cj7PvkPYJq9 PhfxFoez2ibzGpvO7NqkRNK/0zsGH8c+GZf2gzf2Gb5NhhqUfFIKjJIioj3koUdYLD1X CU1kGCr00qZon5e991QguAtr2xKfe87a1tWqbR3kLl7vIweiPI7nyLBf2MzZ7dQo82LK Tm4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=skmNHPbTYLwyxoraHBJpLpuS512+i4UR+d4KzIFrXzo=; b=ghda/v9xypluNcHAcY1xjwPKWv/Eyvmh2G0yXbT2TTQXVhiCMHzBDptGkLkRECjMiy wHvB4LC8k/3PoBA+A+lIqSzqjznPdw8XEtGluyxka3hIiknbhsqnCctz9A0G6qscDj6T YrkVvdPgRMbE7DJ/sIRTbEeRJzzfJlCALH3yPjL+Xv/bSthPwCPEQsM8EoDKXj83nqpj beDlTgysCpV72do3CRCESZgYc9ExkbQmbB7729gJBSF891khIrUgV/tgSp5b2lCgcuS8 8MOPNy3Us/Oizorz9zwQQUcIsjI/HK6uUR0UBxnKXCSkfQlPCN6fRtTM304/y6vhhm+1 g8cw== X-Gm-Message-State: AFqh2koJwcVDwmD7MrAo0KChFFcNPBsbjb8ZqckAGkgFLSkTYu2MrT+Z lnn3HT5UjTPQsgFZzRDeutA7trftnDw= X-Google-Smtp-Source: AMrXdXvwxPom+8pP9fNt6a6nAoWVR8+muMZ9FIRFEqS1HHzsnhrSJPf0g6plar5raO5p9grs5bFtPDq/NHI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:3c81:b0:219:dbed:ade9 with SMTP id pv1-20020a17090b3c8100b00219dbedade9mr4575858pjb.125.1672967603847; Thu, 05 Jan 2023 17:13:23 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:38 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-6-seanjc@google.com> Subject: [PATCH v5 05/33] KVM: x86: Don't inhibit APICv/AVIC on xAPIC ID "change" if APIC is disabled From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Don't inhibit APICv/AVIC due to an xAPIC ID mismatch if the APIC is hardware disabled. The ID cannot be consumed while the APIC is disabled, and the ID is guaranteed to be set back to the vcpu_id when the APIC is hardware enabled (architectural behavior correctly emulated by KVM). Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or= APIC base") Cc: stable@vger.kernel.org Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 33a661d82da7..191b5a962700 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2072,6 +2072,9 @@ static void kvm_lapic_xapic_id_updated(struct kvm_lap= ic *apic) { struct kvm *kvm =3D apic->vcpu->kvm; =20 + if (!kvm_apic_hw_enabled(apic)) + return; + if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) return; =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 25886C3DA7A for ; Fri, 6 Jan 2023 01:14:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236823AbjAFBOA (ORCPT ); Thu, 5 Jan 2023 20:14:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236660AbjAFBN0 (ORCPT ); Thu, 5 Jan 2023 20:13:26 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99B1971FF5 for ; Thu, 5 Jan 2023 17:13:25 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-46658ec0cfcso2656287b3.19 for ; Thu, 05 Jan 2023 17:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=TSmJoHpGEg4kYZow7Hfuz8WMYi0D8WbHpbMSfsD+jaY=; b=svIrwG0BQCeHJr9kAw3C+ZqzVl4Z8noxUTH4Nm3fxagfr95d0yzpFEtYY0HeWbhhKa Mj7UpQwZ7gK6e4mFFGwm0yRoGFdQDHTTjKT6l5xTDNF8OFTJh2qF4SspR394jOniGrm7 VB61W1PzyR7BbjmWZILBvd/PVnnDPQhcIb6iUkb+AW8JAjkUmWmRfBYZ1Q8StJ44SPZ5 LDv7eYcCPaniI5y9ttvrcjEwaToRELdufqVSRdy9bWT89upLDk1TBMAJzDoeGg2Mx5WW EFeJq5rozALDwYstow/5AByuY7f51vDJ08FP07o3mQkp1a2xtOeuAxfqH1LPWOQly+pZ b+eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=TSmJoHpGEg4kYZow7Hfuz8WMYi0D8WbHpbMSfsD+jaY=; b=jwmPhw9iDypZn1fOziSXDNFxg62mv3eBp0uTRkzu3SOQLyfbKhk4Bzf6yp4JLkyY2B S7kKZ2ltW0iUXtGcrPr/SrxxISO93gmu1Mjd2sKympT4aflMcRg0/1JeOObOSvSeIa7M HTccHwyQdYt6Z/euQH3iSSeWdUvHlJBizvp0sZhGig4BSqCPhtRBcpEGFijetfHwhLOx ThB7/EPPMXEf73JO+biyw89X6L5coR6u3iKHFeMjk846TrrsiBQwUjPLnf/j2Of+ggtf ncPK4hublW92enkMgLBC/TOUKD9fVknnjuGzE9p989SsEEBCEvuNd4oFoTa/D7dX6FwG VNVg== X-Gm-Message-State: AFqh2krbwI0ZTgPknDVOZ2I2wf14nyYi3lSY+XFIUaI/NC3xQz6rbSCk KjVEHG5pz9XSySGpctqhiW/hbpsZR34= X-Google-Smtp-Source: AMrXdXvRb8GUwaflHjmzqoT+l70tuGqw2W20zoxljhq4Dl3XelKFi0JCTXs13kako0Te+i2vI/4z9Eyl5lw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a0d:c2c1:0:b0:4ad:5c08:7e67 with SMTP id e184-20020a0dc2c1000000b004ad5c087e67mr1617563ywd.75.1672967605381; Thu, 05 Jan 2023 17:13:25 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:39 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-7-seanjc@google.com> Subject: [PATCH v5 06/33] KVM: x86: Don't inhibit APICv/AVIC if xAPIC ID mismatch is due to 32-bit ID From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Truncate the vcpu_id, a.k.a. x2APIC ID, to an 8-bit value when comparing it against the xAPIC ID to avoid false positives (sort of) on systems with >255 CPUs, i.e. with IDs that don't fit into a u8. The intent of APIC_ID_MODIFIED is to inhibit APICv/AVIC when the xAPIC is changed from it's original value, The mismatch isn't technically a false positive, as architecturally the xAPIC IDs do end up being aliased in this scenario, and neither APICv nor AVIC correctly handles IPI virtualization when there is aliasing. However, KVM already deliberately does not honor the aliasing behavior that results when an x2APIC ID gets truncated to an xAPIC ID. I.e. the resulting APICv/AVIC behavior is aligned with KVM's existing behavior when KVM's x2APIC hotplug hack is effectively enabled. If/when KVM provides a way to disable the hotplug hack, APICv/AVIC can piggyback whatever logic disables the optimized APIC map (which is what provides the hotplug hack), i.e. so that KVM's optimized map and APIC virtualization yield the same behavior. For now, fix the immediate problem of APIC virtualization being disabled for large VMs, which is a much more pressing issue than ensuring KVM honors architectural behavior for APIC ID aliasing. Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or= APIC base") Reported-by: Suravee Suthikulpanit Cc: stable@vger.kernel.org Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 191b5a962700..2183a9b8efa5 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2078,7 +2078,12 @@ static void kvm_lapic_xapic_id_updated(struct kvm_la= pic *apic) if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) return; =20 - if (kvm_xapic_id(apic) =3D=3D apic->vcpu->vcpu_id) + /* + * Deliberately truncate the vCPU ID when detecting a modified APIC ID + * to avoid false positives if the vCPU ID, i.e. x2APIC ID, is a 32-bit + * value. + */ + if (kvm_xapic_id(apic) =3D=3D (u8)apic->vcpu->vcpu_id) return; =20 kvm_set_apicv_inhibit(apic->vcpu->kvm, APICV_INHIBIT_REASON_APIC_ID_MODIF= IED); --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 1A01CC3DA7A for ; Fri, 6 Jan 2023 01:14:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236089AbjAFBOJ (ORCPT ); Thu, 5 Jan 2023 20:14:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236708AbjAFBN2 (ORCPT ); Thu, 5 Jan 2023 20:13:28 -0500 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 4BA0F71FFF for ; Thu, 5 Jan 2023 17:13:27 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id r17-20020a17090aa09100b0021903e75f14so35032pjp.9 for ; Thu, 05 Jan 2023 17:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=mau3/kl+h/eXbbhdIv+Q9nrr9eoqBg2GeLPH+58IXTM=; b=MuWW2qpJuc98zl/fk2bBGCoFbQUn8ySbzjYk2e+aQt/pYvBHlalQf9JAEiYDfakLuC FPDKX6vcfTIEvyBDDFD3eqeJCy8L/kjshK79uiq9izQdHi4QTYdjVALwTSrPX5c31maW 6ocE9I3gWdUjBMlcCvPCCehjYDH8PfRDlnC3AofHAR1hg/KVKRDJgdXM/T8H/cjfLdYI soK+Cv8sVX/0oHlmt5ip06ahzTp52VL997D/yMr7mqIpFZsF/biOBOinhjpbNOMu3DWw ouGZbYzHIRGScKW38SoFVYKCoYqBQh4nxrCJtVpfWPOuPmbDZ8vAawybfCn0EVWkI2gu W3OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=mau3/kl+h/eXbbhdIv+Q9nrr9eoqBg2GeLPH+58IXTM=; b=VeZv2kUOqc8ulfTtP5DLweRKTDr6UwZqk1pKd82D2V66zTAheMgyztYhoEVrq9uOEo hp9IqPQsQItyxflYPe+e3/4jMGuR+KZTo6chmt8vCmzIQBfDko5fydzomLiYtlz8XIQx +4ugz8jRsfwTQzau9846dXg8iokOm9zr7TjbOJulC5gOUgahaY6XmarQtwAyK+6W8cGT Av6tCNKXLmvSMbAzBsijvjVSlxekfW4dDiqVeckIEzPiB9/bX9iPuikrwmwuhX/aZsKi oypvy+LeJxl+VxHewsZ2aYaRBRNHHKkSc6Sd7D4ukwE4Plwh8g3zf+0IT4y/ZY65eWYX dLWQ== X-Gm-Message-State: AFqh2kqQe42ZjDYnZmY0sy4IcHuoHils7qq+kBgElYni5ikjD4eXCRV4 AFYbq+tny1wN4ImrHnn1JAB0GUCjz8A= X-Google-Smtp-Source: AMrXdXu5+eh7HONlGDZZe4RoW4xraPHwRpONNf2PrW0NUv4OdKawja0IC5LIJvg9IriXZVRGFdUBQK+5VzQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:fa49:b0:226:ce49:3df6 with SMTP id dt9-20020a17090afa4900b00226ce493df6mr249539pjb.61.1672967606965; Thu, 05 Jan 2023 17:13:26 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:40 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-8-seanjc@google.com> Subject: [PATCH v5 07/33] KVM: SVM: Don't put/load AVIC when setting virtual APIC mode From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the VMCB updates from avic_refresh_apicv_exec_ctrl() into avic_set_virtual_apic_mode() and invert the dependency being said functions to avoid calling avic_vcpu_{load,put}() and avic_set_pi_irte_mode() when "only" setting the virtual APIC mode. avic_set_virtual_apic_mode() is invoked from common x86 with preemption enabled, which makes avic_vcpu_{load,put}() unhappy. Luckily, calling those and updating IRTE stuff is unnecessary as the only reason avic_set_virtual_apic_mode() is called is to handle transitions between xAPIC and x2APIC that don't also toggle APICv activation. And if activation doesn't change, there's no need to fiddle with the physical APIC ID table or update IRTE. The "full" refresh is guaranteed to be called if activation changes in this case as the only call to the "set" path is: kvm_vcpu_update_apicv(vcpu); static_call_cond(kvm_x86_set_virtual_apic_mode)(vcpu); and kvm_vcpu_update_apicv() invokes the refresh if activation changes: if (apic->apicv_active =3D=3D activate) goto out; apic->apicv_active =3D activate; kvm_apic_update_apicv(vcpu); static_call(kvm_x86_refresh_apicv_exec_ctrl)(vcpu); Rename the helper to reflect that it is also called during "refresh". WARNING: CPU: 183 PID: 49186 at arch/x86/kvm/svm/avic.c:1081 avic_vcpu_pu= t+0xde/0xf0 [kvm_amd] CPU: 183 PID: 49186 Comm: stable Tainted: G O 6.0.0-smp--= fcddbca45f0a-sink #34 Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/= 27/2022 RIP: 0010:avic_vcpu_put+0xde/0xf0 [kvm_amd] avic_refresh_apicv_exec_ctrl+0x142/0x1c0 [kvm_amd] avic_set_virtual_apic_mode+0x5a/0x70 [kvm_amd] kvm_lapic_set_base+0x149/0x1a0 [kvm] kvm_set_apic_base+0x8f/0xd0 [kvm] kvm_set_msr_common+0xa3a/0xdc0 [kvm] svm_set_msr+0x364/0x6b0 [kvm_amd] __kvm_set_msr+0xb8/0x1c0 [kvm] kvm_emulate_wrmsr+0x58/0x1d0 [kvm] msr_interception+0x1c/0x30 [kvm_amd] svm_invoke_exit_handler+0x31/0x100 [kvm_amd] svm_handle_exit+0xfc/0x160 [kvm_amd] vcpu_enter_guest+0x21bb/0x23e0 [kvm] vcpu_run+0x92/0x450 [kvm] kvm_arch_vcpu_ioctl_run+0x43e/0x6e0 [kvm] kvm_vcpu_ioctl+0x559/0x620 [kvm] Fixes: 05c4fe8c1bd9 ("KVM: SVM: Refresh AVIC configuration when changing AP= IC mode") Cc: stable@vger.kernel.org Cc: Suravee Suthikulpanit Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 31 +++++++++++++++---------------- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/svm.h | 2 +- 3 files changed, 17 insertions(+), 18 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 3b2c88b168ba..97ad0661f963 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -747,18 +747,6 @@ void avic_apicv_post_state_restore(struct kvm_vcpu *vc= pu) avic_handle_ldr_update(vcpu); } =20 -void avic_set_virtual_apic_mode(struct kvm_vcpu *vcpu) -{ - if (!lapic_in_kernel(vcpu) || avic_mode =3D=3D AVIC_MODE_NONE) - return; - - if (kvm_get_apic_mode(vcpu) =3D=3D LAPIC_MODE_INVALID) { - WARN_ONCE(true, "Invalid local APIC state (vcpu_id=3D%d)", vcpu->vcpu_id= ); - return; - } - avic_refresh_apicv_exec_ctrl(vcpu); -} - static int avic_set_pi_irte_mode(struct kvm_vcpu *vcpu, bool activate) { int ret =3D 0; @@ -1100,17 +1088,18 @@ void avic_vcpu_put(struct kvm_vcpu *vcpu) WRITE_ONCE(*(svm->avic_physical_id_cache), entry); } =20 - -void avic_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu) +void avic_refresh_virtual_apic_mode(struct kvm_vcpu *vcpu) { struct vcpu_svm *svm =3D to_svm(vcpu); struct vmcb *vmcb =3D svm->vmcb01.ptr; - bool activated =3D kvm_vcpu_apicv_active(vcpu); + + if (!lapic_in_kernel(vcpu) || avic_mode =3D=3D AVIC_MODE_NONE) + return; =20 if (!enable_apicv) return; =20 - if (activated) { + if (kvm_vcpu_apicv_active(vcpu)) { /** * During AVIC temporary deactivation, guest could update * APIC ID, DFR and LDR registers, which would not be trapped @@ -1124,6 +1113,16 @@ void avic_refresh_apicv_exec_ctrl(struct kvm_vcpu *v= cpu) avic_deactivate_vmcb(svm); } vmcb_mark_dirty(vmcb, VMCB_AVIC); +} + +void avic_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu) +{ + bool activated =3D kvm_vcpu_apicv_active(vcpu); + + if (!enable_apicv) + return; + + avic_refresh_virtual_apic_mode(vcpu); =20 if (activated) avic_vcpu_load(vcpu, vcpu->cpu); diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 6ffadbd57744..26044e1d2422 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4771,7 +4771,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata =3D { .enable_nmi_window =3D svm_enable_nmi_window, .enable_irq_window =3D svm_enable_irq_window, .update_cr8_intercept =3D svm_update_cr8_intercept, - .set_virtual_apic_mode =3D avic_set_virtual_apic_mode, + .set_virtual_apic_mode =3D avic_refresh_virtual_apic_mode, .refresh_apicv_exec_ctrl =3D avic_refresh_apicv_exec_ctrl, .check_apicv_inhibit_reasons =3D avic_check_apicv_inhibit_reasons, .apicv_post_state_restore =3D avic_apicv_post_state_restore, diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 4826e6cc611b..d0ed3f595229 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -648,7 +648,7 @@ void avic_vcpu_blocking(struct kvm_vcpu *vcpu); void avic_vcpu_unblocking(struct kvm_vcpu *vcpu); void avic_ring_doorbell(struct kvm_vcpu *vcpu); unsigned long avic_vcpu_get_apicv_inhibit_reasons(struct kvm_vcpu *vcpu); -void avic_set_virtual_apic_mode(struct kvm_vcpu *vcpu); +void avic_refresh_virtual_apic_mode(struct kvm_vcpu *vcpu); =20 =20 /* sev.c */ --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 34190C3DA7A for ; Fri, 6 Jan 2023 01:14:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235836AbjAFBON (ORCPT ); Thu, 5 Jan 2023 20:14:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236738AbjAFBN3 (ORCPT ); Thu, 5 Jan 2023 20:13:29 -0500 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 EAB6371FC2 for ; Thu, 5 Jan 2023 17:13:28 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id g32-20020a635660000000b00478c21b8095so208173pgm.10 for ; Thu, 05 Jan 2023 17:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=vMUnRQfVbAJv33RqxFDNJJJTw+ranbI7U0SAs08XATU=; b=G0S4DPyFrd2Oopyroqh9Cz+8c5WqAKldFy75kkimMEIxV5yGuhY63/jc5SSl8Gm6ow h5k5dfPgQ6cySfnnFTdy3suRsCkubzhnft2Qb4DNgZ1K1z0/K4m86z1Olk1zTNEn+vcb Vvlp7boDP/jU4GYiHSbAB3/mC9kpQZp+L4sF80R2yV45vQnY3+3593a/0icBu71baSWr d2cGicwM/cN95qmenJDi+9o+Y3+/tOjD9WduMIyXiwssF32BUmqVMegBR+dcwcb7po3U 7ZqHfbVAX+YJKOPNoAaqKvi7dAO1uVxczzvvi+hh2CIBiLRoQ6u1fALpCpM1WolSrWs9 1Ntw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=vMUnRQfVbAJv33RqxFDNJJJTw+ranbI7U0SAs08XATU=; b=Y1tNan+K5930J1K4liXQeGJUmOncEz7txTs+wdQm9R+thv2Es2FgaHJY0vh2TvUopG +bgGzpK4sJmuqympl38SxMJ/ddjik5ESkQ9a8WxeO+pVnKOhM+7ZgIRu6j0dgfHw4McP xawzTapsEK65s25Ue5a68IMCIQEDaBlI8X92fflYRJjKcyATMItygMSdyieXmJwF623C edFK7d+U/l8nLhqo/60acYmy1nLRlICDTXNFDMrUL3kWQ3xYLj9QwTWQSOi5Wz2FbXCp lL6PPzd1nXiN34W3msEvxtePZ8Vdbkiv3aDHruUmcgh3j0nStRK70vVa2Y6yGs26hS5Q AWjQ== X-Gm-Message-State: AFqh2kqya7CKyvu2Z05YwjsPsc2nKeb7WedE7FtxWis9y8j+5mzWj4K6 YSp+7NSGB5Kaf+Njm3BlsKFkw/7G5Uk= X-Google-Smtp-Source: AMrXdXuudHup8qpImaQf0/5abeg0Y+xEfxUzUer6fZO+gAvhbkcBPXjm11rIZkOPqnYsqI6yl/Ume75/0NA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:2451:b0:580:9b0b:4fde with SMTP id d17-20020a056a00245100b005809b0b4fdemr3392591pfj.49.1672967608513; Thu, 05 Jan 2023 17:13:28 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:41 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-9-seanjc@google.com> Subject: [PATCH v5 08/33] KVM: x86: Handle APICv updates for APIC "mode" changes via request From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use KVM_REQ_UPDATE_APICV to react to APIC "mode" changes, i.e. to handle the APIC being hardware enabled/disabled and/or x2APIC being toggled. There is no need to immediately update APICv state, the only requirement is that APICv be updating prior to the next VM-Enter. Making a request will allow piggybacking KVM_REQ_UPDATE_APICV to "inhibit" the APICv memslot when x2APIC is enabled. Doing that directly from kvm_lapic_set_base() isn't feasible as KVM's SRCU must not be held when modifying memslots (to avoid deadlock), and may or may not be held when kvm_lapic_set_base() is called, i.e. KVM can't do the right thing without tracking that is rightly buried behind CONFIG_PROVE_RCU=3Dy. Suggested-by: Maxim Levitsky Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 2183a9b8efa5..3ed74ad60516 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2401,7 +2401,7 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 va= lue) kvm_apic_set_x2apic_id(apic, vcpu->vcpu_id); =20 if ((old_value ^ value) & (MSR_IA32_APICBASE_ENABLE | X2APIC_ENABLE)) { - kvm_vcpu_update_apicv(vcpu); + kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu); static_call_cond(kvm_x86_set_virtual_apic_mode)(vcpu); } =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 ED007C3DA7A for ; Fri, 6 Jan 2023 01:14:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236738AbjAFBOT (ORCPT ); Thu, 5 Jan 2023 20:14:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236806AbjAFBNc (ORCPT ); Thu, 5 Jan 2023 20:13:32 -0500 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B91B72D07 for ; Thu, 5 Jan 2023 17:13:30 -0800 (PST) Received: by mail-pf1-x449.google.com with SMTP id ca10-20020a056a00418a00b00581dff62bb7so44958pfb.13 for ; Thu, 05 Jan 2023 17:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=AyyJxQdOuQ1HMd97et9gNBfdu2A+bTjtvnw5z18m+ZY=; b=n3f4DDGgwl8y3FetIa6hhUj8fZP1Vy6XVXj5BUFUUOJ0KMAv0fVJVc9d74Q9+ZkM85 N5q2+hS/Cn/Gh5l1CddiI4JJs11r5Sj4FYCInlpqZeVCiCEeuJaagkODP7FZKXy3DuGd W95QR3jNMFXRxL9+eCgy8hf6rPiwOV6rEObaPA/eVcEqY28nAPiNcLKPI/Y2FJWlY/Gr gtIV4EG0KM5H0XNfJTpObusljai093RjgxkeHgc6idUDdYFiqnPTNz46K8mmwdGxW9jd iUnfCDnIsB+/0gq58XiUNgE8v9+Ap3mYfNRRYK/klTU8IvKVMplMQv5dVtKdHE3cgxLF u0Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=AyyJxQdOuQ1HMd97et9gNBfdu2A+bTjtvnw5z18m+ZY=; b=h+nr+HuXfNih6w/B8L+RYZkSk2hNoa7g93/Q0+od6QAGecWf5tOlnf6TuCCxYI/pKc 29ou99snYxtGoOJzc9eFVTBxsO3BUmElHL43THmb7yg8/6mviAM9+fu699vd1ZKYEGh4 CqddZyQmrI/oWwyW5iFvQtT3p6IKcXyGRRTeTCffpftjOh1FcqkZ8TQox1QRCyQdstLf WS0uKh7ZZB6uuHKKSaeFyrCEO3+N4UNcsQT1Yhg9i4xCF4M+gEvXSVcVFdCKdOgQuM3J XQMEpSc8Yj5ktKGRm3MgaaPtL7puQfszScc6DrHFHfkHc+54vq5bZ6uYfMKMapdFyotk Na2Q== X-Gm-Message-State: AFqh2krIBz0Vwc83yckHja8JCL8TGaJS/L56I16SvGKQV2d1qSxLTM1X vRGkFTiKvX0ZYeZz0olCCoCWLnFnhKk= X-Google-Smtp-Source: AMrXdXsJTMbOzZ0K/SQrXcu5c8coRhChkRcw6+yG+IPWl1olBN5AujCViadAk0NIMA1fo8H5iBEqC2oASz0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:fa82:b0:225:ed9f:fdc6 with SMTP id cu2-20020a17090afa8200b00225ed9ffdc6mr3839156pjb.116.1672967610011; Thu, 05 Jan 2023 17:13:30 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:42 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-10-seanjc@google.com> Subject: [PATCH v5 09/33] KVM: x86: Move APIC access page helper to common x86 code From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the APIC access page allocation helper function to common x86 code, the allocation routine is virtually identical between APICv (VMX) and AVIC (SVM). Keep APICv's gfn_to_page() + put_page() sequence, which verifies that a backing page can be allocated, i.e. that the system isn't under heavy memory pressure. Forcing the backing page to be populated isn't strictly necessary, but skipping the effective prefetch only delays the inevitable. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 35 +++++++++++++++++++++++++++++++++++ arch/x86/kvm/lapic.h | 1 + arch/x86/kvm/svm/avic.c | 41 +++++++---------------------------------- arch/x86/kvm/vmx/vmx.c | 35 +---------------------------------- 4 files changed, 44 insertions(+), 68 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 3ed74ad60516..e73386c26d2c 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2435,6 +2435,41 @@ void kvm_apic_update_apicv(struct kvm_vcpu *vcpu) apic->highest_isr_cache =3D -1; } =20 +int kvm_alloc_apic_access_page(struct kvm *kvm) +{ + struct page *page; + void __user *hva; + int ret =3D 0; + + mutex_lock(&kvm->slots_lock); + if (kvm->arch.apic_access_memslot_enabled) + goto out; + + hva =3D __x86_set_memory_region(kvm, APIC_ACCESS_PAGE_PRIVATE_MEMSLOT, + APIC_DEFAULT_PHYS_BASE, PAGE_SIZE); + if (IS_ERR(hva)) { + ret =3D PTR_ERR(hva); + goto out; + } + + page =3D gfn_to_page(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT); + if (is_error_page(page)) { + ret =3D -EFAULT; + goto out; + } + + /* + * Do not pin the page in memory, so that memory hot-unplug + * is able to migrate it. + */ + put_page(page); + kvm->arch.apic_access_memslot_enabled =3D true; +out: + mutex_unlock(&kvm->slots_lock); + return ret; +} +EXPORT_SYMBOL_GPL(kvm_alloc_apic_access_page); + void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) { struct kvm_lapic *apic =3D vcpu->arch.apic; diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h index 58c3242fcc7a..8c6442751dab 100644 --- a/arch/x86/kvm/lapic.h +++ b/arch/x86/kvm/lapic.h @@ -112,6 +112,7 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_= lapic_irq *irq, struct dest_map *dest_map); int kvm_apic_local_deliver(struct kvm_lapic *apic, int lvt_type); void kvm_apic_update_apicv(struct kvm_vcpu *vcpu); +int kvm_alloc_apic_access_page(struct kvm *kvm); =20 bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic *src, struct kvm_lapic_irq *irq, int *r, struct dest_map *dest_map); diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 97ad0661f963..ec28ba4c5f1b 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -256,39 +256,6 @@ static u64 *avic_get_physical_id_entry(struct kvm_vcpu= *vcpu, return &avic_physical_id_table[index]; } =20 -/* - * Note: - * AVIC hardware walks the nested page table to check permissions, - * but does not use the SPA address specified in the leaf page - * table entry since it uses address in the AVIC_BACKING_PAGE pointer - * field of the VMCB. Therefore, we set up the - * APIC_ACCESS_PAGE_PRIVATE_MEMSLOT (4KB) here. - */ -static int avic_alloc_access_page(struct kvm *kvm) -{ - void __user *ret; - int r =3D 0; - - mutex_lock(&kvm->slots_lock); - - if (kvm->arch.apic_access_memslot_enabled) - goto out; - - ret =3D __x86_set_memory_region(kvm, - APIC_ACCESS_PAGE_PRIVATE_MEMSLOT, - APIC_DEFAULT_PHYS_BASE, - PAGE_SIZE); - if (IS_ERR(ret)) { - r =3D PTR_ERR(ret); - goto out; - } - - kvm->arch.apic_access_memslot_enabled =3D true; -out: - mutex_unlock(&kvm->slots_lock); - return r; -} - static int avic_init_backing_page(struct kvm_vcpu *vcpu) { u64 *entry, new_entry; @@ -305,7 +272,13 @@ static int avic_init_backing_page(struct kvm_vcpu *vcp= u) if (kvm_apicv_activated(vcpu->kvm)) { int ret; =20 - ret =3D avic_alloc_access_page(vcpu->kvm); + /* + * Note, AVIC hardware walks the nested page table to check + * permissions, but does not use the SPA address specified in + * the leaf SPTE since it uses address in the AVIC_BACKING_PAGE + * pointer field of the VMCB. + */ + ret =3D kvm_alloc_apic_access_page(vcpu->kvm); if (ret) return ret; } diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 0220e22b89ca..8ed14fcfe870 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -3808,39 +3808,6 @@ static void seg_setup(int seg) vmcs_write32(sf->ar_bytes, ar); } =20 -static int alloc_apic_access_page(struct kvm *kvm) -{ - struct page *page; - void __user *hva; - int ret =3D 0; - - mutex_lock(&kvm->slots_lock); - if (kvm->arch.apic_access_memslot_enabled) - goto out; - hva =3D __x86_set_memory_region(kvm, APIC_ACCESS_PAGE_PRIVATE_MEMSLOT, - APIC_DEFAULT_PHYS_BASE, PAGE_SIZE); - if (IS_ERR(hva)) { - ret =3D PTR_ERR(hva); - goto out; - } - - page =3D gfn_to_page(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT); - if (is_error_page(page)) { - ret =3D -EFAULT; - goto out; - } - - /* - * Do not pin the page in memory, so that memory hot-unplug - * is able to migrate it. - */ - put_page(page); - kvm->arch.apic_access_memslot_enabled =3D true; -out: - mutex_unlock(&kvm->slots_lock); - return ret; -} - int allocate_vpid(void) { int vpid; @@ -7394,7 +7361,7 @@ static int vmx_vcpu_create(struct kvm_vcpu *vcpu) vmx->loaded_vmcs =3D &vmx->vmcs01; =20 if (cpu_need_virtualize_apic_accesses(vcpu)) { - err =3D alloc_apic_access_page(vcpu->kvm); + err =3D kvm_alloc_apic_access_page(vcpu->kvm); if (err) goto free_vmcs; } --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 B5952C3DA7A for ; Fri, 6 Jan 2023 01:14:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236936AbjAFBOb (ORCPT ); Thu, 5 Jan 2023 20:14:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236815AbjAFBNc (ORCPT ); Thu, 5 Jan 2023 20:13:32 -0500 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 B6DF071FF5 for ; Thu, 5 Jan 2023 17:13:31 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id a11-20020a17090acb8b00b00226d4edae5dso50691pju.2 for ; Thu, 05 Jan 2023 17:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=fS+csXJyxOMcx0c1E+e+VEzk2Ik+KMEsEvy9GYC3FuY=; b=qPmMRHzY2Unv460fRWZ9mu+FUamlJOMoLR2rG7Sh1B1e0bLjVE5XjdLjAE7R5krYn5 uai9FKshpsbwsfFBKwmN53nHURaI8+80Xlya6y4I+saqoXWNe57ouoamKfL7j7vOjAcP ygUCVv1sMfYPva6qmO2QoP5JF2CelCT8zU0M0G8IiirAj0gvEDUCBvtkycFyJ6tswmog 2ESRRfDQLO+1QLwHxMWGxQg6LvRijd+h/CsKKZvyaP21RZ/Yir8xzIhpghaLUVTWDBlR CPJsJInRhC5JF1v9li9IWMVKhXHPQHOem/6s4o9j7py+POR+NiyK0vMwYIyOGPM074J/ zItA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=fS+csXJyxOMcx0c1E+e+VEzk2Ik+KMEsEvy9GYC3FuY=; b=sh2eMY1nTJVKXum6/jfrdw4/mEGdDfLhfpjlILiwTaxD4mflygfxyalSmogcegZjJi YZIibUOAODv40PWXt1JbUNxyETtvuMCMCXi0zTOwIOd3jp3XcXpTu0Y8sHC7TOySWdIW G9Z/9YGZnpyF0r8hRlzBIKBOy8OTVTFY/qHMQw0K/QFU32guestaAv5eV/w90Kh/mzEb HQPKKsNNRirOa+5wL5CC7SUW4iM9luOpxipRqt9LmHuUK2r3uOi1ssSNi5s3iwZxtXKQ 7iIfXkvvPSOACb81Ih08zM6FGmwp9j48yEOYEohJMu2Voti0TtCtts4HxkLcMfh8AEII Jrpw== X-Gm-Message-State: AFqh2kp3sN+YFYIVkPw8qprzb0D8LqPUd/TfJAcsRPKv3AjZE+WmgOuQ N4Xk7Rshg2vzLBw5V0K3vfSXrnKrDhk= X-Google-Smtp-Source: AMrXdXvDN56/1fbaQn51oOa/BNA3PQnJD5ufQrR6us1w8OXhQW6bqd17mqJZ1+sMC7WWtebxdT+51X18Dz0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:efcb:b0:186:971b:b7e5 with SMTP id ja11-20020a170902efcb00b00186971bb7e5mr2648231plb.54.1672967611493; Thu, 05 Jan 2023 17:13:31 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:43 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-11-seanjc@google.com> Subject: [PATCH v5 10/33] KVM: x86: Inhibit APIC memslot if x2APIC and AVIC are enabled From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Free the APIC access page memslot if any vCPU enables x2APIC and SVM's AVIC is enabled to prevent accesses to the virtual APIC on vCPUs with x2APIC enabled. On AMD, if its "hybrid" mode is enabled (AVIC is enabled when x2APIC is enabled even without x2AVIC support), keeping the APIC access page memslot results in the guest being able to access the virtual APIC page as x2APIC is fully emulated by KVM. I.e. hardware isn't aware that the guest is operating in x2APIC mode. Exempt nested SVM's update of APICv state from the new logic as x2APIC can't be toggled on VM-Exit. In practice, invoking the x2APIC logic should be harmless precisely because it should be a glorified nop, but play it safe to avoid latent bugs, e.g. with dropping the vCPU's SRCU lock. Intel doesn't suffer from the same issue as APICv has fully independent VMCS controls for xAPIC vs. x2APIC virtualization. Technically, KVM should provide bus error semantics and not memory semantics for the APIC page when x2APIC is enabled, but KVM already provides memory semantics in other scenarios, e.g. if APICv/AVIC is enabled and the APIC is hardware disabled (via APIC_BASE MSR). Note, checking apic_access_memslot_enabled without taking locks relies it being set during vCPU creation (before kvm_vcpu_reset()). vCPUs can race to set the inhibit and delete the memslot, i.e. can get false positives, but can't get false negatives as apic_access_memslot_enabled can't be toggled "on" once any vCPU reaches KVM_RUN. Opportunistically drop the "can" while updating avic_activate_vmcb()'s comment, i.e. to state that KVM _does_ support the hybrid mode. Move the "Note:" down a line to conform to preferred kernel/KVM multi-line comment style. Opportunistically update the apicv_update_lock comment, as it isn't actually used to protect apic_access_memslot_enabled (which is protected by slots_lock). Fixes: 0e311d33bfbe ("KVM: SVM: Introduce hybrid-AVIC mode") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm_host.h | 10 +++++---- arch/x86/kvm/lapic.c | 38 ++++++++++++++++++++++++++++++++- arch/x86/kvm/lapic.h | 1 + arch/x86/kvm/svm/avic.c | 12 +++++------ arch/x86/kvm/svm/nested.c | 2 +- arch/x86/kvm/svm/svm.c | 2 ++ arch/x86/kvm/x86.c | 27 +++++++++++++++++++++-- 7 files changed, 78 insertions(+), 14 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index c70690b2c82d..1d92c148e799 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1249,10 +1249,11 @@ struct kvm_arch { struct kvm_apic_map __rcu *apic_map; atomic_t apic_map_dirty; =20 - /* Protects apic_access_memslot_enabled and apicv_inhibit_reasons */ - struct rw_semaphore apicv_update_lock; - bool apic_access_memslot_enabled; + bool apic_access_memslot_inhibited; + + /* Protects apicv_inhibit_reasons */ + struct rw_semaphore apicv_update_lock; unsigned long apicv_inhibit_reasons; =20 gpa_t wall_clock; @@ -1599,6 +1600,7 @@ struct kvm_x86_ops { void (*enable_irq_window)(struct kvm_vcpu *vcpu); void (*update_cr8_intercept)(struct kvm_vcpu *vcpu, int tpr, int irr); bool (*check_apicv_inhibit_reasons)(enum kvm_apicv_inhibit reason); + bool allow_apicv_in_x2apic_without_x2apic_virtualization; void (*refresh_apicv_exec_ctrl)(struct kvm_vcpu *vcpu); void (*hwapic_irr_update)(struct kvm_vcpu *vcpu, int max_irr); void (*hwapic_isr_update)(int isr); @@ -1973,7 +1975,7 @@ gpa_t kvm_mmu_gva_to_gpa_system(struct kvm_vcpu *vcpu= , gva_t gva, =20 bool kvm_apicv_activated(struct kvm *kvm); bool kvm_vcpu_apicv_activated(struct kvm_vcpu *vcpu); -void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu); +void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu); void __kvm_set_or_clear_apicv_inhibit(struct kvm *kvm, enum kvm_apicv_inhibit reason, bool set); void kvm_set_or_clear_apicv_inhibit(struct kvm *kvm, diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index e73386c26d2c..355ea688df4a 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2442,7 +2442,8 @@ int kvm_alloc_apic_access_page(struct kvm *kvm) int ret =3D 0; =20 mutex_lock(&kvm->slots_lock); - if (kvm->arch.apic_access_memslot_enabled) + if (kvm->arch.apic_access_memslot_enabled || + kvm->arch.apic_access_memslot_inhibited) goto out; =20 hva =3D __x86_set_memory_region(kvm, APIC_ACCESS_PAGE_PRIVATE_MEMSLOT, @@ -2470,6 +2471,41 @@ int kvm_alloc_apic_access_page(struct kvm *kvm) } EXPORT_SYMBOL_GPL(kvm_alloc_apic_access_page); =20 +void kvm_inhibit_apic_access_page(struct kvm_vcpu *vcpu) +{ + struct kvm *kvm =3D vcpu->kvm; + + if (!kvm->arch.apic_access_memslot_enabled) + return; + + kvm_vcpu_srcu_read_unlock(vcpu); + + mutex_lock(&kvm->slots_lock); + + if (kvm->arch.apic_access_memslot_enabled) { + __x86_set_memory_region(kvm, APIC_ACCESS_PAGE_PRIVATE_MEMSLOT, 0, 0); + /* + * Clear "enabled" after the memslot is deleted so that a + * different vCPU doesn't get a false negative when checking + * the flag out of slots_lock. No additional memory barrier is + * needed as modifying memslots requires waiting other vCPUs to + * drop SRCU (see above), and false positives are ok as the + * flag is rechecked after acquiring slots_lock. + */ + kvm->arch.apic_access_memslot_enabled =3D false; + + /* + * Mark the memslot as inhibited to prevent reallocating the + * memslot during vCPU creation, e.g. if a vCPU is hotplugged. + */ + kvm->arch.apic_access_memslot_inhibited =3D true; + } + + mutex_unlock(&kvm->slots_lock); + + kvm_vcpu_srcu_read_lock(vcpu); +} + void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool init_event) { struct kvm_lapic *apic =3D vcpu->arch.apic; diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h index 8c6442751dab..df316ede7546 100644 --- a/arch/x86/kvm/lapic.h +++ b/arch/x86/kvm/lapic.h @@ -113,6 +113,7 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct kvm_= lapic_irq *irq, int kvm_apic_local_deliver(struct kvm_lapic *apic, int lvt_type); void kvm_apic_update_apicv(struct kvm_vcpu *vcpu); int kvm_alloc_apic_access_page(struct kvm *kvm); +void kvm_inhibit_apic_access_page(struct kvm_vcpu *vcpu); =20 bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic *src, struct kvm_lapic_irq *irq, int *r, struct dest_map *dest_map); diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index ec28ba4c5f1b..0a75993afed6 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -72,12 +72,12 @@ static void avic_activate_vmcb(struct vcpu_svm *svm) =20 vmcb->control.int_ctl |=3D AVIC_ENABLE_MASK; =20 - /* Note: - * KVM can support hybrid-AVIC mode, where KVM emulates x2APIC - * MSR accesses, while interrupt injection to a running vCPU - * can be achieved using AVIC doorbell. The AVIC hardware still - * accelerate MMIO accesses, but this does not cause any harm - * as the guest is not supposed to access xAPIC mmio when uses x2APIC. + /* + * Note: KVM supports hybrid-AVIC mode, where KVM emulates x2APIC MSR + * accesses, while interrupt injection to a running vCPU can be + * achieved using AVIC doorbell. KVM disables the APIC access page + * (deletes the memslot) if any vCPU has x2APIC enabled, thus enabling + * AVIC in hybrid mode activates only the doorbell mechanism. */ if (apic_x2apic_mode(svm->vcpu.arch.apic) && avic_mode =3D=3D AVIC_MODE_X2) { diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index bc9cd7086fa9..34ac03969f28 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -1106,7 +1106,7 @@ int nested_svm_vmexit(struct vcpu_svm *svm) * to benefit from it right away. */ if (kvm_apicv_activated(vcpu->kvm)) - kvm_vcpu_update_apicv(vcpu); + __kvm_vcpu_update_apicv(vcpu); =20 return 0; } diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 26044e1d2422..7651d665723e 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -5028,6 +5028,8 @@ static __init int svm_hardware_setup(void) svm_x86_ops.vcpu_blocking =3D NULL; svm_x86_ops.vcpu_unblocking =3D NULL; svm_x86_ops.vcpu_get_apicv_inhibit_reasons =3D NULL; + } else if (avic_mode =3D=3D AVIC_MODE_X1) { + svm_x86_ops.allow_apicv_in_x2apic_without_x2apic_virtualization =3D true; } =20 if (vls) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 39b8dd37bc40..1abe3f1e821c 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10045,7 +10045,7 @@ void kvm_make_scan_ioapic_request(struct kvm *kvm) kvm_make_all_cpus_request(kvm, KVM_REQ_SCAN_IOAPIC); } =20 -void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) +void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) { struct kvm_lapic *apic =3D vcpu->arch.apic; bool activate; @@ -10080,7 +10080,30 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) preempt_enable(); up_read(&vcpu->kvm->arch.apicv_update_lock); } -EXPORT_SYMBOL_GPL(kvm_vcpu_update_apicv); +EXPORT_SYMBOL_GPL(__kvm_vcpu_update_apicv); + +static void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) +{ + if (!lapic_in_kernel(vcpu)) + return; + + /* + * Due to sharing page tables across vCPUs, the xAPIC memslot must be + * deleted if any vCPU has xAPIC virtualization and x2APIC enabled, but + * and hardware doesn't support x2APIC virtualization. E.g. some AMD + * CPUs support AVIC but not x2APIC. KVM still allows enabling AVIC in + * this case so that KVM can the AVIC doorbell to inject interrupts to + * running vCPUs, but KVM must not create SPTEs for the APIC base as + * the vCPU would incorrectly be able to access the vAPIC page via MMIO + * despite being in x2APIC mode. For simplicity, inhibiting the APIC + * access page is sticky. + */ + if (apic_x2apic_mode(vcpu->arch.apic) && + kvm_x86_ops.allow_apicv_in_x2apic_without_x2apic_virtualization) + kvm_inhibit_apic_access_page(vcpu); + + __kvm_vcpu_update_apicv(vcpu); +} =20 void __kvm_set_or_clear_apicv_inhibit(struct kvm *kvm, enum kvm_apicv_inhibit reason, bool set) --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 5E392C3DA7A for ; Fri, 6 Jan 2023 01:14:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236917AbjAFBOX (ORCPT ); Thu, 5 Jan 2023 20:14:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236825AbjAFBNe (ORCPT ); Thu, 5 Jan 2023 20:13:34 -0500 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 8E56D71FF6 for ; Thu, 5 Jan 2023 17:13:33 -0800 (PST) Received: by mail-pf1-x44a.google.com with SMTP id y10-20020aa7942a000000b005814a9d972bso57646pfo.5 for ; Thu, 05 Jan 2023 17:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=Yz9E2DnzGU1LH62FYK53IVWLc/c5snlTFiIPiIg7gYk=; b=JgI8xYDcfH+1NRbV5JPQ/HsQ5Ob4bKUgvDUh7lrOmgE0/necFRjH5QYPhFaFmhgGMu OeU03FLmBpTYjyxCsPwWOd+H0+/nd+6aCbBGp+kM7XdoO2veu07K0u4DRTQxL3YoEUjj I/vg1qyC80S7VHKDBPcofn7cDZDkQd7Naam2HEj9c0pbitjBMUu/jOYZ6O/nt9996cvK XKfrs3+t4peZfihZtHDFI16/d/5TarxwGnwlSwg+fKowIWwi5FsSXShTDLj+IyWqsJaK UcscAhxeyQXWw2h8dHy2GwwYAG2whLIVwLsrUlv3j7pj3Juohy5MFxU+TSwuptAVGCr4 mBCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Yz9E2DnzGU1LH62FYK53IVWLc/c5snlTFiIPiIg7gYk=; b=T5NlVjjd6YT4DhO/cGUbw+46o6yrCm4dm6uOuU2MmZ6D2JsKN5qjNunAWIXhyuwUap ESxChOvleZtzUV6+HGa2A0SW6PZ9lm978v6vrvwf7yseTw9qomTN4IsvFalIMMnCdrFP /UlH/LASs1L+C2aA+pdFKg9c47fDGosvi94qpRawKe2EIZnDwLGgEi5IRl1c/uvBuyRY KIuPaMFb9fEuurAFlZ7VKgF0pxAkJ1W9nnnbVkHrfuTwWhDg3Zzv0kj3ZwluuRFrwWzO eH39lvmdS9roLtiMD5jwwTcWLVnsqZfzVLcvSSH6cXVAyh12pqvI3KoMB7hk46CQ3kT1 80yw== X-Gm-Message-State: AFqh2krZCyRPb739CBmtb2LEacjkFpy+fZaKnjFsbYpTzhsv01m1Q8UF aK9m3xiedL+S+iHk/ZTOLMDPBRtXKIs= X-Google-Smtp-Source: AMrXdXuHIxc6PnZAKmk2gR51ZGTv0l6j0GP029d2lQWQ1BQcRYdeD6OI/qIctUPgNI4DYKgskKo57+QPfa8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a65:5582:0:b0:481:b930:78dc with SMTP id j2-20020a655582000000b00481b93078dcmr2897762pgs.272.1672967613224; Thu, 05 Jan 2023 17:13:33 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:44 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-12-seanjc@google.com> Subject: [PATCH v5 11/33] KVM: SVM: Replace "avic_mode" enum with "x2avic_enabled" boolean From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Replace the "avic_mode" enum with a single bool to track whether or not x2AVIC is enabled. KVM already has "apicv_enabled" that tracks if any flavor of AVIC is enabled, i.e. AVIC_MODE_NONE and AVIC_MODE_X1 are redundant and unnecessary noise. No functional change intended. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 46 +++++++++++++++++++---------------------- arch/x86/kvm/svm/svm.c | 4 ++-- arch/x86/kvm/svm/svm.h | 9 +------- 3 files changed, 24 insertions(+), 35 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 0a75993afed6..10b0e996e2e3 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -53,7 +53,7 @@ static DEFINE_HASHTABLE(svm_vm_data_hash, SVM_VM_DATA_HAS= H_BITS); static u32 next_vm_id =3D 0; static bool next_vm_id_wrapped =3D 0; static DEFINE_SPINLOCK(svm_vm_data_hash_lock); -enum avic_modes avic_mode; +bool x2avic_enabled; =20 /* * This is a wrapper of struct amd_iommu_ir_data. @@ -79,8 +79,7 @@ static void avic_activate_vmcb(struct vcpu_svm *svm) * (deletes the memslot) if any vCPU has x2APIC enabled, thus enabling * AVIC in hybrid mode activates only the doorbell mechanism. */ - if (apic_x2apic_mode(svm->vcpu.arch.apic) && - avic_mode =3D=3D AVIC_MODE_X2) { + if (x2avic_enabled && apic_x2apic_mode(svm->vcpu.arch.apic)) { vmcb->control.int_ctl |=3D X2APIC_MODE_MASK; vmcb->control.avic_physical_id |=3D X2AVIC_MAX_PHYSICAL_ID; /* Disabling MSR intercept for x2APIC registers */ @@ -247,8 +246,8 @@ static u64 *avic_get_physical_id_entry(struct kvm_vcpu = *vcpu, u64 *avic_physical_id_table; struct kvm_svm *kvm_svm =3D to_kvm_svm(vcpu->kvm); =20 - if ((avic_mode =3D=3D AVIC_MODE_X1 && index > AVIC_MAX_PHYSICAL_ID) || - (avic_mode =3D=3D AVIC_MODE_X2 && index > X2AVIC_MAX_PHYSICAL_ID)) + if ((!x2avic_enabled && index > AVIC_MAX_PHYSICAL_ID) || + (index > X2AVIC_MAX_PHYSICAL_ID)) return NULL; =20 avic_physical_id_table =3D page_address(kvm_svm->avic_physical_id_table_p= age); @@ -262,8 +261,8 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu) int id =3D vcpu->vcpu_id; struct vcpu_svm *svm =3D to_svm(vcpu); =20 - if ((avic_mode =3D=3D AVIC_MODE_X1 && id > AVIC_MAX_PHYSICAL_ID) || - (avic_mode =3D=3D AVIC_MODE_X2 && id > X2AVIC_MAX_PHYSICAL_ID)) + if ((!x2avic_enabled && id > AVIC_MAX_PHYSICAL_ID) || + (id > X2AVIC_MAX_PHYSICAL_ID)) return -EINVAL; =20 if (!vcpu->arch.apic->regs) @@ -1066,10 +1065,7 @@ void avic_refresh_virtual_apic_mode(struct kvm_vcpu = *vcpu) struct vcpu_svm *svm =3D to_svm(vcpu); struct vmcb *vmcb =3D svm->vmcb01.ptr; =20 - if (!lapic_in_kernel(vcpu) || avic_mode =3D=3D AVIC_MODE_NONE) - return; - - if (!enable_apicv) + if (!lapic_in_kernel(vcpu) || !enable_apicv) return; =20 if (kvm_vcpu_apicv_active(vcpu)) { @@ -1145,32 +1141,32 @@ bool avic_hardware_setup(struct kvm_x86_ops *x86_op= s) if (!npt_enabled) return false; =20 + /* AVIC is a prerequisite for x2AVIC. */ + if (!boot_cpu_has(X86_FEATURE_AVIC) && !force_avic) { + if (boot_cpu_has(X86_FEATURE_X2AVIC)) { + pr_warn(FW_BUG "Cannot support x2AVIC due to AVIC is disabled"); + pr_warn(FW_BUG "Try enable AVIC using force_avic option"); + } + return false; + } + if (boot_cpu_has(X86_FEATURE_AVIC)) { - avic_mode =3D AVIC_MODE_X1; pr_info("AVIC enabled\n"); } else if (force_avic) { /* * Some older systems does not advertise AVIC support. * See Revision Guide for specific AMD processor for more detail. */ - avic_mode =3D AVIC_MODE_X1; pr_warn("AVIC is not supported in CPUID but force enabled"); pr_warn("Your system might crash and burn"); } =20 /* AVIC is a prerequisite for x2AVIC. */ - if (boot_cpu_has(X86_FEATURE_X2AVIC)) { - if (avic_mode =3D=3D AVIC_MODE_X1) { - avic_mode =3D AVIC_MODE_X2; - pr_info("x2AVIC enabled\n"); - } else { - pr_warn(FW_BUG "Cannot support x2AVIC due to AVIC is disabled"); - pr_warn(FW_BUG "Try enable AVIC using force_avic option"); - } - } + x2avic_enabled =3D boot_cpu_has(X86_FEATURE_X2AVIC); + if (x2avic_enabled) + pr_info("x2AVIC enabled\n"); =20 - if (avic_mode !=3D AVIC_MODE_NONE) - amd_iommu_register_ga_log_notifier(&avic_ga_log_notifier); + amd_iommu_register_ga_log_notifier(&avic_ga_log_notifier); =20 - return !!avic_mode; + return true; } diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 7651d665723e..9f172f2de195 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -813,7 +813,7 @@ void svm_set_x2apic_msr_interception(struct vcpu_svm *s= vm, bool intercept) if (intercept =3D=3D svm->x2avic_msrs_intercepted) return; =20 - if (avic_mode !=3D AVIC_MODE_X2 || + if (!x2avic_enabled || !apic_x2apic_mode(svm->vcpu.arch.apic)) return; =20 @@ -5028,7 +5028,7 @@ static __init int svm_hardware_setup(void) svm_x86_ops.vcpu_blocking =3D NULL; svm_x86_ops.vcpu_unblocking =3D NULL; svm_x86_ops.vcpu_get_apicv_inhibit_reasons =3D NULL; - } else if (avic_mode =3D=3D AVIC_MODE_X1) { + } else if (!x2avic_enabled) { svm_x86_ops.allow_apicv_in_x2apic_without_x2apic_virtualization =3D true; } =20 diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index d0ed3f595229..546825c82490 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -35,14 +35,7 @@ extern u32 msrpm_offsets[MSRPM_OFFSETS] __read_mostly; extern bool npt_enabled; extern int vgif; extern bool intercept_smi; - -enum avic_modes { - AVIC_MODE_NONE =3D 0, - AVIC_MODE_X1, - AVIC_MODE_X2, -}; - -extern enum avic_modes avic_mode; +extern bool x2avic_enabled; =20 /* * Clean bits in VMCB. --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 E1BF9C3DA7A for ; Fri, 6 Jan 2023 01:14:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236957AbjAFBOe (ORCPT ); Thu, 5 Jan 2023 20:14:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236255AbjAFBNf (ORCPT ); Thu, 5 Jan 2023 20:13:35 -0500 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 372DE72D1A for ; Thu, 5 Jan 2023 17:13:35 -0800 (PST) Received: by mail-pj1-x1049.google.com with SMTP id 31-20020a17090a0fa200b00226e43409c2so36456pjz.9 for ; Thu, 05 Jan 2023 17:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=kDxvCyND+GW2720NKX+RgCL5mWGsrG1FRlKlZQabxpo=; b=ReJLu44Xuh4L0IBAiISnjpPDDmPZ4zwt1bptT0oPD7m/aH0WSmyL3GOnkvXTm/nwxL QJ2LJh6tqzSOReRZuSNjKCRtIHdOrYNhOhnIRueYmyjdWqB3GFnXlunLvUvGnn4jS3+3 8ORcT4qtwKM/HGxgM9Mq6zhIXA7OV0ahXuuSC7z8ZOb4BFRxm1bbk667UvcrQgj798yj dTlMJlvImnDEKZrTB62yq9A6UHtYeivWKHoGzHpHX5Y2L+qxA3RgMEGSKLV/3jHtIAMq TFis3gn/knWcYiPuIwBJ+dNPLg/fgfC6RRqacslGH7qUqPsb+NXbhNr4R2x8JJ7H1SfC 1XFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kDxvCyND+GW2720NKX+RgCL5mWGsrG1FRlKlZQabxpo=; b=WXViLn2QSJyd3QqJ7yW8iSbGDiVo3GTYoa+EUirOaRhoUFxW65gEWtmOWiQTQ3XTyT N/xIPxmpkbqERjuET1I/IHHm3D6DYYpj29GF5/d8sn1tqvyhxO4vcpmiddgiWdotGApz +wB2goQu7K4jiwo6t0Ms8vOpIhCKMhOzxdSe6to0ae+B5a2QKJ6mdoyRGRPeJJHCwXoI 2Md60D9KnypPwRn08cyWxsJL20CS/pJsYgQAblSO9tR+E9u1DAAh1o6DfZS8bfGBlvjx eQoVfS5C4cSMzpFgB0UpB8MItcscEHJGl+cg15AbUmCVRHgxSVMVqpiweaSe9leQFuiJ wi7Q== X-Gm-Message-State: AFqh2koiCJZwwr474yuFe2+Ln3s2MVQD8/90JVKEL5eOt5qaWYnvEKuF v2J5w/KuhwUQmC0Tmcm4FzbHgFJC2hQ= X-Google-Smtp-Source: AMrXdXsI6obmtHI5V7B7wmBHR7mIfmRtZG2EiLT/QjCy0gfiqMsIPsfndMILkmOZcFdKLlasZmLbvJLVT5E= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a65:6748:0:b0:483:cd24:1cb7 with SMTP id c8-20020a656748000000b00483cd241cb7mr2838151pgu.190.1672967614819; Thu, 05 Jan 2023 17:13:34 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:45 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-13-seanjc@google.com> Subject: [PATCH v5 12/33] KVM: SVM: Compute dest based on sender's x2APIC status for AVIC kick From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Compute the destination from ICRH using the sender's x2APIC status, not each (potential) target's x2APIC status. Fixes: c514d3a348ac ("KVM: SVM: Update avic_kick_target_vcpus to support 32= -bit APIC ID") Cc: Li RongQing Signed-off-by: Sean Christopherson Reviewed-by: Li RongQing Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 10b0e996e2e3..f2db0021c45f 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -429,6 +429,7 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm,= struct kvm_lapic *source static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *sour= ce, u32 icrl, u32 icrh, u32 index) { + u32 dest =3D apic_x2apic_mode(source) ? icrh : GET_XAPIC_DEST_FIELD(icrh); unsigned long i; struct kvm_vcpu *vcpu; =20 @@ -444,13 +445,6 @@ static void avic_kick_target_vcpus(struct kvm *kvm, st= ruct kvm_lapic *source, * since entered the guest will have processed pending IRQs at VMRUN. */ kvm_for_each_vcpu(i, vcpu, kvm) { - u32 dest; - - if (apic_x2apic_mode(vcpu->arch.apic)) - dest =3D icrh; - else - dest =3D GET_XAPIC_DEST_FIELD(icrh); - if (kvm_apic_match_dest(vcpu, source, icrl & APIC_SHORT_MASK, dest, icrl & APIC_DEST_MASK)) { vcpu->arch.apic->irr_pending =3D true; --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 72977C3DA7A for ; Fri, 6 Jan 2023 01:14:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236965AbjAFBOj (ORCPT ); Thu, 5 Jan 2023 20:14:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236819AbjAFBNj (ORCPT ); Thu, 5 Jan 2023 20:13:39 -0500 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 E50A672D16 for ; Thu, 5 Jan 2023 17:13:36 -0800 (PST) Received: by mail-pl1-x649.google.com with SMTP id l15-20020a170903244f00b001927c3a0055so134122pls.6 for ; Thu, 05 Jan 2023 17:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=hanAIN1FDjCqq9DaKdKzw+37XL7mO/LpW1Uuz4oItLY=; b=BpE+M+imcFeJplZu6dyhWUzUUaWyR/Fm2UvwG0pbVeRkfy5RLyiWL7CS7gsyVQvwak AcFRlBLd8Gi2GEMc1kCZJWHd9kqUKRARrK4J1HATMCTvfK1QDVOyWznFi4TVkwxf7TVr PU5DMNU7EfG1NIBLp0Tz4MDNCxp2FVDVb05J4IHw4+DFw4BtwSDAnPvSkXQtKBFIaxsT 6Jip/PQAxFu1MwNACIkF21o4oDgTD46unsSfN9CjVcHMk/SRJnJ3orggDzTAN0B+9/Le r1eP58berdKr1IhYEyG10vPjuzo15J9f6id/gcomZ4yrADSVYphwDpUxND5F+GuDLx0X Z9Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=hanAIN1FDjCqq9DaKdKzw+37XL7mO/LpW1Uuz4oItLY=; b=7mhefcaA11aCJ6I7R6D3UCh9Al6Ddqi9Jqmuu9Fkxfoc2Sr9UCMnShw1HrAeAW2ej7 kstODZS7aAPe9/EjWaHVtzwIfpoKIFEP44Z2YQy2j7vroCw34ePe1zm2tI0+PYyEDTk2 aej8i5vz/6Ym1F8M4HxbWvkbLR3dX4fRH6Pcv/PyZ6X8LEMuuNNZo6Zm4BqBQrawg+VT WkFeoLQo9aiRWqul9j3qMtE1/FAzSbq2ejlM1TSabvx553EBygcQSesCfWPZ86fiAH7r XO9D2xzNxivQnI1Rnwc5qo+XISwaESTeuw8uJ16YXP3otAJhFhB5G0rZlwCZ8I59HMai nrhg== X-Gm-Message-State: AFqh2kpPQXKSR1qP5sdrgkhpXdUm2kMoL2QKNBiK8FaUxrsllD/QQ6C6 dP+4UzYWolMgPzOa97BgtHefgXvW5WE= X-Google-Smtp-Source: AMrXdXug5uzFbFp03CGZxhwh+qTEFZM/nw0QQbAl4oU2OUntE7PxWXR8Zcu08nZtctMPkvty7n5fySEy0F4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:a013:b0:223:3448:eb18 with SMTP id q19-20020a17090aa01300b002233448eb18mr4464943pjp.41.1672967616474; Thu, 05 Jan 2023 17:13:36 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:46 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-14-seanjc@google.com> Subject: [PATCH v5 13/33] KVM: SVM: Fix x2APIC Logical ID calculation for avic_kick_target_vcpus_fast From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Suravee Suthikulpanit For X2APIC ID in cluster mode, the logical ID is bit [15:0]. Fixes: 603ccef42ce9 ("KVM: x86: SVM: fix avic_kick_target_vcpus_fast") Cc: Maxim Levitsky Signed-off-by: Suravee Suthikulpanit Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index f2db0021c45f..0f67fd34ef99 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -356,7 +356,7 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm,= struct kvm_lapic *source =20 if (apic_x2apic_mode(source)) { /* 16 bit dest mask, 16 bit cluster id */ - bitmap =3D dest & 0xFFFF0000; + bitmap =3D dest & 0xFFFF; cluster =3D (dest >> 16) << 4; } else if (kvm_lapic_get_reg(source, APIC_DFR) =3D=3D APIC_DFR_FLAT) { /* 8 bit dest mask*/ --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 EA0A6C3DA7A for ; Fri, 6 Jan 2023 01:14:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232270AbjAFBOm (ORCPT ); Thu, 5 Jan 2023 20:14:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236843AbjAFBNk (ORCPT ); Thu, 5 Jan 2023 20:13:40 -0500 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 5728A71FF6 for ; Thu, 5 Jan 2023 17:13:38 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id a11-20020a17090a8c0b00b00226cdbf8bbcso1917799pjo.5 for ; Thu, 05 Jan 2023 17:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=dY73TyImmD0wCqNL26nvzhCHfX8vBgtKvyMOXbN+v1I=; b=B861zubBIjRS4M7hrE2P/lP1yiAP6O9QSDe8ztqdzZ75i+UmjMLuMJpNqdL1Elk8v/ RAAfOXEHLS8mwZoF3qdVZsbOy4/D5cBa1NaNov3OMq4WhgX+YWKDc18ZxIck79I1eX76 1S9Dd/6XPyWvlMNYGUn+0Bxbfx7NM3Bb8F2MkBes6HJ441yQNZ9yJnSAr6SZrWwUMgF0 F6fMSah5f8GauF6VTpl4lM81mhmTu8PAsbyUeUc8I9prYkJWnHInHrRzbBeahfU3Lci8 NUNUa/xmwowTdGQxAb69BtM7JoxrsfzEZIYUinrzK/gKYn1gTY4gK8xbr8v0C/Ggak2O zMHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=dY73TyImmD0wCqNL26nvzhCHfX8vBgtKvyMOXbN+v1I=; b=XJLGe8j0VLA7j+luMlBPMxbVvHGNFfJMrkhGOhr6c//QGf7j5kk5DiPD3e9rVnqbR3 FJjGEh0XNqvfSO/ClHW3e08PJKlp9WPYSEA55JwgTCEJjCgbuUmTUS+aDR6bx/BNLZMs rPeHnkDV2WzF/N9PkLn/SRoTaky0dZwbxlc99zY4XFLYMFleydeXyjCrhvWNU/F108AD QtRrx8GcfWM6HRma5ZJysflvSyDPjRK/gLt+9nGUbmhTo5uhDyi8aCSOSTlWJXneajuk F4XHOWkFuYRzkKMSYQy2jWONwQJ3qk12dIBbOY4AlHh0U39iQWXvUH9l28e5kYw+7afC eYpg== X-Gm-Message-State: AFqh2kpy2mg463Sl/dVFC8mAoXBiJ0dWxAbE7zW0GrexUaNXjLzWVxT3 lY8xhl2sb0MIvNKd52QBn1xNLCOx2tw= X-Google-Smtp-Source: AMrXdXvXUwoPtx1VGD8IrsXsf3RNGjmLaGKsP+ZxpWSG6SVLX4nROauFHzf5Vp7o4I738ZRKSXgckNPWa9E= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:999c:0:b0:582:74a2:1e4e with SMTP id k28-20020aa7999c000000b0058274a21e4emr1235081pfh.26.1672967617919; Thu, 05 Jan 2023 17:13:37 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:47 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-15-seanjc@google.com> Subject: [PATCH v5 14/33] Revert "KVM: SVM: Use target APIC ID to complete x2AVIC IRQs when possible" From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Due to a likely mismerge of patches, KVM ended up with a superfluous commit to "enable" AVIC's fast path for x2AVIC mode. Even worse, the superfluous commit has several bugs and creates a nasty local shadow variable. Rather than fix the bugs piece-by-piece[*] to achieve the same end result, revert the patch wholesale. Opportunistically add a comment documenting the x2AVIC dependencies. This reverts commit 8c9e639da435874fb845c4d296ce55664071ea7a. [*] https://lore.kernel.org/all/YxEP7ZBRIuFWhnYJ@google.com Fixes: 8c9e639da435 ("KVM: SVM: Use target APIC ID to complete x2AVIC IRQs = when possible") Suggested-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 0f67fd34ef99..e4b5f8b14882 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -378,7 +378,17 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm= , struct kvm_lapic *source =20 logid_index =3D cluster + __ffs(bitmap); =20 - if (!apic_x2apic_mode(source)) { + if (apic_x2apic_mode(source)) { + /* + * For x2APIC, the logical APIC ID is a read-only value + * that is derived from the x2APIC ID, thus the x2APIC + * ID can be found by reversing the calculation (done + * above). Note, bits 31:20 of the x2APIC ID are not + * propagated to the logical ID, but KVM limits the + * x2APIC ID limited to KVM_MAX_VCPU_IDS. + */ + l1_physical_id =3D logid_index; + } else { u32 *avic_logical_id_table =3D page_address(kvm_svm->avic_logical_id_table_page); =20 @@ -393,23 +403,6 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm= , struct kvm_lapic *source =20 l1_physical_id =3D logid_entry & AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK; - } else { - /* - * For x2APIC logical mode, cannot leverage the index. - * Instead, calculate physical ID from logical ID in ICRH. - */ - int cluster =3D (icrh & 0xffff0000) >> 16; - int apic =3D ffs(icrh & 0xffff) - 1; - - /* - * If the x2APIC logical ID sub-field (i.e. icrh[15:0]) - * contains anything but a single bit, we cannot use the - * fast path, because it is limited to a single vCPU. - */ - if (apic < 0 || icrh !=3D (1 << apic)) - return -EINVAL; - - l1_physical_id =3D (cluster << 4) + apic; } } =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 3C686C3DA7A for ; Fri, 6 Jan 2023 01:14:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231151AbjAFBOr (ORCPT ); Thu, 5 Jan 2023 20:14:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236864AbjAFBNl (ORCPT ); Thu, 5 Jan 2023 20:13:41 -0500 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 09CFA72D1A for ; Thu, 5 Jan 2023 17:13:40 -0800 (PST) Received: by mail-pg1-x549.google.com with SMTP id s76-20020a632c4f000000b0049ceb0f185eso209927pgs.7 for ; Thu, 05 Jan 2023 17:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=+aYaKFD5zMoXFl3Mrpqz5yT+Tj9hEBdwhn1YhcxYDeU=; b=sVrsJnqLgRkQyST7umHC5BB4qxL1l41vI7qq4E+/x2fYGDtl5AblzcCHBALLb9sRU2 ri/9ceRv5yQOzb3I+MmQ3K1QAJGXYtF1Y4wKvQgdg92ouBF5eFn7dTG1dhyfPIaqfNya TtWAEjejrgGg4APj5FxYfagDJ/CSY7RVZ3U4SuZnL+FCbmpn1Z0CShem1/ETEBsadwyt q2k7WmsXJhirwxtI6qS8NTr7kOKbg63MA7fFnTq0fgXqguYnYjo331l4d5XiadWpW5Ye 8DaMyvexx2ci4k40Bay6fKvVXBqel9Gu10bgBFLXHp4mCFYpcUuvkphUhvN6nqw7lctd sOqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=+aYaKFD5zMoXFl3Mrpqz5yT+Tj9hEBdwhn1YhcxYDeU=; b=Nqke4zypgPJpU7Ewvju31NALpKMJVkN2s6PqI76X7LBROo5ZBf1booc3ZDM8PAkVMx VTndwR2ZuqKjRVeefuWk9zYdvKaYM7b8XKZUJZHf1J4I2CTcIFgZ9+Glr3kUCZXasj9g gZOOJnUauvIouCegJFmwajXtK1CJXH41qXfjijYmOuci9eRzEvDORZIFVewI80AwoILE yLaEK+gj/ORcOx1iy9xpjfK7tiRLjVqO0d1nON0TeJPQkdP8SlbKR2UEWoK6y4CryM6m L+s8HBCLgdOh1c3OZx1KIvPsvxLGTdTWv5eM0zJqc9m2CzmRbGyLfj7q+uaMjY68tkyj H68A== X-Gm-Message-State: AFqh2krVkufRW0+BJ/VHjm+cUKrzV0lcPkejp3Vyw2uTA0pVmaNLN6zW c1Paeh3ZOYIgeDjyFLPiIqG5R3D+gUI= X-Google-Smtp-Source: AMrXdXsFgmf3vW4OGvIOFJZ6YjwA2U3Z4H//RGBlZizTl/eqLOIH4Tvb+Bga8Mjioz5BnlSq2KifbpKrqKg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a62:1c4d:0:b0:581:1898:93ae with SMTP id c74-20020a621c4d000000b00581189893aemr2945460pfc.51.1672967619557; Thu, 05 Jan 2023 17:13:39 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:48 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-16-seanjc@google.com> Subject: [PATCH v5 15/33] KVM: SVM: Document that vCPU ID == APIC ID in AVIC kick fastpatch From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Document that AVIC is inhibited if any vCPU's APIC ID diverges from its vCPU ID, i.e. that there's no need to check for a destination match in the AVIC kick fast path. Opportunistically tweak comments to remove "guest bug", as that suggests KVM is punting on error handling, which is not the case. Targeting a non-existent vCPU or no vCPUs _may_ be a guest software bug, but whether or not it's a guest bug is irrelevant. Such behavior is architecturally legal and thus needs to faithfully emulated by KVM (and it is). Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index e4b5f8b14882..eb2ad5b54877 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -368,8 +368,8 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm,= struct kvm_lapic *source cluster =3D (dest >> 4) << 2; } =20 + /* Nothing to do if there are no destinations in the cluster. */ if (unlikely(!bitmap)) - /* guest bug: nobody to send the logical interrupt to */ return 0; =20 if (!is_power_of_2(bitmap)) @@ -397,7 +397,7 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm,= struct kvm_lapic *source if (WARN_ON_ONCE(index !=3D logid_index)) return -EINVAL; =20 - /* guest bug: non existing/reserved logical destination */ + /* Nothing to do if the logical destination is invalid. */ if (unlikely(!(logid_entry & AVIC_LOGICAL_ID_ENTRY_VALID_MASK))) return 0; =20 @@ -406,9 +406,13 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm= , struct kvm_lapic *source } } =20 + /* + * KVM inhibits AVIC if any vCPU ID diverges from the vCPUs APIC ID, + * i.e. APIC ID =3D=3D vCPU ID. Once again, nothing to do if the target + * vCPU doesn't exist. + */ target_vcpu =3D kvm_get_vcpu_by_id(kvm, l1_physical_id); if (unlikely(!target_vcpu)) - /* guest bug: non existing vCPU is a target of this IPI*/ return 0; =20 target_vcpu->arch.apic->irr_pending =3D true; --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 EFE60C3DA7A for ; Fri, 6 Jan 2023 01:14:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230283AbjAFBOy (ORCPT ); Thu, 5 Jan 2023 20:14:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236457AbjAFBNm (ORCPT ); Thu, 5 Jan 2023 20:13:42 -0500 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 B9F6B755C0 for ; Thu, 5 Jan 2023 17:13:41 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id a72-20020a63904b000000b00489753edf13so193132pge.21 for ; Thu, 05 Jan 2023 17:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=oP9W5uEc0+NE0fVZ2qt9BCyCXd37G2flkZxHxmfC/SM=; b=lhDl+F1m6Gb0QU4uj7oQnM7HxwxTzwFuUmvYMgYeFyh51hje6BROAa43BG6gPCKOQ9 mXg2BNy7HNWgQnFTSvJ76inFBvNiKBUNM0ekR9tSNdfBgbsItS8r2eW55T0KiR1lleuO zsJ9gMXPeJOJK5DofJFUl3QAHW4fOodnMdMud/78Ky9bo0+QlOyU9O3SDaD0baeAJl0Y AzBavAYI+JEMNEG286Nwgd1wgNkre5V0hbGrdGe7ilPJLhohyfPUElcrdiyPGfEy5PHM FHwabkbcnCagvLjwMnmj03+7Yo4DoX9huXkkR2rNhT6nmkfz1ecQ2jnLi4jXTswKTZu7 h6Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=oP9W5uEc0+NE0fVZ2qt9BCyCXd37G2flkZxHxmfC/SM=; b=K1Z0eM4j96kaKReb1gHwYMMJPoYJUp+M18QymSzO9/DKzx5K1891ZVXiWM8OeKLvi4 tLthWc4gRoqf5oW5J7/aTCxsCGI5wlKBoEqM5Nn2liRejk9zhTRaJFcNviNVxvhdL/Ow ractCGiM47yftZb5Eo1JuS6tLzOGcCnpVRR+9oWGLc4OjCY3Am5vCF4P1AQ/gn2Erquu m4RtO83Ti8aSOYgoQJM2Glf7/9WWd6lbV3Q8PC7NtwT60P+S/41cd0oxvsxj7iEi8T7y D7rZpQ1j31gAXQQARkz1IMrjBuAbM8dGJXci2RlyHkNsIv5xwlQx/GZy4hmgRAflaHT6 XC/g== X-Gm-Message-State: AFqh2koVYtZTG+TU1k+6eppaPFFV7nGNRjyEIGe6RLtI3TEBBENBiVjP 7iYOAmiA9yCaHqHpr8NCt0vUbUqo1vU= X-Google-Smtp-Source: AMrXdXuo9NMFxPPxTioFXxvW8HWI9616amHLNe3R+YqEc09hS3vc70SRtVnQtbxqS1unCUr1aTSKNQ062xM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:a98a:b0:189:bf5d:c968 with SMTP id bh10-20020a170902a98a00b00189bf5dc968mr2459776plb.118.1672967621397; Thu, 05 Jan 2023 17:13:41 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:49 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-17-seanjc@google.com> Subject: [PATCH v5 16/33] KVM: SVM: Add helper to perform final AVIC "kick" of single vCPU From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add a helper to perform the final kick, two instances of the ICR decoding is one too many. No functional change intended. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index eb2ad5b54877..76da9f19272e 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -317,6 +317,16 @@ void avic_ring_doorbell(struct kvm_vcpu *vcpu) put_cpu(); } =20 + +static void avic_kick_vcpu(struct kvm_vcpu *vcpu, u32 icrl) +{ + vcpu->arch.apic->irr_pending =3D true; + svm_complete_interrupt_delivery(vcpu, + icrl & APIC_MODE_MASK, + icrl & APIC_INT_LEVELTRIG, + icrl & APIC_VECTOR_MASK); +} + /* * A fast-path version of avic_kick_target_vcpus(), which attempts to match * destination APIC ID to vCPU without looping through all vCPUs. @@ -415,11 +425,7 @@ static int avic_kick_target_vcpus_fast(struct kvm *kvm= , struct kvm_lapic *source if (unlikely(!target_vcpu)) return 0; =20 - target_vcpu->arch.apic->irr_pending =3D true; - svm_complete_interrupt_delivery(target_vcpu, - icrl & APIC_MODE_MASK, - icrl & APIC_INT_LEVELTRIG, - icrl & APIC_VECTOR_MASK); + avic_kick_vcpu(target_vcpu, icrl); return 0; } =20 @@ -443,13 +449,8 @@ static void avic_kick_target_vcpus(struct kvm *kvm, st= ruct kvm_lapic *source, */ kvm_for_each_vcpu(i, vcpu, kvm) { if (kvm_apic_match_dest(vcpu, source, icrl & APIC_SHORT_MASK, - dest, icrl & APIC_DEST_MASK)) { - vcpu->arch.apic->irr_pending =3D true; - svm_complete_interrupt_delivery(vcpu, - icrl & APIC_MODE_MASK, - icrl & APIC_INT_LEVELTRIG, - icrl & APIC_VECTOR_MASK); - } + dest, icrl & APIC_DEST_MASK)) + avic_kick_vcpu(vcpu, icrl); } } =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 85E83C53210 for ; Fri, 6 Jan 2023 01:15:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231989AbjAFBPP (ORCPT ); Thu, 5 Jan 2023 20:15:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236904AbjAFBNq (ORCPT ); Thu, 5 Jan 2023 20:13:46 -0500 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D2A2755ED for ; Thu, 5 Jan 2023 17:13:43 -0800 (PST) Received: by mail-pf1-x449.google.com with SMTP id b197-20020a621bce000000b00581b15e98cdso52507pfb.8 for ; Thu, 05 Jan 2023 17:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=32VPrBOq73WvzaefBtIggxIbeFo+/Cphxagan15DZtk=; b=jd8smTqkN0IDXl0EXdgRXlAJ/OS3kl8MhbTYhzhDohUUGbZZl5lSPukmE+oBw3lj7z PxNhmSnmJVnRb6FSuglJuxUQTCkRHNOz5eq5KcA1W7oKV68H5fHcnolhQXk+fddFJ1Hd hbZici3wfOyM0UW98R0ko2SBRyhhQmDianmMPJx0070qaH81nLGCKtLl7bEKABvmi7aO QK4wuHY0UZazpgqwD++59W+5Kg31nQ5tD4f08Ij0GC45cK5kBY4EZHIu8FdH2MMpLI6V PITyVaUx5b0jz2DOJdrcwYTr1ajr0cdExOuhyfistWyms77xsn9VyfX02NLrkyFryM/h oyQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=32VPrBOq73WvzaefBtIggxIbeFo+/Cphxagan15DZtk=; b=sbgCPVqrR1TwJGD9DuWVTtQcelEoPmyvfkY1UFoqaUfoZSUAgwH7uF4hP5BQwZXpQj NwYWfJQsKu9l84mwarO50gQWEKySwzfD906nvuN7P/bUenLj313Rfq9ESqZje1vz7v3R nLnqTchANu8S/BkqaHSi4GflnUdqMGZABLTzhxvf3l8uy40Ol6KYa1E4IIFBWpVtgoVy goaiVxFUHX0F0P4NPwatqDKHm2tlgK7NxVuXkgRbwu/PpvDtXgQEIGEsErGWZPSvjo3y 6x6L8/KvcSGCwNp715fka98jCEC4IIAQJRu2OsP+hStUx7JXs5/6l/mm7rxLXfZuzCEu 1XJA== X-Gm-Message-State: AFqh2kr3wQXKTXaSmyCUj8c9+c4+jjXowVvHGKwxwVcZkPgQKVS1xM5T BGZxMnhSHs6SRnazo3gVoYLRexOzLlU= X-Google-Smtp-Source: AMrXdXtuJEBL1IRZU3ombN6RWg4sQ5n5Oog+uPmHfCTlEmqlHlrX4+YyMkSQ683RnTNJrI0x6tppXZ5xgHc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a62:ee05:0:b0:581:c732:2b60 with SMTP id e5-20020a62ee05000000b00581c7322b60mr1822093pfi.25.1672967622912; Thu, 05 Jan 2023 17:13:42 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:50 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-18-seanjc@google.com> Subject: [PATCH v5 17/33] KVM: x86: Explicitly skip optimized logical map setup if vCPU's LDR==0 From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Explicitly skip the optimized map setup if the vCPU's LDR is '0', i.e. if the vCPU will never respond to logical mode interrupts. KVM already skips setup in this case, but relies on kvm_apic_map_get_logical_dest() to generate mask=3D=3D0. KVM still needs the mask=3D0 check as a non-zero = LDR can yield mask=3D=3D0 depending on the mode, but explicitly handling the LDR will make it simpler to clean up the logical mode tracking in the future. No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 355ea688df4a..2aee712e42bb 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -286,10 +286,12 @@ void kvm_recalculate_apic_map(struct kvm *kvm) continue; =20 ldr =3D kvm_lapic_get_reg(apic, APIC_LDR); + if (!ldr) + continue; =20 if (apic_x2apic_mode(apic)) { new->mode |=3D KVM_APIC_MODE_X2APIC; - } else if (ldr) { + } else { ldr =3D GET_APIC_LOGICAL_ID(ldr); if (kvm_lapic_get_reg(apic, APIC_DFR) =3D=3D APIC_DFR_FLAT) new->mode |=3D KVM_APIC_MODE_XAPIC_FLAT; --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 043A4C3DA7A for ; Fri, 6 Jan 2023 01:15:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229651AbjAFBP2 (ORCPT ); Thu, 5 Jan 2023 20:15:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231977AbjAFBOu (ORCPT ); Thu, 5 Jan 2023 20:14:50 -0500 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 6607178158 for ; Thu, 5 Jan 2023 17:13:45 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id 84-20020a630257000000b00477f88d334eso206165pgc.11 for ; Thu, 05 Jan 2023 17:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=MIpLae0T5AbCbYssh6yL+LWrf7kA0VhnIInAr1jWLwo=; b=HMV/ef6O14LeBA3Jy7RqRsvThrAAzkTKxDiHiaZ9sAkaBr0ro37oTgiEwA/2yxIKft fHqxeCDK+EmfSK/sNshmtOqXfhoHeJAyZxIFhJaAJBYw9pgZzd1DP/0HMCLppyGxMSOW F4wU1IlrC056jJXzE72fMZnJhq4j8jfx6vhBXaYIXY4Y8y2/o9nXuJOg4xdbWcjEjNCg +lcCaA6l7jWboOVXvSIeQc2judfhqwsz6MKx3CEwaPmxxGHoWYkloKqro27ynw+3mcqZ 5P3/uyqw4Yx/HSxK4+ir/2D+TsDg6sA0c4D+JJlYT97htW+lehezmeQLRFwuSwfoHyMb HpuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=MIpLae0T5AbCbYssh6yL+LWrf7kA0VhnIInAr1jWLwo=; b=6y9Ir0W0v0XDVLHynRg5Ka36kjmToolCx802bZkZLBCVVKOfCCWdGHqY1xUAp1sxRT VV6jRJsbaBh/egkf9kJtJ1DwD1CKSiU+6YEfKXgMVneAl0Mnxlf4gilSrENVW1WhRowr z/HCsfMoLg3+Cl4/i0Wr8uRBvxg/XM5emTN5JgjWwMa6x3AO7aY/ZwawK5Mfaewq1XyY U46/oZ/fw47b9F3OJKPvu73h6sgpmuDJVpuONbxAM8uJqz+n1k1Y8zBHwPC1OxOt4Mb1 M6+/Z1cR6+/WL+/YiN//oivYaiEUiknt1/jOsres2FS2JMhdMkAs6tF0Cb8Eyd4ppvTj 5D3w== X-Gm-Message-State: AFqh2kreR87vE32ezkmF3JulUX3kGqWKyryuoUhtKvYrwaarDCxw2DGJ neQh1EkuhxNyOAQfqmPcHSt+9RZLOEU= X-Google-Smtp-Source: AMrXdXvvw++u47Qs40R5b1mXS1QCnB2I9NNrgWTFloOJVufaN7u+the61ku5jAGuieiQbdlQ0HAkbXEiW9s= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e482:b0:186:5a0c:85a2 with SMTP id i2-20020a170902e48200b001865a0c85a2mr2799022ple.79.1672967624670; Thu, 05 Jan 2023 17:13:44 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:51 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-19-seanjc@google.com> Subject: [PATCH v5 18/33] KVM: x86: Explicitly track all possibilities for APIC map's logical modes From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Track all possibilities for the optimized APIC map's logical modes instead of overloading the pseudo-bitmap and treating any "unknown" value as "invalid". As documented by the now-stale comment above the mode values, the values did have meaning when the optimized map was originally added. That dependent logical was removed by commit e45115b62f9a ("KVM: x86: use physical LAPIC array for logical x2APIC"), but the obfuscated behavior and its comment were left behind. Opportunistically rename "mode" to "logical_mode", partly to make it clear that the "disabled" case applies only to the logical map, but also to prove that there is no lurking code that expects "mode" to be a bitmap. Functionally, this is a glorified nop. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm_host.h | 29 ++++++++++++++++-------- arch/x86/kvm/lapic.c | 40 ++++++++++++++++++++++++++------- 2 files changed, 52 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 1d92c148e799..732421a0ad02 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1022,19 +1022,30 @@ struct kvm_arch_memory_slot { }; =20 /* - * We use as the mode the number of bits allocated in the LDR for the - * logical processor ID. It happens that these are all powers of two. - * This makes it is very easy to detect cases where the APICs are - * configured for multiple modes; in that case, we cannot use the map and - * hence cannot use kvm_irq_delivery_to_apic_fast either. + * Track the mode of the optimized logical map, as the rules for decoding = the + * destination vary per mode. Enabling the optimized logical map requires= all + * software-enabled local APIs to be in the same mode, each addressable AP= IC to + * be mapped to only one MDA, and each MDA to map to at most one APIC. */ -#define KVM_APIC_MODE_XAPIC_CLUSTER 4 -#define KVM_APIC_MODE_XAPIC_FLAT 8 -#define KVM_APIC_MODE_X2APIC 16 +enum kvm_apic_logical_mode { + /* All local APICs are software disabled. */ + KVM_APIC_MODE_SW_DISABLED, + /* All software enabled local APICs in xAPIC cluster addressing mode. */ + KVM_APIC_MODE_XAPIC_CLUSTER, + /* All software enabled local APICs in xAPIC flat addressing mode. */ + KVM_APIC_MODE_XAPIC_FLAT, + /* All software enabled local APICs in x2APIC mode. */ + KVM_APIC_MODE_X2APIC, + /* + * Optimized map disabled, e.g. not all local APICs in the same logical + * mode, same logical ID assigned to multiple APICs, etc. + */ + KVM_APIC_MODE_MAP_DISABLED, +}; =20 struct kvm_apic_map { struct rcu_head rcu; - u8 mode; + enum kvm_apic_logical_mode logical_mode; u32 max_apic_id; union { struct kvm_lapic *xapic_flat_map[8]; diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 2aee712e42bb..2567998b692c 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -168,7 +168,12 @@ static bool kvm_use_posted_timer_interrupt(struct kvm_= vcpu *vcpu) =20 static inline bool kvm_apic_map_get_logical_dest(struct kvm_apic_map *map, u32 dest_id, struct kvm_lapic ***cluster, u16 *mask) { - switch (map->mode) { + switch (map->logical_mode) { + case KVM_APIC_MODE_SW_DISABLED: + /* Arbitrarily use the flat map so that @cluster isn't NULL. */ + *cluster =3D map->xapic_flat_map; + *mask =3D 0; + return true; case KVM_APIC_MODE_X2APIC: { u32 offset =3D (dest_id >> 16) * 16; u32 max_apic_id =3D map->max_apic_id; @@ -193,8 +198,10 @@ static inline bool kvm_apic_map_get_logical_dest(struc= t kvm_apic_map *map, *cluster =3D map->xapic_cluster_map[(dest_id >> 4) & 0xf]; *mask =3D dest_id & 0xf; return true; + case KVM_APIC_MODE_MAP_DISABLED: + return false; default: - /* Not optimized. */ + WARN_ON_ONCE(1); return false; } } @@ -256,10 +263,12 @@ void kvm_recalculate_apic_map(struct kvm *kvm) goto out; =20 new->max_apic_id =3D max_id; + new->logical_mode =3D KVM_APIC_MODE_SW_DISABLED; =20 kvm_for_each_vcpu(i, vcpu, kvm) { struct kvm_lapic *apic =3D vcpu->arch.apic; struct kvm_lapic **cluster; + enum kvm_apic_logical_mode logical_mode; u16 mask; u32 ldr; u8 xapic_id; @@ -282,7 +291,8 @@ void kvm_recalculate_apic_map(struct kvm *kvm) if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id]) new->phys_map[xapic_id] =3D apic; =20 - if (!kvm_apic_sw_enabled(apic)) + if (new->logical_mode =3D=3D KVM_APIC_MODE_MAP_DISABLED || + !kvm_apic_sw_enabled(apic)) continue; =20 ldr =3D kvm_lapic_get_reg(apic, APIC_LDR); @@ -290,17 +300,31 @@ void kvm_recalculate_apic_map(struct kvm *kvm) continue; =20 if (apic_x2apic_mode(apic)) { - new->mode |=3D KVM_APIC_MODE_X2APIC; + logical_mode =3D KVM_APIC_MODE_X2APIC; } else { ldr =3D GET_APIC_LOGICAL_ID(ldr); if (kvm_lapic_get_reg(apic, APIC_DFR) =3D=3D APIC_DFR_FLAT) - new->mode |=3D KVM_APIC_MODE_XAPIC_FLAT; + logical_mode =3D KVM_APIC_MODE_XAPIC_FLAT; else - new->mode |=3D KVM_APIC_MODE_XAPIC_CLUSTER; + logical_mode =3D KVM_APIC_MODE_XAPIC_CLUSTER; } =20 - if (!kvm_apic_map_get_logical_dest(new, ldr, &cluster, &mask)) + /* + * To optimize logical mode delivery, all software-enabled APICs must + * be configured for the same mode. + */ + if (new->logical_mode =3D=3D KVM_APIC_MODE_SW_DISABLED) { + new->logical_mode =3D logical_mode; + } else if (new->logical_mode !=3D logical_mode) { + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; continue; + } + + if (WARN_ON_ONCE(!kvm_apic_map_get_logical_dest(new, ldr, + &cluster, &mask))) { + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; + continue; + } =20 if (mask) cluster[ffs(mask) - 1] =3D apic; @@ -953,7 +977,7 @@ static bool kvm_apic_is_broadcast_dest(struct kvm *kvm,= struct kvm_lapic **src, { if (kvm->arch.x2apic_broadcast_quirk_disabled) { if ((irq->dest_id =3D=3D APIC_BROADCAST && - map->mode !=3D KVM_APIC_MODE_X2APIC)) + map->logical_mode !=3D KVM_APIC_MODE_X2APIC)) return true; if (irq->dest_id =3D=3D X2APIC_BROADCAST) return true; --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 28FDEC4708E for ; Fri, 6 Jan 2023 01:16:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231233AbjAFBP6 (ORCPT ); Thu, 5 Jan 2023 20:15:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232489AbjAFBPQ (ORCPT ); Thu, 5 Jan 2023 20:15:16 -0500 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 C93DB32245 for ; Thu, 5 Jan 2023 17:13:52 -0800 (PST) Received: by mail-pj1-x1049.google.com with SMTP id h14-20020a17090adb8e00b002264c50f36aso44900pjv.4 for ; Thu, 05 Jan 2023 17:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=6hlceM30Jbe/aO6Zo5aK3/yVy9oHh4ItTVnXmjKPlGU=; b=DcPb1qUmg7YoNAiRnrOTms0+X2InGNfOnaIJCUywCz0TjNATymUn0rZht9kPh1bYoy x/0b6nsj0j5zWG9+87qJ8O3dw7Ng+4VU7nw79ltSWrfsa4ykz+gZvepfAWFi6/Gq+x+j 2vaMZW4QDtV7w9AWz3y8QOBUISI41CXh8om3PjOBKC5y4b3nhif0kTHzsczzIQs/BEU1 QIlkfaEbAYJ7y+h9iONXkUhYExHOruVjj+fgVVfDZYJ00AUV16JtavxUTNBzsjKoEe1S yzDEWgFMLeddHqAK3R7IwL8VHrb6wVwlyo5f2wkZyuxPJaPEB5unpB/ic0NyE+doq2/p qD/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=6hlceM30Jbe/aO6Zo5aK3/yVy9oHh4ItTVnXmjKPlGU=; b=nfm2aHdSC03BwysUkexb4xBQs8g9F+cCX3pN/PdNTxHxECOUa4Rhnx9HUrdzO9dI/g w9N47t1wvSB0vi3hbj49ow1ikk3On4l+3G3JSpikW7piJg60g7kv0XTeJEfgO0axqc9Z +jgjceHxW1y8oQLX0Dm1dmOow9XGTbJp0PgFwiJkjs5vf6arBbOg6VG0SzJzweFkHFDo 0TB85pm3+BTLIHuiuy/cUi7ZmoipZ4XuWPNAVUEmXbBe2loG5elJfKeEPwbL0gKTc+3P sTSIr9UDUs6XMJKaYsWYtmwTHZTfcj0QjGWk7btRLzNsj4GCgMyesqfsBms7IqdiUV66 EhHQ== X-Gm-Message-State: AFqh2kr1l4k8WvClJDXjbMNLDznLOequxl1nISev0KGWkCD0szHNvEvy PN0arW0dTnCNMWzWQeMHf/PM+5Q1EBg= X-Google-Smtp-Source: AMrXdXvsBWPz/jQPJ0hhAaHa3gbYN1tslfVwRMDp2UU6Zzuh1ejjfNG7L4wTL72BU0eN3nK5TYbkycUGLQw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a62:1584:0:b0:581:1083:2cc5 with SMTP id 126-20020a621584000000b0058110832cc5mr2680623pfv.14.1672967626186; Thu, 05 Jan 2023 17:13:46 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:52 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-20-seanjc@google.com> Subject: [PATCH v5 19/33] KVM: x86: Skip redundant x2APIC logical mode optimized cluster setup From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards 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 optimized cluster[] setup for x2APIC logical mode, as KVM reuses the optimized map's phys_map[] and doesn't actually need to insert the target apic into the cluster[]. The LDR is derived from the x2APIC ID, and both are read-only in KVM, thus the vCPU's cluster[ldr] is guaranteed to be the same entry as the vCPU's phys_map[x2apic_id] entry. Skipping the unnecessary setup will allow a future fix for aliased xAPIC logical IDs to simply require that cluster[ldr] is non-NULL, i.e. won't have to special case x2APIC. Alternatively, the future check could allow "cluster[ldr] =3D=3D apic", but that ends up being terribly confusing because cluster[ldr] is only set at the very end, i.e. it's only possible due to x2APIC's shenanigans. Another alternative would be to send x2APIC down a separate path _after_ the calculation and then assert that all of the above, but the resulting code is rather messy, and it's arguably unnecessary since asserting that the actual LDR matches the expected LDR means that simply testing that interrupts are delivered correctly provides the same guarantees. Reported-by: Suravee Suthikulpanit Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 2567998b692c..fd7726ff95c6 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -166,6 +166,11 @@ static bool kvm_use_posted_timer_interrupt(struct kvm_= vcpu *vcpu) return kvm_can_post_timer_interrupt(vcpu) && vcpu->mode =3D=3D IN_GUEST_M= ODE; } =20 +static inline u32 kvm_apic_calc_x2apic_ldr(u32 id) +{ + return ((id >> 4) << 16) | (1 << (id & 0xf)); +} + static inline bool kvm_apic_map_get_logical_dest(struct kvm_apic_map *map, u32 dest_id, struct kvm_lapic ***cluster, u16 *mask) { switch (map->logical_mode) { @@ -320,6 +325,18 @@ void kvm_recalculate_apic_map(struct kvm *kvm) continue; } =20 + /* + * In x2APIC mode, the LDR is read-only and derived directly + * from the x2APIC ID, thus is guaranteed to be addressable. + * KVM reuses kvm_apic_map.phys_map to optimize logical mode + * x2APIC interrupts by reversing the LDR calculation to get + * cluster of APICs, i.e. no additional work is required. + */ + if (apic_x2apic_mode(apic)) { + WARN_ON_ONCE(ldr !=3D kvm_apic_calc_x2apic_ldr(x2apic_id)); + continue; + } + if (WARN_ON_ONCE(!kvm_apic_map_get_logical_dest(new, ldr, &cluster, &mask))) { new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; @@ -386,11 +403,6 @@ static inline void kvm_apic_set_dfr(struct kvm_lapic *= apic, u32 val) atomic_set_release(&apic->vcpu->kvm->arch.apic_map_dirty, DIRTY); } =20 -static inline u32 kvm_apic_calc_x2apic_ldr(u32 id) -{ - return ((id >> 4) << 16) | (1 << (id & 0xf)); -} - static inline void kvm_apic_set_x2apic_id(struct kvm_lapic *apic, u32 id) { u32 ldr =3D kvm_apic_calc_x2apic_ldr(id); --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 50C43C3DA7A for ; Fri, 6 Jan 2023 01:16:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232554AbjAFBQP (ORCPT ); Thu, 5 Jan 2023 20:16:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231561AbjAFBPg (ORCPT ); Thu, 5 Jan 2023 20:15:36 -0500 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 0FC9F3227D for ; Thu, 5 Jan 2023 17:14:03 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id j18-20020a170902da9200b00189b3b16addso97691plx.23 for ; Thu, 05 Jan 2023 17:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=+A51GFnbIGYLOWeoxnDIO9I82OkrlDigpTJkMvBwJMw=; b=F8yzvupPXsGW06DH+1jZGD+zuxJ+ciFFDXXj42wqvm5h/vD4rhWkB30ytSbi5IxBuA Q5xYNnENse/uvcUlUomuo7rHIYID/0orsR2GikNSViLFaGeDyOT+YXUA6lCTMd22/TEh aI3kr97jkgXyYnUf4ENzElIjb1HTY47wtaolr+BE6/YVwz1ssR3YJf4tpjzZ3nVYqzMY ZnhnbxON18+UcKHIAdr2Cljg4XsGGn9t9JwVHz2zt8nMQ5p+aGq4LDXRs9h5/BhafCxC FGAk9Wc0ZmsylkByffi09PfVC11igMnAmYKf47AhvnSHzgj81CSlQ/MCY0a9Im14Ntm5 vS8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=+A51GFnbIGYLOWeoxnDIO9I82OkrlDigpTJkMvBwJMw=; b=FLqfTxCUDuRqQxt013VPfPTDqeajE8ep6hltxOHTAHOHm6SBOQqLDDu0hey33qCFEd 3/iYRkaH/QkiQGlKZr3rAiERv/YEdqjhSjY64FTMFmwu2j6hL4HQUN2ji2dJnlK+EUr5 RmlA06yeHZZBro3nWT/SdzA9x7sZ+aXqi++pweouJC7D18t24hFcgSdYo2nOukKIzWvs ohryWhE4p+h7w+r6z4jPe/AN0DQUDpPKkWYnZsMHfrCy7HKU8qZcZnKcnFSbMruUZYno VEIik/uDyM3XDf4/To4e155JM1mZCQnM3TgikCn0661hZ1aAICwtKzcUUh7kEO/ZEv82 NOIQ== X-Gm-Message-State: AFqh2kpfc6LMMwQh2rWpteNMF92w4kV7yDqqJEbymBHJpcB4gGE9suSC NDBZaqjmf/xaORMXtNhvYwhC338braI= X-Google-Smtp-Source: AMrXdXsYY7BVFxPRMEfoT/emgTWWz1OhSiCaBGRQGPHU+fL6h44G8pju8fB+2riNfABFA2yT830hOts7P8A= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:46d8:b0:226:6523:7849 with SMTP id jx24-20020a17090b46d800b0022665237849mr1263637pjb.66.1672967627955; Thu, 05 Jan 2023 17:13:47 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:53 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-21-seanjc@google.com> Subject: [PATCH v5 20/33] KVM: x86: Disable APIC logical map if logical ID covers multiple MDAs From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Disable the optimized APIC logical map if a logical ID covers multiple MDAs, i.e. if a vCPU has multiple bits set in its ID. In logical mode, events match if "ID & MDA !=3D 0", i.e. creating an entry for only the first bit can cause interrupts to be missed. Note, creating an entry for every bit is also wrong as KVM would generate IPIs for every matching bit. It would be possible to teach KVM to play nice with this edge case, but it is very much an edge case and probably not used in any real world OS, i.e. it's not worth optimizing. Fixes: 1e08ec4a130e ("KVM: optimize apic interrupt delivery") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index fd7726ff95c6..dca87bb6dd1a 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -343,8 +343,14 @@ void kvm_recalculate_apic_map(struct kvm *kvm) continue; } =20 - if (mask) - cluster[ffs(mask) - 1] =3D apic; + if (!mask) + continue; + + if (!is_power_of_2(mask)) { + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; + continue; + } + cluster[ffs(mask) - 1] =3D apic; } out: old =3D rcu_dereference_protected(kvm->arch.apic_map, --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 ACA8AC53210 for ; Fri, 6 Jan 2023 01:16:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231883AbjAFBQS (ORCPT ); Thu, 5 Jan 2023 20:16:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231663AbjAFBPh (ORCPT ); Thu, 5 Jan 2023 20:15:37 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0AEB7816E for ; Thu, 5 Jan 2023 17:14:03 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-4b34cf67fb6so3169297b3.6 for ; Thu, 05 Jan 2023 17:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=QiGveUbKaqMPt6iTfsOvtO6yQmlbHWlXsxHlqUGMl/I=; b=IgbrbTl5VVQEWYsKOJIdi6Yh1Rkg0pxnO5FKrfb/4/5Qxejylccur32ccSkChi1BWm uNrufnv52MO1GV4aPWUTlMIVQdCAw64PEWa6M/B6kgKNK6cZuFwD85AckL/9uoZHparz +298w25KwqbNpkDWWG3fvXwVJOprfJez5wLuAtZsf1CEg/vV/I0j2/tIj4s84NJ2x24a 6xUmJHZcg6MlqBKqNcneW//MiQUT5D9tk2KcNx2zZ2UBS+Ekss9Guu2K2rJnWRh8PqYk hsoOAg/4wWltiJSgyf24wg3gGckY2Hk5Dsmn8pePTXlBQhal0Ru6ni9RiKz1Syw4a6zl QdAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=QiGveUbKaqMPt6iTfsOvtO6yQmlbHWlXsxHlqUGMl/I=; b=lmM5A0LdrSjA7exHjBKhmgsuSmabrTwQDInbPm73UuLhQwCXeBz+leuNs9sPKp+T6+ IRjdHvWTg2SdTCYXb53khkFep3e/2WKxgq3MYUuRRIucC3yBe0Vd+Ud+EEVJVfyben6Z eDqT65/FU4gyLzdv+SBRxx+rWIQEYDu1eIIxg+vvcasLwsIW+RUoIA4NCzF/kioi4flp 0h0LLbhlEm2L78OyypkkFWTEloJoERysReQ59IMziCWAr8BMdv4L4BJxrC8tYALUQECJ AuGJhOlqvKlhbOyGpKm/yfU678t/rdG+5zVuU+ter88qCp9CGup+7dl7qPEu1ltaYSMt jGyQ== X-Gm-Message-State: AFqh2kpRFE/2gSt8j2NPpAWMscZwuHxKhdbf1q0kHj7ijn4VkMqN5NjR 4eLpFhaEGOokXA0KMYu/wxiv6vCzGKU= X-Google-Smtp-Source: AMrXdXtfxGfz2gG4ErZYxvuoVjkwSn3FVdr74faXbyyI8MKRfjpjhpYAUJbYOlNFP1jqpsbpwf1rN5sAlGc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:6784:0:b0:460:c029:6c76 with SMTP id b126-20020a816784000000b00460c0296c76mr362480ywc.515.1672967629741; Thu, 05 Jan 2023 17:13:49 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:54 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-22-seanjc@google.com> Subject: [PATCH v5 21/33] KVM: x86: Disable APIC logical map if vCPUs are aliased in logical mode From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Disable the optimized APIC logical map if multiple vCPUs are aliased to the same logical ID. Architecturally, all CPUs whose logical ID matches the MDA are supposed to receive the interrupt; overwriting existing map entries can result in missed IPIs. Fixes: 1e08ec4a130e ("KVM: optimize apic interrupt delivery") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index dca87bb6dd1a..9c0554bae3b1 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -346,11 +346,12 @@ void kvm_recalculate_apic_map(struct kvm *kvm) if (!mask) continue; =20 - if (!is_power_of_2(mask)) { + ldr =3D ffs(mask) - 1; + if (!is_power_of_2(mask) || cluster[ldr]) { new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; continue; } - cluster[ffs(mask) - 1] =3D apic; + cluster[ldr] =3D apic; } out: old =3D rcu_dereference_protected(kvm->arch.apic_map, --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 F2CA0C3DA7A for ; Fri, 6 Jan 2023 01:16:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233245AbjAFBQj (ORCPT ); Thu, 5 Jan 2023 20:16:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232243AbjAFBP5 (ORCPT ); Thu, 5 Jan 2023 20:15:57 -0500 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 059AA3E859 for ; Thu, 5 Jan 2023 17:14:08 -0800 (PST) Received: by mail-pf1-x44a.google.com with SMTP id a18-20020a62bd12000000b0056e7b61ec78so33190pff.17 for ; Thu, 05 Jan 2023 17:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=+6ioVOt6Y8ZSfzod+z4E7s6OaCseHKr4cxWSag07wVE=; b=O03cZ1UPddU8+XWJbySLwg3naywoqGigzTnJjgko5PE9IcKnBBaU5jVcmQtdY0IUfb oio/dzcsZGvSts18YYk/Av8B13MvrBhXlFRUuDK0yLNsOJWBi85p0sB/MZ1MD+y/3ZZB /s2g21t9mqzfA0erk1tjtpxXtyCn5AGjRZPmTnIOoKwOZTkcYC4omQh9wLxqqahT0jub lzVDgF7bYgo/pCVCXp9GjXJ9J89NBZnp/w7Dj957/VEmzMscANc264m0H1Lg6AcFmOBD DgXgqOnwy4ySU7l0z1Jeg4vNgbdZvnttpRpx7hadVpe4cGu1VWHrzFSvfBXXU1z2bjnq rKNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=+6ioVOt6Y8ZSfzod+z4E7s6OaCseHKr4cxWSag07wVE=; b=3bgB+X2n1L/KQWi4cySerZ8YZxHc5m7Q/+neaaDB/w/0p47jAuDxdCtpQRfMiqh0SA 55Quf05iiyTh1QKbNjkzaysqz7uirLPN+qJe3noZWbYrndfL9kHtsG0zd+jkzYclqxQ1 KnX313Xn0EgbLOYh4TBHD1Xk/sJVlCGJPCDwhAoYPmJj0KBa0tuxDoq+A9lSOvz2tGLS x/QhhAJPgfVB4ggPKON3ARHJxFUMREz2DQeMfpRqQK7joe5KEQ68Qj5mXL6cMF9FwC7c hxZ7WKK+iG2ckhn4e0wmM83L8Yf0SiQpvS4YjLU79RHj4KCiuZEtygSvoCmM4yI5NfPi u/Tg== X-Gm-Message-State: AFqh2koHRU2xupnMYjEAndNpfgbb71IrTr3JGb8w9EY7718B8AylB1ys /b3nEsLT7hgJHsGsX5JNgEry06M8EYo= X-Google-Smtp-Source: AMrXdXvU+z8G6WL9sUSr49SDJHZoyA8j92U9Ai5TJks5PAdZnP3VkOSjGEgGIMU0vTB0Vro0DdkHJBRgGU0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:ab05:b0:192:4d6a:2add with SMTP id ik5-20020a170902ab0500b001924d6a2addmr2740731plb.109.1672967631378; Thu, 05 Jan 2023 17:13:51 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:55 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-23-seanjc@google.com> Subject: [PATCH v5 22/33] KVM: x86: Honor architectural behavior for aliased 8-bit APIC IDs From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Apply KVM's hotplug hack if and only if userspace has enabled 32-bit IDs for x2APIC. If 32-bit IDs are not enabled, disable the optimized map to honor x86 architectural behavior if multiple vCPUs shared a physical APIC ID. As called out in the changelog that added the hack, all CPUs whose (possibly truncated) APIC ID matches the target are supposed to receive the IPI. KVM intentionally differs from real hardware, because real hardware (Knights Landing) does just "x2apic_id & 0xff" to decide whether to accept the interrupt in xAPIC mode and it can deliver one interrupt to more than one physical destination, e.g. 0x123 to 0x123 and 0x23. Applying the hack even when x2APIC is not fully enabled means KVM doesn't correctly handle scenarios where the guest has aliased xAPIC IDs across multiple vCPUs, as only the vCPU with the lowest vCPU ID will receive any interrupts. It's extremely unlikely any real world guest aliases APIC IDs, or even modifies APIC IDs, but KVM's behavior is arbitrary, e.g. the lowest vCPU ID "wins" regardless of which vCPU is "aliasing" and which vCPU is "normal". Furthermore, the hack is _not_ guaranteed to work! The hack works if and only if the optimized APIC map is successfully allocated. If the map allocation fails (unlikely), KVM will fall back to its unoptimized behavior, which _does_ honor the architectural behavior. Pivot on 32-bit x2APIC IDs being enabled as that is required to take advantage of the hotplug hack (see kvm_apic_state_fixup()), i.e. won't break existing setups unless they are way, way off in the weeds. And an entry in KVM's errata to document the hack. Alternatively, KVM could provide an actual x2APIC quirk and document the hack that way, but there's unlikely to ever be a use case for disabling the quirk. Go the errata route to avoid having to validate a quirk no one cares about. Fixes: 5bd5db385b3e ("KVM: x86: allow hotplug of VCPU with APIC ID over 0xf= f") Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- Documentation/virt/kvm/x86/errata.rst | 11 ++++++ arch/x86/kvm/lapic.c | 50 ++++++++++++++++++++++----- 2 files changed, 52 insertions(+), 9 deletions(-) diff --git a/Documentation/virt/kvm/x86/errata.rst b/Documentation/virt/kvm= /x86/errata.rst index 410e0aa63493..49a05f24747b 100644 --- a/Documentation/virt/kvm/x86/errata.rst +++ b/Documentation/virt/kvm/x86/errata.rst @@ -37,3 +37,14 @@ Nested virtualization features ------------------------------ =20 TBD + +x2APIC +------ +When KVM_X2APIC_API_USE_32BIT_IDS is enabled, KVM activates a hack/quirk t= hat +allows sending events to a single vCPU using its x2APIC ID even if the tar= get +vCPU has legacy xAPIC enabled, e.g. to bring up hotplugged vCPUs via INIT-= SIPI +on VMs with > 255 vCPUs. A side effect of the quirk is that, if multiple = vCPUs +have the same physical APIC ID, KVM will deliver events targeting that API= C ID +only to the vCPU with the lowest vCPU ID. If KVM_X2APIC_API_USE_32BIT_IDS= is +not enabled, KVM follows x86 architecture when processing interrupts (all = vCPUs +matching the target APIC ID receive the interrupt). diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 9c0554bae3b1..e9f258de91bd 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -274,10 +274,10 @@ void kvm_recalculate_apic_map(struct kvm *kvm) struct kvm_lapic *apic =3D vcpu->arch.apic; struct kvm_lapic **cluster; enum kvm_apic_logical_mode logical_mode; + u32 x2apic_id, physical_id; u16 mask; u32 ldr; u8 xapic_id; - u32 x2apic_id; =20 if (!kvm_apic_present(vcpu)) continue; @@ -285,16 +285,48 @@ void kvm_recalculate_apic_map(struct kvm *kvm) xapic_id =3D kvm_xapic_id(apic); x2apic_id =3D kvm_x2apic_id(apic); =20 - /* Hotplug hack: see kvm_apic_match_physical_addr(), ... */ - if ((apic_x2apic_mode(apic) || x2apic_id > 0xff) && - x2apic_id <=3D new->max_apic_id) - new->phys_map[x2apic_id] =3D apic; /* - * ... xAPIC ID of VCPUs with APIC ID > 0xff will wrap-around, - * prevent them from masking VCPUs with APIC ID <=3D 0xff. + * Apply KVM's hotplug hack if userspace has enable 32-bit APIC + * IDs. Allow sending events to vCPUs by their x2APIC ID even + * if the target vCPU is in legacy xAPIC mode, and silently + * ignore aliased xAPIC IDs (the x2APIC ID is truncated to 8 + * bits, causing IDs > 0xff to wrap and collide). + * + * Honor the architectural (and KVM's non-optimized) behavior + * if userspace has not enabled 32-bit x2APIC IDs. Each APIC + * is supposed to process messages independently. If multiple + * vCPUs have the same effective APIC ID, e.g. due to the + * x2APIC wrap or because the guest manually modified its xAPIC + * IDs, events targeting that ID are supposed to be recognized + * by all vCPUs with said ID. */ - if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id]) - new->phys_map[xapic_id] =3D apic; + if (kvm->arch.x2apic_format) { + /* See also kvm_apic_match_physical_addr(). */ + if ((apic_x2apic_mode(apic) || x2apic_id > 0xff) && + x2apic_id <=3D new->max_apic_id) + new->phys_map[x2apic_id] =3D apic; + + if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id]) + new->phys_map[xapic_id] =3D apic; + } else { + /* + * Disable the optimized map if the physical APIC ID is + * already mapped, i.e. is aliased to multiple vCPUs. + * The optimized map requires a strict 1:1 mapping + * between IDs and vCPUs. + */ + if (apic_x2apic_mode(apic)) + physical_id =3D x2apic_id; + else + physical_id =3D xapic_id; + + if (new->phys_map[physical_id]) { + kvfree(new); + new =3D NULL; + goto out; + } + new->phys_map[physical_id] =3D apic; + } =20 if (new->logical_mode =3D=3D KVM_APIC_MODE_MAP_DISABLED || !kvm_apic_sw_enabled(apic)) --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 72422C4708E for ; Fri, 6 Jan 2023 01:16:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231179AbjAFBQf (ORCPT ); Thu, 5 Jan 2023 20:16:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232228AbjAFBP5 (ORCPT ); Thu, 5 Jan 2023 20:15:57 -0500 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 3FD333E85E for ; Thu, 5 Jan 2023 17:14:09 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id n1-20020a170902e54100b00192cc6850ffso108804plf.18 for ; Thu, 05 Jan 2023 17:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=ZYN39wk6a5NRPTtVgQ2fmBkBZpoYFPy36qtJQgrzBbQ=; b=S4tMZcslkr51udzOZhWe5rKJnCQOlvWCj/gy1+r0cmExiw+cnm625YYiIx8qAy+rxD WvQgMxjEoJ9RMz74DDzoYV0cEZd9fIWBvu19nxlEKwAH50Xx4FuNpoFVUcgflwQJEmrS eJ6h18W2yIpdYB+fSPatYOOy2+0JgVN81vNGq4AmpfL1sQJ+L+DzVIA4kaxrkDdk+Kxs yX3KZ6hxCMxxepCxPmR0I5QKTDhwjTUuZ5zXzQk1rkP4kdAB8qBwDUmsRn4cQl61qejp GXqhyHZjijzndqJQIuKbqe8zAn+FYcY7F4/TpJ4UFQoxhUpsZcfqCaYEyvGEMbo4XoTB 8oKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ZYN39wk6a5NRPTtVgQ2fmBkBZpoYFPy36qtJQgrzBbQ=; b=yPFSaMK8U9bDujjnA0KK3mVkm7uZ8n4WdNUVAjWUeIvfPABdiS8wG2LuyAZujT2Sq/ FS4J4P70lcghZiLrhUUW5qmiO7Ckxv0pnGhVvXf2fKHvICZ4P7ZcsHwjl70SOhXvHnRa VpKoK6R3dPG3Xrfzat1IJrBksIRyXskhNLsDOtSGMU0rO9Fjq2DxIssKXNMpLgTjtQV8 QshrOEBcOa/HslFQFKmgF8t26JnOnLfI18YNdKvAXKLRnKHFxujl6ac7DssNAXhSs8PH Cq1QeKoIoBaWbNMjR/54Qj3s9+ekHJ512MpLFPWkVpv5DSrB+c9Z5eczuboMsmABFy1k QRyQ== X-Gm-Message-State: AFqh2kpRuDppNztpkmQgDM83KhH824W9mzMndx2CiFCh3WSLzrPOEOi4 ZYXlazbTLOHfdlBjsC2gDpMhe1e/fPE= X-Google-Smtp-Source: AMrXdXtIxuiZo4uQS0TAEd0ESAD1k/+gcNYoYbiUur7Y/bROd25mlKsy0v4oVfmQ6pLGio+ZNRfdiUZO9I0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:a50c:b0:226:744:d464 with SMTP id a12-20020a17090aa50c00b002260744d464mr2481575pjq.62.1672967632838; Thu, 05 Jan 2023 17:13:52 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:56 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-24-seanjc@google.com> Subject: [PATCH v5 23/33] KVM: x86: Inhibit APICv/AVIC if the optimized physical map is disabled From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Inhibit APICv/AVIC if the optimized physical map is disabled so that KVM KVM provides consistent APIC behavior if xAPIC IDs are aliased due to vcpu_id being truncated and the x2APIC hotplug hack isn't enabled. If the hotplug hack is disabled, events that are emulated by KVM will follow architectural behavior (all matching vCPUs receive events, even if the "match" is due to truncation), whereas APICv and AVIC will deliver events only to the first matching vCPU, i.e. the vCPU that matches without truncation. Note, the "extra" inhibit is needed because KVM deliberately ignores mismatches due to truncation when applying the APIC_ID_MODIFIED inhibit so that large VMs (>255 vCPUs) can run with APICv/AVIC. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm_host.h | 6 ++++++ arch/x86/kvm/lapic.c | 13 ++++++++++++- arch/x86/kvm/svm/avic.c | 1 + arch/x86/kvm/vmx/vmx.c | 1 + 4 files changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 732421a0ad02..5865bad08a23 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1174,6 +1174,12 @@ enum kvm_apicv_inhibit { */ APICV_INHIBIT_REASON_BLOCKIRQ, =20 + /* + * APICv is disabled because not all vCPUs have a 1:1 mapping between + * APIC ID and vCPU, _and_ KVM is not applying its x2APIC hotplug hack. + */ + APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED, + /* * For simplicity, the APIC acceleration is inhibited * first time either APIC ID or APIC base are changed by the guest diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index e9f258de91bd..297da684c25f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -386,6 +386,16 @@ void kvm_recalculate_apic_map(struct kvm *kvm) cluster[ldr] =3D apic; } out: + /* + * The optimized map is effectively KVM's internal version of APICv, + * and all unwanted aliasing that results in disabling the optimized + * map also applies to APICv. + */ + if (!new) + kvm_set_apicv_inhibit(kvm, APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED); + else + kvm_clear_apicv_inhibit(kvm, APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED); + old =3D rcu_dereference_protected(kvm->arch.apic_map, lockdep_is_held(&kvm->arch.apic_map_lock)); rcu_assign_pointer(kvm->arch.apic_map, new); @@ -2158,7 +2168,8 @@ static void kvm_lapic_xapic_id_updated(struct kvm_lap= ic *apic) /* * Deliberately truncate the vCPU ID when detecting a modified APIC ID * to avoid false positives if the vCPU ID, i.e. x2APIC ID, is a 32-bit - * value. + * value. If the wrap/truncation results in unwanted aliasing, APICv + * will be inhibited as part of updating KVM's optimized APIC maps. */ if (kvm_xapic_id(apic) =3D=3D (u8)apic->vcpu->vcpu_id) return; diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 76da9f19272e..d1ac19f053ce 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -965,6 +965,7 @@ bool avic_check_apicv_inhibit_reasons(enum kvm_apicv_in= hibit reason) BIT(APICV_INHIBIT_REASON_PIT_REINJ) | BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | BIT(APICV_INHIBIT_REASON_SEV) | + BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED); =20 diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 8ed14fcfe870..ef84d11a0fe4 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -8029,6 +8029,7 @@ static bool vmx_check_apicv_inhibit_reasons(enum kvm_= apicv_inhibit reason) BIT(APICV_INHIBIT_REASON_ABSENT) | BIT(APICV_INHIBIT_REASON_HYPERV) | BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | + BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED); =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 A42E1C3DA7A for ; Fri, 6 Jan 2023 01:16:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229938AbjAFBQo (ORCPT ); Thu, 5 Jan 2023 20:16:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229757AbjAFBP7 (ORCPT ); Thu, 5 Jan 2023 20:15:59 -0500 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 7B3A73E863 for ; Thu, 5 Jan 2023 17:14:10 -0800 (PST) Received: by mail-pg1-x549.google.com with SMTP id r126-20020a632b84000000b004393806c06eso216745pgr.4 for ; Thu, 05 Jan 2023 17:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=o4UAETXkM62nM2yYuGHBJ1AdJGjwtbarF4DTw13SG8M=; b=j2HNEccBP7np7M1sGlh/lR9iiwoxeu2tDdMfTtFmom/1SMGw9AQClRjRPjxLcQnERb P92ChTGaFkoInGodIaAPnUdfY53bosFhp2WBXli5H0PS/7/07MxxqJE4tVPSrQgL9zZ4 iy1PiDEc0mmhxGDEB4e9NZbEj87Xzb/ZJTKCAfEMolx9oL+EUzsxesFZVBys6msUS/dV BlERFFcesl/Aa0+XdXyltbE2MS4q6xScax+5zeprGT9eHK5nBMbpS06o+TwXC7g9SbZh y2NdVD5PQ5H5gTO6T23k2qqLzFuLP2O4eK7GOViM+89twqSlz/6vLB7iSc/KWmjVNb6L ngZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=o4UAETXkM62nM2yYuGHBJ1AdJGjwtbarF4DTw13SG8M=; b=JSDbWrD9ACsmneEMnSvpKY+4E20r6+d6E4pO/k4nPU9msbFGlbKJcW8j0RRf9r+BZZ yUnya16QLTgCsCwRQ75Hi+kewz7KAbU/tWo9UWW1/hgvdQncKk6M1Tl+jnfvYYBjVPh4 v+MGhDHf2/4BlVoVQcAxDOjRyuAF8AXTa6vsuV04ZvhDapfTNuMevRd9mGwzXDiu0FOm Xae5sVfNUS/7vVlLUytYLskgyRzMk0GwuoqESQailk/oP8rAT4/Kv5vZUudNbOP4pJPp 1a87JiN3qknpgQyVmYqdGmP5VCXFIKJRYlvDDI8q+WTKL34yz/hgDPBFbodIrxBE7yXM qcDA== X-Gm-Message-State: AFqh2krladJi4DOtGA+m+s56lEWTikJHvgl979FgryCoAoh/I4sePL0z V1JrafXLtYsh7DQWNxg4ST6F6U8lfLs= X-Google-Smtp-Source: AMrXdXuxaeNgG3qV2/dc3S4AdIlGeqilvlmQHbJQGHhMswaBgY/s1jn0nF3f3Xk4hQBpGykQGzmLpuaPAjQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:2e05:b0:225:b536:1209 with SMTP id q5-20020a17090a2e0500b00225b5361209mr4108245pjd.101.1672967634940; Thu, 05 Jan 2023 17:13:54 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:57 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-25-seanjc@google.com> Subject: [PATCH v5 24/33] KVM: SVM: Inhibit AVIC if vCPUs are aliased in logical mode From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Inhibit SVM's AVIC if multiple vCPUs are aliased to the same logical ID. Architecturally, all CPUs whose logical ID matches the MDA are supposed to receive the interrupt; overwriting existing entries in AVIC's logical=3D>physical map can result in missed IPIs. Fixes: 18f40c53e10f ("svm: Add VMEXIT handlers for AVIC") Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm_host.h | 6 ++++++ arch/x86/kvm/lapic.c | 5 +++++ arch/x86/kvm/svm/avic.c | 3 ++- 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 5865bad08a23..b41a01b3a4af 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1218,6 +1218,12 @@ enum kvm_apicv_inhibit { * AVIC is disabled because SEV doesn't support it. */ APICV_INHIBIT_REASON_SEV, + + /* + * AVIC is disabled because not all vCPUs with a valid LDR have a 1:1 + * mapping between logical ID and vCPU. + */ + APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED, }; =20 struct kvm_arch { diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 297da684c25f..0faf80cdc1be 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -396,6 +396,11 @@ void kvm_recalculate_apic_map(struct kvm *kvm) else kvm_clear_apicv_inhibit(kvm, APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED); =20 + if (!new || new->logical_mode =3D=3D KVM_APIC_MODE_MAP_DISABLED) + kvm_set_apicv_inhibit(kvm, APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED); + else + kvm_clear_apicv_inhibit(kvm, APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED); + old =3D rcu_dereference_protected(kvm->arch.apic_map, lockdep_is_held(&kvm->arch.apic_map_lock)); rcu_assign_pointer(kvm->arch.apic_map, new); diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index d1ac19f053ce..1fd473a57159 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -967,7 +967,8 @@ bool avic_check_apicv_inhibit_reasons(enum kvm_apicv_in= hibit reason) BIT(APICV_INHIBIT_REASON_SEV) | BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | - BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED); + BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED) | + BIT(APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED); =20 return supported & BIT(reason); } --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 97330C4708E for ; Fri, 6 Jan 2023 01:16:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233363AbjAFBQt (ORCPT ); Thu, 5 Jan 2023 20:16:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231882AbjAFBQH (ORCPT ); Thu, 5 Jan 2023 20:16:07 -0500 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 DAA573E86F for ; Thu, 5 Jan 2023 17:14:11 -0800 (PST) Received: by mail-pf1-x44a.google.com with SMTP id ct7-20020a056a000f8700b00582e67e255bso51206pfb.9 for ; Thu, 05 Jan 2023 17:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=7iPI0dl/ko2Lo6A5R8RXBXgr3khsxs/MyGTJ8pdxMPM=; b=ZaSgs0lSr/JJODEuSDEI4kPBIyYKk9ZEyKSnyX14YyGd+KcacGTqLZcQzCGgZE1j/6 NhleuIjiv89JqbxHeQJ2Fprh/hJA77EhZiE7Un9s7rlCZWL3wpLO7HF3MQmyLZf7y4Ey VcOQdJzEVe7LplFmBqKjTZykJBAlohsByvNNW9lasR6poy+KaKwQfCauHCUg8lk2GuCr STJy0HpuTrmVNyrlm//D66UZkS31Zf8sJ865YAvoNzjGqsLiiU9H/LbsQC4gJDvKi18C ZEIF2PUBAPFwzWPsCyqVAYSubqlxyCUI3MWPQbqMACZP+SDYU3Zh1jblTcAvddN2fd5p Qc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=7iPI0dl/ko2Lo6A5R8RXBXgr3khsxs/MyGTJ8pdxMPM=; b=GvdWmCzCbkjSCVgJv4ryNUAD8zZ/jBEmV1dPyT/tSQpBRu2ELtbhl5W+3PdYnGlMB5 Q/bqI7wPC1wuuRHquOB+qUUx2DDWjRGXsjQiq8URuCynSLDgjqSE6AkmqKKGmxGpBgG4 k0vgN98ppy0G2VH293ETE1F6oTnxsI2GrAkSkmFY8eQybLC/+fIB6ibVNFGW21FZqcR+ 687r0yVcKHML94hjyx4c4F5B8bL98Jqmantm4B8RR62wEbAGW4AW5xi10ocaFRRb+XAs apEw1vy2gIuEAvMZxMUdHPMKAEGTTr9/a86+oSDNH1TfpqyNyZMWX/NXedxnMPJTMbM6 lO2g== X-Gm-Message-State: AFqh2krKmsRdm2BunbWouMd+sAymGatr6dhzTnIzpJjP3QbKvFQCJZ/C ScXz+BUnKH9Kq3OgXYrLVX153smD5q4= X-Google-Smtp-Source: AMrXdXuV5ubZU24A/2Z/LOyqgUjmQaAt0DIadBOPeaJ7WZw6iqYZ9yittKRNJ+NxDunMF7rB5NynpgV5WyA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:3604:b0:219:d1eb:b8a1 with SMTP id ml4-20020a17090b360400b00219d1ebb8a1mr4230658pjb.174.1672967636674; Thu, 05 Jan 2023 17:13:56 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:58 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-26-seanjc@google.com> Subject: [PATCH v5 25/33] KVM: SVM: Always update local APIC on writes to logical dest register From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Update the vCPU's local (virtual) APIC on LDR writes even if the write "fails". The APIC needs to recalc the optimized logical map even if the LDR is invalid or zero, e.g. if the guest clears its LDR, the optimized map will be left as is and the vCPU will receive interrupts using its old LDR. Fixes: 18f40c53e10f ("svm: Add VMEXIT handlers for AVIC") Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 1fd473a57159..144e383a4c5d 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -573,7 +573,7 @@ static void avic_invalidate_logical_id_entry(struct kvm= _vcpu *vcpu) clear_bit(AVIC_LOGICAL_ID_ENTRY_VALID_BIT, (unsigned long *)entry); } =20 -static int avic_handle_ldr_update(struct kvm_vcpu *vcpu) +static void avic_handle_ldr_update(struct kvm_vcpu *vcpu) { int ret =3D 0; struct vcpu_svm *svm =3D to_svm(vcpu); @@ -582,10 +582,10 @@ static int avic_handle_ldr_update(struct kvm_vcpu *vc= pu) =20 /* AVIC does not support LDR update for x2APIC */ if (apic_x2apic_mode(vcpu->arch.apic)) - return 0; + return; =20 if (ldr =3D=3D svm->ldr_reg) - return 0; + return; =20 avic_invalidate_logical_id_entry(vcpu); =20 @@ -594,8 +594,6 @@ static int avic_handle_ldr_update(struct kvm_vcpu *vcpu) =20 if (!ret) svm->ldr_reg =3D ldr; - - return ret; } =20 static void avic_handle_dfr_update(struct kvm_vcpu *vcpu) @@ -617,8 +615,7 @@ static int avic_unaccel_trap_write(struct kvm_vcpu *vcp= u) =20 switch (offset) { case APIC_LDR: - if (avic_handle_ldr_update(vcpu)) - return 0; + avic_handle_ldr_update(vcpu); break; case APIC_DFR: avic_handle_dfr_update(vcpu); --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 997EBC4708E for ; Fri, 6 Jan 2023 01:17:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233683AbjAFBRG (ORCPT ); Thu, 5 Jan 2023 20:17:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231646AbjAFBQO (ORCPT ); Thu, 5 Jan 2023 20:16:14 -0500 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 B796865ACD for ; Thu, 5 Jan 2023 17:14:17 -0800 (PST) Received: by mail-pj1-x104a.google.com with SMTP id g15-20020a17090a128f00b0022628a85a1cso125277pja.4 for ; Thu, 05 Jan 2023 17:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=J1V7EU+EWrvW5nteFG4b5GW6PZRHrRfQBnmCjlAIqUI=; b=rDxj9tQKYiqzEAX+7OptTHqneRJr0YZTO6aN9x2uXwofIdTLT+XyoddoR04GgEymcW 25D9NbmM6Vgxi0CgBfoiD3JVPyjTkX0GiuWUYqrP0ZNe05jdX/VbXNcZ5c8J0vzsBsv6 ujJcI9s4r9ExZTWATWI8o6fbaFJoF+aOmrVNfw4fCQSYCaLNG5VsjIGmNR+08wBm3Drb B57EFQ87pbPdeCc3NufrdRe1bo9pg7o0yCRUEwvs3Hgjzdwo2Ca5VTroIQEdWgSVzzYv mlhm/Z6a0pm/y23HQH6gmGxkAA7HtHBaUvgSffwXOme8r+mYa7SGg7BsGqygbGmKSCda kYBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=J1V7EU+EWrvW5nteFG4b5GW6PZRHrRfQBnmCjlAIqUI=; b=qdVlcKc8lnOmRQbw4bVLwYn8az+yFPAAhnRNzNH4xxozXwJRBl+g0YnA28U6xGUK4q AaJLw2IAtMgnl7VmbL/jQzJ4BltplceCOcSEgfBxRieLJG4s5NPbr3KEooNF5Mjvui4/ 9K6BBU7o2mNK+3TUMCOtGmxs40LQwR2E3QJNhtV8mC3l1Ho2RSs0Yqh+wBG+j9jloSlm X3hMhefK2BH18fPsGU1gdB66P8UmuGlj3Qx7ZrYCHiFJOMT6QoequgROollcx87xdTre xBGKWkZjK4JKjOVANBGwzGw8PYxtO55OXt7Kq3d4BRBEuqrq4HAqlaZarkvOKi/7xKrK pDdA== X-Gm-Message-State: AFqh2kq8shHN3KpkivsVE0B5iMKPSi2QQ3/AmoTIBrHs7W2SQEN1otnH HScVHpf1uAlvQ/r3zZgMWHBQoQcmwkA= X-Google-Smtp-Source: AMrXdXuM1Zf3I6N21WYVCEKzK0BaaasVg37qf8H7UQ2G6VwfuCFBj22ob5iTFvQCuSf2Ul2Ql0Gy5P66Hf4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:af91:b0:219:9eaa:80e2 with SMTP id w17-20020a17090aaf9100b002199eaa80e2mr3338754pjq.207.1672967638285; Thu, 05 Jan 2023 17:13:58 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:12:59 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-27-seanjc@google.com> Subject: [PATCH v5 26/33] KVM: SVM: Update svm->ldr_reg cache even if LDR is "bad" From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Update SVM's cache of the LDR even if the new value is "bad". Leaving stale information in the cache can result in KVM missing updates and/or invalidating the wrong entry, e.g. if avic_invalidate_logical_id_entry() is triggered after a different vCPU has "claimed" the old LDR. Fixes: 18f40c53e10f ("svm: Add VMEXIT handlers for AVIC") Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 144e383a4c5d..5b33f91b701c 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -539,7 +539,7 @@ static u32 *avic_get_logical_id_entry(struct kvm_vcpu *= vcpu, u32 ldr, bool flat) return &logical_apic_id_table[index]; } =20 -static int avic_ldr_write(struct kvm_vcpu *vcpu, u8 g_physical_id, u32 ldr) +static void avic_ldr_write(struct kvm_vcpu *vcpu, u8 g_physical_id, u32 ld= r) { bool flat; u32 *entry, new_entry; @@ -547,15 +547,13 @@ static int avic_ldr_write(struct kvm_vcpu *vcpu, u8 g= _physical_id, u32 ldr) flat =3D kvm_lapic_get_reg(vcpu->arch.apic, APIC_DFR) =3D=3D APIC_DFR_FLA= T; entry =3D avic_get_logical_id_entry(vcpu, ldr, flat); if (!entry) - return -EINVAL; + return; =20 new_entry =3D READ_ONCE(*entry); new_entry &=3D ~AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK; new_entry |=3D (g_physical_id & AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_M= ASK); new_entry |=3D AVIC_LOGICAL_ID_ENTRY_VALID_MASK; WRITE_ONCE(*entry, new_entry); - - return 0; } =20 static void avic_invalidate_logical_id_entry(struct kvm_vcpu *vcpu) @@ -575,7 +573,6 @@ static void avic_invalidate_logical_id_entry(struct kvm= _vcpu *vcpu) =20 static void avic_handle_ldr_update(struct kvm_vcpu *vcpu) { - int ret =3D 0; struct vcpu_svm *svm =3D to_svm(vcpu); u32 ldr =3D kvm_lapic_get_reg(vcpu->arch.apic, APIC_LDR); u32 id =3D kvm_xapic_id(vcpu->arch.apic); @@ -589,11 +586,8 @@ static void avic_handle_ldr_update(struct kvm_vcpu *vc= pu) =20 avic_invalidate_logical_id_entry(vcpu); =20 - if (ldr) - ret =3D avic_ldr_write(vcpu, id, ldr); - - if (!ret) - svm->ldr_reg =3D ldr; + svm->ldr_reg =3D ldr; + avic_ldr_write(vcpu, id, ldr); } =20 static void avic_handle_dfr_update(struct kvm_vcpu *vcpu) --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 C0A10C3DA7A for ; Fri, 6 Jan 2023 01:17:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232119AbjAFBRQ (ORCPT ); Thu, 5 Jan 2023 20:17:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229643AbjAFBQ1 (ORCPT ); Thu, 5 Jan 2023 20:16:27 -0500 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9922265ADD for ; Thu, 5 Jan 2023 17:14:20 -0800 (PST) Received: by mail-yb1-xb4a.google.com with SMTP id k18-20020a25e812000000b0077cc9ab9dd9so425086ybd.8 for ; Thu, 05 Jan 2023 17:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=G/xMBTyIGc3/xkevi67fvj8wyXuCW/OQud7CJpQaZ3I=; b=d6QlI5kw/H8GG/AjdSQEB/z5oht/Dlvzb9pO6xzHuZuAfEpDPK0ubjoADbbBmfnpip lWPSmAFPSaimE6lYMZceH/Dq8aCshL0Uyq6vA0W4P5OLUz3h5Vf5ONtVay7T/m59CFem DMJdWK90qXXkUTFbGZuPDdtyzYWxe8hii8trgtihyNeKBPcmz5CtIFQ/23aaAfs94xsl Sg4uVP8j8Dy9Mt38n+KhVJN6fk52HJx9m33qQD1GeqhFFIKqoZkU98q5/5BQS5/EonhA +b0dawmxW7RqY0D6xUNS6b67hvED4rvw20R73gddAGkTQezXNkdFYleIciX/WQAf7W+I ZeYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=G/xMBTyIGc3/xkevi67fvj8wyXuCW/OQud7CJpQaZ3I=; b=rwFw9brKjPKs/mOaWeTNJyZeCZ1JWYXpuuMwPUGWcKySTR433tEvHqhpea5FnfHfs9 RBQ/HF2k1XRFjLxFNeA+zY0od3CdymzjO6ds1/gWdCRVoGo2pOZqNnLv8UwZohmKj0bO FQbmyUeuNDwtm84F3xpskIgq2cKtaz3wwV18Y9rQihl1gXWJbotJ92R+buy9x+mxdtlX DyLx4eXHI1tpJneeSr/fK7HRhvOjfvr4k0HZ6blX89x8x+VeAiSPyM/V/6miQqsA3SlD amGYtAf5eCZPtG57q1fJHkm7UCkd2DKfphymWoSCjufrcwnAdCnV8sRw5i4jUvOk5u65 /SfA== X-Gm-Message-State: AFqh2kodHBgwBEFPQ5YSU2le0cRBNQ8Sug1qMkAfLVGI4JZfMNzoit5q QeMFwQIRoeozrP6AT7wNZtVZyPLRyY8= X-Google-Smtp-Source: AMrXdXtJ8A+dklY8RabbB87iQeh3UphH07RFupduopzL4/GE/67V7Z6y5SX3TO8pDN528R2ZOzCaLSqapgs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:bd0a:0:b0:7b3:f488:ea6d with SMTP id f10-20020a25bd0a000000b007b3f488ea6dmr674590ybk.311.1672967640100; Thu, 05 Jan 2023 17:14:00 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:00 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-28-seanjc@google.com> Subject: [PATCH v5 27/33] KVM: SVM: Require logical ID to be power-of-2 for AVIC entry From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Do not modify AVIC's logical ID table if the logical ID portion of the LDR is not a power-of-2, i.e. if the LDR has multiple bits set. Taking only the first bit means that KVM will fail to match MDAs that intersect with "higher" bits in the "ID" The "ID" acts as a bitmap, but is referred to as an ID because there's an implicit, unenforced "requirement" that software only set one bit. This edge case is arguably out-of-spec behavior, but KVM cleanly handles it in all other cases, e.g. the optimized logical map (and AVIC!) is also disabled in this scenario. Refactor the code to consolidate the checks, and so that the code looks more like avic_kick_target_vcpus_fast(). Fixes: 18f40c53e10f ("svm: Add VMEXIT handlers for AVIC") Cc: Suravee Suthikulpanit Cc: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 5b33f91b701c..eb979695e7d8 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -513,26 +513,26 @@ unsigned long avic_vcpu_get_apicv_inhibit_reasons(str= uct kvm_vcpu *vcpu) static u32 *avic_get_logical_id_entry(struct kvm_vcpu *vcpu, u32 ldr, bool= flat) { struct kvm_svm *kvm_svm =3D to_kvm_svm(vcpu->kvm); - int index; u32 *logical_apic_id_table; - int dlid =3D GET_APIC_LOGICAL_ID(ldr); + u32 cluster, index; =20 - if (!dlid) - return NULL; + ldr =3D GET_APIC_LOGICAL_ID(ldr); =20 - if (flat) { /* flat */ - index =3D ffs(dlid) - 1; - if (index > 7) + if (flat) { + cluster =3D 0; + } else { + cluster =3D (ldr >> 4); + if (cluster >=3D 0xf) return NULL; - } else { /* cluster */ - int cluster =3D (dlid & 0xf0) >> 4; - int apic =3D ffs(dlid & 0x0f) - 1; - - if ((apic < 0) || (apic > 7) || - (cluster >=3D 0xf)) - return NULL; - index =3D (cluster << 2) + apic; + ldr &=3D 0xf; } + if (!ldr || !is_power_of_2(ldr)) + return NULL; + + index =3D __ffs(ldr); + if (WARN_ON_ONCE(index > 7)) + return NULL; + index +=3D (cluster << 2); =20 logical_apic_id_table =3D (u32 *) page_address(kvm_svm->avic_logical_id_t= able_page); =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 99866C3DA7A for ; Fri, 6 Jan 2023 01:17:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232739AbjAFBRY (ORCPT ); Thu, 5 Jan 2023 20:17:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232168AbjAFBQ2 (ORCPT ); Thu, 5 Jan 2023 20:16:28 -0500 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C669D65AEB for ; Thu, 5 Jan 2023 17:14:21 -0800 (PST) Received: by mail-pf1-x449.google.com with SMTP id bx21-20020a056a00429500b00582d85bb03bso35761pfb.16 for ; Thu, 05 Jan 2023 17:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=kgKvdTfQ27wv6seVSF5aAgO210OBrcuZvgQgigmAgek=; b=WJv9DzW7OiR5WxhCTMswF2puPwUNWRNLasJ4h3JJ3mwxe13GYAmZ+MCwjs0kXjBg0v Mv0JiXikj5UXUyf3Q7VFTI2RxiiDCS1Aq09YHScmHzn6YK2l0qRFB9713Vqmf/At92QU VPHkLv78SiClzvEy/3z0eV1D60+5F5LDoiilczrSvFYkD9QMY8xo+LGRGsiTe9hsxoWp U2Z8DnSXNNc0TXoqRwMqEuldIle0PtrgK4nbuO8TK4nvH+DBn6o0uAMPPiU4ZIWgCCOe 0ucXFRf10VCnvSydh5GnIZD2vQJCE6fnMFBK+e5WubcHBAvjx8hJUemWLu/Fwlgdffie Qnxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kgKvdTfQ27wv6seVSF5aAgO210OBrcuZvgQgigmAgek=; b=XBSoV6r9CIjxH/qAThfRr2oMYH7Pjs1zD2hrcDtmcTZFgkVHryxfe9NoEk5flUPwev 7ttxp2EsJ8AQjcg+lJdLJAStwxm+SJKvVUKY1yTOeqxioh1GsSg8ONWArOO2zp2i+ZZ+ bMw2NG/zCGSEaYZAUQCzKhTpQTWrJjcuQO20gBhnAZFGl+dOeByvk7G21TyclUbbHO3K E18pTkKj4Sp97Hxe9lPptVvXPv02ZgTKoMLm52c3uHZ5g7ieo56XU6GkHRP+zz4vZy0K TviYQFe3FCAP2yMiRMINRAL2DoVactlhviS+Niq9UFQAWFhdRXxGpsrWNMWrX1+T4peo erlw== X-Gm-Message-State: AFqh2krOnLFT7flA70kPZkif+2Cy2lSgecC0lF/zIbe7uyxkblj4PLcm U3zA57AHfIMkGDpEi3EXnz9MRxhWvLI= X-Google-Smtp-Source: AMrXdXuJbFofIitOc/6xWYIyeZDywhl+ROr6/sAMLkCKVeOGD0jStiz6cC6dnMAksAsxqesy3qXq724fV8w= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:bd12:b0:225:b164:8874 with SMTP id y18-20020a17090abd1200b00225b1648874mr4020777pjr.87.1672967641623; Thu, 05 Jan 2023 17:14:01 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:01 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-29-seanjc@google.com> Subject: [PATCH v5 28/33] KVM: SVM: Handle multiple logical targets in AVIC kick fastpath From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Iterate over all target logical IDs in the AVIC kick fastpath instead of bailing if there is more than one target. Now that KVM inhibits AVIC if vCPUs aren't mapped 1:1 with logical IDs, each bit in the destination is guaranteed to match to at most one vCPU, i.e. iterating over the bitmap is guaranteed to kick each valid target exactly once. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 112 ++++++++++++++++++++++------------------ 1 file changed, 63 insertions(+), 49 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index eb979695e7d8..2c6737f72bd4 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -327,6 +327,50 @@ static void avic_kick_vcpu(struct kvm_vcpu *vcpu, u32 = icrl) icrl & APIC_VECTOR_MASK); } =20 +static void avic_kick_vcpu_by_physical_id(struct kvm *kvm, u32 physical_id, + u32 icrl) +{ + /* + * KVM inhibits AVIC if any vCPU ID diverges from the vCPUs APIC ID, + * i.e. APIC ID =3D=3D vCPU ID. + */ + struct kvm_vcpu *target_vcpu =3D kvm_get_vcpu_by_id(kvm, physical_id); + + /* Once again, nothing to do if the target vCPU doesn't exist. */ + if (unlikely(!target_vcpu)) + return; + + avic_kick_vcpu(target_vcpu, icrl); +} + +static void avic_kick_vcpu_by_logical_id(struct kvm *kvm, u32 *avic_logica= l_id_table, + u32 logid_index, u32 icrl) +{ + u32 physical_id; + + if (avic_logical_id_table) { + u32 logid_entry =3D avic_logical_id_table[logid_index]; + + /* Nothing to do if the logical destination is invalid. */ + if (unlikely(!(logid_entry & AVIC_LOGICAL_ID_ENTRY_VALID_MASK))) + return; + + physical_id =3D logid_entry & + AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK; + } else { + /* + * For x2APIC, the logical APIC ID is a read-only value that is + * derived from the x2APIC ID, thus the x2APIC ID can be found + * by reversing the calculation (stored in logid_index). Note, + * bits 31:20 of the x2APIC ID aren't propagated to the logical + * ID, but KVM limits the x2APIC ID limited to KVM_MAX_VCPU_IDS. + */ + physical_id =3D logid_index; + } + + avic_kick_vcpu_by_physical_id(kvm, physical_id, icrl); +} + /* * A fast-path version of avic_kick_target_vcpus(), which attempts to match * destination APIC ID to vCPU without looping through all vCPUs. @@ -334,11 +378,10 @@ static void avic_kick_vcpu(struct kvm_vcpu *vcpu, u32= icrl) static int avic_kick_target_vcpus_fast(struct kvm *kvm, struct kvm_lapic *= source, u32 icrl, u32 icrh, u32 index) { - u32 l1_physical_id, dest; - struct kvm_vcpu *target_vcpu; int dest_mode =3D icrl & APIC_DEST_MASK; int shorthand =3D icrl & APIC_SHORT_MASK; struct kvm_svm *kvm_svm =3D to_kvm_svm(kvm); + u32 dest; =20 if (shorthand !=3D APIC_DEST_NOSHORT) return -EINVAL; @@ -355,14 +398,14 @@ static int avic_kick_target_vcpus_fast(struct kvm *kv= m, struct kvm_lapic *source if (!apic_x2apic_mode(source) && dest =3D=3D APIC_BROADCAST) return -EINVAL; =20 - l1_physical_id =3D dest; - - if (WARN_ON_ONCE(l1_physical_id !=3D index)) + if (WARN_ON_ONCE(dest !=3D index)) return -EINVAL; =20 + avic_kick_vcpu_by_physical_id(kvm, dest, icrl); } else { - u32 bitmap, cluster; - int logid_index; + u32 *avic_logical_id_table; + unsigned long bitmap, i; + u32 cluster; =20 if (apic_x2apic_mode(source)) { /* 16 bit dest mask, 16 bit cluster id */ @@ -382,50 +425,21 @@ static int avic_kick_target_vcpus_fast(struct kvm *kv= m, struct kvm_lapic *source if (unlikely(!bitmap)) return 0; =20 - if (!is_power_of_2(bitmap)) - /* multiple logical destinations, use slow path */ - return -EINVAL; - - logid_index =3D cluster + __ffs(bitmap); - - if (apic_x2apic_mode(source)) { - /* - * For x2APIC, the logical APIC ID is a read-only value - * that is derived from the x2APIC ID, thus the x2APIC - * ID can be found by reversing the calculation (done - * above). Note, bits 31:20 of the x2APIC ID are not - * propagated to the logical ID, but KVM limits the - * x2APIC ID limited to KVM_MAX_VCPU_IDS. - */ - l1_physical_id =3D logid_index; - } else { - u32 *avic_logical_id_table =3D - page_address(kvm_svm->avic_logical_id_table_page); - - u32 logid_entry =3D avic_logical_id_table[logid_index]; - - if (WARN_ON_ONCE(index !=3D logid_index)) - return -EINVAL; - - /* Nothing to do if the logical destination is invalid. */ - if (unlikely(!(logid_entry & AVIC_LOGICAL_ID_ENTRY_VALID_MASK))) - return 0; - - l1_physical_id =3D logid_entry & - AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK; - } + if (apic_x2apic_mode(source)) + avic_logical_id_table =3D NULL; + else + avic_logical_id_table =3D page_address(kvm_svm->avic_logical_id_table_p= age); + + /* + * AVIC is inhibited if vCPUs aren't mapped 1:1 with logical + * IDs, thus each bit in the destination is guaranteed to map + * to at most one vCPU. + */ + for_each_set_bit(i, &bitmap, 16) + avic_kick_vcpu_by_logical_id(kvm, avic_logical_id_table, + cluster + i, icrl); } =20 - /* - * KVM inhibits AVIC if any vCPU ID diverges from the vCPUs APIC ID, - * i.e. APIC ID =3D=3D vCPU ID. Once again, nothing to do if the target - * vCPU doesn't exist. - */ - target_vcpu =3D kvm_get_vcpu_by_id(kvm, l1_physical_id); - if (unlikely(!target_vcpu)) - return 0; - - avic_kick_vcpu(target_vcpu, icrl); return 0; } =20 --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 BD2D0C53210 for ; Fri, 6 Jan 2023 01:17:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233839AbjAFBRa (ORCPT ); Thu, 5 Jan 2023 20:17:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232814AbjAFBQa (ORCPT ); Thu, 5 Jan 2023 20:16:30 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF8C765AF2 for ; Thu, 5 Jan 2023 17:14:22 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-47ede4426e1so3120787b3.7 for ; Thu, 05 Jan 2023 17:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=0PXIy8RA30k82n5MqadBULMYpw3jcQQNxAI0MLkfm2o=; b=ARYzhqPubKAcUMlq5dSBX0xvRbkdMD3Z7If0ag7prbjxIne2GkJ8lAhHrtaEOpMtq7 wIIAhYz1/Ajx9d5Cslo0C4NAiwSy8WApA2ndyhaXFs6IngyBWHUw8/RvgrKmAvHUhpkO cyOgu6KCI3mBFPHHb5Py5lPdjDvIYKL4PgTbXDJoeb9G5AmvTkBPp7JhJ96D5XJeOmNF H71WGUwe4Z9AK+ykt/tiEyDRK2He33wLTdGnjX2xFBC78IVPGeo7k2WIXLG0DcCUuoTc xxOGpURmrBMBR/Kj4dorDzcHumIWTMXaSANO4lHr0MkNbDkcual08RTxiy0tgP3OCVKT 4hUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=0PXIy8RA30k82n5MqadBULMYpw3jcQQNxAI0MLkfm2o=; b=vCoZhtwVQpHeNmymXkVIXtq6YTrS0tyIqlCkjrrekGFFl53Rtoo3B1N/KlycD2Fb0R inpI0m8i+kQw3MpObC4qQyIMz2Z1tIy5TpDvlq3RBl+ADVXQmmDIiVydzl5NpJSIcYC1 KeAmaW4VC+/MBpGuaoiM95H5IKgLGj1zOP++vrXLeqgbJhFR6fPUlX+Ku/6+lBFYxgXJ lm1U0x90ROO8J+IgZqj0aVpHo+R5ap1QOr2Fq2ed15qFZn3/3KusB1PYZzfi5PfxHEzZ OXmZ/wkJ3LIbGCIAf0kUFXzDbFERG2DswQ3sXIj4uNgRUFyi+AnO+DCh80zn/CXdCOIR SP2w== X-Gm-Message-State: AFqh2kr8f4nPYGfjD/IgnOS9KPZ1FxuK/9XcxtQj0dhPoWcoF2mw21WL W3J3z0QJhvMYIQEO6Q0U3DrYEUr0Zo8= X-Google-Smtp-Source: AMrXdXt4VBg4zaH9HqqIlH27H/G6sq0m1dLXG6txeQ75uTMkvGpBIpTSTbajtVV7xXJrKV//LkmnjgWpK6g= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:d095:0:b0:7b6:daae:ad50 with SMTP id h143-20020a25d095000000b007b6daaead50mr235713ybg.89.1672967643231; Thu, 05 Jan 2023 17:14:03 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:02 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-30-seanjc@google.com> Subject: [PATCH v5 29/33] KVM: SVM: Ignore writes to Remote Read Data on AVIC write traps From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Drop writes to APIC_RRR, a.k.a. Remote Read Data Register, on AVIC unaccelerated write traps. The register is read-only and isn't emulated by KVM. Sending the register through kvm_apic_write_nodecode() will result in screaming when x2APIC is enabled due to the unexpected failure to retrieve the MSR (KVM expects that only "legal" accesses will trap). Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode= ") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 2c6737f72bd4..ff08732469cb 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -628,6 +628,9 @@ static int avic_unaccel_trap_write(struct kvm_vcpu *vcp= u) case APIC_DFR: avic_handle_dfr_update(vcpu); break; + case APIC_RRR: + /* Ignore writes to Read Remote Data, it's read-only. */ + return 1; default: break; } --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 C206CC4708E for ; Fri, 6 Jan 2023 01:17:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231231AbjAFBRn (ORCPT ); Thu, 5 Jan 2023 20:17:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233100AbjAFBQf (ORCPT ); Thu, 5 Jan 2023 20:16:35 -0500 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 D494D66A46 for ; Thu, 5 Jan 2023 17:14:26 -0800 (PST) Received: by mail-pl1-x649.google.com with SMTP id u2-20020a17090341c200b00192bc565119so113041ple.16 for ; Thu, 05 Jan 2023 17:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=W3CTpeuTrONtPW+ec2MrTe8ezQAG+SLQuSBj7Ovyik8=; b=S6d4NqHLamXPB3TUzvg3wWGtflUgM+3032jxUGcWO+TIgGbYTgEZ1dItWZfCPcvS28 iXiyK0PdzysKJ3KTu6Vh++OXSwnsJjuZYij3xPUTqg48YQLoigPTIE+PNWDsCfWZ05sp 5UXanJYrEQPO/nX6a/lpM3SyeQFam6jOg7eWs4/vILF0zjgMJ+ozejPA1ldsMHpnuTlW l9iOORsEIXr1u9vl+1jNxDhB125UO1MvGvwE1MjXJiiQsPS3/+Ye/MSHUYhlAC/i8aBe e6tsoVldGRzmGu+eMdRHuhLOUBg9x9DNQmGvOQo2AEHznkFuR/mgi8UDZin3miEW1ZWb nWjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=W3CTpeuTrONtPW+ec2MrTe8ezQAG+SLQuSBj7Ovyik8=; b=rkIcHaF/fcTiOp0HQLduRp/ogrp2oEFLv8Xuj0RomG1LT2l4UKJk1GMejcPHnp0/aX P7v55pCjqFd1dZrDipxm4QBJULO3MuI8Cb5aETUM/U8M2Imh5LwyNqjx7FB6XYRwwMYP z44Y1Csf+rljcIT37NDb8r9OZoDl9eupzxvzkbgOcyzqkV5GvJsV2yzg5ruTTk5vHHjF yB1JyBE6UQvfykWVK+WrtADTKe23eGhqv58CAPR+eIF8cBoGlaDlqXMMRmyKbJ2LdWPI 7Q7yR62qxyw636gXe4v1zwcmkae6LjdnZn7aHFD5orzbPc2iWumvd/DNVyyHgulYurPT Gm1Q== X-Gm-Message-State: AFqh2kqxDed6cEv8fhADuycuVzAGSREpwJtq8W/JHxKLoFzh1ZiiB6o0 CwxcT84/6UHBDnWJKLeLy2QwlBYUtYU= X-Google-Smtp-Source: AMrXdXurLBy7RyZTd4A490U1pCV44uNhtw92Xvqpe1ooafmPQQVUKqN/ZszlQdE1ZwrkqYWej1YXiB6zPRs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a62:7986:0:b0:581:5a36:b2f8 with SMTP id u128-20020a627986000000b005815a36b2f8mr2165620pfc.32.1672967645128; Thu, 05 Jan 2023 17:14:05 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:03 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-31-seanjc@google.com> Subject: [PATCH v5 30/33] Revert "KVM: SVM: Do not throw warning when calling avic_vcpu_load on a running vcpu" From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Turns out that some warnings exist for good reasons. Restore the warning in avic_vcpu_load() that guards against calling avic_vcpu_load() on a running vCPU now that KVM avoids doing so when switching between x2APIC and xAPIC. The entire point of the WARN is to highlight that KVM should not be reloading an AVIC. Opportunistically convert the WARN_ON() to WARN_ON_ONCE() to avoid spamming the kernel if it does fire. This reverts commit c0caeee65af3944b7b8abbf566e7cc1fae15c775. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/svm/avic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index ff08732469cb..80f346b79c62 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -1034,6 +1034,7 @@ void avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu) return; =20 entry =3D READ_ONCE(*(svm->avic_physical_id_cache)); + WARN_ON_ONCE(entry & AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK); =20 entry &=3D ~AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK; entry |=3D (h_physical_id & AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK); --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 0D892C54E76 for ; Fri, 6 Jan 2023 01:16:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233039AbjAFBQc (ORCPT ); Thu, 5 Jan 2023 20:16:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232211AbjAFBP5 (ORCPT ); Thu, 5 Jan 2023 20:15:57 -0500 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 1BFEA3E84E for ; Thu, 5 Jan 2023 17:14:07 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id 84-20020a630257000000b00477f88d334eso206611pgc.11 for ; Thu, 05 Jan 2023 17:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=cR/0ceEXEHjIeOFsd1KOHfCSQeyMtOUPjLT+49U/bNY=; b=KUx3F3fVD+glWOuqkHgxHp63h2M/R8XvEJtJC5/Er2iHJUSIKfZVgKor5axiG7oSmw M59DpMcb/+ssrKmnfGF5Jt6CxdEKCndq8qtx1NhNMNCMjzQKepuUMtTfaZBCg3OEronK lOY42an0Tv2CMbi8cYn8EFFoWA5vPA91dizfRYNVWltzCtKEXt26bOV+CMagEXGPaOzy J3fQgQDdPqNnHFtgTm4BwdgvlkV8QCSGzJB8sunc072rV+JDbBb5U3JE2f9LeH0rOmxo 1GlM0OFV/jKGjOSTwr6jwgXbFAfAOxwFLb0x8934veHGjFRcsALCV/53gVuhAPRD9paf slew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=cR/0ceEXEHjIeOFsd1KOHfCSQeyMtOUPjLT+49U/bNY=; b=E41XREJjjbJjQf8S7zFLbeALtYnJKrkE3UGC0Byw1MUy+ME9I046NMkV8CFn7RjXFH Jw+P4pVU2JvnaWbWXriSevXz/4yH+n5f+CmcsaBCr1tbi1sYW7C/j+lQJ5ExpZ44RnDI nZk9YztJuxkdoZ6u19mTKwin+6VyFNYm8Dxo5R6I0WaA0H4jzi8KNh9JkS2iPujH75CU pECYHgGHdWIPY9PesI238IyLN+jb4nkdy3sMkxaSSAfDCAjo9FCahGKg26U2Y5JJpvry XoIQO4LUCBiFqL7gIm5bHBDUWeOnY+8ibVJTIB64TdQ9t5FcCl7q/phQFk7qdIcVLDY8 I9FQ== X-Gm-Message-State: AFqh2kqLO7JKXaLAJ36YVwmUuA+O2hu6AdoWQXqIKe3Pl+TLEZV3oGBj tLXFNUxmDLFqQkUlpem3cwiu+kth8ic= X-Google-Smtp-Source: AMrXdXsMeqYHFOOm4KjIKdYw33J4rXlNA7UURqx3sznCGLpwh8MvZvv3xaXUSCoMvXX7nx9SylHuuwEkNyM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:9a5d:0:b0:580:984e:6e3f with SMTP id x29-20020aa79a5d000000b00580984e6e3fmr3666194pfj.66.1672967646823; Thu, 05 Jan 2023 17:14:06 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:04 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-32-seanjc@google.com> Subject: [PATCH v5 31/33] KVM: x86: Track required APICv inhibits with variable, not callback From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Track the per-vendor required APICv inhibits with a variable instead of calling into vendor code every time KVM wants to query the set of required inhibits. The required inhibits are a property of the vendor's virtualization architecture, i.e. are 100% static. Using a variable allows the compiler to inline the check, e.g. generate a single-uop TEST+Jcc, and thus eliminates any desire to avoid checking inhibits for performance reasons. No functional change intended. Reviewed-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/include/asm/kvm-x86-ops.h | 1 - arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/svm/avic.c | 19 ------------------- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/svm.h | 16 +++++++++++++++- arch/x86/kvm/vmx/vmx.c | 24 +++++++++++------------- arch/x86/kvm/x86.c | 2 +- 7 files changed, 29 insertions(+), 36 deletions(-) diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-= x86-ops.h index abccd51dcfca..84f43caef9b7 100644 --- a/arch/x86/include/asm/kvm-x86-ops.h +++ b/arch/x86/include/asm/kvm-x86-ops.h @@ -76,7 +76,6 @@ KVM_X86_OP(set_nmi_mask) KVM_X86_OP(enable_nmi_window) KVM_X86_OP(enable_irq_window) KVM_X86_OP_OPTIONAL(update_cr8_intercept) -KVM_X86_OP(check_apicv_inhibit_reasons) KVM_X86_OP(refresh_apicv_exec_ctrl) KVM_X86_OP_OPTIONAL(hwapic_irr_update) KVM_X86_OP_OPTIONAL(hwapic_isr_update) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index b41a01b3a4af..7ca854714ccd 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1623,6 +1623,7 @@ struct kvm_x86_ops { void (*enable_irq_window)(struct kvm_vcpu *vcpu); void (*update_cr8_intercept)(struct kvm_vcpu *vcpu, int tpr, int irr); bool (*check_apicv_inhibit_reasons)(enum kvm_apicv_inhibit reason); + const unsigned long required_apicv_inhibits; bool allow_apicv_in_x2apic_without_x2apic_virtualization; void (*refresh_apicv_exec_ctrl)(struct kvm_vcpu *vcpu); void (*hwapic_irr_update)(struct kvm_vcpu *vcpu, int max_irr); diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 80f346b79c62..14677bc31b83 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -963,25 +963,6 @@ int avic_pi_update_irte(struct kvm *kvm, unsigned int = host_irq, return ret; } =20 -bool avic_check_apicv_inhibit_reasons(enum kvm_apicv_inhibit reason) -{ - ulong supported =3D BIT(APICV_INHIBIT_REASON_DISABLE) | - BIT(APICV_INHIBIT_REASON_ABSENT) | - BIT(APICV_INHIBIT_REASON_HYPERV) | - BIT(APICV_INHIBIT_REASON_NESTED) | - BIT(APICV_INHIBIT_REASON_IRQWIN) | - BIT(APICV_INHIBIT_REASON_PIT_REINJ) | - BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | - BIT(APICV_INHIBIT_REASON_SEV) | - BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | - BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | - BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED) | - BIT(APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED); - - return supported & BIT(reason); -} - - static inline int avic_update_iommu_vcpu_affinity(struct kvm_vcpu *vcpu, int cpu, bool r) { diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 9f172f2de195..f2453df77727 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4773,8 +4773,8 @@ static struct kvm_x86_ops svm_x86_ops __initdata =3D { .update_cr8_intercept =3D svm_update_cr8_intercept, .set_virtual_apic_mode =3D avic_refresh_virtual_apic_mode, .refresh_apicv_exec_ctrl =3D avic_refresh_apicv_exec_ctrl, - .check_apicv_inhibit_reasons =3D avic_check_apicv_inhibit_reasons, .apicv_post_state_restore =3D avic_apicv_post_state_restore, + .required_apicv_inhibits =3D AVIC_REQUIRED_APICV_INHIBITS, =20 .get_exit_info =3D svm_get_exit_info, =20 diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 546825c82490..41eabb098b13 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -621,6 +621,21 @@ void svm_switch_vmcb(struct vcpu_svm *svm, struct kvm_= vmcb_info *target_vmcb); extern struct kvm_x86_nested_ops svm_nested_ops; =20 /* avic.c */ +#define AVIC_REQUIRED_APICV_INHIBITS \ +( \ + BIT(APICV_INHIBIT_REASON_DISABLE) | \ + BIT(APICV_INHIBIT_REASON_ABSENT) | \ + BIT(APICV_INHIBIT_REASON_HYPERV) | \ + BIT(APICV_INHIBIT_REASON_NESTED) | \ + BIT(APICV_INHIBIT_REASON_IRQWIN) | \ + BIT(APICV_INHIBIT_REASON_PIT_REINJ) | \ + BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | \ + BIT(APICV_INHIBIT_REASON_SEV) | \ + BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | \ + BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | \ + BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED) | \ + BIT(APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED) \ +) =20 bool avic_hardware_setup(struct kvm_x86_ops *ops); int avic_ga_log_notifier(u32 ga_tag); @@ -634,7 +649,6 @@ void avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu); void avic_vcpu_put(struct kvm_vcpu *vcpu); void avic_apicv_post_state_restore(struct kvm_vcpu *vcpu); void avic_refresh_apicv_exec_ctrl(struct kvm_vcpu *vcpu); -bool avic_check_apicv_inhibit_reasons(enum kvm_apicv_inhibit reason); int avic_pi_update_irte(struct kvm *kvm, unsigned int host_irq, uint32_t guest_irq, bool set); void avic_vcpu_blocking(struct kvm_vcpu *vcpu); diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index ef84d11a0fe4..ad2ac66ef32e 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -8023,18 +8023,16 @@ static void vmx_hardware_unsetup(void) free_kvm_area(); } =20 -static bool vmx_check_apicv_inhibit_reasons(enum kvm_apicv_inhibit reason) -{ - ulong supported =3D BIT(APICV_INHIBIT_REASON_DISABLE) | - BIT(APICV_INHIBIT_REASON_ABSENT) | - BIT(APICV_INHIBIT_REASON_HYPERV) | - BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | - BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | - BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | - BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED); - - return supported & BIT(reason); -} +#define VMX_REQUIRED_APICV_INHIBITS \ +( \ + BIT(APICV_INHIBIT_REASON_DISABLE)| \ + BIT(APICV_INHIBIT_REASON_ABSENT) | \ + BIT(APICV_INHIBIT_REASON_HYPERV) | \ + BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | \ + BIT(APICV_INHIBIT_REASON_PHYSICAL_ID_ALIASED) | \ + BIT(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) | \ + BIT(APICV_INHIBIT_REASON_APIC_BASE_MODIFIED) \ +) =20 static void vmx_vm_destroy(struct kvm *kvm) { @@ -8118,7 +8116,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata =3D { .refresh_apicv_exec_ctrl =3D vmx_refresh_apicv_exec_ctrl, .load_eoi_exitmap =3D vmx_load_eoi_exitmap, .apicv_post_state_restore =3D vmx_apicv_post_state_restore, - .check_apicv_inhibit_reasons =3D vmx_check_apicv_inhibit_reasons, + .required_apicv_inhibits =3D VMX_REQUIRED_APICV_INHIBITS, .hwapic_irr_update =3D vmx_hwapic_irr_update, .hwapic_isr_update =3D vmx_hwapic_isr_update, .guest_apic_has_interrupt =3D vmx_guest_apic_has_interrupt, diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 1abe3f1e821c..5becce5bd45a 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10112,7 +10112,7 @@ void __kvm_set_or_clear_apicv_inhibit(struct kvm *k= vm, =20 lockdep_assert_held_write(&kvm->arch.apicv_update_lock); =20 - if (!static_call(kvm_x86_check_apicv_inhibit_reasons)(reason)) + if (!(kvm_x86_ops.required_apicv_inhibits & BIT(reason))) return; =20 old =3D new =3D kvm->arch.apicv_inhibit_reasons; --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 813BDC4708E for ; Fri, 6 Jan 2023 01:18:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233033AbjAFBSA (ORCPT ); Thu, 5 Jan 2023 20:18:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233723AbjAFBRZ (ORCPT ); Thu, 5 Jan 2023 20:17:25 -0500 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 1F56766A7D for ; Thu, 5 Jan 2023 17:14:35 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id j21-20020a63fc15000000b00476d6932baeso189878pgi.23 for ; Thu, 05 Jan 2023 17:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=yPL//5YzExDyFBxSbINxOiuXfpNssPuyAQmCUXdDYKM=; b=ITnWjyO8T1tXSabcL3f42Ng1M0AJc9npIkp2Q59qXsQHAoNEWBngWKNIEljJYY382P LjtIJQ0Gi2WcpaeGsFihuIZREDskbZrPunbY5mFmnDacbZQh63sCnnSS7VGgSSbmF8dd xH2lpUiFMQDIADtGR/as+G9a0NeTzCS7ogR5daO6pwh0033NZIzhL/y0Hsi26sJxIUGG 16tZdGTzB/m6SXpPzljyu/GHbv6GD7dEWFVUTvG4YgHjTR8WwmAxhOdMOYpZ7bzO8jN7 gEThBdfPXiNp6fgcIBGDUdrZBodxgpm8T3oPtVVOIMIqi2WtPMICCdENwk+xIajOqJUZ rNxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=yPL//5YzExDyFBxSbINxOiuXfpNssPuyAQmCUXdDYKM=; b=Km1+JrrX37vD8BoMJ0zIoYGgGkYUz1ehZh6gDSUPLqIFHm0cRsF2BebL1NCLd4apEh KK58/RGR4MMdtioTs+XtuYZbyXnv506tVijOLRRSFe4rs/ei/5pev2M22KoEUK5nIV5J 91K91aRYYCxG1PxEV1OO7G1RnQC3gpx7yl1UR/Kwd+rCVlWVqytMrrGWX7Z5DeWyifox WuoO0jjg7wB2ogTh1Q2PpyYYJv/2lfw972HfC6J7gyJyR2V7Zho9th+2MtJ9zjAi4i+G bh1I4iUr1+mtPVggcrF2VNePNB/FwePjHZhZ558sTLQBs019TqtBVaWqnsJjOy21PhBA yviQ== X-Gm-Message-State: AFqh2kp871oA0C5IuOdyjFH1qAudVFIQ32cVzdA/wAH2jrZIr5BsViPc 0T8tyV+aTGfS5Myl2QnLUojMN6NfXes= X-Google-Smtp-Source: AMrXdXtpLq5sL01+xsDb+D2+MNcPpPFQLJXTFTZOGsk4M1JW/fDTbPx8SEolst183Tp7RqWQ4itCWSmKD5c= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:488d:b0:226:9d77:e730 with SMTP id b13-20020a17090a488d00b002269d77e730mr827196pjh.198.1672967648544; Thu, 05 Jan 2023 17:14:08 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:05 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-33-seanjc@google.com> Subject: [PATCH v5 32/33] KVM: x86: Allow APICv APIC ID inhibit to be cleared From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Greg Edwards Legacy kernels prior to commit 4399c03c6780 ("x86/apic: Remove verify_local_APIC()") write the APIC ID of the boot CPU twice to verify a functioning local APIC. This results in APIC acceleration inhibited on these kernels for reason APICV_INHIBIT_REASON_APIC_ID_MODIFIED. Allow the APICV_INHIBIT_REASON_APIC_ID_MODIFIED inhibit reason to be cleared if/when all APICs in xAPIC mode set their APIC ID back to the expected vcpu_id value. Fold the functionality previously in kvm_lapic_xapic_id_updated() into kvm_recalculate_apic_map(), as this allows examining all APICs in one pass. Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or= APIC base") Signed-off-by: Greg Edwards Link: https://lore.kernel.org/r/20221117183247.94314-1-gedwards@ddn.com Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 41 +++++++++++++++-------------------------- 1 file changed, 15 insertions(+), 26 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 0faf80cdc1be..856e81a2dc64 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -236,6 +236,7 @@ void kvm_recalculate_apic_map(struct kvm *kvm) struct kvm_vcpu *vcpu; unsigned long i; u32 max_id =3D 255; /* enough space for any xAPIC ID */ + bool xapic_id_mismatch =3D false; =20 /* Read kvm->arch.apic_map_dirty before kvm->arch.apic_map. */ if (atomic_read_acquire(&kvm->arch.apic_map_dirty) =3D=3D CLEAN) @@ -285,6 +286,15 @@ void kvm_recalculate_apic_map(struct kvm *kvm) xapic_id =3D kvm_xapic_id(apic); x2apic_id =3D kvm_x2apic_id(apic); =20 + /* + * Deliberately truncate the vCPU ID when detecting a mismatched + * APIC ID to avoid false positives if the vCPU ID, i.e. x2APIC + * ID, is a 32-bit value. Any unwanted aliasing due to + * truncation results will be detected below. + */ + if (!apic_x2apic_mode(apic) && xapic_id !=3D (u8)vcpu->vcpu_id) + xapic_id_mismatch =3D true; + /* * Apply KVM's hotplug hack if userspace has enable 32-bit APIC * IDs. Allow sending events to vCPUs by their x2APIC ID even @@ -401,6 +411,11 @@ void kvm_recalculate_apic_map(struct kvm *kvm) else kvm_clear_apicv_inhibit(kvm, APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED); =20 + if (xapic_id_mismatch) + kvm_set_apicv_inhibit(kvm, APICV_INHIBIT_REASON_APIC_ID_MODIFIED); + else + kvm_clear_apicv_inhibit(kvm, APICV_INHIBIT_REASON_APIC_ID_MODIFIED); + old =3D rcu_dereference_protected(kvm->arch.apic_map, lockdep_is_held(&kvm->arch.apic_map_lock)); rcu_assign_pointer(kvm->arch.apic_map, new); @@ -2160,28 +2175,6 @@ static void apic_manage_nmi_watchdog(struct kvm_lapi= c *apic, u32 lvt0_val) } } =20 -static void kvm_lapic_xapic_id_updated(struct kvm_lapic *apic) -{ - struct kvm *kvm =3D apic->vcpu->kvm; - - if (!kvm_apic_hw_enabled(apic)) - return; - - if (KVM_BUG_ON(apic_x2apic_mode(apic), kvm)) - return; - - /* - * Deliberately truncate the vCPU ID when detecting a modified APIC ID - * to avoid false positives if the vCPU ID, i.e. x2APIC ID, is a 32-bit - * value. If the wrap/truncation results in unwanted aliasing, APICv - * will be inhibited as part of updating KVM's optimized APIC maps. - */ - if (kvm_xapic_id(apic) =3D=3D (u8)apic->vcpu->vcpu_id) - return; - - kvm_set_apicv_inhibit(apic->vcpu->kvm, APICV_INHIBIT_REASON_APIC_ID_MODIF= IED); -} - static int get_lvt_index(u32 reg) { if (reg =3D=3D APIC_LVTCMCI) @@ -2202,7 +2195,6 @@ static int kvm_lapic_reg_write(struct kvm_lapic *apic= , u32 reg, u32 val) case APIC_ID: /* Local APIC ID */ if (!apic_x2apic_mode(apic)) { kvm_apic_set_xapic_id(apic, val >> 24); - kvm_lapic_xapic_id_updated(apic); } else { ret =3D 1; } @@ -2923,9 +2915,6 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct = kvm_lapic_state *s) } memcpy(vcpu->arch.apic->regs, s->regs, sizeof(*s)); =20 - if (!apic_x2apic_mode(apic)) - kvm_lapic_xapic_id_updated(apic); - atomic_set_release(&apic->vcpu->kvm->arch.apic_map_dirty, DIRTY); kvm_recalculate_apic_map(vcpu->kvm); kvm_apic_set_version(vcpu); --=20 2.39.0.314.g84b9a713c41-goog From nobody Sun May 12 15:43:16 2024 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 EBA8FC3DA7A for ; Fri, 6 Jan 2023 01:18:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233450AbjAFBST (ORCPT ); Thu, 5 Jan 2023 20:18:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234012AbjAFBRo (ORCPT ); Thu, 5 Jan 2023 20:17:44 -0500 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 EBFBC6A0DE for ; Thu, 5 Jan 2023 17:14:38 -0800 (PST) Received: by mail-pf1-x44a.google.com with SMTP id v23-20020aa78097000000b005748c087db1so63796pff.2 for ; Thu, 05 Jan 2023 17:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=lYOUn7bh0UicjBFjjEdDwT1xATl/+MO6+EoBl3NK56I=; b=JFoorMQdp+YgGEAg84gXvng2oRxSc4H5kJAMfboM5Mhb3vLfvIO60QTModIJsKv4jb js+UtfEVxx0ljRZ4LROq3D9pzaagrjQu/rIoJrzwTwAsBWtOmbkF4MACp5qDxwmXldZ7 Hqv5BmP5u4BHn9IfhyH3q4d9HQfLLN3//ceZhVB9phW6GJ12YdFm7CyGMHl2KzWy6ptu M8XdaaM/LdUnmDvHKu3UHgWArzMl9mfDM0BHwlNpIRR8SsdCTLRnqJrIhXWtdLM5eYep P2BPCDVq6QebSx86cXamSHSU/iG28oHVF4OZNL0BPpndI7AWGTZVH9ZxQTsiMfbC3Gvb YTYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=lYOUn7bh0UicjBFjjEdDwT1xATl/+MO6+EoBl3NK56I=; b=O/Ls8jGST6ta1WP50kftd6pszvAZ9lrOueEI6ZLDgr4U/jc3Xvei4fTAjOQzfK1QCp xVleORZ9zthVGZlbSQWQSAQtCGZm64gLBANSALMWsPXCjbXiIMgsoLdoEtGxNS2+d+u+ Ych+DQRpM3tOMY1H4rrTrGO3iuStYTV8miMsOfQZ+ZfekOZvqAvdNHWiS4NmngtAnKkv 6nMcArmarbHYPQURpInfgyqXW8N++z2f2GzIeYXFmjgBixBSppAi44g2XnYDVCMiTeXw W+mqRw9Dzt32toBQSWH2U8HnMq8eRcvXI/qiHM9f6yI9JCvn8SN1KWZSnzIDbHy/4KuP jv+w== X-Gm-Message-State: AFqh2koX8dkdGR7r4HH9ZdV/ugmn0FxBgTxw0tWuU69N5DiD/d6PuuqA 9GYxvksDi+L2fOXM6TaBnwrtnTD2kmg= X-Google-Smtp-Source: AMrXdXs579hiyLgywoJiAnuKEjYjiSIarsQN53OmCJJWSmSEL6W2XsZ2wsa/Ao0YkU5eq+VsM+gVDOsKpWE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e548:b0:18f:8f1e:992f with SMTP id n8-20020a170902e54800b0018f8f1e992fmr3573473plf.64.1672967650383; Thu, 05 Jan 2023 17:14:10 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 6 Jan 2023 01:13:06 +0000 In-Reply-To: <20230106011306.85230-1-seanjc@google.com> Mime-Version: 1.0 References: <20230106011306.85230-1-seanjc@google.com> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20230106011306.85230-34-seanjc@google.com> Subject: [PATCH v5 33/33] KVM: x86: Add helpers to recalc physical vs. logical optimized APIC maps From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Maxim Levitsky , Suravee Suthikulpanit , Li RongQing , Greg Edwards Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the guts of kvm_recalculate_apic_map()'s main loop to two separate helpers to handle recalculating the physical and logical pieces of the optimized map. Having 100+ lines of code in the for-loop makes it hard to understand what is being calculated where. No functional change intended. Suggested-by: Maxim Levitsky Signed-off-by: Sean Christopherson Tested-by: Kishon VijayAbraham Tested-by: Suravee Suthikulpanit --- arch/x86/kvm/lapic.c | 250 +++++++++++++++++++++++-------------------- 1 file changed, 133 insertions(+), 117 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 856e81a2dc64..669ea125b7e2 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -218,6 +218,134 @@ static void kvm_apic_map_free(struct rcu_head *rcu) kvfree(map); } =20 +static int kvm_recalculate_phys_map(struct kvm_apic_map *new, + struct kvm_vcpu *vcpu, + bool *xapic_id_mismatch) +{ + struct kvm_lapic *apic =3D vcpu->arch.apic; + u32 x2apic_id =3D kvm_x2apic_id(apic); + u32 xapic_id =3D kvm_xapic_id(apic); + u32 physical_id; + + /* + * Deliberately truncate the vCPU ID when detecting a mismatched APIC + * ID to avoid false positives if the vCPU ID, i.e. x2APIC ID, is a + * 32-bit value. Any unwanted aliasing due to truncation results will + * be detected below. + */ + if (!apic_x2apic_mode(apic) && xapic_id !=3D (u8)vcpu->vcpu_id) + *xapic_id_mismatch =3D true; + + /* + * Apply KVM's hotplug hack if userspace has enable 32-bit APIC IDs. + * Allow sending events to vCPUs by their x2APIC ID even if the target + * vCPU is in legacy xAPIC mode, and silently ignore aliased xAPIC IDs + * (the x2APIC ID is truncated to 8 bits, causing IDs > 0xff to wrap + * and collide). + * + * Honor the architectural (and KVM's non-optimized) behavior if + * userspace has not enabled 32-bit x2APIC IDs. Each APIC is supposed + * to process messages independently. If multiple vCPUs have the same + * effective APIC ID, e.g. due to the x2APIC wrap or because the guest + * manually modified its xAPIC IDs, events targeting that ID are + * supposed to be recognized by all vCPUs with said ID. + */ + if (vcpu->kvm->arch.x2apic_format) { + /* See also kvm_apic_match_physical_addr(). */ + if ((apic_x2apic_mode(apic) || x2apic_id > 0xff) && + x2apic_id <=3D new->max_apic_id) + new->phys_map[x2apic_id] =3D apic; + + if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id]) + new->phys_map[xapic_id] =3D apic; + } else { + /* + * Disable the optimized map if the physical APIC ID is already + * mapped, i.e. is aliased to multiple vCPUs. The optimized + * map requires a strict 1:1 mapping between IDs and vCPUs. + */ + if (apic_x2apic_mode(apic)) + physical_id =3D x2apic_id; + else + physical_id =3D xapic_id; + + if (new->phys_map[physical_id]) + return -EINVAL; + + new->phys_map[physical_id] =3D apic; + } + + return 0; +} + +static void kvm_recalculate_logical_map(struct kvm_apic_map *new, + struct kvm_vcpu *vcpu) +{ + struct kvm_lapic *apic =3D vcpu->arch.apic; + enum kvm_apic_logical_mode logical_mode; + struct kvm_lapic **cluster; + u16 mask; + u32 ldr; + + if (new->logical_mode =3D=3D KVM_APIC_MODE_MAP_DISABLED) + return; + + if (!kvm_apic_sw_enabled(apic)) + return; + + ldr =3D kvm_lapic_get_reg(apic, APIC_LDR); + if (!ldr) + return; + + if (apic_x2apic_mode(apic)) { + logical_mode =3D KVM_APIC_MODE_X2APIC; + } else { + ldr =3D GET_APIC_LOGICAL_ID(ldr); + if (kvm_lapic_get_reg(apic, APIC_DFR) =3D=3D APIC_DFR_FLAT) + logical_mode =3D KVM_APIC_MODE_XAPIC_FLAT; + else + logical_mode =3D KVM_APIC_MODE_XAPIC_CLUSTER; + } + + /* + * To optimize logical mode delivery, all software-enabled APICs must + * be configured for the same mode. + */ + if (new->logical_mode =3D=3D KVM_APIC_MODE_SW_DISABLED) { + new->logical_mode =3D logical_mode; + } else if (new->logical_mode !=3D logical_mode) { + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; + return; + } + + /* + * In x2APIC mode, the LDR is read-only and derived directly from the + * x2APIC ID, thus is guaranteed to be addressable. KVM reuses + * kvm_apic_map.phys_map to optimize logical mode x2APIC interrupts by + * reversing the LDR calculation to get cluster of APICs, i.e. no + * additional work is required. + */ + if (apic_x2apic_mode(apic)) { + WARN_ON_ONCE(ldr !=3D kvm_apic_calc_x2apic_ldr(kvm_x2apic_id(apic))); + return; + } + + if (WARN_ON_ONCE(!kvm_apic_map_get_logical_dest(new, ldr, + &cluster, &mask))) { + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; + return; + } + + if (!mask) + return; + + ldr =3D ffs(mask) - 1; + if (!is_power_of_2(mask) || cluster[ldr]) + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; + else + cluster[ldr] =3D apic; +} + /* * CLEAN -> DIRTY and UPDATE_IN_PROGRESS -> DIRTY changes happen without a= lock. * @@ -272,128 +400,16 @@ void kvm_recalculate_apic_map(struct kvm *kvm) new->logical_mode =3D KVM_APIC_MODE_SW_DISABLED; =20 kvm_for_each_vcpu(i, vcpu, kvm) { - struct kvm_lapic *apic =3D vcpu->arch.apic; - struct kvm_lapic **cluster; - enum kvm_apic_logical_mode logical_mode; - u32 x2apic_id, physical_id; - u16 mask; - u32 ldr; - u8 xapic_id; - if (!kvm_apic_present(vcpu)) continue; =20 - xapic_id =3D kvm_xapic_id(apic); - x2apic_id =3D kvm_x2apic_id(apic); - - /* - * Deliberately truncate the vCPU ID when detecting a mismatched - * APIC ID to avoid false positives if the vCPU ID, i.e. x2APIC - * ID, is a 32-bit value. Any unwanted aliasing due to - * truncation results will be detected below. - */ - if (!apic_x2apic_mode(apic) && xapic_id !=3D (u8)vcpu->vcpu_id) - xapic_id_mismatch =3D true; - - /* - * Apply KVM's hotplug hack if userspace has enable 32-bit APIC - * IDs. Allow sending events to vCPUs by their x2APIC ID even - * if the target vCPU is in legacy xAPIC mode, and silently - * ignore aliased xAPIC IDs (the x2APIC ID is truncated to 8 - * bits, causing IDs > 0xff to wrap and collide). - * - * Honor the architectural (and KVM's non-optimized) behavior - * if userspace has not enabled 32-bit x2APIC IDs. Each APIC - * is supposed to process messages independently. If multiple - * vCPUs have the same effective APIC ID, e.g. due to the - * x2APIC wrap or because the guest manually modified its xAPIC - * IDs, events targeting that ID are supposed to be recognized - * by all vCPUs with said ID. - */ - if (kvm->arch.x2apic_format) { - /* See also kvm_apic_match_physical_addr(). */ - if ((apic_x2apic_mode(apic) || x2apic_id > 0xff) && - x2apic_id <=3D new->max_apic_id) - new->phys_map[x2apic_id] =3D apic; - - if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id]) - new->phys_map[xapic_id] =3D apic; - } else { - /* - * Disable the optimized map if the physical APIC ID is - * already mapped, i.e. is aliased to multiple vCPUs. - * The optimized map requires a strict 1:1 mapping - * between IDs and vCPUs. - */ - if (apic_x2apic_mode(apic)) - physical_id =3D x2apic_id; - else - physical_id =3D xapic_id; - - if (new->phys_map[physical_id]) { - kvfree(new); - new =3D NULL; - goto out; - } - new->phys_map[physical_id] =3D apic; - } - - if (new->logical_mode =3D=3D KVM_APIC_MODE_MAP_DISABLED || - !kvm_apic_sw_enabled(apic)) - continue; - - ldr =3D kvm_lapic_get_reg(apic, APIC_LDR); - if (!ldr) - continue; - - if (apic_x2apic_mode(apic)) { - logical_mode =3D KVM_APIC_MODE_X2APIC; - } else { - ldr =3D GET_APIC_LOGICAL_ID(ldr); - if (kvm_lapic_get_reg(apic, APIC_DFR) =3D=3D APIC_DFR_FLAT) - logical_mode =3D KVM_APIC_MODE_XAPIC_FLAT; - else - logical_mode =3D KVM_APIC_MODE_XAPIC_CLUSTER; + if (kvm_recalculate_phys_map(new, vcpu, &xapic_id_mismatch)) { + kvfree(new); + new =3D NULL; + goto out; } =20 - /* - * To optimize logical mode delivery, all software-enabled APICs must - * be configured for the same mode. - */ - if (new->logical_mode =3D=3D KVM_APIC_MODE_SW_DISABLED) { - new->logical_mode =3D logical_mode; - } else if (new->logical_mode !=3D logical_mode) { - new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; - continue; - } - - /* - * In x2APIC mode, the LDR is read-only and derived directly - * from the x2APIC ID, thus is guaranteed to be addressable. - * KVM reuses kvm_apic_map.phys_map to optimize logical mode - * x2APIC interrupts by reversing the LDR calculation to get - * cluster of APICs, i.e. no additional work is required. - */ - if (apic_x2apic_mode(apic)) { - WARN_ON_ONCE(ldr !=3D kvm_apic_calc_x2apic_ldr(x2apic_id)); - continue; - } - - if (WARN_ON_ONCE(!kvm_apic_map_get_logical_dest(new, ldr, - &cluster, &mask))) { - new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; - continue; - } - - if (!mask) - continue; - - ldr =3D ffs(mask) - 1; - if (!is_power_of_2(mask) || cluster[ldr]) { - new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; - continue; - } - cluster[ldr] =3D apic; + kvm_recalculate_logical_map(new, vcpu); } out: /* --=20 2.39.0.314.g84b9a713c41-goog