Hello all, Thank you for answering my previous question where I had tried to cause a VMEXIT as a result of #BP interrupts arising out of a kprobe hit. I am now able to record VMEXITs of type KVM_EXIT_DEBUG and I also see that the userspace program (QEMU) is automatically taking care of injecting the #BP into the guest. I do not update the RIP any more. As a result of this, the guest execution continues successfully. I am now trying to set kretprobes and trying to record KVM_EXIT_DEBUG again. I am having trouble reliably getting the VMEXITs. For example, if I set a return probe on the function "native_safe_halt", I seem to get VMEXITs of type KVM_EXIT_DEBUG reliably continuously. If I try to set a return probe on the function "unix_stream_read_generic" however, I get VMEXITs right at the time the kernel module is loaded, after which the VMEXITs stop coming altogether. The same observation is seen when I set a kretprobe on the function "free_one_page" or "free_compound_page". Why is this behavior so unpredictable? It seems like some of these VMEXIT events are "caught by a lock" and they are released only when the kernel module is loaded/unloaded. I am using the kretprobe example from a read-only repository on Github (spotify/linux). Why do VMEXITs stop coming and how is it dependent on the probed function? Can the behavior of return probes change depending on the function being probed? Thank you very much. Best Regards, Arnabjyoti Kalita
