Documentation/powerpc/transactional_memory.txt

   1 Transactional Memory support
   2 ============================
   3
   4 POWER kernel support for this feature is currently limited to supporting
   5 its use by user programs.  It is not currently used by the kernel itself.
   6
   7 This file aims to sum up how it is supported by Linux and what behaviour you
   8 can expect from your user programs.
   9
  10
  11 Basic overview
  12 ==============
  13
  14 Hardware Transactional Memory is supported on POWER8 processors, and is a
  15 feature that enables a different form of atomic memory access.  Several new
  16 instructions are presented to delimit transactions; transactions are
  17 guaranteed to either complete atomically or roll back and undo any partial
  18 changes.
  19
  20 A simple transaction looks like this:
  21
  22 begin_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
  37 abort_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
  45 The 'tbegin' instruction denotes the start point, and 'tend' the end point.
  46 Between these points the processor is in 'Transactional' state; any memory
  47 references will complete in one go if there are no conflicts with other
  48 transactional or non-transactional accesses within the system.  In this
  49 example, the transaction completes as though it were normal straight-line code
  50 IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
  51 atomic move of money from the current account to the savings account has been
  52 performed.  Even though the normal ld/std instructions are used (note no
  53 lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
  54 updated, or neither will be updated.
  55
  56 If, in the meantime, there is a conflict with the locations accessed by the
  57 transaction, the transaction will be aborted by the CPU.  Register and memory
  58 state 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
  60 abort handler can check the cause of the failure, and retry.
  61
  62 Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
  63 and a few other status/flag regs; see the ISA for details.
  64
  65 Causes 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
  74 Syscalls
  75 ========
  76
  77 Syscalls made from within an active transaction will not be performed and the
  78 transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL
  79 | TM_CAUSE_PERSISTENT.
  80
  81 Syscalls made from within a suspended transaction are performed as normal and
  82 the transaction is not explicitly doomed by the kernel.  However, what the
  83 kernel does to perform the syscall may result in the transaction being doomed
  84 by the hardware.  The syscall is performed in suspended mode so any side
  85 effects will be persistent, independent of transaction success or failure.  No
  86 guarantees are provided by the kernel about which syscalls will affect
  87 transaction success.
  88
  89 Care must be taken when relying on syscalls to abort during active transactions
  90 if the calls are made via a library.  Libraries may cache values (which may
  91 give the appearance of success) or perform operations that cause transaction
  92 failure before entering the kernel (which may produce different failure codes).
  93 Examples are glibc's getpid() and lazy symbol resolution.
  94
  95
  96 Signals
  97 =======
  98
  99 Delivery of signals (both sync and async) during transactions provides a second
 100 thread state (ucontext/mcontext) to represent the second transactional register
 101 state.  Signal delivery 'treclaim's to capture both register states, so signals
 102 abort transactions.  The usual ucontext_t passed to the signal handler
 103 represents the checkpointed/original register state; the signal appears to have
 104 arisen at 'tbegin+4'.
 105
 106 If the sighandler ucontext has uc_link set, a second ucontext has been
 107 delivered.  For future compatibility the MSR.TS field should be checked to
 108 determine the transactional state -- if so, the second ucontext in uc->uc_link
 109 represents the active transactional registers at the point of the signal.
 110
 111 For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
 112 field shows the transactional mode.
 113
 114 For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
 115 bits are stored in the MSR of the second ucontext, i.e. in
 116 uc->uc_link->uc_mcontext.regs->msr.  The top word contains the transactional
 117 state TS.
 118
 119 However, basic signal handlers don't need to be aware of transactions
 120 and simply returning from the handler will deal with things correctly:
 121
 122 Transaction-aware signal handlers can read the transactional register state
 123 from the second ucontext.  This will be necessary for crash handlers to
 124 determine, for example, the address of the instruction causing the SIGSEGV.
 125
 126 Example 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
 151 When in an active transaction that takes a signal, we need to be careful with
 152 the stack.  It's possible that the stack has moved back up after the tbegin.
 153 The obvious case here is when the tbegin is called inside a function that
 154 returns before a tend.  In this case, the stack is part of the checkpointed
 155 transactional memory state.  If we write over this non transactionally or in
 156 suspend, we are in trouble because if we get a tm abort, the program counter and
 157 stack pointer will be back at the tbegin but our in memory stack won't be valid
 158 anymore.
 159
 160 To avoid this, when taking a signal in an active transaction, we need to use
 161 the stack pointer from the checkpointed state, rather than the speculated
 162 state.  This ensures that the signal context (written tm suspended) will be
 163 written below the stack required for the rollback.  The transaction is aborted
 164 because of the treclaim, so any memory written between the tbegin and the
 165 signal will be rolled back anyway.
 166
 167 For signals taken in non-TM or suspended mode, we use the
 168 normal/non-checkpointed stack pointer.
 169
 170 Any transaction initiated inside a sighandler and suspended on return
 171 from the sighandler to the kernel will get reclaimed and discarded.
 172
 173 Failure cause codes used by kernel
 174 ==================================
 175
 176 These are defined in <asm/reg.h>, and distinguish different reasons why the
 177 kernel 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
 188 These can be checked by the user program's abort handler as TEXASR[0:7].  If
 189 bit 7 is set, it indicates that the error is consider persistent.  For example
 190 a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.
 191
 192 GDB
 193 ===
 194
 195 GDB and ptrace are not currently TM-aware.  If one stops during a transaction,
 196 it looks like the transaction has just started (the checkpointed state is
 197 presented).  The transaction cannot then be continued and will take the failure
 198 handler route.  Furthermore, the transactional 2nd register state will be
 199 inaccessible.  GDB can currently be used on programs using TM, but not sensibly
 200 in parts within transactions.
 201
 202 POWER9
 203 ======
 204
 205 TM on POWER9 has issues with storing the complete register state. This
 206 is described in this commit:
 207
 208     commit 4bb3c7a0208fc13ca70598efd109901a7cd45ae7
 209     Author: Paul Mackerras <paulus@ozlabs.org>
 210     Date:   Wed Mar 21 21:32:01 2018 +1100
 211     KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9
 212
 213 To account for this different POWER9 chips have TM enabled in
 214 different ways.
 215
 216 On POWER9N DD2.01 and below, TM is disabled. ie
 217 HWCAP2[PPC_FEATURE2_HTM] is not set.
 218
 219 On POWER9N DD2.1 TM is configured by firmware to always abort a
 220 transaction when tm suspend occurs. So tsuspend will cause a
 221 transaction to be aborted and rolled back. Kernel exceptions will also
 222 cause the transaction to be aborted and rolled back and the exception
 223 will not occur. If userspace constructs a sigcontext that enables TM
 224 suspend, the sigcontext will be rejected by the kernel. This mode is
 225 advertised to users with HWCAP2[PPC_FEATURE2_HTM_NO_SUSPEND] set.
 226 HWCAP2[PPC_FEATURE2_HTM] is not set in this mode.
 227
 228 On POWER9N DD2.2 and above, KVM and POWERVM emulate TM for guests (as
 229 described in commit 4bb3c7a0208f), hence TM is enabled for guests
 230 ie. HWCAP2[PPC_FEATURE2_HTM] is set for guest userspace. Guests that
 231 makes heavy use of TM suspend (tsuspend or kernel suspend) will result
 232 in traps into the hypervisor and hence will suffer a performance
 233 degradation. Host userspace has TM disabled
 234 ie. HWCAP2[PPC_FEATURE2_HTM] is not set. (although we make enable it
 235 at some point in the future if we bring the emulation into host
 236 userspace context switching).
 237
 238 POWER9C DD1.2 and above are only available with POWERVM and hence
 239 Linux only runs as a guest. On these systems TM is emulated like on
 240 POWER9N DD2.2.
 241
 242 Guest migration from POWER8 to POWER9 will work with POWER9N DD2.2 and
 243 POWER9C DD1.2. Since earlier POWER9 processors don't support TM
 244 emulation, migration from POWER8 to POWER9 is not supported there.