From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxoqM-0005is-GG for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:19:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxoqH-0005hE-UW for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:19:10 -0500 Received: from [199.232.76.173] (port=35075 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxoqH-0005h8-Ny for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:19:05 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:32948) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxoqG-0007Zf-Ng for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:19:05 -0500 Message-ID: <4911FFB1.7070209@web.de> Date: Wed, 05 Nov 2008 21:18:57 +0100 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig10F3CC92EB6A1905873BE91F" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [5620] Add safety net against potential infinite loop Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10F3CC92EB6A1905873BE91F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable malc wrote: > Revision: 5620 > http://svn.sv.gnu.org/viewvc/?view=3Drev&root=3Dqemu&revision= =3D5620 > Author: malc > Date: 2008-11-04 14:18:13 +0000 (Tue, 04 Nov 2008) >=20 > Log Message: > ----------- > Add safety net against potential infinite loop >=20 > cpu_interrupt might be called while translating the TB, but before it > is linked into a potentially infinite loop and becomes env->current_tb.= >=20 > Currently this can (and does) cause huge problems only when using > dyntick clock, with other (periodic) clocks host_alarm_handler will > eventually be executed resulting in a call to cpu_interrupt which will > reset the recursion of running TB and the damage is "only" latency. >=20 > Modified Paths: > -------------- > trunk/cpu-exec.c >=20 > Modified: trunk/cpu-exec.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- trunk/cpu-exec.c 2008-11-04 13:17:17 UTC (rev 5619) > +++ trunk/cpu-exec.c 2008-11-04 14:18:13 UTC (rev 5620) > @@ -623,6 +623,14 @@ > } > spin_unlock(&tb_lock); > env->current_tb =3D tb; > + > + /* cpu_interrupt might be called while translating the= > + TB, but before it is linked into a potentially > + infinite loop and becomes env->current_tb. Avoid > + starting execution if there is a pending interrupt.= */ > + if (unlikely (env->interrupt_request & CPU_INTERRUPT_E= XIT)) > + env->current_tb =3D NULL; > + > while (env->current_tb) { > tc_ptr =3D tb->tc_ptr; > /* execute the generated code */ This somehow breaks single-stepping via gdbstub. Unless you have an instant idea (or even fix), I will dig for the reasons. Jan --------------enig10F3CC92EB6A1905873BE91F 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkR/7UACgkQniDOoMHTA+lrogCfRcNf6hWnZuiMUwI40gJj5q/Z UE0An3kRKuZHZAoCuRYecVbMYwX/66Js =RCmn -----END PGP SIGNATURE----- --------------enig10F3CC92EB6A1905873BE91F--