From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7pCh-0007PB-US for qemu-devel@nongnu.org; Wed, 24 Jun 2015 14:15:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7pCe-0004yc-NT for qemu-devel@nongnu.org; Wed, 24 Jun 2015 14:15:19 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:34173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7pCe-0004yM-IM for qemu-devel@nongnu.org; Wed, 24 Jun 2015 14:15:16 -0400 Received: by wgqq4 with SMTP id q4so43129030wgq.1 for ; Wed, 24 Jun 2015 11:15:16 -0700 (PDT) References: <1435160084-938-1-git-send-email-alex.bennee@linaro.org> <558AD458.4000905@redhat.com> <87y4j9xbxh.fsf@linaro.org> <558AE78B.90705@redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <558AE78B.90705@redhat.com> Date: Wed, 24 Jun 2015 19:15:56 +0100 Message-ID: <87vbedx99f.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Paolo Bonzini Cc: mttcg@greensocs.com, peter.maydell@linaro.org, Alexander Spyridakis , mark.burton@greensocs.com, qemu-devel@nongnu.org, fred.konrad@greensocs.com Paolo Bonzini writes: > On 24/06/2015 19:18, Alex Bennée wrote: >>>> >> @@ -196,6 +196,8 @@ void arm_handle_psci_call(ARMCPU *cpu) >>>> >> } >>>> >> target_cpu_class->set_pc(target_cpu_state, entry); >>>> >> >>>> >> + 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. >> Oh so this might well fail in KVM too? >> >> The qemu_cpu_kick does a qemu_cond_broadcast(cpu->halt_cond) which seems >> a little excessive? Won't all sleeping CPUs wake up (and return to sleep)? > > On KVM (and I assume on MT-TCG), each CPU has a different halt_cond. You are right of course, I got my sense the wrong way around. Given it is per-cpu I wonder if you will ever have multiple threads waiting on it? Anyway I'll fix that up and re-submit after I've tested to see of these test cases break current KVM. > > Paolo -- Alex Bennée