On Sun, May 01, 2022, Arnabjyoti Kalita wrote: > Hello all, > > I intend to run a kernel module inside my guest VM. The kernel module > sets kprobes on a couple of functions in the linux kernel. After > registering the kprobes successfully, I can see that the kprobes are > being hit repeatedly. > > I would like to cause a VMEXIT when these kprobes are hit. I know that > kprobes use a breakpoint instruction (INT 3) to successfully execute > the pre and post handlers. This would mean that the execution of the > instruction INT 3 should technically cause a VMEXIT. No, it should cause #BP. KVM doesn't intercept #BP by default because there's no reason to do so. > However, I do not get any software exception type VMEXITs when these kprobes > are hit. > > I have used the commands "perf kvm stat record" and "perf kvm stat > report --event=vmexit" to try and observe the VMEXIT reasons and I do > not see any VMEXIT of type "EXCEPTION_NMI" being returned in the > period that the kprobe was being hit. > > My host uses a modified Linux kernel 5.8.0 while my guest runs a 4.4.0 > Linux kernel. Both the guest and the host use the x86_64 architecture. > I am using QEMU version 5.0.1. What changes are needed in the Linux > kernel to make sure that I get an exception in the form of a VMEXIT > whenever the kprobes are hit? This can be done entirely from userspace by enabling KVM_GUESTDBG_USE_SW_BP, e.g. struct kvm_guest_debug debug; memset(&debug, 0, sizeof(debug)); debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP; ioctl(vcpu->fd, KVM_SET_GUEST_DEBUG, &debug); That will intercept #BP and exit to userspace with KVM_EXIT_DEBUG. Note, it's userspace's responsibility to re-inject the #BP if userspace wants to forward the #BP to the guest. There's a bit more info in Documentation/virt/kvm/api.rst under KVM_SET_GUEST_DEBUG.
