From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7n7L-0007qY-0p for qemu-devel@nongnu.org; Wed, 24 Jun 2015 12:01:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7n7F-0008P9-C1 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 12:01:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7n7F-0008Ou-70 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 12:01:33 -0400 Message-ID: <558AD458.4000905@redhat.com> Date: Wed, 24 Jun 2015 18:01:28 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1435160084-938-1-git-send-email-alex.bennee@linaro.org> In-Reply-To: <1435160084-938-1-git-send-email-alex.bennee@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (MTTCG) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= , mttcg@greensocs.com, mark.burton@greensocs.com, fred.konrad@greensocs.com Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, Alexander Spyridakis On 24/06/2015 17:34, Alex Benn=C3=A9e wrote: > Testing with Alexander's bare metal syncronisation tests fails in MTTCG > leaving one CPU spinning forever waiting for the second CPU to wake up. > We simply need to poke the halt_cond once we have processed the PSCI > power on call. >=20 > Tested-by: Alex Benn=C3=A9e > CC: Alexander Spyridakis >=20 > --- > TODO > - exactly how does the vexpress wake up it's sleeping CPUs? > --- > target-arm/psci.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/target-arm/psci.c b/target-arm/psci.c > index d8fafab..661ff28 100644 > --- a/target-arm/psci.c > +++ b/target-arm/psci.c > @@ -196,6 +196,8 @@ void arm_handle_psci_call(ARMCPU *cpu) > } > target_cpu_class->set_pc(target_cpu_state, entry); > =20 > + qemu_cond_signal(target_cpu_state->halt_cond); That's called qemu_cpu_kick(target_cpu_state). :) The patch should be acceptable now upstream, I think. Paolo > ret =3D 0; > break; > case QEMU_PSCI_0_1_FN_CPU_OFF: >=20