From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IviBU-0002BR-GN
	for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:43:44 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IviBS-0002B7-Va
	for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:43:44 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IviBS-0002B4-So
	for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:43:42 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1IviBS-0002cc-Jd
	for qemu-devel@nongnu.org; Fri, 23 Nov 2007 18:43:42 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC] Ensure SIGALRM causes a cpu_loop_exit
Date: Fri, 23 Nov 2007 23:43:35 +0000
References: <fb249edb0711231450u5f2405e9h1f36ec879afa114e@mail.gmail.com>
In-Reply-To: <fb249edb0711231450u5f2405e9h1f36ec879afa114e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200711232343.37131.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> =C2=A0 There is a chance that when using "unix" or "dynticks" clock, the
> signal arrives when no cpu is executing.

I've seen similar stalls, but not managed to track down the source. Your=20
analysis seems correct.

> + =C2=A0 =C2=A0/* cause an interrupt in the first cpu that tries to start=
 running */
> + =C2=A0 =C2=A0if (!env) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0env_pending_request | mask

IIUC We should assert that mask =3D=3D CPU_INTERRUPT_EXIT. If we try to rai=
se an=20
actual interrupt without an active CPU then something else is wrong. In fac=
t=20
this probably means env_pending_request can be a simple boolean (indicating=
=20
we want to break out of cpu_exec), rather than munging it into=20
env->interrupt_request.

it took me a while to figure out exactly which race condition we're avoidin=
g=20
here. How adding a comment like:

/* There is a window for signals to arrive between main_loop checking for=20
events and setting cpu_single_env here.  Check if this occurred and we need=
=20
to exit back to the IO loop. */

> + =C2=A0 =C2=A0if (env_pending_request) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_interrupt(env1, env_pending_request);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0env_pending_request =3D 0;
> + =C2=A0 =C2=A0}
> +