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).
>
> 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.
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.
>
> 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.
>
> Questions:
> - Does anyone see traps and pitfalls in this approach?
> - May I replace the existing interface with this one, or am I overseeing
> some use case that already worked with the current code so that ABI
> compatibility is required (most debug stuff should have been simply
> broken so far, also due to bugs in userland)?
>
> Jan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________ kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-------------------------------------------------------------------------
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
