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. 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 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). 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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