Hello Jim and Sean, Thank you for your answers. If I re-inject the #BP back into the guest, does it automatically take care of updating the RIP and continuing execution? I have seen that advancing RIP is unpredictable, works for some instructions, not for others, so ideally I wouldn't want to go that route. Regards, Arnabjyoti Kalita On Wed, May 11, 2022 at 7:29 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Wed, May 11, 2022, Jim Mattson wrote: > > 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. > > And kprobes aren't the only thing that will generate #BP, e.g. the kernel uses > INT3 for patching, userspace debuggers in the guest can insert INT3, etc... The > correct thing to do is to re-inject the #BP back into the guest without touching > RIP.
