diff options
author | Ben Gardon <bgardon@google.com> | 2019-03-12 19:45:58 +0100 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2019-03-15 19:16:45 +0100 |
commit | 92da008fa21034c369cdb8ca2b629fe5c196826b (patch) | |
tree | 780a56475b588838e148a1c198b6a67b379abd46 /MAINTAINERS | |
parent | Merge tag 'kvmarm-for-v5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/... (diff) | |
download | linux-92da008fa21034c369cdb8ca2b629fe5c196826b.tar.xz linux-92da008fa21034c369cdb8ca2b629fe5c196826b.zip |
Revert "KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()"
This reverts commit 71883a62fcd6c70639fa12cda733378b4d997409.
The above commit contains an optimization to kvm_zap_gfn_range which
uses gfn-limited TLB flushes, if enabled. If using these limited flushes,
kvm_zap_gfn_range passes lock_flush_tlb=false to slot_handle_level_range
which creates a race when the function unlocks to call cond_resched.
See an example of this race below:
CPU 0 CPU 1 CPU 3
// zap_direct_gfn_range
mmu_lock()
// *ptep == pte_1
*ptep = 0
if (lock_flush_tlb)
flush_tlbs()
mmu_unlock()
// In invalidate range
// MMU notifier
mmu_lock()
if (pte != 0)
*ptep = 0
flush = true
if (flush)
flush_remote_tlbs()
mmu_unlock()
return
// Host MM reallocates
// page previously
// backing guest memory.
// Guest accesses
// invalid page
// through pte_1
// in its TLB!!
Tested: Ran all kvm-unit-tests on a Intel Haswell machine with and
without this patch. The patch introduced no new failures.
Signed-off-by: Ben Gardon <bgardon@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions