On 09.11.24 09:03, Paolo Bonzini wrote:
On 11/8/24 19:44, Sean Christopherson wrote:On Fri, Nov 08, 2024, Paolo Bonzini wrote:Queued, thanks.Noooo! Can you un-queue?Yes, I hadn't even pushed it to kvm/queue. I applied it out of a whim but then realized that it wasn't really -rc7 material.The return from kvm_mmu_page_fault() is NOT RET_PF_xxx, it's KVM outer 0/1/- errno.I.e. '1' is saying "resume the guest", it has *nothing* to do with RET_PF_RETRY. E.g. that path also handles RET_PF_FIXED, RET_PF_SPURIOUS, etc.Gah, I even checked the function and was messed up by the other "return RET_PF_RETRY".If you add X86EMUL_* to the mix, it's even worse. I had to read this three times to understand that it was *not* returning X86EMUL_CONTINUE by mistake. Can I haz strongly-typed enums like in C++?...r = kvm_check_emulate_insn(vcpu, emulation_type, insn, insn_len); if (r != X86EMUL_CONTINUE) { ... } if (!(emulation_type & EMULTYPE_NO_DECODE)) { kvm_clear_exception_queue(vcpu); if (kvm_vcpu_check_code_breakpoint(vcpu, emulation_type, &r)) return r; ... }So yeah this really has to be fixed the right way, after all even RET_PF_* started out as a conversion from 0/1.Obligatory bikeshedding, how do KVM_RET_USER and KVM_RET_GUEST sound like?
+1 Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
