On Mon, Jun 03, 2024, Paolo Bonzini wrote: > On Mon, Jun 3, 2024 at 7:54 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > However, VM boots up fine without any issues and operational. > > Yes, the caller uses kvm_handle_hva_range() as if it returned void. > > > Ah, the "break" will only break out of the memslot loop, it won't break out of > > the address space loop. Stupid SMM. > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index b312d0cbe60b..70f5a39f8302 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -651,7 +651,7 @@ static __always_inline kvm_mn_ret_t __kvm_handle_hva_range(struct kvm *kvm, > > range->on_lock(kvm); > > > > if (IS_KVM_NULL_FN(range->handler)) > > - break; > > + goto mmu_unlock; > > } > > r.ret |= range->handler(kvm, &gfn_range); > > } > > @@ -660,6 +660,7 @@ static __always_inline kvm_mn_ret_t __kvm_handle_hva_range(struct kvm *kvm, > > if (range->flush_on_ret && r.ret) > > kvm_flush_remote_tlbs(kvm); > > > > +mmu_unlock: > > if (r.found_memslot) > > KVM_MMU_UNLOCK(kvm); > > Yep. If you want to just reply with Signed-off-by I'll mix the > original commit message and your patch. Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
