On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote: > Hollis Blanchard wrote: > > On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: > >> So gdb on power relies only on those few hw-breakpoints? With x86 you > >> can perfectly run gdb (with soft BPs) in parallel with the gdbstub > >> (currently based on hw-BPs, but the same would be true for soft-BPs > >> inserted by the gdbstub). > > > > GDB on Power inserts trap instructions, i.e. standard "soft" breakpoints. It > > does not rely on the hardware breakpoints. > > > > It gets a little more complicated when you involve a GDB stub. IIRC, GDB will > > ask the stub to set the breakpoint, and if the stub doesn't support it, GDB > > will fall back to overwriting the instructions in memory. Does the Qemu GDB > > stub advertise breakpoint support? > > Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something > even gdbserver does not do! It just handles watchpoints (Z2..4). > > > > > If not, the only support needed in KVM would be to send all debug interrupts > > to qemu, and allow qemu to send them back down for in-guest breakpoints. > > > > Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's > kernel side should not yet inform QEMU about soft-BP exceptions. But in > theory, this should be easily fixable (or is already the case for other > archs). And it would safe us from keeping track of N software > breakpoints, where N could even become larger than 32, the current > hardcoded limit for plain QEMU. :) > > Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is > insufficient: We need a return channel for the debug register state > (specifically to figure out details about hit watchpoints). I'm now > favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us > to write _and_ read-back the suggested data structure.
How about simply extending kvm_exit.debug to contain the virtual address of the breakpoint hit? In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would just need to see if that address is for a breakpoint Qemu set or not. If so, it's happy. If not, (commence handwaving) tell KVM to forward the debug interrupt to the guest. This way, the list of breakpoints is maintained in userspace (in the qemu gdb stub), which is nice because it could be arbitrarily large. Also, this is not specific to hardware debug registers: soft and hard breakpoint interrupts would follow the same path. There's still a question of whether the GDB stub should set the breakpoint itself (Z0/Z1) or force GDB to modify memory, but either way the KVM code is simple. -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
