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.
>
The current interface is limited, yes.
> 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.
>
The problem is that the breakpoints are visible to the guest. If the
guest swaps a page, the breakpoint will be swapped with it. If it
reallocates a page to a different use it will overwrite the breakpoint.
It's very brittle.
For Linux kernel debugging these issues don't show up in practice, but
other kernels are able to swap their own memory.
> 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;
>
[pad]
> struct kvm_debug_guest_arch arch;
> }
>
The guest debug inteface can probablty be 100% arch specific.
> 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;
>
[pad]
> __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).
>
There's much more that can be done. Branch stepping, last branch
recording, etc.
> Questions:
> - Does anyone see traps and pitfalls in this approach?
>
It seems workable, modulo the non-transparency of the debugger.
> - 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)?
>
This will break compilation of older userspace, so a new interface is
preferred, complete with KVM_CAP_...
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-------------------------------------------------------------------------
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
