1Transactional Memory support
  2============================
  3
  4POWER kernel support for this feature is currently limited to supporting
  5its use by user programs.  It is not currently used by the kernel itself.
  6
  7This file aims to sum up how it is supported by Linux and what behaviour you
  8can expect from your user programs.
  9
 10
 11Basic overview
 12==============
 13
 14Hardware Transactional Memory is supported on POWER8 processors, and is a
 15feature that enables a different form of atomic memory access.  Several new
 16instructions are presented to delimit transactions; transactions are
 17guaranteed to either complete atomically or roll back and undo any partial
 18changes.
 19
 20A simple transaction looks like this:
 21
 22begin_move_money:
 23  tbegin
 24  beq   abort_handler
 25
 26  ld    r4, SAVINGS_ACCT(r3)
 27  ld    r5, CURRENT_ACCT(r3)
 28  subi  r5, r5, 1
 29  addi  r4, r4, 1
 30  std   r4, SAVINGS_ACCT(r3)
 31  std   r5, CURRENT_ACCT(r3)
 32
 33  tend
 34
 35  b     continue
 36
 37abort_handler:
 38  ... test for odd failures ...
 39
 40  /* Retry the transaction if it failed because it conflicted with
 41   * someone else: */
 42  b     begin_move_money
 43
 44
 45The 'tbegin' instruction denotes the start point, and 'tend' the end point.
 46Between these points the processor is in 'Transactional' state; any memory
 47references will complete in one go if there are no conflicts with other
 48transactional or non-transactional accesses within the system.  In this
 49example, the transaction completes as though it were normal straight-line code
 50IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
 51atomic move of money from the current account to the savings account has been
 52performed.  Even though the normal ld/std instructions are used (note no
 53lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
 54updated, or neither will be updated.
 55
 56If, in the meantime, there is a conflict with the locations accessed by the
 57transaction, the transaction will be aborted by the CPU.  Register and memory
 58state will roll back to that at the 'tbegin', and control will continue from
 59'tbegin+4'.  The branch to abort_handler will be taken this second time; the
 60abort handler can check the cause of the failure, and retry.
 61
 62Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
 63and a few other status/flag regs; see the ISA for details.
 64
 65Causes of transaction aborts
 66============================
 67
 68- Conflicts with cache lines used by other processors
 69- Signals
 70- Context switches
 71- See the ISA for full documentation of everything that will abort transactions.
 72
 73
 74Syscalls
 75========
 76
 77Syscalls made from within an active transaction will not be performed and the
 78transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL
 79| TM_CAUSE_PERSISTENT.
 80
 81Syscalls made from within a suspended transaction are performed as normal and
 82the transaction is not explicitly doomed by the kernel.  However, what the
 83kernel does to perform the syscall may result in the transaction being doomed
 84by the hardware.  The syscall is performed in suspended mode so any side
 85effects will be persistent, independent of transaction success or failure.  No
 86guarantees are provided by the kernel about which syscalls will affect
 87transaction success.
 88
 89Care must be taken when relying on syscalls to abort during active transactions
 90if the calls are made via a library.  Libraries may cache values (which may
 91give the appearance of success) or perform operations that cause transaction
 92failure before entering the kernel (which may produce different failure codes).
 93Examples are glibc's getpid() and lazy symbol resolution.
 94
 95
 96Signals
 97=======
 98
 99Delivery of signals (both sync and async) during transactions provides a second
100thread state (ucontext/mcontext) to represent the second transactional register
101state.  Signal delivery 'treclaim's to capture both register states, so signals
102abort transactions.  The usual ucontext_t passed to the signal handler
103represents the checkpointed/original register state; the signal appears to have
104arisen at 'tbegin+4'.
105
106If the sighandler ucontext has uc_link set, a second ucontext has been
107delivered.  For future compatibility the MSR.TS field should be checked to
108determine the transactional state -- if so, the second ucontext in uc->uc_link
109represents the active transactional registers at the point of the signal.
110
111For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
112field shows the transactional mode.
113
114For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
115bits are stored in the MSR of the second ucontext, i.e. in
116uc->uc_link->uc_mcontext.regs->msr.  The top word contains the transactional
117state TS.
118
119However, basic signal handlers don't need to be aware of transactions
120and simply returning from the handler will deal with things correctly:
121
122Transaction-aware signal handlers can read the transactional register state
123from the second ucontext.  This will be necessary for crash handlers to
124determine, for example, the address of the instruction causing the SIGSEGV.
125
126Example signal handler:
127
128    void crash_handler(int sig, siginfo_t *si, void *uc)
129    {
130      ucontext_t *ucp = uc;
131      ucontext_t *transactional_ucp = ucp->uc_link;
132
133      if (ucp_link) {
134        u64 msr = ucp->uc_mcontext.regs->msr;
135        /* May have transactional ucontext! */
136#ifndef __powerpc64__
137        msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
138#endif
139        if (MSR_TM_ACTIVE(msr)) {
140           /* Yes, we crashed during a transaction.  Oops. */
141   fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
142                           "crashy instruction was at 0x%llx\n",
143                           ucp->uc_mcontext.regs->nip,
144                           transactional_ucp->uc_mcontext.regs->nip);
145        }
146      }
147
148      fix_the_problem(ucp->dar);
149    }
150
151When in an active transaction that takes a signal, we need to be careful with
152the stack.  It's possible that the stack has moved back up after the tbegin.
153The obvious case here is when the tbegin is called inside a function that
154returns before a tend.  In this case, the stack is part of the checkpointed
155transactional memory state.  If we write over this non transactionally or in
156suspend, we are in trouble because if we get a tm abort, the program counter and
157stack pointer will be back at the tbegin but our in memory stack won't be valid
158anymore.
159
160To avoid this, when taking a signal in an active transaction, we need to use
161the stack pointer from the checkpointed state, rather than the speculated
162state.  This ensures that the signal context (written tm suspended) will be
163written below the stack required for the rollback.  The transaction is aborted
164because of the treclaim, so any memory written between the tbegin and the
165signal will be rolled back anyway.
166
167For signals taken in non-TM or suspended mode, we use the
168normal/non-checkpointed stack pointer.
169
170Any transaction initiated inside a sighandler and suspended on return
171from the sighandler to the kernel will get reclaimed and discarded.
172
173Failure cause codes used by kernel
174==================================
175
176These are defined in <asm/reg.h>, and distinguish different reasons why the
177kernel aborted a transaction:
178
179 TM_CAUSE_RESCHED       Thread was rescheduled.
180 TM_CAUSE_TLBI          Software TLB invalid.
181 TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.
182 TM_CAUSE_SYSCALL       Syscall from active transaction.
183 TM_CAUSE_SIGNAL        Signal delivered.
184 TM_CAUSE_MISC          Currently unused.
185 TM_CAUSE_ALIGNMENT     Alignment fault.
186 TM_CAUSE_EMULATE       Emulation that touched memory.
187
188These can be checked by the user program's abort handler as TEXASR[0:7].  If
189bit 7 is set, it indicates that the error is consider persistent.  For example
190a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.
191
192GDB
193===
194
195GDB and ptrace are not currently TM-aware.  If one stops during a transaction,
196it looks like the transaction has just started (the checkpointed state is
197presented).  The transaction cannot then be continued and will take the failure
198handler route.  Furthermore, the transactional 2nd register state will be
199inaccessible.  GDB can currently be used on programs using TM, but not sensibly
200in parts within transactions.