1 ============================
2 Transactional Memory support
3 ============================
4
5 POWER kernel support for this feature is curre
6 its use by user programs. It is not currently
7
8 This file aims to sum up how it is supported b
9 can expect from your user programs.
10
11
12 Basic overview
13 ==============
14
15 Hardware Transactional Memory is supported on
16 feature that enables a different form of atomi
17 instructions are presented to delimit transact
18 guaranteed to either complete atomically or ro
19 changes.
20
21 A simple transaction looks like this::
22
23 begin_move_money:
24 tbegin
25 beq abort_handler
26
27 ld r4, SAVINGS_ACCT(r3)
28 ld r5, CURRENT_ACCT(r3)
29 subi r5, r5, 1
30 addi r4, r4, 1
31 std r4, SAVINGS_ACCT(r3)
32 std r5, CURRENT_ACCT(r3)
33
34 tend
35
36 b continue
37
38 abort_handler:
39 ... test for odd failures ...
40
41 /* Retry the transaction if it failed beca
42 * someone else: */
43 b begin_move_money
44
45
46 The 'tbegin' instruction denotes the start poi
47 Between these points the processor is in 'Tran
48 references will complete in one go if there ar
49 transactional or non-transactional accesses wi
50 example, the transaction completes as though i
51 IF no other processor has touched SAVINGS_ACCT
52 atomic move of money from the current account
53 performed. Even though the normal ld/std inst
54 lwarx/stwcx), either *both* SAVINGS_ACCT(r3) a
55 updated, or neither will be updated.
56
57 If, in the meantime, there is a conflict with
58 transaction, the transaction will be aborted b
59 state will roll back to that at the 'tbegin',
60 'tbegin+4'. The branch to abort_handler will
61 abort handler can check the cause of the failu
62
63 Checkpointed registers include all GPRs, FPRs,
64 and a few other status/flag regs; see the ISA
65
66 Causes of transaction aborts
67 ============================
68
69 - Conflicts with cache lines used by other pro
70 - Signals
71 - Context switches
72 - See the ISA for full documentation of everyt
73
74
75 Syscalls
76 ========
77
78 Syscalls made from within an active transactio
79 transaction will be doomed by the kernel with
80 | TM_CAUSE_PERSISTENT.
81
82 Syscalls made from within a suspended transact
83 the transaction is not explicitly doomed by th
84 kernel does to perform the syscall may result
85 by the hardware. The syscall is performed in
86 effects will be persistent, independent of tra
87 guarantees are provided by the kernel about wh
88 transaction success.
89
90 Care must be taken when relying on syscalls to
91 if the calls are made via a library. Librarie
92 give the appearance of success) or perform ope
93 failure before entering the kernel (which may
94 Examples are glibc's getpid() and lazy symbol
95
96
97 Signals
98 =======
99
100 Delivery of signals (both sync and async) duri
101 thread state (ucontext/mcontext) to represent
102 state. Signal delivery 'treclaim's to capture
103 abort transactions. The usual ucontext_t pass
104 represents the checkpointed/original register
105 arisen at 'tbegin+4'.
106
107 If the sighandler ucontext has uc_link set, a
108 delivered. For future compatibility the MSR.T
109 determine the transactional state -- if so, th
110 represents the active transactional registers
111
112 For 64-bit processes, uc->uc_mcontext.regs->ms
113 field shows the transactional mode.
114
115 For 32-bit processes, the mcontext's MSR regis
116 bits are stored in the MSR of the second ucont
117 uc->uc_link->uc_mcontext.regs->msr. The top w
118 state TS.
119
120 However, basic signal handlers don't need to b
121 and simply returning from the handler will dea
122
123 Transaction-aware signal handlers can read the
124 from the second ucontext. This will be necess
125 determine, for example, the address of the ins
126
127 Example signal handler::
128
129 void crash_handler(int sig, siginfo_t *si,
130 {
131 ucontext_t *ucp = uc;
132 ucontext_t *transactional_ucp = ucp->uc_
133
134 if (ucp_link) {
135 u64 msr = ucp->uc_mcontext.regs->msr;
136 /* May have transactional ucontext! */
137 #ifndef __powerpc64__
138 msr |= ((u64)transactional_ucp->uc_mco
139 #endif
140 if (MSR_TM_ACTIVE(msr)) {
141 /* Yes, we crashed during a transac
142 fprintf(stderr, "Transaction to be restarte
143 "crashy instruction
144 ucp->uc_mcontext.re
145 transactional_ucp->
146 }
147 }
148
149 fix_the_problem(ucp->dar);
150 }
151
152 When in an active transaction that takes a sig
153 the stack. It's possible that the stack has m
154 The obvious case here is when the tbegin is ca
155 returns before a tend. In this case, the stac
156 transactional memory state. If we write over
157 suspend, we are in trouble because if we get a
158 stack pointer will be back at the tbegin but o
159 anymore.
160
161 To avoid this, when taking a signal in an acti
162 the stack pointer from the checkpointed state,
163 state. This ensures that the signal context (
164 written below the stack required for the rollb
165 because of the treclaim, so any memory written
166 signal will be rolled back anyway.
167
168 For signals taken in non-TM or suspended mode,
169 normal/non-checkpointed stack pointer.
170
171 Any transaction initiated inside a sighandler
172 from the sighandler to the kernel will get rec
173
174 Failure cause codes used by kernel
175 ==================================
176
177 These are defined in <asm/reg.h>, and distingu
178 kernel aborted a transaction:
179
180 ====================== ======================
181 TM_CAUSE_RESCHED Thread was rescheduled
182 TM_CAUSE_TLBI Software TLB invalid.
183 TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable
184 TM_CAUSE_SYSCALL Syscall from active tr
185 TM_CAUSE_SIGNAL Signal delivered.
186 TM_CAUSE_MISC Currently unused.
187 TM_CAUSE_ALIGNMENT Alignment fault.
188 TM_CAUSE_EMULATE Emulation that touched
189 ====================== ======================
190
191 These can be checked by the user program's abo
192 bit 7 is set, it indicates that the error is c
193 a TM_CAUSE_ALIGNMENT will be persistent while
194
195 GDB
196 ===
197
198 GDB and ptrace are not currently TM-aware. If
199 it looks like the transaction has just started
200 presented). The transaction cannot then be co
201 handler route. Furthermore, the transactional
202 inaccessible. GDB can currently be used on pr
203 in parts within transactions.
204
205 POWER9
206 ======
207
208 TM on POWER9 has issues with storing the compl
209 is described in this commit::
210
211 commit 4bb3c7a0208fc13ca70598efd109901a7cd
212 Author: Paul Mackerras <paulus@ozlabs.org>
213 Date: Wed Mar 21 21:32:01 2018 +1100
214 KVM: PPC: Book3S HV: Work around transacti
215
216 To account for this different POWER9 chips hav
217 different ways.
218
219 On POWER9N DD2.01 and below, TM is disabled. i
220 HWCAP2[PPC_FEATURE2_HTM] is not set.
221
222 On POWER9N DD2.1 TM is configured by firmware
223 transaction when tm suspend occurs. So tsuspen
224 transaction to be aborted and rolled back. Ker
225 cause the transaction to be aborted and rolled
226 will not occur. If userspace constructs a sigc
227 suspend, the sigcontext will be rejected by th
228 advertised to users with HWCAP2[PPC_FEATURE2_H
229 HWCAP2[PPC_FEATURE2_HTM] is not set in this mo
230
231 On POWER9N DD2.2 and above, KVM and POWERVM em
232 described in commit 4bb3c7a0208f), hence TM is
233 ie. HWCAP2[PPC_FEATURE2_HTM] is set for guest
234 makes heavy use of TM suspend (tsuspend or ker
235 in traps into the hypervisor and hence will su
236 degradation. Host userspace has TM disabled
237 ie. HWCAP2[PPC_FEATURE2_HTM] is not set. (alth
238 at some point in the future if we bring the em
239 userspace context switching).
240
241 POWER9C DD1.2 and above are only available wit
242 Linux only runs as a guest. On these systems T
243 POWER9N DD2.2.
244
245 Guest migration from POWER8 to POWER9 will wor
246 POWER9C DD1.2. Since earlier POWER9 processors
247 emulation, migration from POWER8 to POWER9 is
248
249 Kernel implementation
250 =====================
251
252 h/rfid mtmsrd quirk
253 -------------------
254
255 As defined in the ISA, rfid has a quirk which
256 exception handling. When in a userspace transa
257 kernel via some exception, MSR will end up as
258 off but TM suspended). Regularly the kernel wi
259 the MSR and will perform an rfid to do this. I
260 have SRR0 TM = 0 and TS = 00 (ie. TM off and n
261 resulting MSR will retain TM = 0 and TS=01 fro
262 suspend). This is a quirk in the architecture
263 be a transition from TS=01 to TS=00 (ie. suspe
264 which is an illegal transition.
265
266 This quirk is described the architecture in th
267 with these lines:
268
269 if (MSR 29:31 ¬ = 0b010 | SRR1 29:31 ¬ = 0
270 MSR 29:31 <- SRR1 29:31
271
272 hrfid and mtmsrd have the same quirk.
273
274 The Linux kernel uses this quirk in its early
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.