From: Paolo Bonzini <pbonzini@redhat.com>
To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: Sean Christopherson <seanjc@google.com>
Subject: [PATCH 7/7] KVM: x86: Flush guest TLB when emulating a RESET to strictly honor the spec
Date: Mon, 2 Nov 2026 18:14:28 -0500 [thread overview]
Message-ID: <20261102231428.13523-8-pbonzini@redhat.com> (raw)
In-Reply-To: <20261102231428.13523-1-pbonzini@redhat.com>
From: Sean Christopherson <seanjc@google.com>
Flush the guest TLB when emulating a RESET even though such a flush should
be completely unnecessary since KVM only performs a RESET when creating a
vCPU, and so it should be impossible for the vCPU to have any accrued TLB
state. Making the flush unconditional aligns KVM's behavior with both the
SDM and APM (ignoring that both specifications contradict themselves), and
avoids having to worry about hypotheticals like "what if KVM did provide a
way to emulate RESET after a vCPU is created?".
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20261022015407.279870-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/x86.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 09c6df00ebb6..26e7beaff8a0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9731,9 +9731,6 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
kvm_x86_call(set_efer)(vcpu, 0);
kvm_x86_call(update_exception_bitmap)(vcpu);
- if (old_cr0 & X86_CR0_PG)
- kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);
-
/*
* Unconditionally reset the MMU, even though super strictly speaking,
* a MMU reset is only necessary if and only one of the page role bits
@@ -9750,16 +9747,16 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
kvm_mmu_reset_context(vcpu);
/*
- * Intel's SDM states that all TLB entries are flushed on INIT. AMD's
- * APM states the TLBs are untouched by INIT, but it also states that
- * the TLBs are flushed on "External initialization of the processor."
- * Flush the guest TLB regardless of vendor, there is no meaningful
- * benefit in relying on the guest to flush the TLB immediately after
- * INIT. A spurious TLB flush is benign and likely negligible from a
- * performance perspective.
+ * Intel's SDM states that all TLB entries are flushed on INIT "as with
+ * a hardware reset", and AMD's APM states the TLBs are flushed on
+ * "External initialization of the processor". Flush the guest TLB for
+ * both RESET and INIT, regardless of vendor, even though both the SDM
+ * and APM contradict the above statements in other tables. There is
+ * no meaningful benefit in relying on the guest to flush the TLB, and
+ * a spurious TLB flush is benign and likely negligible from a
+ * performance perspective (especially for RESET).
*/
- if (init_event)
- kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);
+ kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);
}
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_vcpu_reset);
--
2.52.0
prev parent reply other threads:[~2026-11-02 23:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 23:14 [PATCH 0/7] KVM: a bunch of fixes Paolo Bonzini
2026-11-02 23:14 ` [PATCH 1/7] KVM: nSVM: Check validity of vmcs01 save area copied from SMRAM on RSM Paolo Bonzini
2026-11-02 23:14 ` [PATCH 2/7] KVM: x86/mmu: Conditionally resched when retrying gPTE walk on A/D update failure Paolo Bonzini
2026-11-02 23:14 ` [PATCH 3/7] KVM: x86: Conditionally resched when restarting REP string emulation Paolo Bonzini
2026-11-02 23:14 ` [PATCH 4/7] KVM: nVMX: Process each host MSR entry at most once when unwinding failed VM-Entry Paolo Bonzini
2026-11-02 23:39 ` Jim Mattson
2026-11-03 0:10 ` Sean Christopherson
2026-11-03 0:34 ` Jim Mattson
2026-11-02 23:14 ` [PATCH 5/7] KVM: x86/mmu: Cap number of parent PTEs per SP at 1000 (the arbitrary rmap limit) Paolo Bonzini
2026-11-02 23:14 ` [PATCH 6/7] KVM: x86: Unconditionally reset MMU context when emulating INIT Paolo Bonzini
2026-11-02 23:14 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261102231428.13523-8-pbonzini@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®