KVM: nVMX: Emulate guest TLB flush on nested VM-Enter with new vpid12
authorSean Christopherson <seanjc@google.com>
Thu, 25 Nov 2021 01:49:44 +0000 (01:49 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 8 Dec 2021 08:04:43 +0000 (09:04 +0100)
commit85f2cf6419dd2b562d8ced2deb913ed83fdc703d
tree1dd2361b0f0220b5ccc1e22cbb25b5c8235ba466
parent3a929e1d7e5e0e0fbdbe0dc9ee04638745965108
KVM: nVMX: Emulate guest TLB flush on nested VM-Enter with new vpid12

commit 712494de96f35f3e146b36b752c2afe0fdc0f0cc upstream.

Fully emulate a guest TLB flush on nested VM-Enter which changes vpid12,
i.e. L2's VPID, instead of simply doing INVVPID to flush real hardware's
TLB entries for vpid02.  From L1's perspective, changing L2's VPID is
effectively a TLB flush unless "hardware" has previously cached entries
for the new vpid12.  Because KVM tracks only a single vpid12, KVM doesn't
know if the new vpid12 has been used in the past and so must treat it as
a brand new, never been used VPID, i.e. must assume that the new vpid12
represents a TLB flush from L1's perspective.

For example, if L1 and L2 share a CR3, the first VM-Enter to L2 (with a
VPID) is effectively a TLB flush as hardware/KVM has never seen vpid12
and thus can't have cached entries in the TLB for vpid12.

Reported-by: Lai Jiangshan <jiangshanlai+lkml@gmail.com>
Fixes: 5c614b3583e7 ("KVM: nVMX: nested VPID emulation")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20211125014944.536398-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/x86/kvm/vmx/nested.c