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?
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature