Paolo Bonzini <pbonz...@redhat.com> writes: > On 24/06/2015 17:34, Alex Bennée 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. >> >> Tested-by: Alex Bennée <alex.ben...@linaro.org> >> CC: Alexander Spyridakis <a.spyrida...@virtualopensystems.com> >> >> --- >> TODO >> - exactly how does the vexpress wake up it's sleeping CPUs? >> --- >> target-arm/psci.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> 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); >> >> + 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)? > > Paolo > >> ret = 0; >> break; >> case QEMU_PSCI_0_1_FN_CPU_OFF: >> -- Alex Bennée
