KVM: x86/mmu: Honor NEED_RESCHED when zapping rmaps and blocking is allowed
authorSean Christopherson <seanjc@google.com>
Fri, 9 Aug 2024 19:43:25 +0000 (12:43 -0700)
committerSean Christopherson <seanjc@google.com>
Tue, 10 Sep 2024 03:22:04 +0000 (20:22 -0700)
commit548f87f667a38ffeb2f021d9cfbc1f1b34fb4cb5
treee4776eeced952920bea8ecdfea3f62310191a9b4
parentdd9eaad744f4ed30913cca423439a1765a760c71
KVM: x86/mmu: Honor NEED_RESCHED when zapping rmaps and blocking is allowed

Convert kvm_unmap_gfn_range(), which is the helper that zaps rmap SPTEs in
response to an mmu_notifier invalidation, to use __kvm_rmap_zap_gfn_range()
and feed in range->may_block.  In other words, honor NEED_RESCHED by way of
cond_resched() when zapping rmaps.  This fixes a long-standing issue where
KVM could process an absurd number of rmap entries without ever yielding,
e.g. if an mmu_notifier fired on a PUD (or larger) range.

Opportunistically rename __kvm_zap_rmap() to kvm_zap_rmap(), and drop the
old kvm_zap_rmap().  Ideally, the shuffling would be done in a different
patch, but that just makes the compiler unhappy, e.g.

  arch/x86/kvm/mmu/mmu.c:1462:13: error: ‘kvm_zap_rmap’ defined but not used

Reported-by: Peter Xu <peterx@redhat.com>
Link: https://lore.kernel.org/r/20240809194335.1726916-14-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
arch/x86/kvm/mmu/mmu.c