From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793831263; b=1ueAloboYGd8+vwnH5GA6G634UzyC7+KAd+elZq9vQDwL/MoRiSphDuKIG1dNK/ZNuRR XlhZVVP4wspBo9nQHt8ejy29EcrthLFYlf9voFpWLE/tSwCyLaYN/YxYhJ2hWrpEyaOnI Ja9Aff4rhd0s+3fZhBCwNHfAIPOzbEI3pWi+kpHdbU5bwGFyxllPFY3hViWedaTy63o9R P1jK1cjMs+QNOjtPMV32ibokDXbcnM6gFPAjKrRFxYJBqZboKRXyKXHqlmFXfRCoN689A 8mtD+KZawm5YnD4DIXh1T5lx18SN3W6iIzZmlOnUuD9xQqOfwn7s4HGbpWyJ7f8RwDA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793831263; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=B13mQ3ePzlo18ZNt+K65KD+uLyzre57rGfyD70x/T74=; b=mY0MZgv5Pdw24g0bspTN72KuSkvvU9ODTAsVlfJlSJY5pxBLKT4P/2w6TjxLsKrC70jp acT39Nphbty8dd1pRMraCYWbLwZrth3YS22VYGxkCZM3RXlcVqmCgyXcFLtGOmsGVsbi8 qpxRhD2tLvBKRYLmW0+2Gs9hQN4T+jjIXTNiSALM+BM8F6jVVxGXuFIHXhwDml9rzHM60 yqDovTUDbfYrtOXWx8U0dGrBfaL1YFT0+e4bNFRRtPHU5O60hQ2Dos6wo8gk7iyymCZKn tZ5VngSg0RwCmzX7Zjemy90DJoUDqfWqQs8HUctnhQm5DEb3KKcVEEEseE8Z7yP+4dQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="xgdWrGa/"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1F86606B2C2; Wed, 4 Nov 2026 22:27:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=xgdWrGa/ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 413DA1F000C1; Wed, 4 Nov 2026 22:27:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793831263; bh=B13mQ3ePzlo18ZNt+K65KD+uLyzre57rGfyD70x/T74=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=xgdWrGa/z9J+htiFa9C5YtHyXu3213LRcPveo5FJ+wpY/IQLOnlBK31XNL4DtwZ9Z LbpCIEaVNYBIitzIRftvsSbBgl35mqCu+vKDUYr/85JHsVG9oWKYPwaiGN5qMtt0BW zoS2a6zbVBkdC7VtuVYB8qsDIEvhYflc1Hlg3YJU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Stefan Teodorescu , Yosry Ahmed , Tom Lendacky , Jim Mattson , Sean Christopherson , Paolo Bonzini , Sasha Levin Subject: [PATCH 6.18 0600/1005] KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN Date: Wed, 4 Nov 2026 16:05:33 -0500 Message-ID: <20261104211100.659411866@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211043.516122098@linuxfoundation.org> References: <20261104211043.516122098@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sean Christopherson [ Upstream commit 60d93c27859fb3ec5b5a689e24de303f166477d0 ] Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush. Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away. Fixes: 38e5e92fe8c0 ("KVM: SVM: Implement Flush-By-Asid feature") Cc: stable@vger.kernel.org Reported-by: Stefan Teodorescu Suggested-by: Yosry Ahmed Cc: Tom Lendacky Cc: Jim Mattson Signed-off-by: Sean Christopherson Message-ID: <20260904170642.3291466-2-seanjc@google.com> Signed-off-by: Paolo Bonzini [ sashal: Replaced the svm_is_vmrun_failure() helper with an exit_code != SVM_EXIT_ERR check and dropped the ERAPS CLEAR_RAP context block, since neither exists in this tree. ] Signed-off-by: Sasha Levin --- arch/x86/kvm/svm/svm.c | 14 +++++++++++--- arch/x86/kvm/svm/svm.h | 1 + 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 5f3c6d7974fb9..3de16ee6698a6 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1781,8 +1781,7 @@ static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd) if (sd->next_asid > sd->max_asid) { ++sd->asid_generation; sd->next_asid = sd->min_asid; - svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID; - vmcb_mark_dirty(svm->vmcb, VMCB_ASID); + sd->flush_all_asids = true; } svm->current_vmcb->asid_generation = sd->asid_generation; @@ -4334,6 +4333,11 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags) svm->vmcb->control.asid = svm->asid; vmcb_mark_dirty(svm->vmcb, VMCB_ASID); } + if (this_cpu_ptr(&svm_data)->flush_all_asids) { + svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID; + vmcb_mark_dirty(svm->vmcb, VMCB_ASID); + } + svm->vmcb->save.cr2 = vcpu->arch.cr2; svm_fixup_nested_rips(vcpu); @@ -4416,7 +4420,11 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags) svm->nested.nested_run_pending = 0; } - svm->vmcb->control.tlb_ctl = TLB_CONTROL_DO_NOTHING; + if (svm->vmcb->control.exit_code != SVM_EXIT_ERR) { + this_cpu_ptr(&svm_data)->flush_all_asids = false; + svm->vmcb->control.tlb_ctl = TLB_CONTROL_DO_NOTHING; + } + vmcb_mark_all_clean(svm->vmcb); /* if exit due to PF check for async PF */ diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index df081ae666f0d..f8ea26ba71423 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -351,6 +351,7 @@ struct svm_cpu_data { u32 next_asid; u32 min_asid; + bool flush_all_asids; bool bp_spec_reduce_set; struct vmcb *save_area; -- 2.53.0