[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (M
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (MTTCG) |
Date: |
Wed, 24 Jun 2015 18:18:18 +0100 |
Paolo Bonzini <address@hidden> 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 <address@hidden>
>> CC: Alexander Spyridakis <address@hidden>
>>
>> ---
>> 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
Re: [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (MTTCG), Alexander Spyridakis, 2015/06/24