Hollis Blanchard wrote: > 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?
Ah, there is an interface for such stuff already! And it can even take quite some payload... > 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. Yes, but I would rather pass the debug registers (more general: some arch dependent state set) back in this slot. Those contain everything the gdbstub needs to know to catch relevant hardware-BP/watchpoint events (and report them to the gdb frontend). > > 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. Only rejecting Z0 will enable us to avoid any soft-BP tracking in qemu-kvm, and that is definitely my plan. Z1 may become an option to add later on and would be answered as "unsupported" for now. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
