From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC] Reworking KVM_DEBUG_GUEST Date: Wed, 14 May 2008 17:28:51 +0200 Message-ID: <482B0533.2060603@web.de> References: <48282B63.6000204@web.de> <1210777972.6580.15.camel@thinkpadL> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0135132174==" Cc: kvm-devel To: jyoung5@us.ibm.com Return-path: In-Reply-To: <1210777972.6580.15.camel@thinkpadL> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0135132174== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDC0D1A205184C961D3F03D2A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDC0D1A205184C961D3F03D2A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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. I= n >> 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 leas= t > on Power) will throw an exception or trap. Then you deal with it. >=20 > 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). >=20 >=20 >> Why do we set breakpoints in the kernel? Why not simply catching all >> debug traps, inserting software breakpoint ops into the guest code, an= d >> handling all this stuff as normal debuggers do? And the hardware >> breakpoints should just be pushed through the kernel interface like >> ptrace does. >=20 > 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 littl= e > hairy.=20 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_. >=20 > Currently I'm actually implementing breakpoint support now in Power. Bu= t > 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. := ) ) >=20 >> 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; >> } >=20 >=20 >> 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 x8= 6 >> 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). >=20 > 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 wa= y? Jan --------------enigDC0D1A205184C961D3F03D2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIKwU2niDOoMHTA+kRAqXJAJ45tF/g6KxgIXyGmbUqfvI7cFNuUACfYEtw /jwwxuqLlKG8q4OTsd1t0Wk= =MY/m -----END PGP SIGNATURE----- --------------enigDC0D1A205184C961D3F03D2A-- --===============0135132174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --===============0135132174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============0135132174==--