Re: [RFC] Reworking KVM_DEBUG_GUEST

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3294 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

[-- Attachment #2: Type: text/plain, Size: 230 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel