On 6/3/24 15:38, Sean Christopherson wrote: > 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> Thanks Sean, Paolo. I will send v2 with Sean's patch. -- Thanks Babu Moger
