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