Hi Cyril,
On Wed, Jun 08, 2016 at 02:00:34PM +1000, Cyril Bur wrote:
> @@ -917,24 +907,10 @@ static inline void tm_recheckpoint_new_task(struct
> task_struct *new)
> "(new->msr 0x%lx, new->origmsr 0x%lx)\n",
> new->pid, new->thread.regs->msr, msr);
>
> - /* This loads the checkpointed FP/VEC state, if used */
> tm_recheckpoint(&new->thread, msr);
>
> - /* This loads the speculative FP/VEC state, if used */
> - if (msr & MSR_FP) {
> - do_load_up_transact_fpu(&new->thread);
> - new->thread.regs->msr |=
> - (MSR_FP | new->thread.fpexc_mode);
> - }
> -#ifdef CONFIG_ALTIVEC
> - if (msr & MSR_VEC) {
> - do_load_up_transact_altivec(&new->thread);
> - new->thread.regs->msr |= MSR_VEC;
> - }
> -#endif
> - /* We may as well turn on VSX too since all the state is restored now */
> - if (msr & MSR_VSX)
> - new->thread.regs->msr |= MSR_VSX;
> + /* Won't restore math get called later? */
> + restore_math(new->thread.regs);
I have some question for the "restore_math" in tm_recheckpoint_new_task().
Per my understanding, now after tm_recheckpoint, the fp_state content
is obsolete. However restore_math() will try to restore FP/Vec/VSX state
from fp_state, (orginally it is right, since fp_state was the valid
checkpointed state and consistent with FP register ). Should we remove
the restore_math() here?
And, should the thread's MSR now set FP bit in tm_recheckpoint(), to
indicate that FP register content is "fresh" in contrast to thread.fp_state?
Please correct me if I am wrong.
Thanks,
- Simon
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
