1177633Sdfr============================ 2177633SdfrTransactional Memory support 3261057Smav============================ 4261057Smav 5261057SmavPOWER kernel support for this feature is currently limited to supporting 6261057Smavits use by user programs. It is not currently used by the kernel itself. 7261057Smav 8261057SmavThis file aims to sum up how it is supported by Linux and what behaviour you 9261057Smavcan expect from your user programs. 10261057Smav 11261057Smav 12261057SmavBasic overview 13261057Smav============== 14261057Smav 15261057SmavHardware Transactional Memory is supported on POWER8 processors, and is a 16261057Smavfeature that enables a different form of atomic memory access. Several new 17177633Sdfrinstructions are presented to delimit transactions; transactions are 18261057Smavguaranteed to either complete atomically or roll back and undo any partial 19261057Smavchanges. 20261057Smav 21261057SmavA simple transaction looks like this:: 22261057Smav 23261057Smav begin_move_money: 24261057Smav tbegin 25261057Smav beq abort_handler 26261057Smav 27261057Smav ld r4, SAVINGS_ACCT(r3) 28261057Smav ld r5, CURRENT_ACCT(r3) 29177633Sdfr subi r5, r5, 1 30177633Sdfr addi r4, r4, 1 31177633Sdfr std r4, SAVINGS_ACCT(r3) 32177633Sdfr std r5, CURRENT_ACCT(r3) 33177633Sdfr 34177633Sdfr tend 35177633Sdfr 36177633Sdfr b continue 37177633Sdfr 38177633Sdfr abort_handler: 39177633Sdfr ... test for odd failures ... 40177633Sdfr 41177633Sdfr /* Retry the transaction if it failed because it conflicted with 42177633Sdfr * someone else: */ 43177633Sdfr b begin_move_money 44177633Sdfr 45177633Sdfr 46177633SdfrThe 'tbegin' instruction denotes the start point, and 'tend' the end point. 47177633SdfrBetween these points the processor is in 'Transactional' state; any memory 48177633Sdfrreferences will complete in one go if there are no conflicts with other 49177633Sdfrtransactional or non-transactional accesses within the system. In this 50193650Srwatsonexample, the transaction completes as though it were normal straight-line code 51177633SdfrIF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an 52177633Sdfratomic move of money from the current account to the savings account has been 53177633Sdfrperformed. Even though the normal ld/std instructions are used (note no 54177633Sdfrlwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be 55184588Sdfrupdated, or neither will be updated. 56184588Sdfr 57184588SdfrIf, in the meantime, there is a conflict with the locations accessed by the 58184588Sdfrtransaction, the transaction will be aborted by the CPU. Register and memory 59184588Sdfrstate will roll back to that at the 'tbegin', and control will continue from 60184588Sdfr'tbegin+4'. The branch to abort_handler will be taken this second time; the 61184588Sdfrabort handler can check the cause of the failure, and retry. 62177633Sdfr 63177633SdfrCheckpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR 64177633Sdfrand a few other status/flag regs; see the ISA for details. 65177633Sdfr 66177633SdfrCauses of transaction aborts 67177633Sdfr============================ 68177633Sdfr 69177633Sdfr- Conflicts with cache lines used by other processors 70177633Sdfr- Signals 71177633Sdfr- Context switches 72177633Sdfr- See the ISA for full documentation of everything that will abort transactions. 73177633Sdfr 74177633Sdfr 75177633SdfrSyscalls 76177633Sdfr======== 77177633Sdfr 78177633SdfrSyscalls made from within an active transaction will not be performed and the 79177633Sdfrtransaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL 80177633Sdfr| TM_CAUSE_PERSISTENT. 81177633Sdfr 82177633SdfrSyscalls made from within a suspended transaction are performed as normal and 83177633Sdfrthe transaction is not explicitly doomed by the kernel. However, what the 84177633Sdfrkernel does to perform the syscall may result in the transaction being doomed 85177633Sdfrby the hardware. The syscall is performed in suspended mode so any side 86177633Sdfreffects will be persistent, independent of transaction success or failure. No 87184588Sdfrguarantees are provided by the kernel about which syscalls will affect 88184588Sdfrtransaction success. 89177633Sdfr 90177633SdfrCare must be taken when relying on syscalls to abort during active transactions 91177633Sdfrif the calls are made via a library. Libraries may cache values (which may 92177633Sdfrgive the appearance of success) or perform operations that cause transaction 93177633Sdfrfailure before entering the kernel (which may produce different failure codes). 94177633SdfrExamples are glibc's getpid() and lazy symbol resolution. 95177633Sdfr 96177633Sdfr 97177633SdfrSignals 98177633Sdfr======= 99177633Sdfr 100184588SdfrDelivery of signals (both sync and async) during transactions provides a second 101184588Sdfrthread state (ucontext/mcontext) to represent the second transactional register 102184588Sdfrstate. Signal delivery 'treclaim's to capture both register states, so signals 103184588Sdfrabort transactions. The usual ucontext_t passed to the signal handler 104184588Sdfrrepresents the checkpointed/original register state; the signal appears to have 105177633Sdfrarisen at 'tbegin+4'. 106177633Sdfr 107177633SdfrIf the sighandler ucontext has uc_link set, a second ucontext has been 108177633Sdfrdelivered. For future compatibility the MSR.TS field should be checked to 109177633Sdfrdetermine the transactional state -- if so, the second ucontext in uc->uc_link 110177633Sdfrrepresents the active transactional registers at the point of the signal. 111177633Sdfr 112184588SdfrFor 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS 113184588Sdfrfield shows the transactional mode. 114184588Sdfr 115184588SdfrFor 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32 116184588Sdfrbits are stored in the MSR of the second ucontext, i.e. in 117184588Sdfruc->uc_link->uc_mcontext.regs->msr. The top word contains the transactional 118184588Sdfrstate TS. 119184588Sdfr 120184588SdfrHowever, basic signal handlers don't need to be aware of transactions 121184588Sdfrand simply returning from the handler will deal with things correctly: 122184588Sdfr 123184588SdfrTransaction-aware signal handlers can read the transactional register state 124184588Sdfrfrom the second ucontext. This will be necessary for crash handlers to 125184588Sdfrdetermine, for example, the address of the instruction causing the SIGSEGV. 126184588Sdfr 127184588SdfrExample signal handler:: 128184588Sdfr 129184588Sdfr void crash_handler(int sig, siginfo_t *si, void *uc) 130184588Sdfr { 131184588Sdfr ucontext_t *ucp = uc; 132184588Sdfr ucontext_t *transactional_ucp = ucp->uc_link; 133184588Sdfr 134184588Sdfr if (ucp_link) { 135184588Sdfr u64 msr = ucp->uc_mcontext.regs->msr; 136184588Sdfr /* May have transactional ucontext! */ 137184588Sdfr #ifndef __powerpc64__ 138184588Sdfr msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32; 139184588Sdfr #endif 140184588Sdfr if (MSR_TM_ACTIVE(msr)) { 141184588Sdfr /* Yes, we crashed during a transaction. Oops. */ 142177633Sdfr fprintf(stderr, "Transaction to be restarted at 0x%llx, but " 143177633Sdfr "crashy instruction was at 0x%llx\n", 144177633Sdfr ucp->uc_mcontext.regs->nip, 145177633Sdfr transactional_ucp->uc_mcontext.regs->nip); 146184588Sdfr } 147184588Sdfr } 148177633Sdfr 149177633Sdfr fix_the_problem(ucp->dar); 150177633Sdfr } 151177633Sdfr 152184588SdfrWhen in an active transaction that takes a signal, we need to be careful with 153184588Sdfrthe stack. It's possible that the stack has moved back up after the tbegin. 154184588SdfrThe obvious case here is when the tbegin is called inside a function that 155177633Sdfrreturns before a tend. In this case, the stack is part of the checkpointed 156184588Sdfrtransactional memory state. If we write over this non transactionally or in 157184588Sdfrsuspend, we are in trouble because if we get a tm abort, the program counter and 158184588Sdfrstack pointer will be back at the tbegin but our in memory stack won't be valid 159184588Sdfranymore. 160184588Sdfr 161184588SdfrTo avoid this, when taking a signal in an active transaction, we need to use 162184588Sdfrthe stack pointer from the checkpointed state, rather than the speculated 163184588Sdfrstate. This ensures that the signal context (written tm suspended) will be 164184588Sdfrwritten below the stack required for the rollback. The transaction is aborted 165184588Sdfrbecause of the treclaim, so any memory written between the tbegin and the 166184588Sdfrsignal will be rolled back anyway. 167184588Sdfr 168194498SbrooksFor signals taken in non-TM or suspended mode, we use the 169177633Sdfrnormal/non-checkpointed stack pointer. 170177633Sdfr 171177633SdfrAny transaction initiated inside a sighandler and suspended on return 172177633Sdfrfrom the sighandler to the kernel will get reclaimed and discarded. 173177633Sdfr 174177633SdfrFailure cause codes used by kernel 175177633Sdfr================================== 176177633Sdfr 177177633SdfrThese are defined in <asm/reg.h>, and distinguish different reasons why the 178184588Sdfrkernel aborted a transaction: 179177633Sdfr 180194498Sbrooks ====================== ================================ 181184588Sdfr TM_CAUSE_RESCHED Thread was rescheduled. 182193650Srwatson TM_CAUSE_TLBI Software TLB invalid. 183193650Srwatson TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap. 184184588Sdfr TM_CAUSE_SYSCALL Syscall from active transaction. 185177633Sdfr TM_CAUSE_SIGNAL Signal delivered. 186177633Sdfr TM_CAUSE_MISC Currently unused. 187184588Sdfr TM_CAUSE_ALIGNMENT Alignment fault. 188184588Sdfr TM_CAUSE_EMULATE Emulation that touched memory. 189184588Sdfr ====================== ================================ 190184588Sdfr 191184588SdfrThese can be checked by the user program's abort handler as TEXASR[0:7]. If 192177633Sdfrbit 7 is set, it indicates that the error is considered persistent. For example 193177633Sdfra TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not. 194177633Sdfr 195177633SdfrGDB 196177633Sdfr=== 197 198GDB and ptrace are not currently TM-aware. If one stops during a transaction, 199it looks like the transaction has just started (the checkpointed state is 200presented). The transaction cannot then be continued and will take the failure 201handler route. Furthermore, the transactional 2nd register state will be 202inaccessible. GDB can currently be used on programs using TM, but not sensibly 203in parts within transactions. 204 205POWER9 206====== 207 208TM on POWER9 has issues with storing the complete register state. This 209is described in this commit:: 210 211 commit 4bb3c7a0208fc13ca70598efd109901a7cd45ae7 212 Author: Paul Mackerras <paulus@ozlabs.org> 213 Date: Wed Mar 21 21:32:01 2018 +1100 214 KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9 215 216To account for this different POWER9 chips have TM enabled in 217different ways. 218 219On POWER9N DD2.01 and below, TM is disabled. ie 220HWCAP2[PPC_FEATURE2_HTM] is not set. 221 222On POWER9N DD2.1 TM is configured by firmware to always abort a 223transaction when tm suspend occurs. So tsuspend will cause a 224transaction to be aborted and rolled back. Kernel exceptions will also 225cause the transaction to be aborted and rolled back and the exception 226will not occur. If userspace constructs a sigcontext that enables TM 227suspend, the sigcontext will be rejected by the kernel. This mode is 228advertised to users with HWCAP2[PPC_FEATURE2_HTM_NO_SUSPEND] set. 229HWCAP2[PPC_FEATURE2_HTM] is not set in this mode. 230 231On POWER9N DD2.2 and above, KVM and POWERVM emulate TM for guests (as 232described in commit 4bb3c7a0208f), hence TM is enabled for guests 233ie. HWCAP2[PPC_FEATURE2_HTM] is set for guest userspace. Guests that 234makes heavy use of TM suspend (tsuspend or kernel suspend) will result 235in traps into the hypervisor and hence will suffer a performance 236degradation. Host userspace has TM disabled 237ie. HWCAP2[PPC_FEATURE2_HTM] is not set. (although we make enable it 238at some point in the future if we bring the emulation into host 239userspace context switching). 240 241POWER9C DD1.2 and above are only available with POWERVM and hence 242Linux only runs as a guest. On these systems TM is emulated like on 243POWER9N DD2.2. 244 245Guest migration from POWER8 to POWER9 will work with POWER9N DD2.2 and 246POWER9C DD1.2. Since earlier POWER9 processors don't support TM 247emulation, migration from POWER8 to POWER9 is not supported there. 248 249Kernel implementation 250===================== 251 252h/rfid mtmsrd quirk 253------------------- 254 255As defined in the ISA, rfid has a quirk which is useful in early 256exception handling. When in a userspace transaction and we enter the 257kernel via some exception, MSR will end up as TM=0 and TS=01 (ie. TM 258off but TM suspended). Regularly the kernel will want change bits in 259the MSR and will perform an rfid to do this. In this case rfid can 260have SRR0 TM = 0 and TS = 00 (ie. TM off and non transaction) and the 261resulting MSR will retain TM = 0 and TS=01 from before (ie. stay in 262suspend). This is a quirk in the architecture as this would normally 263be a transition from TS=01 to TS=00 (ie. suspend -> non transactional) 264which is an illegal transition. 265 266This quirk is described the architecture in the definition of rfid 267with these lines: 268 269 if (MSR 29:31 �� = 0b010 | SRR1 29:31 �� = 0b000) then 270 MSR 29:31 <- SRR1 29:31 271 272hrfid and mtmsrd have the same quirk. 273 274The Linux kernel uses this quirk in its early exception handling. 275