On Wed, 2008-05-14 at 17:28 +0200, Jan Kiszka wrote:
> 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?
I think you should go ahead and go for it. I will be required to make
changes around it for the use of hardware breakpoints if it goes in. But
honestly it would be better to only use software breakpoints if they
work, as opposed to hardware breakpoints .. due to the limits.
>
> Jan
>
-------------------------------------------------------------------------
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
