On 04/13/2015 02:18 PM, Anshuman Khandual wrote:

On 04/10/2015 04:03 PM, Ulrich Weigand wrote:

quoted

Anshuman Khandual [off-list ref] wrote on 10.04.2015
11:10:35:

I believed it stores the check pointed MSR value which was in the register
before the transaction started. But then how it is different from the
ckpt_regs.msr, I am not sure. Mikey or Michael should be able to clarify
more on this. I can see "orig_msr" getting used in many places to hold the
check pointed value of MSR.

tm_orig_msr is used during process context switch only. ckpt_regs
gets used in the signal context where we save all userspace context.
So ptrace would look into the saved MSR value correctly inside
ckpt_regs.msr slot. I believe thats the check pointed MSR value
we are interested in from the ptrace perspective not the tm_orig_msr
which just gets used during process context switch.

quoted

  I may be misreading kernel code, but it seems the kernel does not
actually
  use the ckpt_regs.msr slot at all, and therefore the corresponding slot
of
  the NT_PPC_TM_CGPR regset is likewise undefined/unused.  Would it not be
  more consistent to use that slot to pass the checkpointed MSR?

Hmm. Its a valid point. Would like to get some more clarity on this from
Mikey whether that slot can be used for check pointed MSR value or not.
Then why did we have these two slots to hold the same check pointed MSR
value in the first place at all. Getting confused a bit.

Using ckpt_regs.msr during process context switch instead of tm_orig_msr seems
to be working fine and all the basic TM tests pass, in which case we can drop
tm_orig_msr from thread_struct. Will post a patch on this and see whats the
response from others.