[PATCH] arm: vfp: always clear vfp_current_hw_state when forcing reload

[Yuanyuan ZHONG]

On Wed, Oct 2, 2013 at 5:11 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Oct 02, 2013 at 04:59:47PM -0500, Yuanyuan Zhong wrote:
>> The current thread trying to clear the held vfp state may not be
>> the owner of hw state. For example,
>>       Core0                   Core1
>>                               Thread1 uses VFP.
>>                                 Thread1 vfpstate.hard.cpu = 1.
>>                                 vfp_current_hw_state[1] points to Thread1
>>                                   vfpstate.
>>       Going to suspend.
>>       Freeze Thread1.
>>                               Thread1 is switched out.
>>                               VFP HW registers saved to Thread1 vfpstate.
>
> Correct so far.  At this point:
>
>                                 vfp_current_hw_state[1] = &thread1->vfpstate;
>                                 thread1->vfpstate.hard.cpu = 1;
>
>>       Core0 disables Core1.
>>                               Stopper thread calls vfp_force_reload().
>>                               Stopper thread vfpstate.hard.cpu = NR_CPUS.
>
> Correct, except there's another part to this.  vfp_state_in_hw() returns
> true here, since thread1->vfpstate.hard.cpu is the dying CPU (CPU 1), and
> vfp_current_hw_state[1] is &thread1->vfpstate.  So we also do this:
>
>                                 clear FPEXC_EN
>                                 vfp_current_hw_state[1] = NULL;
>
vfp_state_in_hw() returns false. It's checking current_thread_info()
which is the stopper thread migration/1, not thread1.
>>                               ...
>>                               (No PM notifier for non-idle path. So
>>                                 vfp_pm_suspend() is NOT called on Core1.)
>>                               ...
>>                               Core1 is off and VFP HW registers are lost.
>>       ...
>>       Core0 enables Core1.
>>       Core0 thaw Thread1.
>>       Thread1 migrate to Core1
>>         before using VFP.
>>                               Thread1 starts using VFP.
>>                               Now we have vfp_current_hw_state[1] points
>>                                 to Thread1 vfpstate. And Thread1 has
>>                                 vfpstate.hard.cpu = 1.
>
> No.  With my above correction:
>                                 vfp_current_hw_state[1] = NULL
>
> and that forces a reload of the saved context.