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.

Jan

Attachment: 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

Reply via email to