[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
From: |
Alex Bennée |
Subject: |
Re: [Qemu-arm] [PATCH v9 20/25] target-arm/powerctl: defer cpu reset work to CPU context |
Date: |
Fri, 03 Feb 2017 15:02:54 +0000 |
User-agent: |
mu4e 0.9.19; emacs 25.1.91.7 |
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
thread runs.
>
> thanks
> -- PMM
--
Alex Bennée