On Fri, May 6, 2022 at 11:31 PM Arnabjyoti Kalita <akalita@xxxxxxxxxxxxxxxxx> wrote: > > Dear Sean and all, > > When a VMEXIT happens of type "KVM_EXIT_DEBUG" because a hardware > breakpoint was triggered when an instruction was about to be executed, > does the instruction where the breakpoint was placed actually execute > before the VMEXIT happens? > > I am attempting to record the occurrence of the debug exception in > userspace. I do not want to do anything extra with the debug > exception. I have modified the kernel code (handle_exception_nmi) to > do something like this - > > case BP_VECTOR: > /* > * Update instruction length as we may reinject #BP from > * user space while in guest debugging mode. Reading it for > * #DB as well causes no harm, it is not used in that case. > */ > vmx->vcpu.arch.event_exit_inst_len = vmcs_read32(VM_EXIT_INSTRUCTION_LEN); > kvm_run->exit_reason = KVM_EXIT_DEBUG; > ...... > kvm_run->debug.arch.pc = vmcs_readl(GUEST_CS_BASE) + rip; > kvm_run->debug.arch.exception = ex_no; > kvm_rip_write(vcpu, rip + vmcs_read32(VM_EXIT_INSTRUCTION_LEN)); > <---Change : update RIP here > break; > > This allows the guest to proceed after the hardware breakpoint > exception was triggered. However, the guest kernel keeps running into > page fault at arbitrary points in time. So, I'm not sure if I need to > handle something else too. > > I have modified the userspace code to not trigger any exception, it > just records the occurence of this VMEXIT and lets the guest continue. > > Is this the right approach? Probably not. I'm not sure how kprobes work, but the tracepoint hooks at function entry are multi-byte nopl instructions. The int3 instruction that raises a #BP fault is only one byte. If you advance past that byte, you will try to execute the remaining bytes of the original nopl. You want to skip past the entire nopl.
