diff options
author | Sean Christopherson <[email protected]> | 2021-11-25 01:49:44 +0000 |
---|---|---|
committer | Paolo Bonzini <[email protected]> | 2021-11-26 07:11:29 -0500 |
commit | 712494de96f35f3e146b36b752c2afe0fdc0f0cc (patch) | |
tree | 1bc2b07e7f7f4d5238efa3d7dd8d1304ebdb1560 /drivers/fpga/fpga-bridge.c | |
parent | 40e5f9080472b614eeedcc5ba678289cd98d70df (diff) |
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 <[email protected]>
Fixes: 5c614b3583e7 ("KVM: nVMX: nested VPID emulation")
Cc: [email protected]
Signed-off-by: Sean Christopherson <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'drivers/fpga/fpga-bridge.c')
0 files changed, 0 insertions, 0 deletions