Re: [RFC] Reworking KVM_DEBUG_GUEST

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

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

Jerone Young wrote:
> On Mon, 2008-05-12 at 13:34 +0200, Jan Kiszka wrote:
>> Hi,
>>
>> before going wild with my idea, I would like to collect some comments on
>> this approach:
>>
>> While doing first kernel debugging with my debug register patches for
>> kvm, I quickly ran into the 4-breakpoints-only limitation that comes
>> from the fact that we blindly map software to hardware breakpoints.
>> Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
>> in the generic interface is not fair to arch that may support more.
>> Moreover, we do not support watchpoints although this would easily be
>> feasible. But if we supported watchpoints (via debug registers on x86),
>> we would need the break out of the 4 slots limitations even earlier. In
>> short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
>> interface is required.
> So embedded power is also limited to 4 hardware registers for break
> points. But there are 2 sepreate registers fro watch points. The reason
> to use the registers is the hardware does the work for you and (at least
> on Power) will throw an exception or trap. Then you deal with it.
> 
> But you still face the fact that you can only have a small number of
> breakpoints & watch points. Also you cannot use gdb in the guest at the
> sametime while using the gdb stub on the guest itself (as there is only
> one set of registers).

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).

> 
> 
>> Why do we set breakpoints in the kernel? Why not simply catching all
>> debug traps, inserting software breakpoint ops into the guest code, and
>> handling all this stuff as normal debuggers do? And the hardware
>> breakpoints should just be pushed through the kernel interface like
>> ptrace does.
> 
> See above...But the cpu basically does the work for you. So you don't
> have to try and go through and first insert a trap into the code in
> memory. But then you have to remember the code that you replaced with
> the trap and execute it after you handle the trap. This can get a little
> hairy. 

I cannot imaging that this is so hairy. It is basically daily (x86-)
debugger business. Maybe we need to handle it differently if other
arches prefer their own way. But for x86 I don't see a need to restrict
our self to use hw-BPs _only_.

> 
> Currently I'm actually implementing breakpoint support now in Power. But
> you do have to create some mappings to handle traps and see if you put
> the trap there, and execute the code you replaced. Also what if the
> breakpoint is removed. Then you have to go back through and actually
> replace the trap code. Doesn't sound hard, but I'm not sure of all the
> pitfalls.

Again, this /should/ not be different from what gdb does to applications
or kgdb does to the kernel. (Looks like I need to get my feet wet soon. :) )

> 
>> The new KVM_DEBUG_GUEST interface I currently have in mind would look
>> like this:
>>
>> #define KVM_DBGGUEST_ENABLE		0x01
>> #define KVM_DBGGUEST_SINGLESTEP		0x02
>>
>> struct kvm_debug_guest {
>> 	__u32 control;
>> 	struct kvm_debug_guest_arch arch;
>> }
> 
> 
>> Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
>> userspace first, which can then decide to handle or re-inject them.
>> KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
>> would look like this:
>>
>> struct kvm_debug_guest_arch {
>> 	__u32 use_hw_breakpoints;
>> 	__u64 debugreg[8];
>> }
>>
>> If use_hw_breakpoints is non-zero, KVM would completely overwrite the
>> guest's debug registers with the content of debugreg, giving full
>> control of this feature to the host-side debugger (faking the content of
>> debug registers, effectively disabling them for the guest - as we now do
>> all the time).
> 
> Hmmm...so today at least the gdbstub in qemu does not inject traps and
> track code that it trapped (I could be mistaken). This whould all need
> to be implemented as well.

gdbstub inserts "virtual" traps today, ie. a call from the translated
guest code to a helper which signals the breakpoint to the stub. And I
don't want to change this. I want to add the BP injection/removal to
qemu-kvm as it already takes over breakpoint (and soon also watchpoint)
maintenance from qemu.

However, would the proposed interface for KVM_DEBUG_GUEST (with an
appropriate kvm_debug_guest_arch for power) restrict your plans in any way?

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