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 21:49:02 +0200 Message-ID: <482B422E.3000007@web.de> References: <48282B63.6000204@web.de> <200805141325.32231.hollisb@us.ibm.com> <482B390E.7040004@web.de> <200805141433.44192.hollisb@us.ibm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1377152710==" Cc: kvm-devel@lists.sourceforge.net, kvm-ppc-devel@lists.sourceforge.net, jyoung5@us.ibm.com To: Hollis Blanchard Return-path: In-Reply-To: <200805141433.44192.hollisb@us.ibm.com> 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) --===============1377152710== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA263A2339881A1A5F8618935" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA263A2339881A1A5F8618935 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hollis Blanchard wrote: > On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote: >> Hollis Blanchard wrote: >>> On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: >>>> So gdb on power relies only on those few hw-breakpoints? With x86 yo= u >>>> 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). >>> GDB on Power inserts trap instructions, i.e. standard "soft" breakpoi= nts.=20 > It=20 >>> does not rely on the hardware breakpoints. >>> >>> It gets a little more complicated when you involve a GDB stub. IIRC, = GDB=20 > will=20 >>> ask the stub to set the breakpoint, and if the stub doesn't support i= t,=20 > GDB=20 >>> will fall back to overwriting the instructions in memory. Does the Qe= mu=20 > GDB=20 >>> stub advertise breakpoint support? >> Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's somethi= ng >> even gdbserver does not do! It just handles watchpoints (Z2..4). >> >>> If not, the only support needed in KVM would be to send all debug=20 > interrupts=20 >>> to qemu, and allow qemu to send them back down for in-guest breakpoin= ts. >>> >> Simply returning "unsupported" on Z0 is not yet enough for x86, KVM's >> kernel side should not yet inform QEMU about soft-BP exceptions. But i= n >> theory, this should be easily fixable (or is already the case for othe= r >> archs). And it would safe us from keeping track of N software >> breakpoints, where N could even become larger than 32, the current >> hardcoded limit for plain QEMU. :) >> >> Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is >> insufficient: We need a return channel for the debug register state >> (specifically to figure out details about hit watchpoints). I'm now >> favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling u= s >> to write _and_ read-back the suggested data structure. >=20 > How about simply extending kvm_exit.debug to contain the virtual addres= s of=20 > the breakpoint hit? Ah, there is an interface for such stuff already! And it can even take quite some payload... > In Qemu, when exit_reason =3D=3D KVM_EXIT_DEBUG, it would=20 > just need to see if that address is for a breakpoint Qemu set or not. I= f so,=20 > it's happy. If not, (commence handwaving) tell KVM to forward the debug= =20 > interrupt to the guest. This way, the list of breakpoints is maintained= in=20 > userspace (in the qemu gdb stub), which is nice because it could be=20 > arbitrarily large. Yes, but I would rather pass the debug registers (more general: some arch dependent state set) back in this slot. Those contain everything the gdbstub needs to know to catch relevant hardware-BP/watchpoint events (and report them to the gdb frontend). >=20 > Also, this is not specific to hardware debug registers: soft and hard=20 > breakpoint interrupts would follow the same path. There's still a quest= ion of=20 > whether the GDB stub should set the breakpoint itself (Z0/Z1) or force = GDB to=20 > modify memory, but either way the KVM code is simple. Only rejecting Z0 will enable us to avoid any soft-BP tracking in qemu-kvm, and that is definitely my plan. Z1 may become an option to add later on and would be answered as "unsupported" for now. Jan --------------enigA263A2339881A1A5F8618935 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 iD8DBQFIK0IxniDOoMHTA+kRAkr+AJ9aV76JCRzdS3FifECQzx6FORrL+gCffkmU q9CyU3PAWbxAr2QufBFXmqY= =SzuM -----END PGP SIGNATURE----- --------------enigA263A2339881A1A5F8618935-- --===============1377152710== 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/ --===============1377152710== 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 --===============1377152710==--