[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH v9 20/25] target-arm/powerctl: defer cpu reset wor
Re: [Qemu-arm] [PATCH v9 20/25] target-arm/powerctl: defer cpu reset work to CPU context
Fri, 03 Feb 2017 15:02:54 +0000
mu4e 0.9.19; emacs 184.108.40.206
Peter Maydell <address@hidden> writes:
> On 1 February 2017 at 15:05, Alex Bennée <address@hidden> wrote:
>> When switching a new vCPU on we want to complete a bunch of the setup
>> work before we start scheduling the vCPU thread. To do this cleanly we
>> defer vCPU setup to async work which will run the vCPUs execution
>> context as the thread is woken up. The scheduling of the work will kick
>> the vCPU awake.
>> This avoids potential races in MTTCG system emulation.
>> Signed-off-by: Alex Bennée <address@hidden>
>> Reviewed-by: Richard Henderson <address@hidden>
> Can we now have races between arm_set_cpu_on() and
> arm_set_cpu_off() ? It's not clear to me what prevents that.
> With this change our PSCI CPU_ON is no longer effectively
> atomic, which means we need to think about the races
> between PSCI CPU_ON and CPU_OFF, and the fact that the
> core might be in what the PSCI spec section 6.6
> calls an ON_PENDING state (ie CPU_ON has been called
> for it but it hasn't actually booted yet).
Would it be enough to also queue the set_cpu_off work?
The queue itself is safe to add to so you'll end up with a series of
on/off deferred work that will eventually unwind itself when the CPU
> -- PMM