Hi Aneesh, On Mon, Feb 24, 2025 at 02:39:59PM +0530, Aneesh Kumar K.V (Arm) wrote: > The return value for kernel VM exit handlers is confusing and has led to > errors in different kernel exit handlers. A return value of 0 indicates > a return to the VMM, whereas a return value of 1 indicates resuming > execution in the guest. Some handlers mistakenly return 0 to force a > return to the guest. > > This worked in kvmtool because the exit_reason defaulted to > 0 (KVM_EXIT_UNKNOWN), and kvmtool did not error out on an unknown exit > reason. However, forcing a VMM exit with error on KVM_EXIT_UNKNOWN > exit_reson would help catch these bugs early. I think I understand what you're saying - if there's a bug in handle_exit() in KVM that triggers an erroneous exit to userspace, exit_reason and the exit information struct could still be at their default values, which are 0 from when kvm_run was allocated (in kvm_vm_ioctl_create_vcpu()). An exit_reason of 0 is interpreted by userspace as KVM_EXIT_UNKNOWN, but kvmtool on KVM_EXIT_UNKNOWN resumes the guest instead of signalling the error, thus masking the buggy KVM behaviour. The patch looks good to me: Reviewed-by: Alexandru Elisei <alexandru.elisei@xxxxxxx> Thanks, Alex > > Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@xxxxxxxxxx> > --- > kvm-cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kvm-cpu.c b/kvm-cpu.c > index f66dcd07220c..7c62bfc56679 100644 > --- a/kvm-cpu.c > +++ b/kvm-cpu.c > @@ -170,7 +170,7 @@ int kvm_cpu__start(struct kvm_cpu *cpu) > > switch (cpu->kvm_run->exit_reason) { > case KVM_EXIT_UNKNOWN: > - break; > + goto panic_kvm; > case KVM_EXIT_DEBUG: > kvm_cpu__show_registers(cpu); > kvm_cpu__show_code(cpu); > -- > 2.43.0 >