From nobody Sun Apr 28 05:07:31 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 A9A8BC4332F for ; Sat, 1 Oct 2022 00:59:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232785AbiJAA70 (ORCPT ); Fri, 30 Sep 2022 20:59:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232731AbiJAA7V (ORCPT ); Fri, 30 Sep 2022 20:59:21 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A0171AF90C for ; Fri, 30 Sep 2022 17:59:20 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id n1-20020a170902f60100b00179c0a5c51fso4210515plg.7 for ; Fri, 30 Sep 2022 17:59:20 -0700 (PDT) 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; bh=pUJ8lsVIJf7TL6+xh2Qa1ktW0pNw9qF5SOtFc21ozc0=; b=EHxckeTL1GlAOvFEilkBQbLD6ds1ejPwB5HYa+q6bReCiccdbj6zC8h52WYChW07Hc eGpLZDyOes7qwgMhNdFpH7VkR4xSgnABSGvCIny9yMdtFaZG/iVLcyFn+isxJG+jB4cz rZc/c4GcKXGwR6P55J1vDqQbCW/9jMTJDFcbf6xYG2VqSR+/izOd++dhsFayfe1lP+mQ 7MJOineUi9jmPQi8uqti3cCCu+S7uPZaUY4QQmYnxrc2k1rmPLZMD/vT1UyTE5OnTRRl Ph7MtLjXP+DhkurHFZTmGBqcH3BJA5SHK8kCBVpT/RKB+LZ5EQhEyZEG10ybziWuFyBi OFkQ== 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; bh=pUJ8lsVIJf7TL6+xh2Qa1ktW0pNw9qF5SOtFc21ozc0=; b=rYjFAyQ9d06sQ5LS7GbDek0/l3CT/Q+QKohYShzSa1B+D93LPY5YQKLxajNkNDxvMH DbP8d7J8OMs0PxKRc283VbPKUU5/bThLsEcYcc3H5L8bJgqIIZTsDFVW1Cwrk6O+RTjv jnWXboXm1h6dX3Ecv6DBfyvC3X6Ef0mPWwmT/tiIareSZ3Pl4bOmINkivSaBQz7OQU8u N6nZR8QjXcvJad2iA8YmNNO70932HbOBQl6ds8lrxpPbSP4kwpYWvG3v2+U33mAlZoJc MGNGWkyJlfWoTPA5RDP20C+JliYOFgPHuiueuSrdL3aIZa1H6pT4+3ucfRFtwT0P172l OLgA== X-Gm-Message-State: ACrzQf36LaV9fNlELOGapd15qilIPJj1W7OCyJFZ3rP2y2Zy9DsiyZQk eFDZn3Oj/IiIrerY0eOX33nu3sZlJtM= X-Google-Smtp-Source: AMsMyM427lSvL7dveKM7cWZJs9QN8HrabJ4Fbs51cuKCu4aVR61KKeLheiN/vjBxNQvc9SbyPcj+j9hU6sc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:c986:b0:205:f08c:a82b with SMTP id w6-20020a17090ac98600b00205f08ca82bmr517093pjt.1.1664585959605; Fri, 30 Sep 2022 17:59:19 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:44 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-2-seanjc@google.com> Subject: [PATCH v4 01/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 d7639d126e6c..05d079fc2c66 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 5B126C433FE for ; Sat, 1 Oct 2022 00:59:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232213AbiJAA7d (ORCPT ); Fri, 30 Sep 2022 20:59:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231298AbiJAA7X (ORCPT ); Fri, 30 Sep 2022 20:59:23 -0400 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 47C691AF90C for ; Fri, 30 Sep 2022 17:59:22 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id y65-20020a25c844000000b006bb773548d5so5153743ybf.5 for ; Fri, 30 Sep 2022 17:59:22 -0700 (PDT) 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; bh=9HZnxxV4Lu47qHeGw+m4H8xJT/iB8E+mQuPsqkTLvZo=; b=EgHb1LRJAwUhJDvw+Tu8ye1lUjtrA6UHF9kIPSVNUM46EliRJePeMD8MaXA/YtgT5P RHpNWWsXhSZcnyX/BpAJkXdiqIBiUBj5Z9l4PQ2H8GUfHlM1YGTqG4Dm3cCZkcCwM2CH ELe5C0tQtConxuuviisk/6Xq+NMUMnDlZhVvEm7USg2qbd3XI5LJnAnWoN31foRIL1gd 75uYfoPofiVnFwLTi36WSQPAid3GAkreU3c7wXDabIFyUzG7sEQN84lgZyme+akaDcLH pPu350uwcQ09MuIUAIuzS7+V1QUnMQDq82h+Y3zELbFso/K8oFiLliQB/9XBoWDcaKUj 0bOA== 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; bh=9HZnxxV4Lu47qHeGw+m4H8xJT/iB8E+mQuPsqkTLvZo=; b=CfsjarnsO+2yUdXjI7YfRw6Mp8TRiGgNt42+9JCAGkPdaxIGEqoQr2cxhxJGlaFWT4 uekXJ7D30k6vg66KfEIzXtvKh7qlrYpvUu9zGmp7NRPvncHMRK6h7rodpy//cI0aTz1V eKHOUfOzwm+jyqVfGYwgHgUYWQv/AmyBgnDLtEvYKPhLBkcTwRYGqFIq6atrCCymtSj2 Q5ZEJZg7wmoFALbX2kCvcVlMzYx/lPCd2EZjx971i32vic4Hw2DlV1sZgXBeC731yu1K cHxVgkCfCkv3km274wFuSo+ZC6Wt8xcs5tvhOf+Z5Tw76BLpYwFoMgWCcQTiwQ4e2hU8 khag== X-Gm-Message-State: ACrzQf1nMXVaKHBkj8q4bR3pl0oTAj6HOJFDYEXm5PMsnuWbE/7jHVeN sRRXjZztnbrco86lJQhFK8MC44gSG7I= X-Google-Smtp-Source: AMsMyM7C4X+TbFDK1lDbVLfRp8A7a9Ir40+eWROdzkElSMejLkU7QhIylcQz7HLdzJpVQgTReCmvOfgqnro= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:a007:0:b0:6a9:3b58:31f with SMTP id x7-20020a25a007000000b006a93b58031fmr10317698ybh.44.1664585961604; Fri, 30 Sep 2022 17:59:21 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:45 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-3-seanjc@google.com> Subject: [PATCH v4 02/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 05d079fc2c66..5de1c7aa1ce9 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; } EXPORT_SYMBOL_GPL(kvm_apic_update_apicv); =20 @@ -2480,7 +2481,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 E200CC433FE for ; Sat, 1 Oct 2022 00:59:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231487AbiJAA7l (ORCPT ); Fri, 30 Sep 2022 20:59:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231955AbiJAA7Z (ORCPT ); Fri, 30 Sep 2022 20:59:25 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DD8F1AF917 for ; Fri, 30 Sep 2022 17:59:24 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id l72-20020a63914b000000b00434ac6f8214so3703225pge.13 for ; Fri, 30 Sep 2022 17:59:24 -0700 (PDT) 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; bh=gWKbedEYDM+WgMEZuaaXsHPdTjjpS3BqpA6Whi9EiUA=; b=LMWP/ZwmM6mNI84QoaByA7gGMv3UqTyhq7gvWgXvV+gu83W3Xsz5MlcgWVWntOG568 HVYiHsHO9gEuCsJKIR5ZyPrrQFSvnTXvQVWXdsv7W4WHcyq/5DC24dd9IwPWGA6cUdOs shCRfpNnUoRmuPXs91O85K1ECe76YYMC12wNJQT9f91GNEs8BXLas4v2U3oXZmvGKGyJ +sceDgf8U3o8mx28L80DvSeekIQvSi0Egtsjp046zQi9qjLw/QZrMi9yEX1Sy6yR4bXf 5k59U6996zsNYfcRXjFjA7HKVe9O/gOGGxTKQHlogX1uxTUm/Xsp+prVIQ1o063ZqQmv vgoQ== 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; bh=gWKbedEYDM+WgMEZuaaXsHPdTjjpS3BqpA6Whi9EiUA=; b=P0QQJYFvr7KhC+Krw7AyFudeF6MAIFEyHumYkSETqH65FbrjtA6ZHC+1rDtGhZ7QFa aFRLOcL5K94cayHOyuJ+XTf857eXy9xY4Ygkm49U12Jt8u2no/xsgNF1W+RsmevNMnZj Dzgs2SJ9YF7+eaoOO9IZJ8lihLXCVeudyc2X94SKZHNzHLrM5Tgkn4Xo8FXmYZbpFov9 1/+6MnDZunTZ8ShJn9959g8qd7aq4IgQJmJJPhIbVGgIqqpxBj3Bwu9mBak6pzNnFBRD ztg3pFcfjPY+u1P5W64qeQb/+QGjx6OcHxtc5vP53HnaiyvCtSr6G1WskrV9agauEIZ8 KZ0w== X-Gm-Message-State: ACrzQf3FoFzccaIs0/yUBTzFksBfvxiLfk8SP1xbKiuXPQcYLu/FnW0u HP/e9zNrQqRwaUYXJ/voKk+O9ICDVio= X-Google-Smtp-Source: AMsMyM6ZqIp3urmDWoeW4zxYAhyWoaXq1tuhVl0zHsGHO96aoD0eMfzus09JSG0zAhOilveTapAWx7nL7jU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:c986:b0:205:f08c:a82b with SMTP id w6-20020a17090ac98600b00205f08ca82bmr517109pjt.1.1664585963402; Fri, 30 Sep 2022 17:59:23 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:46 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-4-seanjc@google.com> Subject: [PATCH v4 03/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 0275AC433FE for ; Sat, 1 Oct 2022 00:59:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232803AbiJAA7q (ORCPT ); Fri, 30 Sep 2022 20:59:46 -0400 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 S232795AbiJAA7h (ORCPT ); Fri, 30 Sep 2022 20:59:37 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 528391AF92B for ; Fri, 30 Sep 2022 17:59:26 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id p24-20020a63f458000000b0043cd718c49dso3721000pgk.15 for ; Fri, 30 Sep 2022 17:59:25 -0700 (PDT) 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; bh=eHH9N5KGHEqvEJkVzA/2lRA7fGLp5p5N5cp+MpeWrmU=; b=oES2VGRX/fcHEWvWSMYz/FdTQ0OKgPYd4v+iN4OFWl1IvhmYESW3NBjbNFaIdJ/bc0 epzv5I5/opNN4plUCwp/qYOtZv1DfDMXAZxiZyRZhrM7APaIVeu9uz5PhZzZiCld620J eyD8edykEHEnVYOFR8IuQaIveJekH4MhThfWDLI0ic9yXoOAHw233lq/UhVlKdQLCn/K mwqm0aU5pMBfaWIQjD8u6tcGNVwl+KBwWFIEh9j4+F06yIQZ0DhcO49ZsIOMeYMSt+9M 59SWBXBkw97W1ZYknJpjSCFRrGzI2F0iek+X/4zV9nIcUaidiL1ZOqlNGALmqxy930Ky uieg== 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; bh=eHH9N5KGHEqvEJkVzA/2lRA7fGLp5p5N5cp+MpeWrmU=; b=7SWPF6FKQ989ztobxYNr3gIchRGTywc1qw4ymntMtHddHpORHOo/gaR9qhAAKWnaZm NxBwhWcK4E+Rg3rNEHUnQzmumTOrN43hRX09cGyHl9pJNyv3TUGSGFuHAjNplR1WX9vi 1b6FEchnjbW3LhFBHUeVnYTSQQjTda63HJ7kV1RKXNO4BafmuxnNAs3Y/+gpGtEUAdoA 0ACOJb4ELqDf11VdGUyMU0HCcZYwsE+X+EwIdVYHKLWfiuudechuKC6TD91YJfNSmvCW PGE9GstwhILEFjB6CtJqfbRgkA1i06yLhZXylVZwlFnwXfxK2ek95t9kAE0IAAUKB1uL xPFQ== X-Gm-Message-State: ACrzQf0wucI9La8OU4491ZIigPFTTkZvXM3+Lw/pwSHJEqKxC8PNrUwJ apDcOAbYrZZk5YR7vnODhzGuSWgt/Nk= X-Google-Smtp-Source: AMsMyM6DwQfJMtryfb4tmACAzG5TUNWBuDoHaHgLRZczqgpN6QW9JK4bBXHGK5ix9mIsnS/ZONNBqmP68/w= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:d4d2:b0:17d:d70:8045 with SMTP id o18-20020a170902d4d200b0017d0d708045mr3380998plg.73.1664585965378; Fri, 30 Sep 2022 17:59:25 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:47 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-5-seanjc@google.com> Subject: [PATCH v4 04/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 74FF4C433FE for ; Sat, 1 Oct 2022 00:59:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232153AbiJAA7v (ORCPT ); Fri, 30 Sep 2022 20:59:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232799AbiJAA7h (ORCPT ); Fri, 30 Sep 2022 20:59:37 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A91D41AF931 for ; Fri, 30 Sep 2022 17:59:27 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id l72-20020a63914b000000b00434ac6f8214so3703269pge.13 for ; Fri, 30 Sep 2022 17:59:27 -0700 (PDT) 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; bh=M/spcK9wHVTD8Sd/Y0FAGZb50phXWK7By/2gXnYm8Kc=; b=a3A2SsPtQ9WnBAERm+S/X0qzW5ZN8giGyMAolX/ZSvBJAtdQVXwFc+agKJML8greuU sCyvFnkrobvE1RuJBAZ0qPQwaWEjLTkZ4qlwxzEXeJeakNv+RFxGoqybhYcGVP+rtKEA hEm9AxJTXsI6450LFVX2wpo6qpU2mjlIwnoO15CachELhJjVVZizw2SbO8S/QbwX9NJM CgOoNLIsW6p6nO1trhMWu5w5B1ZYd0ivQh/9Gk+c6HCZNqo+wIuajuh3pjbuZhKf650B ikEKgJiU1lwAaiYzMyRdyweY2yOQruVFodsbZdRNTqPp9TXWStmBtVeNIpMkDQa8jzIN irPw== 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; bh=M/spcK9wHVTD8Sd/Y0FAGZb50phXWK7By/2gXnYm8Kc=; b=cMwV9xtKlc1Nevq8qRsf9i1go0uVtx8PHC8NmJIJqukfA2TCgCgwk3VUzkFRjwhR3H hiicjYrgwEU/8cKghfCMi71VwOEfJYQgFOU5XsT/mAr5VTA1WP56gOzKPJHncNzggm72 6mxXP5XhanU/o0/l7WaocL9wuPOGbPnM+oh6pzbLdiFHFc7cVBMh4P8xySkiGdetmyqC ozSzXUfzBp55zf7elATGWVpiZfNAjZBgTNTjfmt4DAY896ef78s6w0SjkkPeXIpAuzx5 D1xShBuZAtIFCVOLLTB+WYwKDuzJ+ykqlEkiMGScT1L/oz/Jbt2rmSY5YrknTWLCLaEl WYdw== X-Gm-Message-State: ACrzQf3iW7iY7oGZJxYo6quMYqXPVzPtG0pZmtMOAYoT3dVJn8t2ly0s FR2yVcMihLDwj435B44hinj6Hm39ERk= X-Google-Smtp-Source: AMsMyM4e5iuCFLGxaNpq8Mv1gv6Lgo21xWESrHHrXsuB08zVPqPVjheNWe+vLOtwtSpyQlff7n2LKTvHcO8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:18d:b0:178:28d1:4a13 with SMTP id z13-20020a170903018d00b0017828d14a13mr11507907plg.160.1664585967120; Fri, 30 Sep 2022 17:59:27 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:48 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-6-seanjc@google.com> Subject: [PATCH v4 05/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 5de1c7aa1ce9..67260f7ce43a 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 03F95C433FE for ; Sat, 1 Oct 2022 01:00:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231666AbiJABAG (ORCPT ); Fri, 30 Sep 2022 21:00:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232817AbiJAA7n (ORCPT ); Fri, 30 Sep 2022 20:59:43 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE85D1B0512 for ; Fri, 30 Sep 2022 17:59:29 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id k16-20020a635a50000000b0042986056df6so3687959pgm.2 for ; Fri, 30 Sep 2022 17:59:29 -0700 (PDT) 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; bh=8hjNN4ZUEN5yzik4GPF3QAZ7pjpHHwe9e1YFPhWs1LA=; b=SIdS+5vPcTQNjxx4yGp9zInt5YLI9mNbsajk/Kjz6DaKHbUcbWXpnWO+4xcrAF+FKX 0rWyTzutNFnlzc6Wjdjd7CA9UB5BXFmvU1l9NzrkfUPULK2cToPuD2s1b/y8BnHgTU44 5lBIEOXG9r6aJDOT5CRSS3r2daKqbe1w99hLwrYNvm8K5yLYxsMYqt7DLRk7eOoW4D3r cokAGbNfnrauW2Ybi1ge9WXGNwOZGj5Z+Cj61Htd1CGlgL7d3EVTMnCQaKAMIFfuI9aI KXM+URI4SopAbSbrEQfG7Oj4eg/6+VgVLUApEVFTtsizjGt97K91FEYbrdRg9+bwJ7tE iLkg== 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; bh=8hjNN4ZUEN5yzik4GPF3QAZ7pjpHHwe9e1YFPhWs1LA=; b=t8nFmWDLb6y8ZOqw2yS/xb0tbUmNB4e/+iBzr2d9ddeeg4yskZA02dqolzR8xSV1Lx G4xOMS+4yWkAve9KzRCUYYAvuWGLBvpNBieeurJKzP7mzcv1yNEZYB5ZAg/Wn6Pb4WqK mwbP/rAGTZKDAvLhfDapzrDK/QLZuEjdjF+GV4tbmgiLhXzk/f/Qr8aflnyaYX0SdZQZ 03kDOwsQXS9VehBRBS52Q5Ql67b9h6Bjdw5iocmbrJ629Qgk+qtzSWFawYx1oLANrjFr JAirABzabbhOMc1plqcqxOGXVEW2k8mhihMezKcV9uuCamJL9qPP0iMFtiqlLqV/4TLB t9dg== X-Gm-Message-State: ACrzQf0ua0SzZV02jwhYOgrlVWk85kU4hZDBIEirGo1t09fJpC42hyhF xHvIeFbl1m9pibG5PzMCFIC+kj4ISes= X-Google-Smtp-Source: AMsMyM5Kh33iYKUenf6bs7uDWTk/lZmL5SkrwARVzir64Qx02mDoVhzCQO8zCsKQBcJyQ14l13qBAjtWaAw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:cccc:b0:178:a9b3:43e6 with SMTP id z12-20020a170902cccc00b00178a9b343e6mr11264194ple.92.1664585968932; Fri, 30 Sep 2022 17:59:28 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:49 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-7-seanjc@google.com> Subject: [PATCH v4 06/32] KVM: x86: Track xAPIC ID only on userspace SET, _after_ vAPIC is updated From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alejandro Jimenez , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 potential changes to a vCPU's xAPIC ID only for KVM_SET_LAPIC, i.e. not for KVM_GET_LAPIC, and process the update after the incoming state provided by userspace is copied to KVM's in-kernel vAPIC. The latter bug is the most problematic issue, as processing the update before KVM's vAPIC is actually updated can result in false positives, e.g. due to the APIC holding an x2APIC ID (wrong format), and false negatives, e.g. due to KVM failing to detect an xAPIC ID "mismatch". Processing an "update" in KVM_GET_LAPIC is likely a benign bug now that the update helper ignores mismatches, but prior to that fix, invoking KVM_GET_LAPIC while the APIC is disabled could effectively cause KVM to consume stale state, e.g. if the APIC were in x2APIC mode before being hardware disabled. Fixes: 3743c2f02517 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or= APIC base") Reported-by: Alejandro Jimenez Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 67260f7ce43a..251856ba0750 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2720,8 +2720,6 @@ static int kvm_apic_state_fixup(struct kvm_vcpu *vcpu, icr =3D __kvm_lapic_get_reg64(s->regs, APIC_ICR); __kvm_lapic_set_reg(s->regs, APIC_ICR2, icr >> 32); } - } else { - kvm_lapic_xapic_id_updated(vcpu->arch.apic); } =20 return 0; @@ -2757,6 +2755,9 @@ 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(vcpu->arch.apic)) + kvm_lapic_xapic_id_updated(vcpu->arch.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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 AA4FAC433F5 for ; Sat, 1 Oct 2022 01:00:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232924AbiJABAK (ORCPT ); Fri, 30 Sep 2022 21:00:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232834AbiJAA7t (ORCPT ); Fri, 30 Sep 2022 20:59:49 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C546A1C057A for ; Fri, 30 Sep 2022 17:59:31 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id m10-20020a170902db0a00b001789bd49db9so4247044plx.23 for ; Fri, 30 Sep 2022 17:59:31 -0700 (PDT) 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; bh=s9F27/phkQq2UQGJLhx33mCxKn5dPEvZBbt0R8d9G7c=; b=fVH/qF1VZKyMyRjY/sLnhdTFwZfP8qKuRGbH2a2ebgYrKogmw4x4xwb2fnlWpS/2xl F29kBEqJOjzSH1Cji+Y71p7q4YqvE3CLbiKnLlaZAGcKSg/XFSRY0oqRW6rrjfaq2FzC Jz5NDxZgvY7tmLQmGMz0BNIV5hrQMwIgA17Rd2u1KX1gZv5Pxn6zz33yLNxeWUpoh5oa NsTSenYxDTFxgnVohl0xvD/art9c3z/54Njxpkz+LHl+yA+Kp6UOcIb/pqDH3x3Qt+Zl hQYofVJqnLSKmAU38R6dSNHMR5+A/1Ic50E/SG8DJm1yv2DIbRN6poNY2AvCoN5iLWG8 EfNg== 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; bh=s9F27/phkQq2UQGJLhx33mCxKn5dPEvZBbt0R8d9G7c=; b=D9NZb5Iv7Cosx0e4rOo23bR1F9CGxWJHOa6N+GjEl7acXlgt3BHHgHSuwKm7+ZXjMN by3lNZeuMyowt2nx9+/yoQFnKZsh0E/rpNqIIOpF35AzHyphK0qYaACZZsSQMvx3Alpj ig/91qa9LH4jgjISgYe1eIUWVMyN8tXzlhsuYFqWKIhZ7ToPkeyaYb+zdyK6pRZFFO1o xpUaCTrziJBfzva3l4WgD/Qfy8vZDs73KCwRcSj1T0ERsE5bu0JA9+ytNzv9zWNM9BU/ uD3E7OUBXfMpOqnEGxpstSjId0mf6lCQqII1UB0637iSiVv9xt+xVbLh7oDyBCoS/OdX nkfA== X-Gm-Message-State: ACrzQf3hzFMgEq5BsN3eGoc6+mNwzCWTjrfeaOcFh82XpISrz68CGFJa UvXAAJNeSMuNPZ4wzfAMU1cvb8WDZvw= X-Google-Smtp-Source: AMsMyM42mHWCz7/oR4t6O2pNVuSHVJkTVJO3X4u2N6jAKZTmdNTqJpNzaauhhc/vYu1KRHG06ThcQRY7F1k= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e742:b0:176:dc6b:eecc with SMTP id p2-20020a170902e74200b00176dc6beeccmr11705111plf.104.1664585970588; Fri, 30 Sep 2022 17:59:30 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:50 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-8-seanjc@google.com> Subject: [PATCH v4 07/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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: Maxim Levitsky Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 251856ba0750..2503f162eb95 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 C0193C433F5 for ; Sat, 1 Oct 2022 01:00:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232602AbiJABAS (ORCPT ); Fri, 30 Sep 2022 21:00:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232810AbiJABAB (ORCPT ); Fri, 30 Sep 2022 21:00:01 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA8D72BED for ; Fri, 30 Sep 2022 17:59:33 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id x23-20020a634857000000b0043c700f6441so3728891pgk.21 for ; Fri, 30 Sep 2022 17:59:33 -0700 (PDT) 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; bh=vp3Zm2+kgOlr3ziWSPXuRqI2fE4f6tbKd5l1IswvpYE=; b=egYtNwL9WiDTUUQSmOtBjCw4C1aDlq6NJo7LA7m7frqyrWffak/2vq3ooJ1W4tIPHv 9b6oSuqho5QCPfBNFUz2ebljvw/CL4h1VM6Ud6UmZLerNabg8xY4CAN+0ijT2iY5nUkS i7oy9MU5L9u+jc5HCWccdX2k2hoDqyWBSfAfYwIAL+mOspt2V5UWNj3QIHO+6RBI+fHD hDCrzH/yBUhjSI5BIliLrNzMCNdk0CKaQ9x7nia96sePPAEyzbWmA4DCHaYhlkUih5vr EO4X17514+b5DZeCEH10eA+4EiJr1zNTTfvzwvwrzpcmLzK1s/bd09XL+NbG5mQAwnA6 QQTg== 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; bh=vp3Zm2+kgOlr3ziWSPXuRqI2fE4f6tbKd5l1IswvpYE=; b=NIke4dUrVB+FiwvauxptCx80pKe4i3G7OWur7TYnNY4mH+7PijkgMwqACmNbcy790t P5VYeHTZMIqDnFhpb3ufNJc+KXQRhxVxRvvAdV88mvQCRfJtyw15P3ZCEFOkIjXqUg/V x93LCVe0ZmlMwnIJ1efHxdqZiuSxGNRxIfJKboB93cRYC/xpQhYSC4m0enFt7ctaq7O3 ccqmzsO21/S6bhXUZ6PSml4kDrk0s7sTmSmAV96u1lO/QDadm1fop7f7qT3uxnqMDyOA HYf+aFRh8Nbgvv1xAPXgeXkVDH8tiVHPmrfk85VfVDuTw5sryzVraSDhvFM25gDuC23b u+VA== X-Gm-Message-State: ACrzQf2oDuvS9+Fs2WuTnFAhCdsSL+y1SVuGFAczUx/lDO5XIW11+ybW lsFYk1XJFvosiI0WQ1HeLd7x5r7RN38= X-Google-Smtp-Source: AMsMyM6WRsYDkYabZj40nG7WD4WfbMfP001vdvR1BDYECaLhgtae6lUxpsjJ1/3+JD1SvZ1EmolFxj95Frk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:4f8d:b0:203:747c:7b7e with SMTP id qe13-20020a17090b4f8d00b00203747c7b7emr997767pjb.98.1664585972158; Fri, 30 Sep 2022 17:59:32 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:51 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-9-seanjc@google.com> Subject: [PATCH v4 08/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Cc: Maxim Levitsky Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 58f0077d9357..afae97ea9a06 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4798,7 +4798,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 6a7686bf6900..7a95f50e80e7 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -646,7 +646,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 D1DB6C433F5 for ; Sat, 1 Oct 2022 01:00:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232949AbiJABAa (ORCPT ); Fri, 30 Sep 2022 21:00:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232870AbiJABAB (ORCPT ); Fri, 30 Sep 2022 21:00:01 -0400 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 D6372FAF8 for ; Fri, 30 Sep 2022 17:59:34 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id z24-20020a056a001d9800b0054667d493bdso3623517pfw.0 for ; Fri, 30 Sep 2022 17:59:34 -0700 (PDT) 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; bh=0E11MpL6SGTty3WKUuaZinB/c2Ize2TmmIc0ubmGHxI=; b=QgihTGnwFiYnFKRuH+UiepjpjJg4APHcd1IGU17rqdVZSYwxxTkSk2beb1FwD6KrGK JubLFWX96s+DzWJ8mRm2AVVniuBn7ZekEBnyDiN3TvLDmDXYaEYFagtTjqvVaW/WrmUF kZRYCPx2+/qIDiEgT4wgjMqrsKJzBFpJAfNTRY4Fy0BI1VNy090DPOBuSJ2I+3+SdIlY dqmcpYSEx3xRFwZq0S2Tfnc0i4jw97xMt6dnnbdh+TUnS9BlPLkE4SY2YaRm1r8Fu6Rt 0fZvjwEJxn6b1gloDMaJHyZYdqnobIGmBeOrHL5wICGMzOYu1bEAk46rPmq7zSv/XbXQ aWzQ== 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; bh=0E11MpL6SGTty3WKUuaZinB/c2Ize2TmmIc0ubmGHxI=; b=hjEBhSrnNGwWsrI2xGtgBrtQxeaGNqTg7guImJ1sUNmgZYalCmak2A5UZp7IqlVoJo dz1YTUu5QYX/PsF3RUMFSB7fW0YrAW4H7MYYKHwym4lWQTxC9lDk2oUaOTqpvMGhnfUk PIG2AcpD2aDpwjUZPjh2ZMsPfjNtcJM1FacxQAwJ9YRLNzo1OC6hc1kKbzs7VWGJuEoQ Ty57r+FpSOOod03R3otogEMoNfjvBcH/7HYiv6ghMlexont7As1QOGJH/D2S5kxYSHOI nFwi1kBqsz4bc/RvEsb51OZd4WueSTWjPqw/IeoS4lhyEFWB9c/GvO3vKz3efvJHOk6H 06yg== X-Gm-Message-State: ACrzQf2DW4DxKgKi9EGBIT1Q2f+p1hFXDUijE2eyk93YtJ8DDn4sQu4s IUZozU8tJgDRzNK3okbG71D0GlHkr1I= X-Google-Smtp-Source: AMsMyM5xd4LpP4RpJnL1ZlZz+D8f72c6fcZYgwlUZ+UVAQHly5Xs2TUx4gtmjHL6k4DVTKF3UcUTTpr0qeg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a62:1684:0:b0:554:cade:6970 with SMTP id 126-20020a621684000000b00554cade6970mr11617488pfw.11.1664585973738; Fri, 30 Sep 2022 17:59:33 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:52 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-10-seanjc@google.com> Subject: [PATCH v4 09/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 2503f162eb95..316b61b56cca 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 33392C433F5 for ; Sat, 1 Oct 2022 01:00:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232966AbiJABAh (ORCPT ); Fri, 30 Sep 2022 21:00:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232825AbiJABAE (ORCPT ); Fri, 30 Sep 2022 21:00:04 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EAAE120A8 for ; Fri, 30 Sep 2022 17:59:36 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id f15-20020a17090a664f00b002038154eb4bso3385246pjm.9 for ; Fri, 30 Sep 2022 17:59:36 -0700 (PDT) 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; bh=WE5d81HbbIB8PtF8lmTW9QEFN11Wp+5ApIIrELuP49A=; b=EVdwXcwOSg047cB4/lcRqcS9bRvxHoA3iIfW6IXdACB64nSC1e/kOQRf6XQp4g8bEZ //BmRdvfbaqsAM0OsU9UiPOzLM60eQ+Zf9egRZlb/UC3mnkDLhfOa5x2QdBwgow7kN8y znfGbstRgmpYn1uOECB+ZEJ9SqyxdKB1IAk9y5qDxkBPLUESw9gf6bRNu6D8h6F8Ds/V t/2p+gEpkZzGTXt96S1pzrqGJZcWOG9ot81OE1LxoytEpptEDkdYcFxVHhvk1CXap17o pjQjOKGl8A5nyBpUddhuOeJa5pKPBq6w9sKoRo9mzU4l+7VwAn+R7yB+UU7tLNmrDDC/ BTew== 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; bh=WE5d81HbbIB8PtF8lmTW9QEFN11Wp+5ApIIrELuP49A=; b=oXFKwS+K8hl7UskX1F8yNHjnAiKTgoTI8q+kuBFGgT7//sdq0s+XKkEqqVybITbRGL CZ0ZkcuLwlQfOxDw00rxp1iKhhsW2AbaoK1Rpb7TdAYBdvnKf7uaNfgQ+KpXXWMM/a8l lJW/1l0qK2j5jVtVYyHCdHU7Mobga6HEu//3VJA6muNaZPkWr3gWhGs8zXlwnapZ54st xmK3B2xvgCIGNrMHPZ6rfAPvANJnrFnrua8QaMaUmGYJRx4reKnh9GBji+B2B9TDYHpD bv1NG6UiSB7DQ2S05qUdLBR8J7j6+dyE9n+XiSX37+T+9GsM891WavV0o60bREzfwJCg /1qw== X-Gm-Message-State: ACrzQf0B1GPSnnFZtawCBMGd9Tp7afNVkXA2iJR90Unodh38clEeNpHL McABvm8jSXreRtg5j6cWXOb14eGW/v0= X-Google-Smtp-Source: AMsMyM4a9IcbCaPHAe9T6HaFEDaLX9Rb+ZC0mKLfRZagbftuEGMOPR1ALP2uq84Q1l1PDjfyV+M6s2C+PO8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:16c4:b0:535:890:d4a with SMTP id l4-20020a056a0016c400b0053508900d4amr11773279pfc.0.1664585975538; Fri, 30 Sep 2022 17:59:35 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:53 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-11-seanjc@google.com> Subject: [PATCH v4 10/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 316b61b56cca..80e8b1cc6dc2 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2436,6 +2436,41 @@ void kvm_apic_update_apicv(struct kvm_vcpu *vcpu) } EXPORT_SYMBOL_GPL(kvm_apic_update_apicv); =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 a5ac4a5a5179..0587a8282cb3 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 9dba04b6b019..974d9a366d5d 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -3771,39 +3771,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; @@ -7348,7 +7315,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 B9D45C433F5 for ; Sat, 1 Oct 2022 01:01:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232996AbiJABBB (ORCPT ); Fri, 30 Sep 2022 21:01:01 -0400 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 S232916AbiJABAJ (ORCPT ); Fri, 30 Sep 2022 21:00:09 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3A60FD9 for ; Fri, 30 Sep 2022 17:59:38 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id u5-20020a170902e80500b00178944c46aaso4238557plg.4 for ; Fri, 30 Sep 2022 17:59:38 -0700 (PDT) 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; bh=KWLmCZe0E9amLO3V8z3dW9zAc7CP2PoiNP0Ya6C73iE=; b=N9CoZyf9np8UYS12KknKpY4ycEV97bcEoj0KkFWQOaJDx4N9yetfKRz4IFo5o5d2DD Nl1f8CWYPggFLcNyKYRbxfP9oCW4+lGDNE2i0hMZt0NHaPYX9WE1ZeMNiitlpyNklHVP JzDGAkWBvDmIU6fyFsQWuuQ7ZE7/81W3HV4lJuSaKlvSCmYqckZ7rJPSc06CXsoRvhTl cau1iWbpSS56U+ZL57IOldQma2a9yF78usCGFoqJvZSEGXo8gXJHgFwlqgUxk4ndY+Sc N7O72tWwIJ8HyVT69ejg+4vB1lt+jhg3sXk7hrM7aMpsWiznlGTBlKcJPMhkaYBIb026 Rt/A== 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; bh=KWLmCZe0E9amLO3V8z3dW9zAc7CP2PoiNP0Ya6C73iE=; b=SWIMrKeDoR8mVKxHZv738OicGiU4FJO59NPhvyD8O+ZzcmRSD0KbQS3JrmeevSG2Sh 4IjG/pxLbGlmZiNFl9LCbnX7KT94LsVb5GtMdnfhu63vh8RVzrdD3Vp0q52DQO2wzYkw zUV7aD3PJSik+ZzMauTT8ZQ9JEp0U/BiHX831Y8MABjuQ7pP9pIkPjmCCQyApO4Apwoi ZpFQuhXX76Pc0Z3cXkJkf4k2BgjaB3VgnHHswWBHRrPkLqZR9/H/v0MVjLFNjcKWSFWb 8DHoMrMT0pIT7KxCpuSW0O1X//8I1eshA4QaXMARrzeJgZuTovXgKW1hfV1zVQaT9O7h lRLw== X-Gm-Message-State: ACrzQf1LZYzNh1+BM+GOus8jII8eSX42yCmXrPoGwvWrgJEtB2eqI/lI EWh5V5xXIz2WHOkawANrjkng/gTP2e8= X-Google-Smtp-Source: AMsMyM7arAVRnDSlz6LLklDRSIN9YSFTUcXVRuLXNnz+RJBNDR3+Iu7wHn6ZGOqqKJ2OSXEFxxnLRipRHhc= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:c986:b0:205:f08c:a82b with SMTP id w6-20020a17090ac98600b00205f08ca82bmr517145pjt.1.1664585977244; Fri, 30 Sep 2022 17:59:37 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:54 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-12-seanjc@google.com> Subject: [PATCH v4 11/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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, due to its "hybrid" mode where 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 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). Reserve an inhibit bit so that common code can detect whether or not the "x2APIC inhibit" applies, but use a dedicated flag to track the inhibit so that it doesn't need to be stripped from apicv_inhibit_reasons (since it's not a "full" inhibit). 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 (it's protected by slots_lock). Fixes: 0e311d33bfbe ("KVM: SVM: Introduce hybrid-AVIC mode") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/include/asm/kvm_host.h | 20 +++++++++++++---- arch/x86/kvm/lapic.c | 38 ++++++++++++++++++++++++++++++++- arch/x86/kvm/lapic.h | 1 + arch/x86/kvm/svm/avic.c | 15 +++++++------ arch/x86/kvm/svm/nested.c | 2 +- arch/x86/kvm/x86.c | 16 ++++++++++++-- 6 files changed, 77 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index d40206b16d6c..062758135c86 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1139,6 +1139,17 @@ enum kvm_apicv_inhibit { * AVIC is disabled because SEV doesn't support it. */ APICV_INHIBIT_REASON_SEV, + + /* + * Due to sharing page tables across vCPUs, the xAPIC memslot must be + * deleted if any vCPU has x2APIC enabled as SVM doesn't provide fully + * independent controls for AVIC vs. x2AVIC, and also because SVM + * supports a "hybrid" AVIC mode for CPUs that support AVIC but not + * x2AVIC. Note, this isn't a "full" inhibit and is tracked separately. + * AVIC can still be activated, but KVM must not create SPTEs for the + * APIC base. For simplicity, this is sticky. + */ + APICV_INHIBIT_REASON_X2APIC, }; =20 struct kvm_arch { @@ -1176,10 +1187,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; @@ -1912,7 +1924,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 80e8b1cc6dc2..42b61469674d 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2443,7 +2443,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, @@ -2471,6 +2472,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 0587a8282cb3..a318609bb050 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..535e35edce1d 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) { @@ -975,7 +975,8 @@ bool avic_check_apicv_inhibit_reasons(enum kvm_apicv_in= hibit reason) BIT(APICV_INHIBIT_REASON_BLOCKIRQ) | BIT(APICV_INHIBIT_REASON_SEV) | 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_X2APIC); =20 return supported & BIT(reason); } diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 4c620999d230..8d5e00a7ef84 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -1084,7 +1084,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/x86.c b/arch/x86/kvm/x86.c index eb9d2c23fb04..a20002924eb4 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10251,7 +10251,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; @@ -10286,7 +10286,19 @@ 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; + + if (apic_x2apic_mode(vcpu->arch.apic) && + static_call(kvm_x86_check_apicv_inhibit_reasons)(APICV_INHIBIT_REASON= _X2APIC)) + 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 CA349C433FE for ; Sat, 1 Oct 2022 01:00:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232978AbiJABAw (ORCPT ); Fri, 30 Sep 2022 21:00:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232911AbiJABAJ (ORCPT ); Fri, 30 Sep 2022 21:00:09 -0400 Received: from mail-pj1-x104a.google.com (mail-pj1-x104a.google.com [IPv6:2607:f8b0:4864:20::104a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27D1F1D330 for ; Fri, 30 Sep 2022 17:59:40 -0700 (PDT) Received: by mail-pj1-x104a.google.com with SMTP id pf10-20020a17090b1d8a00b002037c2aad2bso6616134pjb.0 for ; Fri, 30 Sep 2022 17:59:40 -0700 (PDT) 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; bh=gG4JQbu2ViZJSn6XOJHk3K+AtrYE4frOHCXu3F3JspI=; b=S0qjejtKw0HK2e+AB+To4s2tvxXU5eNChD9TYG2Ljm1vwTblAWSbJnuewazormj+pb ig8PJnzi04D0ykNJNIDmRz5DX9gQsdB3KUxDXSaWY7kor7KmXMt/P3S2LNKA75vSx4TN JFLa4t9LI/gvHr/+c9x7kCXLNkNzkYngX47S6nzmTgoywrleBIArCIJHbS6qa1bjGV9R n6FvofnNhqCpWeYCirfply+3sMSrJA5Mp9olNfgtmHBne38e2/MhdUEJoduqbpOi2md2 Nfi3RyjxzchlveBapqT+f2eMkaJE6f4P4BFBOcnxmM80sL3SZo/Hdr/UoosUpK79Aow/ kIgg== 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; bh=gG4JQbu2ViZJSn6XOJHk3K+AtrYE4frOHCXu3F3JspI=; b=LSrVrC2hoyjk/wg8D7l5PM1czNwvjP3I5VJ8Z0CUfkKWuiLH6G5/QFZji2RKM0fg0X efAfrrxg/n3YlsnlN7/R+BKIpAT2USVK8N4Wo5/XTMQT9n62WKgZa2c6mlCY94VWPFvb lylXN54H6YFiGCDSDsmD5kIHUCCf+pVXBZ87A+Ml77jCtdBrJU6qTcncmHEvULgGSgor +cpiKc3wm7duJNtKd/ebOJFhMdafHg28WRkSXh81wzSFRQs6FXbB6bcNNk8VLJ7bUTSt cY5hOl0/tu9xxfbMMYHWMG+3JsDt/uWFA4vZvIA6V9/a3cp3C+zd7VqYXqZ58OAQABFW PUqw== X-Gm-Message-State: ACrzQf32rM1v/Ey+YOW984yX+gdFQX1FBsWGuwtrcJ10z/tDJRENBgre MsZm7GxE1wZF5w88nY+cJ6ST44tam7Q= X-Google-Smtp-Source: AMsMyM7t1ljaJWmMRhqt5l5lnvlzonOLlepWoWn5KB7qTUB3ENH79KZ9q6fjv44yAx5MIQ5Fvo9qaV7RJiY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:3912:b0:203:c0a0:f582 with SMTP id ob18-20020a17090b391200b00203c0a0f582mr971876pjb.141.1664585978962; Fri, 30 Sep 2022 17:59:38 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:55 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-13-seanjc@google.com> Subject: [PATCH v4 12/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- arch/x86/kvm/svm/avic.c | 46 +++++++++++++++++++---------------------- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/svm.h | 9 +------- 3 files changed, 23 insertions(+), 34 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 535e35edce1d..84beef0edae3 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) @@ -1067,10 +1066,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)) { @@ -1146,32 +1142,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 afae97ea9a06..37fe7bcf8496 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -819,7 +819,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 diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 7a95f50e80e7..29c334a932c3 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 CC99EC433FE for ; Sat, 1 Oct 2022 01:01:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232944AbiJABBH (ORCPT ); Fri, 30 Sep 2022 21:01:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232934AbiJABA3 (ORCPT ); Fri, 30 Sep 2022 21:00:29 -0400 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 19FB8F02E for ; Fri, 30 Sep 2022 17:59:44 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id a6-20020aa78e86000000b0055f94e0cf93so103343pfr.20 for ; Fri, 30 Sep 2022 17:59:44 -0700 (PDT) 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; bh=R71/O1P9jP2UCrSl2xyd7gUnWafXM9iFFvICxHImjJ0=; b=AYxux+7e23c/mGRsa0oWHBBFkLGtZl861dd7syAbRuO7+Ds5sEWlh6juenHY/Ytezx 7rgZYiCikzb8acdYu/zEJxsJRxtR1JAoR5zDGIshNA4Vf85IivSYdGQMMft5PWfN8EDQ qSR1wqQV1MJIrhkVDAdqiPq9tRraTer3NTC7Ujg0YbwQYp24mgz4Agnncjy+RsfYyJ8s gH/km0nAmfWe2IpsjzSC6I8qUj3YXrVQj2P/IOqkoBAky3VX0aXqwlog8dP00gEGViFU PVnZAfF+DGsHTJW18hef0cf/mlDCdKkO2Jis5CG0mwmvGNC8sEgbH3j1OHWzmf2zky1n 4pqQ== 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; bh=R71/O1P9jP2UCrSl2xyd7gUnWafXM9iFFvICxHImjJ0=; b=Gv1Rzl8SqdmYxIsSn0/AOKSA3VLgfWoMUH7loFRjaSCTLrAkcSuzOql5h0nPwo5hkt PiWavwZEngOiwsN4hgO/LU75ojcuDmsJfg5/jD0MV5dZhRB/y7cj7Yw9eT1aw2q1eQ4j dUzxQBIfwXsDwEFoQqkOAdLeeg5Eht4K/SMpWhp5PelN7iSFHCRYm4PfdGcSDND4J1M3 /sPyh3rukRBx5FvFzfKHz0rIETNXc54hyZgZrqnYmRTzxZ8yncD3f445Xmxf3NESpoYE JOiW6XfvKZUqEVkPZ2VrbxcRPiuCsejO2aYnzJhIcHY3szA+LTtxkKzHfASob75OSVH/ vcjg== X-Gm-Message-State: ACrzQf2TMSC8fGtiCK1PUNlDJ9Yo4uxNBfR10QeFW43EmdE+P1tZvtt+ ycMk4LQh9dY6VvkxbUx4uSxRPmiVaqw= X-Google-Smtp-Source: AMsMyM7qCmzQLjzaNVTFgQBGLOTfMEkezvJYAbDwak7x/wzNrXvUQ95sIVSrL0jchLKF+6hUoIv3m/R6pRY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:8891:0:b0:55a:daf4:c188 with SMTP id z17-20020aa78891000000b0055adaf4c188mr11606489pfe.82.1664585980821; Fri, 30 Sep 2022 17:59:40 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:56 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-14-seanjc@google.com> Subject: [PATCH v4 13/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 84beef0edae3..e9aab8ecce83 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 542FDC433F5 for ; Sat, 1 Oct 2022 01:01:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233014AbiJABBn (ORCPT ); Fri, 30 Sep 2022 21:01:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232898AbiJABAs (ORCPT ); Fri, 30 Sep 2022 21:00:48 -0400 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 2C7AB71BDB for ; Fri, 30 Sep 2022 17:59:58 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-349f88710b2so57220507b3.20 for ; Fri, 30 Sep 2022 17:59:58 -0700 (PDT) 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; bh=f70Xbl04urcnggP1iLNXSgd90V7DfOtA4Hkw+IrGqsA=; b=e4uxUpUQ+QYdNoNsX4vjc6+X7Krjind/BXqDg4Mpf0wuclTuUm/UX8PJIBIpwhbdyE 3k8hah7Cj3o8zwn0fmu/X8Whwbjv9wpqeA5/oO2tZZEjMAKFJu0o+cyN/Q4kbu9Ip4Ag jXO1+ddcwdndqBHIDmSaAHoVu5eHb/LZ7GOQzuFCDwsa8KtE1+TFMyWUQGGgoku9bCi5 NLLQ+QqIHKpX7tkSXDjER5jA1BsUXfTbSmaWV8/znmQS1boXEfYGnnR8Rwu+jgt7Tac8 lQIGYQBty3IJiYFTw1IWYFsUrcA0Qz1RRtXI9yzW9WJTlBANcJ4kXL5xfO7wIyonaZWZ JpLQ== 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; bh=f70Xbl04urcnggP1iLNXSgd90V7DfOtA4Hkw+IrGqsA=; b=3Lzv60V/AX66rTPYTyozy+cwnFQ7k9i6DUkGUXPiIzS3xFtvlqc9/NqNKIet7xE2Mq 3wN0I5aQFKtYF8njm7df68xtBSh8b0nX7JmCpohMoaWR4zBylhOe6PwszB+bc4rGOP5A rrBzWn6EYDOz0fpJuoFkvjw+0Xs3k7uEYh5nuqrPKqBsC5NUZthJSzfMUD5pVsTtN6sO 9ajMk9hClas8YoyTrEYpq6uIa6X7DMcq2yYyvGFX87emQTMTB00n/WE9GBOkpel9L4IL Gnjc1ZPj5DDniy/AnGI6DBsjTSBL2RBT5Qzsb3Fp7XcEM26RihD3Lqr4lPSkBimec+ro 3sRg== X-Gm-Message-State: ACrzQf0rc+9Kp9mVJWPQYIWKZs8zPDvP088IS7IvVsTu9Ahoyw944RCP AsFSsJUUDkK9SKs8youyhyQtvU3P6ks= X-Google-Smtp-Source: AMsMyM4lkLby1gHEeOFWlADHcALsYEFrFQWm5GSqcMKQqTBGhNW8SUByosuBg8IDIjuQm/0NpZoRx/Lk644= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1028:b0:6b4:8d06:6b76 with SMTP id x8-20020a056902102800b006b48d066b76mr10610823ybt.182.1664585982678; Fri, 30 Sep 2022 17:59:42 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:57 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-15-seanjc@google.com> Subject: [PATCH v4 14/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 e9aab8ecce83..e35e9363e7ff 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 36F5BC433F5 for ; Sat, 1 Oct 2022 01:01:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232985AbiJABBy (ORCPT ); Fri, 30 Sep 2022 21:01:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232981AbiJABAw (ORCPT ); Fri, 30 Sep 2022 21:00:52 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DCAF786FD for ; Fri, 30 Sep 2022 17:59:58 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id d7-20020a170903230700b00177f6dd8472so4221659plh.6 for ; Fri, 30 Sep 2022 17:59:58 -0700 (PDT) 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; bh=dFvueQwazR7qcZPfUIQimBC+x3rQLHZMrcIkKg64ifQ=; b=EpK0ALenm4zbHpOSA24Pi1/jyH+cK1w2xDgB8+8UDnsHC30boFQKR5lHjpQI65qmEp 4yrKvTH9N0rjbQC0cfCsK288JroxVHupqkSDa9NoyYP77yu4I/3n2r302uuFyFiFjWch 5E5ALuMZRFhuBXbT08VEbhNwsnejhpnyQGPViDE0+/YuNT9KdYI8CnCHLu6dh4GcS8xR Fx5kTEZM6dQs+DZBlQ+JtTjHIBwTBE5wAZu02RrrmHlzYZ6ZyRMXhZ4c8kdu88MtOEQr UyBApkdkfnKok5tYqiAvZ59B/Mfhdltpzuoo9WLcMPJQcM3lZCNIQ16qt7AqZBPi81Ht WpxQ== 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; bh=dFvueQwazR7qcZPfUIQimBC+x3rQLHZMrcIkKg64ifQ=; b=5p8yMXwSrcr1sNx2lVERU+F3M9jd2cqwyluE8cKYjDYIs2v7LFrOFmk8vm7/xKxE0V NNnM0SCkljy6kqK2/F8M00d9NHv5DwQHb+FFga9mvYkTy14NmKlYr+OBCjNqmN+RuIF2 ES96KFF8EtTN4VSbURZA5nroSjLUWTB0ZYLGoZ5kEwgFh4Qg4zKc9Lwor4CCpNSks0yd JAPEiadK64ok9ZFAx4Xu4YxWboo+pC/1HBBrlPSkjC8dl7kJjcIOiLKT9tK6pOYH2aB3 bZtU0BRg2loW1G6i0ms9HJjw3+y/xuT29j3XLkCMBK+CQGWTGAEj7/v//lFGgoHLmP67 0jBQ== X-Gm-Message-State: ACrzQf0GyMfvJsBo/Yxfd2t8m8zdfNmDpVUL+8aGGelBWAq37mLrLias B6uVatr6rZaJ/FmEQa23AyGvfHmhP9s= X-Google-Smtp-Source: AMsMyM7HbBoWFKSA1thkQrOuQSvSNO1SpJDcXbx3J+FoPh5Xuv4GZ8HJM5KW5zk/CDlvfiinmdBqAG+fTy0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:c9cc:b0:17a:a81:2a8c with SMTP id q12-20020a170902c9cc00b0017a0a812a8cmr11487126pld.6.1664585984328; Fri, 30 Sep 2022 17:59:44 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:58 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-16-seanjc@google.com> Subject: [PATCH v4 15/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Reviewed-by: Maxim Levitsky --- 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 e35e9363e7ff..605c36569ddf 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 1AD87C433FE for ; Sat, 1 Oct 2022 01:02:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233028AbiJABB7 (ORCPT ); Fri, 30 Sep 2022 21:01:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232919AbiJABAy (ORCPT ); Fri, 30 Sep 2022 21:00:54 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 078417A74C for ; Fri, 30 Sep 2022 17:59:59 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id f4-20020a636a04000000b0043a18cf1a5aso3683757pgc.14 for ; Fri, 30 Sep 2022 17:59:59 -0700 (PDT) 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; bh=h+90iLbssT+2X1a302WPpFnb6f2TypfnLO84iY5RrGQ=; b=mfZNCXiGnI7p1ypGzL1ptYh32xDJBoAspoF6otY5o4Ynm+Uk57mzPT+wcqcPxQeXVf 40To52bA44S5E2jpfqRz4OdbG9X+FL/OX2VRxFNrzeasSphJ9sf+FwTu2/mPCymNoKAr b1Y1lAaSD1OPqdpUQHync3ncJVBJYpohU1xQP0a/Z38It3zAafP47FvOpPMvYZ+/X5ir 9O91TMuIq3K5mM2KpTzsDXDiXpsHpDH9kOwUbmPrzSPowY75geq4kuaP82LRqbWmZWl1 oBFbWzEFLfOZv+VZ27KG7SjJQYhNDsfjOw4Xy8M6VhGjYw5uOC3JKJc6rLz61SnZ/M8U keZg== 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; bh=h+90iLbssT+2X1a302WPpFnb6f2TypfnLO84iY5RrGQ=; b=6HrXYCtJ2k9ZBhtXRshiYkytpnOiIcAaoUWz2h1eC3CuEX1mCVaSW7zzNA8cJnA9kt ZVNSf7FJX4yGFsFchYAIem7zjz+2yT/FpkKubtoDQUL2cT2I3+btOHx82aJy3JyAV/Sy T34AqaSVUYYmnc35dEe/qqSd6pOo3XPNLbH1cSs6kpxb3OlyqszSQaQ7eIRpHwlsrNhh 3q0HqGMl5sv3aHTSPvFbyFL7EXbWqDjAcAuvr3N3LHGk3vVseV6f9IJht7/GHDhzCILI 29gJSUQtEkb+4flqgrWnyfqpA8m+iwqQHJHa2GrWo6N9NzqX4cG7jSmMbQ982NxSlPr/ PDJw== X-Gm-Message-State: ACrzQf1MsRa6SbrcESpIlmsBxnVjuzJ8dgENd1Ngso/X9QXUKwnshDWf vihgdjy8DNXctz/VQQonDygkmlyRyr4= X-Google-Smtp-Source: AMsMyM5UxvnMw/tmRE+RDi5H/pVH119fO6xKYnbBT71PyTQHZUb50MZJ6s5H9c1lBVwPg8WoW15XancnCxQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:1705:b0:55a:b9c4:6e14 with SMTP id h5-20020a056a00170500b0055ab9c46e14mr11665821pfc.40.1664585985944; Fri, 30 Sep 2022 17:59:45 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:58:59 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-17-seanjc@google.com> Subject: [PATCH v4 16/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 605c36569ddf..40a1ea21074d 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 6E873C433FE for ; Sat, 1 Oct 2022 01:02:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233034AbiJABCF (ORCPT ); Fri, 30 Sep 2022 21:02:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232867AbiJABBD (ORCPT ); Fri, 30 Sep 2022 21:01:03 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71F019568D for ; Fri, 30 Sep 2022 18:00:04 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id cq15-20020a056a00330f00b005438e527f24so3629366pfb.23 for ; Fri, 30 Sep 2022 18:00:03 -0700 (PDT) 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; bh=pEkp28ZobAyyWF46XmIlZjPBuJyvs8FGaKhwOrBbQEk=; b=Mdu+wWgALHSMEFKw+vWqrkrvn4U5zoYpYRfOa11/vzMl04h/uwKkyzXxcwluJ+mU// eApu7Tl7C0cbsMFFcB8lbdCXL487eUEtvgQHTt/72lnAKGsJYVZ/kRXNIJmda5SB6MZo Uvuyn7okG2JagRZv4rsDs7hDjY6faZVXWl+4WQ3Wqg/I4+QO81ZxgL6uC0gxyU3XJKMn iREo3cDJPNE/NULSPtL0rz/J3PEia2Q7WEvApC6Zz47tvJ/aBKhtzGgLMusidl2jnIK7 Wev8LjqGHkQTQsgJZdmu/tUdp53bv+N0VKFlNgGWBv5ztlwe2jp8XUdfZmho3LkYSFbV RFPA== 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; bh=pEkp28ZobAyyWF46XmIlZjPBuJyvs8FGaKhwOrBbQEk=; b=ma2rPup14MLDs3ATpAKgl9+Rt19yGsMxq7BsU5NYxESCJv8s5XU+PVqKI7obt4Chkd wVmQCeLOHGhtWecEtbumgcRPC5ESGNqctTgowZ/axd7Y8lRMZTxVOz5hoYhPVaScghbC Hzq5W7sdumTOnHQdA1cYlqfxRGZKgYx16njxVgGzevl2QogYSrLJEsrPA2G8PvZcguyJ tikXv6I8GDxGxoGXmAhSyf1wuQwqdavah2jmhvLcnl1tFnKgCuWmfDakQKrroNdam+Vd w36UHJ4QHtN2S9MTZDmdWcJZACBCWZJxikmMFU+tmYw2qiFvCYOBC6bhfEs5JlqOobQR Y3tQ== X-Gm-Message-State: ACrzQf1CQOzQoxrNExKSgsyWX8MVDBn5irilcIoIDSBsMvVAB/RygIBy vMkVDDJCFgnfckpgUrkW65H5LFsCd98= X-Google-Smtp-Source: AMsMyM5JPrH/tp8xsCZu6xZTmfecKtT8T9J8eHL9zlhY/bEBC+uhDolSA1yf7GeIEsbujjaSTsMqGsy/mEo= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:c986:b0:205:f08c:a82b with SMTP id w6-20020a17090ac98600b00205f08ca82bmr517167pjt.1.1664585987422; Fri, 30 Sep 2022 17:59:47 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:00 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-18-seanjc@google.com> Subject: [PATCH v4 17/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 40a1ea21074d..dd0e41d454a7 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 0C905C433F5 for ; Sat, 1 Oct 2022 01:02:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233070AbiJABCW (ORCPT ); Fri, 30 Sep 2022 21:02:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232954AbiJABB3 (ORCPT ); Fri, 30 Sep 2022 21:01:29 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70A42B40C5 for ; Fri, 30 Sep 2022 18:00:04 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id s16-20020a170902ea1000b00176cf52a348so4224545plg.3 for ; Fri, 30 Sep 2022 18:00:04 -0700 (PDT) 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; bh=uSNLoOQS29RMH65csyjC62wfSsv+FVU9ZImwILmmR5M=; b=cu5cnfvlhzILzZOTu90hhEus/JcWHKk0Ix+eguBuS8jVRomLlYtEBLLAIExsCXHVev g6ruv5FIBCh63KA5C7qYvzCkgmXv2U425RFzDDfjzHrlpv/ut3aSqLJ02sVsS/9G9UoZ lJgNpEzVPZINtboSHrKUIpfnM2LBuTVEekL/n/jFQjTQUcvhsbKx4xl8fV+SkP9oFLTE fjYjfkNn/+6bwf4SpzKgEjpA+D8aEf3ADt1yH2NQrIE4amB2Hyq7FAY5nU6eV3jPtans 1i0rhHatQHKOmRNzLhHQrwh1Vpcziwky8q+EK7eG9nxMkxSwSSyGWHNN4qDzMRWc1z1B sJuQ== 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; bh=uSNLoOQS29RMH65csyjC62wfSsv+FVU9ZImwILmmR5M=; b=jp8lhEnUe5UyF6OXHqair0gWYrIq+KUKJhIyVD2Bl+PE0AQEn5KKVPXb/hU9hTR03S ZOanitRMby2gkksVCwVu3rQOth2TZcaVbzOVwqOyH+E4Un0sSWCjVju6cdIZs1YyuMnU JqBxfE6RtwHZ14ThTHHedZtpZCC1i5j3wVwYTdY3tGuePvtZRLlVgJ+mT087lcEUMnQI labFg17+qB6+39gJ9oD8aY75vPD4hZ7IczUqprwUBeWOd542YFdzxNFRGYDkIbRuuJKV OYX6nw1VtDGM2xIpx273RcVc+/JCNrSLkVKQa+ZbH5HXgSIts01fcPiiuFIU92W6G7DO SbRg== X-Gm-Message-State: ACrzQf1mYikRUcTb4gLbIomSB1mqnZfxL4yt12qvBOVkOr+w+I6iFgRW F3NWAR5opW2AAN5gkq5/C88QC82+4lQ= X-Google-Smtp-Source: AMsMyM6w6MsNyc53d3SQWAWyqqwFCLjE7PmFUyn7cfk2sU2zLrZqqrfhahhdh28Gf0e/BBKIXtmJ9oeRBTw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:be03:b0:17b:80c1:78c2 with SMTP id r3-20020a170902be0300b0017b80c178c2mr9683660pls.34.1664585989336; Fri, 30 Sep 2022 17:59:49 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:01 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-19-seanjc@google.com> Subject: [PATCH v4 18/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 42b61469674d..cef8b202490b 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 DB131C433FE for ; Sat, 1 Oct 2022 01:02:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233075AbiJABC0 (ORCPT ); Fri, 30 Sep 2022 21:02:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232825AbiJABBb (ORCPT ); Fri, 30 Sep 2022 21:01:31 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F1996409 for ; Fri, 30 Sep 2022 18:00:05 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id o1-20020a170902d4c100b00177f59a9889so4228172plg.13 for ; Fri, 30 Sep 2022 18:00:04 -0700 (PDT) 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; bh=zK4Jovt37qXFHbFlJBhO5Jau1lhwM5kyjhPyeBb+zxM=; b=bQBPOXSXvplAlxFdnxFpTG+zTd/dDqqmFwtaX2mEDQNfR5JfQJO6evuNicPDuus+uM /DXorvYQ778zXY84K+4GPabUJX9hYVodbuLHrnFxJodBiRGFY+RqTp9ExIZRH5UE6Axt TwMltMYnqPQqemOK3okKCNccGi+wlcgtBYEYL2MJMfl1o5VS7STs0IBd1H9841qh8Yyr dFIVW4Y/2pBkxmvxEgNrKyvYrmxySCy96cRPwWhkp5uzZLNIPDxcJFQ3wXFhsTXNme9C WfZ8M0J3+7npYGvTwDZxDtvOif99lNvjaWwgcxgeWObUSmhSDXTK8Qj53zzlS1KW8EMF iCQA== 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; bh=zK4Jovt37qXFHbFlJBhO5Jau1lhwM5kyjhPyeBb+zxM=; b=TMhDwrkJ/UyYI65ymOTIC7oIL2jMyv6oXAuvlzW1L/AwhAsGO0VDLq8eJ0OpnkSrax UVAUgTRXE2IiiFE0wKJx2FUD3v0p1oCiAbW9Dh27jrRyzhskPdk+ljWYW1VlG1F18NSx joCmhG+jz6kdYkkaQnTtXIkDYgrVHTB99RQeSKipOL6DAyn+amzKOQx5MtP/9neUUiAz 50HdPZaG3DR061MMLhC0nYo8jAEwdgBxCgH9Q2LBL+uLBL4hHkHt2FwHHE5Vi2VEmAux a4quhQbweFiC64WReQeeIKrwsvXQ1fmPcw9YCSn0QKrJJNynN6H8O0D5jC8wV/x1o9lz NCMQ== X-Gm-Message-State: ACrzQf2X6rtVzcIvHzJlpyVHHE6I9KEevhTon/xom9RPTvFg1zirihoi 2cLcOB27DvvnWFBiQHOndK7NRCA59OU= X-Google-Smtp-Source: AMsMyM5Ux1hAYz3UA9Uvu+UD0d4yLnaEUrhhU3gxI44ARyfveGvEK+y7RexFIBSc9bzXkd6EMgoSxUmDrSo= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:2314:b0:546:ce91:89a3 with SMTP id h20-20020a056a00231400b00546ce9189a3mr11596003pfh.77.1664585990992; Fri, 30 Sep 2022 17:59:50 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:02 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-20-seanjc@google.com> Subject: [PATCH v4 19/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- arch/x86/include/asm/kvm_host.h | 21 +++++++++++--------- arch/x86/kvm/lapic.c | 35 +++++++++++++++++++++++++-------- 2 files changed, 39 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_hos= t.h index 062758135c86..ac28bbfbf0e3 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -962,19 +962,22 @@ 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 { + KVM_APIC_MODE_SW_DISABLED, + KVM_APIC_MODE_XAPIC_CLUSTER, + KVM_APIC_MODE_XAPIC_FLAT, + KVM_APIC_MODE_X2APIC, + 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 cef8b202490b..9989893fef69 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,26 @@ 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; } + if (new->logical_mode !=3D KVM_APIC_MODE_SW_DISABLED && + new->logical_mode !=3D logical_mode) { + new->logical_mode =3D KVM_APIC_MODE_MAP_DISABLED; + continue; + } + new->logical_mode =3D logical_mode; =20 - if (!kvm_apic_map_get_logical_dest(new, ldr, &cluster, &mask)) + 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 +972,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 E138EC433FE for ; Sat, 1 Oct 2022 01:02:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232880AbiJABCt (ORCPT ); Fri, 30 Sep 2022 21:02:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232991AbiJABB6 (ORCPT ); Fri, 30 Sep 2022 21:01:58 -0400 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 A7F3BBF1D7 for ; Fri, 30 Sep 2022 18:00:07 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id a7-20020a25bac7000000b006bca90f4fa0so5228468ybk.13 for ; Fri, 30 Sep 2022 18:00:07 -0700 (PDT) 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; bh=zGJjgeGb5byLUqJgqEY986KYGiQTamhxB3MKdq/8Nxs=; b=SgVLlvgS6iLoaJTazsHZsgnIzTArr/g8dO5/icu95n9EyKqI6z/C9+WZrRApHDDS/b NXb0om8dRMmQHnwquMIhUlXZ5fyFqQwakCOMrEW40kFS5DxwbUbKhEPVq0OSI6zPTYlF fHPJIgacfJ2YiBVbyrPwwDXTEZT51Mg9av+NxOFSiFaF0LAeOFMuf6QHlvMODZz7OVGa 4XDU8WAn1U057GwvpEj3yQQfAdbAfhdckiFhf+5XbfF5LRn+F52wIm+iXBnM15Z8Kg7T 1zGsF4qF9Hl6jCjYTBkONUuV1Xdc8QHZI531htpLyNSq3D72b8K0ROwIUuY9Mik1G9P8 Y+MA== 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; bh=zGJjgeGb5byLUqJgqEY986KYGiQTamhxB3MKdq/8Nxs=; b=SMC0FDZ50NdDawcz8vczOQo72LO7c296Blmujfz1jG/7bjZFta7Oq5A4GPcDZyyXe7 LnfRtmS4IH9ue+aS9faLiqmqMNxTXvM5Ecq/P0FwXiQ6YZgr6RFNNcvEiSmtAJWj4Jm8 sbexOW2X4aDe/12teCGfRc8cEHcZn1ALrWz1AseestQND8BeJNx7NokWxXTbfN+KEsPW qMxXhHhgDWeGeaxfME5iJmQQqke7xakAanfyuPnmNfTEuyB5b3hDQq6JuaChsGRUroBB GW5DgVqnnZG25F9LSaon9Ft0GyaNpPbdDkh1Czd6+4XP3Mdb9vnE5xOWbpGvoe6MA4tC tD7A== X-Gm-Message-State: ACrzQf3EKsjyhQi2ANdbYtDT5LNX0nKmkkGFTCDDdJda16Bt2xO/x6eu udS1TBb7cug0yA17soobnXbPqQmfhYg= X-Google-Smtp-Source: AMsMyM5oUcNAYKqngfw8uxXjqlArjGuLA67Dj2SROVnmKezZnVMPQAtfcw7SbomFa4FpIqhD0q1v+OEV+Dw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:5cd:0:b0:6ae:a4be:ab42 with SMTP id 196-20020a2505cd000000b006aea4beab42mr10394464ybf.323.1664585992779; Fri, 30 Sep 2022 17:59:52 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:03 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-21-seanjc@google.com> Subject: [PATCH v4 20/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 9989893fef69..fca8bbb44375 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) { @@ -315,6 +320,18 @@ void kvm_recalculate_apic_map(struct kvm *kvm) } new->logical_mode =3D logical_mode; =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; @@ -381,11 +398,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 0202CC433FE for ; Sat, 1 Oct 2022 01:02:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233090AbiJABCh (ORCPT ); Fri, 30 Sep 2022 21:02:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233011AbiJABBn (ORCPT ); Fri, 30 Sep 2022 21:01:43 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53E5DCB44D for ; Fri, 30 Sep 2022 18:00:12 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id f4-20020a636a04000000b0043a18cf1a5aso3683880pgc.14 for ; Fri, 30 Sep 2022 18:00:11 -0700 (PDT) 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; bh=hhcjKYj23YWXw5bc06GwUk4XMJj5K2PGd9rVASFSpWo=; b=qtM8qb/++PwpgXE2ygkDVfIK//jRrXsh1Omp8NBBjy0Bi2V4L+SL0932+qwGCRQ1eO gQVyVdaJpR0xll4/hJ4iUhPV18G5g6CmWEml+Nu41FjKWXxNHqsyU5cI/LIMxOKbeZJu AO4YL/N+HJGs83bExHbqGrJAiGNKstEA8+jouR1/Q7Q2iCKe2mktRsSWjRZsF69BAFUT WdHLiHD7zI5GhMfOJqkkc9MIOEEXzu0Mb80wASiV7p6Znx7/JoBXUsYcG7iEtYCiANUI jOUXmvJ5NbNOLJHuBH9MbmrDWyRwGYcOp79VFDiQ/l/9E//lmqUG7eHAEC0zlE2yLY2g 0Lag== 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; bh=hhcjKYj23YWXw5bc06GwUk4XMJj5K2PGd9rVASFSpWo=; b=YYmujReRGDmyLnpN67W7Z7jy8UyWZxm6C4h8ipCZKKi06U/Y6NZU0mVp2hzes78AIA sBeNPQNPo+/gn93BOof7eNOXSx2b5aZaXFRckGPzNpi2oy9exjNVV8+CcI6xZizKKuYO z3MV3PW4eUohAIJfLl4NQTTSk02JXf52bvW0xITXkOATH+DWcPROd86O6rjo3oMyorQL ORh6Wf2maEOGjJuDZkI8gLDLM/8AteQxP/vsIicG+yBRbR5eNA37d3gcIFSPgAep7O42 MVhdJLLwJtCSymW4XEH893UBn+Sr1XvMGmkbD2p23XAOjyZBE1Tj94TRKd1BXSgY97ab 9vJw== X-Gm-Message-State: ACrzQf2dwMyrph1AQRWOhapmm32J3mYDuC8MuAsOGgKu9AL23bHvqp/H /uD/tBMBO/OppXd7vGO7bhyQGGUiAXg= X-Google-Smtp-Source: AMsMyM6KQ7OLb2NI9kzXe2RozSCiOLmBy6eUO9tIPcSGSxDHZtFK3SySAG6SKJ17NWpDOjDwB4/9hRfn+YI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:2442:b0:176:c8ee:a5d6 with SMTP id l2-20020a170903244200b00176c8eea5d6mr11245653pls.20.1664585994392; Fri, 30 Sep 2022 17:59:54 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:04 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-22-seanjc@google.com> Subject: [PATCH v4 21/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 fca8bbb44375..7fd55e24247c 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -338,8 +338,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 7CB0BC4332F for ; Sat, 1 Oct 2022 01:02:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233111AbiJABCv (ORCPT ); Fri, 30 Sep 2022 21:02:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232992AbiJABCA (ORCPT ); Fri, 30 Sep 2022 21:02:00 -0400 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 D2111E5886 for ; Fri, 30 Sep 2022 18:00:15 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-3521c1a01b5so56805057b3.23 for ; Fri, 30 Sep 2022 18:00:15 -0700 (PDT) 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; bh=LyAH7hE4jcL9QcgVMCH2onNrTIVmeTtfuLQRhpXukZY=; b=MlccqVYVRGGnVkH/IoFciw4sGjXt0kp761f3WozY1LkqPii8NOsfz5TI6jRX0ScdEi be+cHOBk3Rd44MIY03XLtWQ1R5wca3jFhe5LedINJRQ3D+YqxEJcyixFQey64/Qg2zEo 9qgBs+NV5fLTkbYMoDkIUOP1xrMHW44TiPq3sPfC4rnJCmASJYfwDId5FfqpREtIfPKm q7s6mBAK12dQqU59hN7FdLeo0rv9hwP419T3rbDYrqzFDDYFZ+HxiuuOgAA6xkzXxNU9 unZ+rkn0VNl+fgoVEVJ15OENOoio2zWzhzyw6JPdmtU1mjocXLebprCEyy4o7+q4hZFR URuQ== 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; bh=LyAH7hE4jcL9QcgVMCH2onNrTIVmeTtfuLQRhpXukZY=; b=wK8lWgkX6Q0cie0RK8d0BLMPQGU+TT4KagqYyaNFLp/74ECrVso34t/TFVuWXd3XY/ MPjXN0LgnAHwN5InnM0ZeRq6MgXa/tYzaSpyEgUqPo0v4t4UXKI1L5lJyFqc2QBVBRMi WllYFnqph8wVFo7bOSmiDrVvsI6kDFYGp0emPcI/njlumhXLPC4K4vcwWK9W3KujGCNE NH/bJ5mLW7MbjO2zLhY7Ntc53GrBp/8COPC514p0p3HX6pxYKtkwp+9z8PRBpnLbpOY1 0BGkJLVL4w6NxraGBeEFaWids/mClgQU8kn913tJ9JZ6uWHSK2BAhm2JVukL1fsihlQe JftQ== X-Gm-Message-State: ACrzQf3uhy9Jqhxmq6LPhkFFatg5a3HEtGz2Qu0BFOXy69R8aU2j7bJV RSfqdh7lNf6EHG4tKmgW68yEMGE7eFk= X-Google-Smtp-Source: AMsMyM6C+3TlSeGlunUd1eW9Rp33CCs61sjN1XLPKi3j4nR57e92LiXCa3ye9Lka2dxO2w6jaAv/RqCkfuU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:10a:b0:6af:b884:840e with SMTP id o10-20020a056902010a00b006afb884840emr10898548ybh.330.1664585996098; Fri, 30 Sep 2022 17:59:56 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:05 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-23-seanjc@google.com> Subject: [PATCH v4 22/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 7fd55e24247c..14f03e654de4 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -341,11 +341,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 68D2BC433F5 for ; Sat, 1 Oct 2022 01:03:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232876AbiJABDC (ORCPT ); Fri, 30 Sep 2022 21:03:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233040AbiJABCP (ORCPT ); Fri, 30 Sep 2022 21:02:15 -0400 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 12C07F1628 for ; Fri, 30 Sep 2022 18:00:18 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-3553d2d9d7fso52358617b3.5 for ; Fri, 30 Sep 2022 18:00:18 -0700 (PDT) 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; bh=ImF7jtGIWsEQFmZLHvw2ZrcuCkowN+9OcwQZDkOS8Jw=; b=Tn5woglnp5SZq3nLO2ixOB3tUyQGkXWs8upDL1g76RMOiLpG8acsE5ufPXN0hKCDOa Sn7Rc/DEQw/PjSwRu7K+V5+QDpeISlhIamISw5HWMSb3pVUFHm2ix37ueq2JhLsKN4Ig ihQ1Q1qkKkR5cOXm//rspQHc3jrSkee+CA68y/rDNYXaalL+ZX8A6M92b437e9qNFqxy TbSNPtmkYDw9SJGidznnG6V33Ba+xtuKWvqxbcpfNFr8aOf8DBC80ZvD476gVCn873OX sNlv+QZ0dt8a2nuGHdBq0LJ0GpxdYZ2PlXwdnyaqFqzs2iTMO9UGCIdL6kKIQroOL4wc q3qQ== 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; bh=ImF7jtGIWsEQFmZLHvw2ZrcuCkowN+9OcwQZDkOS8Jw=; b=MeTHdUtPxB/pq0ys7MA9q4a7+SaIclPu0u7aMLWm1arSB0jvY+cSJXepvRGqTVp92H RHX/yUA/1GuCxnNCiQ2orsOE8BWEn2QVBFOXyGG2heJ8rgIJLJHWlR8aIa/x0ZimT+uk 8f4E66GG8pwNQS+uZ0kTHFcAma+KHg6Z7X9ebDV9lXjCT1zjpLQDjKSZh3D8gF/8F9Ss 7yLdbmR+dTtKnRUqeSayZe8wqCWrLqMFzW+9O2rqKrSVsv/GwlaMPcMDotHZKTKYkQxr 5Lp18bsc4QPMZNpsFeUQFz002F4TIglL99kfVDNhFsXXzkPrB5e4G4GKJDXy9YOpcIvY laDg== X-Gm-Message-State: ACrzQf0MpmGNW5mqHcxKGrpqDziBXyIRn4NLyXak07kRl0ZWXyAI+jLI SlhHett9VxVsK3jnV14j7jp/tdplvj0= X-Google-Smtp-Source: AMsMyM7dIjlXkMrqH6aATRjv2nSnifL9224lejOfJrNhT6vmaEGrn2lAgRKW1tXwOrn0Uf2KmPaeRpJRxsA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:24d:0:b0:6bd:2936:a191 with SMTP id 74-20020a25024d000000b006bd2936a191mr1724809ybc.112.1664585997792; Fri, 30 Sep 2022 17:59:57 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:06 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-24-seanjc@google.com> Subject: [PATCH v4 23/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 aliase 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") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 14f03e654de4..340c2d3e781b 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 76015C433FE for ; Sat, 1 Oct 2022 01:03:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233064AbiJABDG (ORCPT ); Fri, 30 Sep 2022 21:03:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233043AbiJABCQ (ORCPT ); Fri, 30 Sep 2022 21:02:16 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A40AFFB22 for ; Fri, 30 Sep 2022 18:00:19 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id 126-20020a630284000000b0043942ef3ac7so3726884pgc.11 for ; Fri, 30 Sep 2022 18:00:19 -0700 (PDT) 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; bh=9LreyVzYGzmK/M6pRFe0Kt3YpPFGdlmgJSpVgDAtoSQ=; b=qLJ0vasa9TjSnqtCrvpmPlD+s2Q34ltzW9TU12k/BYcjipcvZZPk+osTW9p044ij8b oDFg2TJJMcpDnJeVRtvk+Pq3JzkiCe1pi2NXrRvkrePVfVmhFw4Hp1ssVVv+V+CiTLkH hCF2fV6hGm/UeyUnOaWB9VIr2hh3Mbiux8AsAvlfPStGHZ0c1KPVlCBIbg+0d0ik0DDN 2qfVTMOGCrMnBN/fbb2EFdTjV+tIey8ME4d48nS1W8c9JWecf5oAA+4qAxT82KWI5aTd F495FB2BUhYF4UGqQzmWIa2cRwTbzj9R8nVBje+3wqhVRPNDuOX47Jti6sSDqHUYH+zm 5r+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; bh=9LreyVzYGzmK/M6pRFe0Kt3YpPFGdlmgJSpVgDAtoSQ=; b=m0PhZeh51z50ThHxV1GpS0LvZUA00sd/24ic/MCyTw4HxAh+/f+a2oovSZ4DzPr9yv WSVIQqLp5rMACaUZAYE2baJaoTNNy5Ug7m9a+ALiQ+QFMJj20An3+MeTQbG5+YhiTj5g s3VMRBob3XawAGQxtohBGHtuvtOraJgNOvQSBeadOVKJQVbobeEyNeoXcERbY52t6eyI xpXqHAVWRQbzCGX2WcxAcnRnArKDaGl+6yB4XlwCdPHYafnVQwcH/IH0PmlYaTVhTxR8 f07yKkZR/ERLTXl2BEivPTnBV+RupUGDxHxu7GGdwpqv7vigCM0V59svIDXIzZpMFU6N t/YQ== X-Gm-Message-State: ACrzQf0HNO+KwAzx7wzIqUrQYZvf2ZFrVu1dmscqyezNZAgQLaHWH/tz w68b5YkS698YrSpwcTDiRGTfP1NBV7Q= X-Google-Smtp-Source: AMsMyM5o3cSRXk1Ul41PlT/qbXOMFsS7yS6gj8hxn9OT7I7Qa9raysNtXDxSjeTeNX11GH6rL7NY0Z2KvKU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e80e:b0:178:2ecb:16bb with SMTP id u14-20020a170902e80e00b001782ecb16bbmr11385068plg.152.1664585999489; Fri, 30 Sep 2022 17:59:59 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:07 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-25-seanjc@google.com> Subject: [PATCH v4 24/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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. Fixes: TDB Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 ac28bbfbf0e3..171e38b94c89 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1104,6 +1104,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 340c2d3e781b..f6f328d36ae2 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -381,6 +381,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); @@ -2153,7 +2163,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 unwatned 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 dd0e41d454a7..2908adc79ea6 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) | BIT(APICV_INHIBIT_REASON_X2APIC); diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 974d9a366d5d..5920166d7260 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7955,6 +7955,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 60BAFC433F5 for ; Sat, 1 Oct 2022 01:03:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233140AbiJABDL (ORCPT ); Fri, 30 Sep 2022 21:03:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232948AbiJABCQ (ORCPT ); Fri, 30 Sep 2022 21:02:16 -0400 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 BEF83139F53 for ; Fri, 30 Sep 2022 18:00:21 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-3553d2d9d7fso52359177b3.5 for ; Fri, 30 Sep 2022 18:00:21 -0700 (PDT) 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; bh=HY4Thk5xVyPi8wKWVdpWupQbepWNLCynruIllm630pU=; b=UMPvRXSU4HOXUmmnmc0jCi/0QPbsXPdSBTKgJqc25cCrOAQgtzf+tyOoZaBNLF9QMg n2b9DRSZpPSdhB7f8X8BG3gj3Ab9xz1/087i9IcnRTZEqBTGL7j6N386w3snyMlZApP4 eDCC4doRfm2dctlxOQilOfUCYiO2GG3IyJoqHMY+uSCGJjhkTDCXTiNeAxnrPTNOdcEL /l5eXYMr3GHQwFnfgq04c5YmsZeJAqhVXP3yMojrBVpADN9ciI0WLE2AfN/tc74m2V23 A1mN+3+oSe91kkpk6MnfzaT7FAeznCOH6k/auTehPLbixkHgvPtO39wpYb8hssFWUtoD ThSA== 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; bh=HY4Thk5xVyPi8wKWVdpWupQbepWNLCynruIllm630pU=; b=z7LYmZbh+WAWWqzk1Fv8EXsg8/6+cjbBF/o8yHs/YfjH6Sw3GnyIRzu++xinKHB0SJ 66XVNJXm46DS9gZF5xOVBiAPk6pizZ3QT3twP2f+zs8vbMN4hNBU0qqyQ5K7V0FT2KTc JSfPaFhxvG9y/pwCX3qhyT7hWLQcUOl+m+XGupQ9wbSCERAMs/a6hEFl/Iau5FnD5/FT KJSnZaMvcxJEUjVwXyIGMEoCXuoFPRYGKWO8BAjLzh7L1rQyFCeANv4fDHrrmjVOGYCs KVUUSvBxW37XuQl/yghLA5yO9INhRFaUUPtb4OYecvGEvQFWQd6BddsLwiJoh4P+754s ++bg== X-Gm-Message-State: ACrzQf0QLErU/O3A7OepnHPIsMbXhmxzTnDIBKAdfnDXIvrrw6WocntA g9EWrjNPURe4p5a+wFkhvLaOSWEK1jU= X-Google-Smtp-Source: AMsMyM6rWD4QbGIvONouo6zkfDiIWLguwc6s8vjrkpUamNM8RtGPhWMCVyL0s7k2Wdo+5V14cJnbWZR176Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:16d6:0:b0:6b1:4a12:b2f4 with SMTP id 205-20020a2516d6000000b006b14a12b2f4mr11014876ybw.217.1664586001024; Fri, 30 Sep 2022 18:00:01 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:08 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-26-seanjc@google.com> Subject: [PATCH v4 25/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 171e38b94c89..4fd06965c773 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1159,6 +1159,12 @@ enum kvm_apicv_inhibit { * APIC base. For simplicity, this is sticky. */ APICV_INHIBIT_REASON_X2APIC, + + /* + * 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 f6f328d36ae2..9b3af49d2524 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -391,6 +391,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 2908adc79ea6..27d5abc15a91 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -968,7 +968,8 @@ bool avic_check_apicv_inhibit_reasons(enum kvm_apicv_in= hibit reason) 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_X2APIC); + BIT(APICV_INHIBIT_REASON_X2APIC) | + BIT(APICV_INHIBIT_REASON_LOGICAL_ID_ALIASED); =20 return supported & BIT(reason); } --=20 2.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 33F7CC433F5 for ; Sat, 1 Oct 2022 01:03:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233148AbiJABDQ (ORCPT ); Fri, 30 Sep 2022 21:03:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232825AbiJABC3 (ORCPT ); Fri, 30 Sep 2022 21:02:29 -0400 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 2B859147CF5 for ; Fri, 30 Sep 2022 18:00:22 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-355ece59b6fso39428007b3.22 for ; Fri, 30 Sep 2022 18:00:22 -0700 (PDT) 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; bh=ImEFAENnzskoKsyXGbezKFbfsi23WTJyFD4CX9MnaEI=; b=oJrKz+f4QiJ3/5je4SGsdwTRQ/Y/8nnEDBVDtGzAMRDyHUe9K/4Q9DVH+kl34nMYCm aBgiPgsp2amkDfLoeSj6BIC0XkDKpbaOekubEXk/BjuqcCAm0hSv6Egx95GdpWkaJmFN +woTDE2gUbnoUPBjnUE8l8yF+a1f9EAAEVR/CLcE4dfUP3D8ndScHGZ/A7HjaQ+oFQCI jU+EgNy96yPE4PyuYN2oPpAVFunJqxq9HNcF2GE9EnBmHnB7xURq7IZJvcb1IJbfbOg0 +H2F7GCQEr3fR6FPsV7wEjoEkNHPOfXQ3MLTnuLutigEF2KtqiJva2Um7RcwM5cVFDNE XzQQ== 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; bh=ImEFAENnzskoKsyXGbezKFbfsi23WTJyFD4CX9MnaEI=; b=hdqs7RZ1GN+gfPn2UdLpO5UChYVuKOGSjit3lcEABNImi4Z5kCNsKlCUChEgvWURGF 9OCwatPDtVNHpCPgIWrCG12RLdjRu4upMJkpWZdMu3bOklbsO/agSQHocYn5krqgAO31 kG95CxMyVo606AAZLM4j4KPLXAWq/ywZ2ShMty1zFska97qK++GK/0zsLYZDBRsPNV62 wdPjyodufaKnEBxK/jQ4J+yLB+VMuPzfGlqsyR0YRMp1+cyX9xutuhOwXZvRu/OlIuWd Tpff9WTHpSawAEbgKGGi3DhNqQml2ooqPkkAT5worUj7VhtTCwzP2tjs5c33u3nbQdXY k1fQ== X-Gm-Message-State: ACrzQf0jGgu1lI84mGnM4B4iDkJ70Rhur6TiS/49t8inrWD78DvTrlOu hJCn8EDWbTfTd9l5+aMlhDNg456yRpI= X-Google-Smtp-Source: AMsMyM6CyT4fI9i6NU13ocWZj2QeuYDkU+7LQIPGX95TT5JuEWDT1ypX3azvcGs6lC8kwjsKARaXwwnxIxo= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1507:b0:6af:9e7:f947 with SMTP id q7-20020a056902150700b006af09e7f947mr10803591ybu.649.1664586002589; Fri, 30 Sep 2022 18:00:02 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:09 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-27-seanjc@google.com> Subject: [PATCH v4 26/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 27d5abc15a91..2b640c73f447 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 30BE4C4332F for ; Sat, 1 Oct 2022 01:03:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233173AbiJABDf (ORCPT ); Fri, 30 Sep 2022 21:03:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233003AbiJABCf (ORCPT ); Fri, 30 Sep 2022 21:02:35 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 118DD15C5BE for ; Fri, 30 Sep 2022 18:00:23 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id 128-20020a630486000000b00435b18f71b3so3696723pge.19 for ; Fri, 30 Sep 2022 18:00:23 -0700 (PDT) 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; bh=1YftLOszR7bSMAKO/7D6fjHIUaI80mCyDkpMabfIDFg=; b=gmlPL8AGoIw5DkSBx9G/sTZrreY5P+Oe1nOe27AcScjwDo5J6rNsdmNQb0IgHx+D3p kecZ3wNctj1k1kVELmY8eA4658Usd/F1FX4RuUD/JLfB1IYWqVF0WZPPM7V9hs49mRpq zKEGEyMAUbFw8/F7lWbA6kPPZogxLCEt0e1z11EEWQn9tN7TO3WUSW/70TGQN6Mr419k kv4XrO7j1dbcTfRH0D3tBVngRbrKQiIB3vSkoB9nFheGpg+QPj9zov9ieJOTWgdMML/u MFJsLfjkZNbQZcbuA3NfT/cQyFrxS4gXzM/WpGBE20SQyy+Gxr1wNllI8cH400pMf6mb A/hQ== 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; bh=1YftLOszR7bSMAKO/7D6fjHIUaI80mCyDkpMabfIDFg=; b=neVRtxKObJre9rKVkWMKkl5aHq8vgIV3P7Xwn4vwAWNngmPy+apFbeMVq9lDFQy+1c SnwGdK7Gml+4OHzhn7Gyttkc7FM/3VFT2XItOefijLNyL9ofcgKazKvBN2aFDAFtZKe8 r7Se73F+uB0LpsgBq3a0egSUI+aR8WuGR6AWgfIEi17aV8LrQZDuKW6N4OmhGLlxT/mw zFyO2JRMhJFG+HPKWg7vPLTiB9nqmpN9y6Gm9LW/2mozgxYLt8kk2AjURdODsUr9Bz/Z 823DzhLmY0BfEleXocWaLP40NnT2bDOjcXXlBc2WBMgiAPh16ameq413gUbkW+UZPT0A iV6Q== X-Gm-Message-State: ACrzQf0sTPuaT+cY6hUZwDL00975PAYtkZHkK7vqr0c70j0Y+HSHryBP kCyb9Pzf58rVOMNMUgDsQMEB6iwFmww= X-Google-Smtp-Source: AMsMyM4bbivakAwydzxsOMq0VdCBO8L/n4+zGlkn++PwBMD69v5jURd9DF/bYRwI5uEcOJczCeyF1x5mwss= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:c950:b0:17c:2248:11b1 with SMTP id i16-20020a170902c95000b0017c224811b1mr7190067pla.165.1664586004063; Fri, 30 Sep 2022 18:00:04 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:10 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-28-seanjc@google.com> Subject: [PATCH v4 27/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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") Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/svm/avic.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 2b640c73f447..4b6fc9d64f4d 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -539,23 +539,24 @@ 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; =20 + if (!ldr) + return; + 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 +576,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 +589,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 7664DC4332F for ; Sat, 1 Oct 2022 01:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233062AbiJABCT (ORCPT ); Fri, 30 Sep 2022 21:02:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232884AbiJABB1 (ORCPT ); Fri, 30 Sep 2022 21:01:27 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71648B4EAC for ; Fri, 30 Sep 2022 18:00:06 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id x23-20020a634857000000b0043c700f6441so3729453pgk.21 for ; Fri, 30 Sep 2022 18:00:06 -0700 (PDT) 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; bh=nUyKM2pzOQLrRGLlm654j+76cYaRMmTuDJ0UvD4UD8Q=; b=B9W/qzV4dQC/CdcbWv3QfbqzmJcMMkm/9VR3lXIqt/GKJak7moqdjAjWuteO/a5ji7 iUxoOlyiYS6lKBRx67amtbyddD3VhD8zNnBBLkHFraDW39sD1RVVxfpv1dnTFAOlYUCu hN/K5FfrHqMunJ9R2LPo0zEEoYThwJGPCjDnvNas9kkEmjlWlk0IM5NpV4VookejGlzF S8qzc063fnhL1DD0wGsUjjG4wCamSAeC2VxPOx1wT56KhOx7HAJ3DT968jDhAyVcjNXc W0413T+2MLyO5fOs3yyC8+wDNDSpdhK7fQRH3FClBV2Lew2GbnyL1kLLDBAlqfgt4ArG 3piw== 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; bh=nUyKM2pzOQLrRGLlm654j+76cYaRMmTuDJ0UvD4UD8Q=; b=3ZItYQszoWUxA5S0mqXQP5NcDftJcFZzx06rAFQBQVV8WxcBLbHc3s/1uDZ68ObM2J Tb8csxE8vpx29XXuwZ8rnGtC73BIORiishlBOaKjnKMpngEY1rPrgsb+yVY7ZJHt0gxH UhyXnmtCMOwDcsxE2m9NxZm0ByCQZEEZwOqErqE/9x8DzUUVV5+AsbE1gokoiaFI7z2t Q7ISHKKslcaML+Rr7GPI0NKMOkmz2G9qiXMUAselaytxyVYBTakHWoP+5N67JBCaSRtv ZtvfHI52tnN3rNcO2vfegXxFT8vCPSaEZA6FJXS/datKMTA81/u0uIa8ac3DC/mvktC3 YRPg== X-Gm-Message-State: ACrzQf0rM1+oeQrax5k6wF+UhfvoLAcS0OVIPnGMSZ9nKvX1wrnt6MKs BnsfUxaeCQDz/+t8ZkVf18lfFtGpsTw= X-Google-Smtp-Source: AMsMyM5oK8ANajLs1pa1CZ8JDzjsdtDhN8aSNXjuvEw5JOnJP3ccHNu+F11TWKlHW6K4K1Yvvws63BWUjJI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:cd06:b0:203:ae0e:6a21 with SMTP id d6-20020a17090acd0600b00203ae0e6a21mr515981pju.0.1664586005501; Fri, 30 Sep 2022 18:00:05 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:11 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-29-seanjc@google.com> Subject: [PATCH v4 28/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 theres 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 Reviewed-by: Maxim Levitsky --- 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 4b6fc9d64f4d..a9e4e09f83fc 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) << 2; + 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 B2B8FC433FE for ; Sat, 1 Oct 2022 01:03:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233184AbiJABDm (ORCPT ); Fri, 30 Sep 2022 21:03:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233019AbiJABCj (ORCPT ); Fri, 30 Sep 2022 21:02:39 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C4CA16DDE3 for ; Fri, 30 Sep 2022 18:00:27 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id w2-20020a63c102000000b004460a972e2eso361844pgf.20 for ; Fri, 30 Sep 2022 18:00:27 -0700 (PDT) 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; bh=YTbh5SVbnv6xk8cQZQzs+Vw8pUphpzRbEkyNKpFeLvc=; b=WDXPv/yH8vlhsGYGSmlQDHHU9S1m265iTQdXcLeqZ7fw/zb4O+oIfuXvU4i1cYX/GT 1liJNlh0WmRjS85Af6CHQjmXMzdseoelxczqS9i1KY7RbYBpSSNhTu2pAVrcQ1lCxqrP O7vXq7x2xznCUkUwtknS2sPHuns2ax3sayQj5DQxIVwLBvI5aBV+FBhBAwOHcIeNMM+v Lmo0qNo/NXAC1Jv2dodA/y2xbHmQstOYF2krP3/uirqp4hD25Fdl2kW/bkZZQooGLj4X RzMfbwaUvQ3lVnzqBw3XtZ6slZH+XOI6m9Ey8WbDuuyA6v4dwultlNaVaxAnYuBqjfzA rM0g== 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; bh=YTbh5SVbnv6xk8cQZQzs+Vw8pUphpzRbEkyNKpFeLvc=; b=cWDUkhzBG+zzoOTFrc2eq7YQ70QUEvuyDXFGfeISTnWEc+siYOrqgheRcU4sDwD3PB PlvuCrVMMFAjcaJzFFFyCvyDT4FdVqyIeoSfCtrwrB1I/jowDOSfRtWuSL+qPzcHzEJK tIVEFR7WOGnztRCyYLh0Yxry+8RDNzn+jlX7zRax/RvAMou99zb9RVPH14P9XWKPtv8e NZOLHZ7LfQUyKeIGfSwMKS+iVSpMgrKGFEqytBD4f6gHuVtwuLTiIMF7HoHCy6l+C4OF VwU8MRW651vfzMDxqrEJ5W4kOaAZbFVTE9oxp6F0wfbERX2TVJHGs3HQxTfqTK1NjzI9 SaUg== X-Gm-Message-State: ACrzQf03cqdwbq6W9y1g1QMUvYjAk1pJKCudLJxZzMGyYu7ZDftiHb26 YUjtBTbQo8UXneqXn8bdC6YlF1jck4w= X-Google-Smtp-Source: AMsMyM7PI3AQtLJqRP1h/kpfCtVdzUjYOms2t77qz2oeWuTeftcu+fehBnr/rUsNUWyNF4MOP/0diTk6myA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:9851:0:b0:53e:87eb:1ffa with SMTP id n17-20020aa79851000000b0053e87eb1ffamr11737536pfq.35.1664586007418; Fri, 30 Sep 2022 18:00:07 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:12 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-30-seanjc@google.com> Subject: [PATCH v4 29/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 a9e4e09f83fc..17e64b056e4e 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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 EDAC8C433F5 for ; Sat, 1 Oct 2022 01:03:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233099AbiJABDp (ORCPT ); Fri, 30 Sep 2022 21:03:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233027AbiJABCr (ORCPT ); Fri, 30 Sep 2022 21:02:47 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43E26F03D for ; Fri, 30 Sep 2022 18:00:28 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id n10-20020a170902e54a00b001782663dcaeso4220178plf.18 for ; Fri, 30 Sep 2022 18:00:27 -0700 (PDT) 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; bh=m33xJ9pBizwrUhfQsmYman/PfJNtqiYZN3F07u+sy1s=; b=doAqyYMrLEzGmhnjgT6yRYK7FatZK4uscBSQzAbeNRy6MapfWpyqdXnFh3wypzCsOr TxoqSN1pxXYXVE9ZgnJD2PS/6pdikSa6RhfSwUtCmulZucCneYFMl1EimC0x9U5NfX9F 2wMhWUgqLM1l+jWiTllRy8PRAMLyhps/RW7pbgQ9vhby954awA8PF9MzpzudnSjGXJjy ewti38RQOPTmHgRWxtymWTcb0W2e0d11sAI5rm4DiuQDCMHdrT1N17ltv+HfwTMDsJGA td6n4ndMZwTN2LEnEVXwvtwQKfxUKYAtfBiXtblqS8PsMxGIg/zL85mD54fFctwlWw/t pa/w== 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; bh=m33xJ9pBizwrUhfQsmYman/PfJNtqiYZN3F07u+sy1s=; b=TUMwUsaUoWwBEi4PgO7G3liiFyp5+ue++IyJ39uuf6AflC+09C/3tgktyNnySexenI TMCcLN7V2lx195wcjpYLSDumU+StMgkzEQ5B+aB814ZORbc+tbwUBC0Cid5ARmz9+4oQ AD8U+qmW3GhI0sfhvzVhbpYCAHXtIIWRbe5zZjP9BAnpTj6OBlBQZcu+9isTyKBL/K3I 0GEk5eKDeclemzMFdgAlF5pvs+zrRJDwgrKFXjKXgqCGGanZzkAjSID09EB8T2U3QCCA DgZ/z4sVMkw7zAYfCwdidd+VDcW3F+0h5LEAFAlJsq4HF0NUdq3Qer37Cr6SuXNWwO6H zKJw== X-Gm-Message-State: ACrzQf3fwi18LfSlH+yYH5p37kplqCf4viWijqUGW/43+KR193ADocq7 yG2biLo2/hiachY5kPF276fYUc1+J5A= X-Google-Smtp-Source: AMsMyM7UFxKVxA9e+lSlEe4vjVtsXH9VjJy9Tw0FAaHrLe0l+PQMiOkThtLnqVYDU9iOBTic3GqUzGrzkAQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:1c8e:b0:205:783b:fe32 with SMTP id oo14-20020a17090b1c8e00b00205783bfe32mr1009086pjb.39.1664586009100; Fri, 30 Sep 2022 18:00:09 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:13 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-31-seanjc@google.com> Subject: [PATCH v4 30/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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 --- 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 17e64b056e4e..953b1fd14b6d 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -631,6 +631,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 87ED0C433F5 for ; Sat, 1 Oct 2022 01:03:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233197AbiJABDu (ORCPT ); Fri, 30 Sep 2022 21:03:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233030AbiJABCr (ORCPT ); Fri, 30 Sep 2022 21:02:47 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9998170B07 for ; Fri, 30 Sep 2022 18:00:28 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id u5-20020a170902e80500b00178944c46aaso4239388plg.4 for ; Fri, 30 Sep 2022 18:00:28 -0700 (PDT) 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; bh=+WScKi0/mMhleZMiFA5QnxX58HadmgDv+cqGuX0Jda4=; b=cAugleHNQ/u7kS9PbZqNOStNuoBnqWLdeRydC5oHYD6JR02YZNq1eDEucHpVKHM8Wq tGdN/HOt+VhcwOQxW8s/Lrkkb+ygvfbU2nPFoCAgY0YK6sy46d9SrxNy8QyuzloPp4SB Qte7oIgg70A1twdSvSKt+PQamrh/zqaEX2Iu+ZOTLHCm1nVBzwMiqmlz8ZKh14Q52fFk QhdW0mAxKsLrrWYq1ndHWpZFMZv6JwaVKEfwWvy73+TFhBF2DZIfapMR2W+vt+pcV6yi +yfuls6iOwO5KNWn6wuVzvR0mQPcdT767HWWTHqM8KBp3KQ+nWwrfC/d+oYn3KBuXUv/ 1BFA== 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; bh=+WScKi0/mMhleZMiFA5QnxX58HadmgDv+cqGuX0Jda4=; b=sJKCQdikhF77RDbZ4ffF2ttOYq8zeJrlPHhyI2n2vDtJv3AcrvcUQutSHUtlPidM4/ yhAZt1dIHj45h4UdxKN38qC4m+tZ3W1nHVDHNs+mkDimQuJP0cri1LjQbr1Y1JWWgz8q 3mK+L7pabVU4wuL4jRIZkz1UbK+YzUmtiA0yKkIyGyXv25Td3T1u34DBKlbkuGseD/eC kOdc0lBUKEmakniWpiDBMCiHIlBiljgRyZgIV/kUUr9GAkMa7mBKnJGf6vTKdvqOf9JF UBt5ZwX9vq6g4E44QD0R9FkUI+AojjYBdR0inJ9nOqlWENAmFzqKdTO0xmJy4tJjJUUC PHPQ== X-Gm-Message-State: ACrzQf0tTIrKQ9aj5OEMXCD0EiyqZYnBJoFqxBmoJzXibHoLBL2yryhn 5R71/FNAQsP7ERQnNljxGvVZua+3n1g= X-Google-Smtp-Source: AMsMyM48IICgWWJ1X/KSjuc2D9WLLMfuymLJrtN4U6/7sbxvvyPeFInciHCCDI4y7x8Lg7Ak4K+jy061XDU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:641:b0:202:8568:4180 with SMTP id q1-20020a17090a064100b0020285684180mr988078pje.227.1664586010770; Fri, 30 Sep 2022 18:00:10 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:14 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-32-seanjc@google.com> Subject: [PATCH v4 31/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- 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 953b1fd14b6d..35b0ef877e53 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -1038,6 +1038,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.38.0.rc1.362.ged0d419d3c-goog From nobody Sun Apr 28 05:07:31 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 896E0C433FE for ; Sat, 1 Oct 2022 01:04:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233143AbiJABEH (ORCPT ); Fri, 30 Sep 2022 21:04:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233135AbiJABDF (ORCPT ); Fri, 30 Sep 2022 21:03:05 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C484A174BE5 for ; Fri, 30 Sep 2022 18:00:30 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id q17-20020a17090aa01100b00205e71e64b2so6600942pjp.3 for ; Fri, 30 Sep 2022 18:00:30 -0700 (PDT) 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; bh=eyqwbJm349LRYDQj4Q3eY3vUEz8lELViSUC9TUap8Us=; b=ZVOriJJzNGNQ8e+FXIjb978WN+CG2URZWCyccFMwUjllgXvPkZI+VqWjlN8zTxsEVG 6mCPHwv5THKb2iei/AGvGCG7mIEMU+xSlMZKR4bgRIPbPf6zd3ezyloLUB0Rz/2dJT1F 0XXagK2WdEz6RHA/z1QcJteLDvKHVn5B6f1B0U45QZ1HhMrZSDsR0wItVDojYJlfzGhs Z8Td61OMrGKCbqjlTXPGjqzcGzolYoGLVWW7H+iMy2bIbYM3vLbz/iiRL6CdLGilT5kk z2/Lr1y2lTiB2QQfM4uRjdONX6tqSn6A0CsCza2SzpkSpSsNldgyMydFLi6hNJz2Rb0c bU7g== 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; bh=eyqwbJm349LRYDQj4Q3eY3vUEz8lELViSUC9TUap8Us=; b=O4dPqDSdKe4UArLQwfgFJObFNUdCgfoLw+dkXGSVBIJWWZ7dO2eobWyfanOOZjz5DH eYvfvDnBDX0lpFH3VzxqUV0a28CkxMfh8ulgAaGFs33H937EU0dhnNEEp/Nyi/Xbv2Ba 20UOUbecHKqpzjA38YlqTMUITId+tw6AYJNHo+5FESmfh/Yf5oi4yuGExBehjlWwdzIL PgC+GFfeZAYf0pGKpWSvUW3hJPBA6ictcBxEimcHxCPQnwmPOc4+SAWvi7I2gU/ReDpm hn8ggW7jossc44JScjXD6yrSUlc1m0hgu3cEHFwpqUTWeFdgrR+TH/KEEPLh0JD+dgeR q+dA== X-Gm-Message-State: ACrzQf2HjqUPSpNu0ghPd0sX4muaCPE2sA9iMbw6KQ5d79/qTQPrSYQS Xky6pVEyH8rkSHfT4wGSJffa/ZbnWBQ= X-Google-Smtp-Source: AMsMyM4WwT6dQV1S5TROIgrH4Ra7twSZw1IOtYSUxAtIMJ3XRfa5mSDyPvx13IcqemI4KrI+zQP2GIcNc9Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:8607:0:b0:53b:13b5:2b6a with SMTP id p7-20020aa78607000000b0053b13b52b6amr11924368pfn.52.1664586012423; Fri, 30 Sep 2022 18:00:12 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 1 Oct 2022 00:59:15 +0000 In-Reply-To: <20221001005915.2041642-1-seanjc@google.com> Mime-Version: 1.0 References: <20221001005915.2041642-1-seanjc@google.com> X-Mailer: git-send-email 2.38.0.rc1.362.ged0d419d3c-goog Message-ID: <20221001005915.2041642-33-seanjc@google.com> Subject: [PATCH v4 32/32] 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 , Suravee Suthikulpanit , Maxim Levitsky , Li RongQing 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. Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/include/asm/kvm-x86-ops.h | 1 - arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/svm/avic.c | 20 -------------------- arch/x86/kvm/svm/svm.c | 2 +- arch/x86/kvm/svm/svm.h | 17 ++++++++++++++++- arch/x86/kvm/vmx/vmx.c | 24 +++++++++++------------- arch/x86/kvm/x86.c | 9 +++++++-- 7 files changed, 36 insertions(+), 39 deletions(-) diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-= x86-ops.h index 82ba4a564e58..533d0e804e5a 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 4fd06965c773..41d1c684a1e1 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1566,7 +1566,7 @@ struct kvm_x86_ops { void (*enable_nmi_window)(struct kvm_vcpu *vcpu); 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; 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); diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 35b0ef877e53..5b25944274b5 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -966,26 +966,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_X2APIC) | - 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 37fe7bcf8496..6bca3f9f39e6 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -4800,8 +4800,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 29c334a932c3..dfde85782da5 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -619,6 +619,22 @@ 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_X2APIC) | \ + 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); @@ -632,7 +648,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 5920166d7260..54bc447ba87e 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7949,18 +7949,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) { @@ -8044,7 +8042,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 a20002924eb4..b307637d9200 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10251,6 +10251,11 @@ void kvm_make_scan_ioapic_request(struct kvm *kvm) kvm_make_all_cpus_request(kvm, KVM_REQ_SCAN_IOAPIC); } =20 +static bool kvm_is_required_apicv_inhibit(enum kvm_apicv_inhibit reason) +{ + return kvm_x86_ops.required_apicv_inhibits & BIT(reason); +} + void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu) { struct kvm_lapic *apic =3D vcpu->arch.apic; @@ -10294,7 +10299,7 @@ static void kvm_vcpu_update_apicv(struct kvm_vcpu *= vcpu) return; =20 if (apic_x2apic_mode(vcpu->arch.apic) && - static_call(kvm_x86_check_apicv_inhibit_reasons)(APICV_INHIBIT_REASON= _X2APIC)) + kvm_is_required_apicv_inhibit(APICV_INHIBIT_REASON_X2APIC)) kvm_inhibit_apic_access_page(vcpu); =20 __kvm_vcpu_update_apicv(vcpu); @@ -10307,7 +10312,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_is_required_apicv_inhibit(reason)) return; =20 old =3D new =3D kvm->arch.apicv_inhibit_reasons; --=20 2.38.0.rc1.362.ged0d419d3c-goog