From nobody Mon Apr 6 20:11:42 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7E89ECAAA1 for ; Sat, 3 Sep 2022 00:25:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232021AbiICAZF (ORCPT ); Fri, 2 Sep 2022 20:25:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231695AbiICAXw (ORCPT ); Fri, 2 Sep 2022 20:23:52 -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 309F710F0BB for ; Fri, 2 Sep 2022 17:23:32 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id d6-20020a170902cec600b00174be1616c4so2116432plg.22 for ; Fri, 02 Sep 2022 17:23:32 -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=IBvO4qkKDFwYqm7S6fXdHOVkKag46t3/GGPLwUice6c=; b=nIs4eo4iqErAuI6XAFNgX6K77AZBYZYcdGu5RBfi6rLgj8zJaVKBGiFUF4jy+f2znL k+qC3Efd6cGYqYiNAJBp29RDUUSv2MhLCeTShr4/p8PfeNBoFjjm1pmgLwA7N9MnAr3z qjFin8J5UL85YT7wnMqEQ+7lLJUPh2RbQka0MzvYphGjsD/IksqIhauUYX33X0QJRmi0 IGsDmQ7WWt9MjzqOY+Kej5U6HJ1a3rr93F0KVIHfiaR0OGq94W+RVMqdNdJtOTMqRc/M UQpkYD+AfhWjSEyTBzdmd1UHeb0n2VLqGhCI0ia5FE6PIyWOr/KtgRP61b6mOmSw4yYk hdQQ== 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=IBvO4qkKDFwYqm7S6fXdHOVkKag46t3/GGPLwUice6c=; b=fuG08FjDQkK0omlWYr1tg73UKNtFsgN40o+6Xs2E9nNuf7YRemcS1H5Ds/ezHu93Cc hW75DohjTZcNaJxVa74sv4Fr0uB+uo7lEqFysFFbkh75GcwXVMsfVjyVaBzxAJg8ESbz N+/vHJGjqvU4fRXLzLw5jRAvX0kpfdwg8iRrosIr6E4MApGko2jAI8YbfECzFS8vppqO lnxav58TDXKdu7wTzhklMN1Q2yjqU/hMKlaI48VOiBzquw9yQDUlNjzML2OSamvu162t mBJk/lN1rR9hsLNlos0WA5Fk0V2q8H1iGG2QGG4pVdYCwmssatqbsVJoPqGKaubf4Kn4 CixQ== X-Gm-Message-State: ACgBeo1AJP5PR/8DPqpvHN5QacR8pJb25e2FhKJ3AkhRMT5oBoj5tshE IJcvNEvWzgYLVkSfxaIdV0fNPYA61hk= X-Google-Smtp-Source: AA6agR5KdEl4pFQ/8xGmdvMSfiM+U4GcrEKxOndZDwfISDdUasj0qKYxoDZRKwWyveAWxdAekfFTP/avhg8= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:22c7:b0:175:3682:9cf5 with SMTP id y7-20020a17090322c700b0017536829cf5mr17164030plg.150.1662164611463; Fri, 02 Sep 2022 17:23:31 -0700 (PDT) Reply-To: Sean Christopherson Date: Sat, 3 Sep 2022 00:22:50 +0000 In-Reply-To: <20220903002254.2411750-1-seanjc@google.com> Mime-Version: 1.0 References: <20220903002254.2411750-1-seanjc@google.com> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220903002254.2411750-20-seanjc@google.com> Subject: [PATCH v2 19/23] 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, 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 --- 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 456f24378961..894d0afd761b 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -566,23 +566,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) @@ -602,7 +603,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); @@ -616,11 +616,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.37.2.789.g6183377224-goog