| Message ID | 20190312184559.187302-2-bgardon@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/2] Revert "KVM/MMU: Flush tlb directly in the kvm_zap_gfn_range()" | expand |
On 12/03/19 19:45, Ben Gardon wrote: > Replace kvm_flush_remote_tlbs with kvm_flush_remote_tlbs_with_address > in slot_handle_level_range. When range based flushes are not enabled > kvm_flush_remote_tlbs_with_address falls back to kvm_flush_remote_tlbs. > > This changes the behavior of many functions that indirectly use > slot_handle_level_range, iff the range based flushes are enabled. The > only potential problem I see with this is that kvm->tlbs_dirty will be > cleared less often, however the only caller of slot_handle_level_range that > checks tlbs_dirty is kvm_mmu_notifier_invalidate_range_start which > checks it and does a kvm_flush_remote_tlbs after calling > kvm_unmap_hva_range anyway. > > 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> > --- > arch/x86/kvm/mmu.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c > index 4cda5ee488454..9a403b7398f54 100644 > --- a/arch/x86/kvm/mmu.c > +++ b/arch/x86/kvm/mmu.c > @@ -5501,7 +5501,9 @@ slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot, > > if (need_resched() || spin_needbreak(&kvm->mmu_lock)) { > if (flush && lock_flush_tlb) { > - kvm_flush_remote_tlbs(kvm); > + kvm_flush_remote_tlbs_with_address(kvm, > + start_gfn, > + iterator.gfn - start_gfn + 1); > flush = false; > } > cond_resched_lock(&kvm->mmu_lock); > @@ -5509,7 +5511,8 @@ slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot, > } > > if (flush && lock_flush_tlb) { > - kvm_flush_remote_tlbs(kvm); > + kvm_flush_remote_tlbs_with_address(kvm, start_gfn, > + end_gfn - start_gfn + 1); > flush = false; > } > > Queued 1/2, and 2/2 for after the merge window. Paolo
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 4cda5ee488454..9a403b7398f54 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -5501,7 +5501,9 @@ slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot, if (need_resched() || spin_needbreak(&kvm->mmu_lock)) { if (flush && lock_flush_tlb) { - kvm_flush_remote_tlbs(kvm); + kvm_flush_remote_tlbs_with_address(kvm, + start_gfn, + iterator.gfn - start_gfn + 1); flush = false; } cond_resched_lock(&kvm->mmu_lock); @@ -5509,7 +5511,8 @@ slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot, } if (flush && lock_flush_tlb) { - kvm_flush_remote_tlbs(kvm); + kvm_flush_remote_tlbs_with_address(kvm, start_gfn, + end_gfn - start_gfn + 1); flush = false; }
Replace kvm_flush_remote_tlbs with kvm_flush_remote_tlbs_with_address in slot_handle_level_range. When range based flushes are not enabled kvm_flush_remote_tlbs_with_address falls back to kvm_flush_remote_tlbs. This changes the behavior of many functions that indirectly use slot_handle_level_range, iff the range based flushes are enabled. The only potential problem I see with this is that kvm->tlbs_dirty will be cleared less often, however the only caller of slot_handle_level_range that checks tlbs_dirty is kvm_mmu_notifier_invalidate_range_start which checks it and does a kvm_flush_remote_tlbs after calling kvm_unmap_hva_range anyway. 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> --- arch/x86/kvm/mmu.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)