Lines Matching +full:back +full:- +full:to +full:- +full:back
5 POWER kernel support for this feature is currently limited to supporting
8 This file aims to sum up how it is supported by Linux and what behaviour you
17 instructions are presented to delimit transactions; transactions are
18 guaranteed to either complete atomically or roll back and undo any partial
49 transactional or non-transactional accesses within the system. In this
50 example, the transaction completes as though it were normal straight-line code
52 atomic move of money from the current account to the savings account has been
59 state will roll back to that at the 'tbegin', and control will continue from
60 'tbegin+4'. The branch to abort_handler will be taken this second time; the
69 - Conflicts with cache lines used by other processors
70 - Signals
71 - Context switches
72 - See the ISA for full documentation of everything that will abort transactions.
84 kernel does to perform the syscall may result in the transaction being doomed
90 Care must be taken when relying on syscalls to abort during active transactions
101 thread state (ucontext/mcontext) to represent the second transactional register
102 state. Signal delivery 'treclaim's to capture both register states, so signals
103 abort transactions. The usual ucontext_t passed to the signal handler
104 represents the checkpointed/original register state; the signal appears to have
108 delivered. For future compatibility the MSR.TS field should be checked to
109 determine the transactional state -- if so, the second ucontext in uc->uc_link
112 For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
115 For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
117 uc->uc_link->uc_mcontext.regs->msr. The top word contains the transactional
120 However, basic signal handlers don't need to be aware of transactions
123 Transaction-aware signal handlers can read the transactional register state
124 from the second ucontext. This will be necessary for crash handlers to
132 ucontext_t *transactional_ucp = ucp->uc_link;
135 u64 msr = ucp->uc_mcontext.regs->msr;
138 msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
142 fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
144 ucp->uc_mcontext.regs->nip,
145 transactional_ucp->uc_mcontext.regs->nip);
149 fix_the_problem(ucp->dar);
152 When in an active transaction that takes a signal, we need to be careful with
153 the stack. It's possible that the stack has moved back up after the tbegin.
158 stack pointer will be back at the tbegin but our in memory stack won't be valid
161 To avoid this, when taking a signal in an active transaction, we need to use
166 signal will be rolled back anyway.
168 For signals taken in non-TM or suspended mode, we use the
169 normal/non-checkpointed stack pointer.
172 from the sighandler to the kernel will get reclaimed and discarded.
198 GDB and ptrace are not currently TM-aware. If one stops during a transaction,
216 To account for this different POWER9 chips have TM enabled in
222 On POWER9N DD2.1 TM is configured by firmware to always abort a
224 transaction to be aborted and rolled back. Kernel exceptions will also
225 cause the transaction to be aborted and rolled back and the exception
228 advertised to users with HWCAP2[PPC_FEATURE2_HTM_NO_SUSPEND] set.
245 Guest migration from POWER8 to POWER9 will work with POWER9N DD2.2 and
247 emulation, migration from POWER8 to POWER9 is not supported there.
253 -------------------
259 the MSR and will perform an rfid to do this. In this case rfid can
263 be a transition from TS=01 to TS=00 (ie. suspend -> non transactional)
270 MSR 29:31 <- SRR1 29:31