diff options
author | Sean Christopherson <seanjc@google.com> | 2021-11-25 04:49:44 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-11-26 15:11:29 +0300 |
commit | 712494de96f35f3e146b36b752c2afe0fdc0f0cc (patch) | |
tree | 1bc2b07e7f7f4d5238efa3d7dd8d1304ebdb1560 /tools/perf/scripts/python | |
parent | 40e5f9080472b614eeedcc5ba678289cd98d70df (diff) | |
download | linux-712494de96f35f3e146b36b752c2afe0fdc0f0cc.tar.xz |
KVM: nVMX: Emulate guest TLB flush on nested VM-Enter with new vpid12
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>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions