From: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx>
The KVM doesn't know whether any TLB for a specific pcid is cached in
the CPU when tdp is enabled. So it is better to flush all the guest
TLB when invalidating any single PCID context.
The case is rare or even impossible since KVM doesn't intercept CR3
write or INVPCID instructions when tdp is enabled. The fix is just
for the sake of robustness in case emulation can reach here or the
interception policy is changed.
Signed-off-by: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx>
---
arch/x86/kvm/x86.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c59b63c56af9..06169ed08db0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1073,6 +1073,16 @@ static void kvm_invalidate_pcid(struct kvm_vcpu *vcpu, unsigned long pcid)
unsigned long roots_to_free = 0;
int i;
+ /*
+ * It is very unlikely to reach here when tdp_enabled. But if it is
+ * the case, the kvm doesn't know whether any TLB for the @pcid is
+ * cached in the CPU. So just flush the guest instead.
+ */
+ if (unlikely(tdp_enabled)) {
+ kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);
+ return;
+ }
+
/*
* If neither the current CR3 nor any of the prev_roots use the given
* PCID, then nothing needs to be done here because a resync will
--
2.19.1.6.gb485710b
