Thank you for your answer, Sean. I think I now have a fair idea on how to proceed. I will re-inject the #BP into the guest from KVM and see what happens. I'm hoping the guest will handle the #BP and continue execution without me needing to make any more changes. Best Regards, Arnabjyoti Kalita On Wed, May 11, 2022 at 8:34 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Wed, May 11, 2022, Arnabjyoti Kalita wrote: > > What could be the various ways a guest could handle #BP? > > The kernel uses INT3 to patch instructions/flows, e.g. for alternatives. For those, > the INT3 handler will unwind to the original RIP and retry. The #BP will keep > occurring until the patching completes. See text_poke_bp_batch(), poke_int3_handler(), > etc... > > Userspace debuggers will do something similar; after catching the #BP, the original > instruction is restored and restarted. > > The reason INT3 is a single byte is so that software can "atomically" trap/patch an > instruction without having to worry about cache line splits. CPUs are guaranteed > to either see the INT3 or the original instruction in its entirety, i.e. other CPUs > will never decode a half-baked instruction. > > The kernel has even fancier uses for things like static_call(), e.g. emulating > CALL, RET, and JMP from the #BP handler. > > > Can we "make" the guest skip the instruction that caused the #BP ? > > Well, technically yes, that's effectively what would happen if the host skips the > INT3 and doesn't inject the #BP. Can you do that and expect the guest not to > crash? Nope.
