^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Transactional Memory support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) POWER kernel support for this feature is currently limited to supporting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) its use by user programs. It is not currently used by the kernel itself.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) This file aims to sum up how it is supported by Linux and what behaviour you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) can expect from your user programs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) Basic overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) Hardware Transactional Memory is supported on POWER8 processors, and is a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) feature that enables a different form of atomic memory access. Several new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) instructions are presented to delimit transactions; transactions are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) guaranteed to either complete atomically or roll back and undo any partial
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) changes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) A simple transaction looks like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) begin_move_money:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) tbegin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) beq abort_handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) ld r4, SAVINGS_ACCT(r3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) ld r5, CURRENT_ACCT(r3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) subi r5, r5, 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) addi r4, r4, 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) std r4, SAVINGS_ACCT(r3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) std r5, CURRENT_ACCT(r3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) tend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) b continue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) abort_handler:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) ... test for odd failures ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) /* Retry the transaction if it failed because it conflicted with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) * someone else: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) b begin_move_money
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) The 'tbegin' instruction denotes the start point, and 'tend' the end point.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) Between these points the processor is in 'Transactional' state; any memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) references will complete in one go if there are no conflicts with other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) transactional or non-transactional accesses within the system. In this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) example, the transaction completes as though it were normal straight-line code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) atomic move of money from the current account to the savings account has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) performed. Even though the normal ld/std instructions are used (note no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) updated, or neither will be updated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) If, in the meantime, there is a conflict with the locations accessed by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) transaction, the transaction will be aborted by the CPU. Register and memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) state will roll back to that at the 'tbegin', and control will continue from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) 'tbegin+4'. The branch to abort_handler will be taken this second time; the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) abort handler can check the cause of the failure, and retry.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) and a few other status/flag regs; see the ISA for details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) Causes of transaction aborts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) - Conflicts with cache lines used by other processors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) - Signals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) - Context switches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) - See the ISA for full documentation of everything that will abort transactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) Syscalls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) ========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) Syscalls made from within an active transaction will not be performed and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) | TM_CAUSE_PERSISTENT.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) Syscalls made from within a suspended transaction are performed as normal and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) the transaction is not explicitly doomed by the kernel. However, what the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) kernel does to perform the syscall may result in the transaction being doomed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) by the hardware. The syscall is performed in suspended mode so any side
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) effects will be persistent, independent of transaction success or failure. No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) guarantees are provided by the kernel about which syscalls will affect
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) transaction success.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) Care must be taken when relying on syscalls to abort during active transactions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) if the calls are made via a library. Libraries may cache values (which may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) give the appearance of success) or perform operations that cause transaction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) failure before entering the kernel (which may produce different failure codes).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) Examples are glibc's getpid() and lazy symbol resolution.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) Signals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) Delivery of signals (both sync and async) during transactions provides a second
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) thread state (ucontext/mcontext) to represent the second transactional register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) state. Signal delivery 'treclaim's to capture both register states, so signals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) abort transactions. The usual ucontext_t passed to the signal handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) represents the checkpointed/original register state; the signal appears to have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) arisen at 'tbegin+4'.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) If the sighandler ucontext has uc_link set, a second ucontext has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) delivered. For future compatibility the MSR.TS field should be checked to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) determine the transactional state -- if so, the second ucontext in uc->uc_link
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) represents the active transactional registers at the point of the signal.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) field shows the transactional mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) bits are stored in the MSR of the second ucontext, i.e. in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) uc->uc_link->uc_mcontext.regs->msr. The top word contains the transactional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) state TS.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) However, basic signal handlers don't need to be aware of transactions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) and simply returning from the handler will deal with things correctly:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) Transaction-aware signal handlers can read the transactional register state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) from the second ucontext. This will be necessary for crash handlers to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) determine, for example, the address of the instruction causing the SIGSEGV.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) Example signal handler::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) void crash_handler(int sig, siginfo_t *si, void *uc)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) ucontext_t *ucp = uc;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) ucontext_t *transactional_ucp = ucp->uc_link;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) if (ucp_link) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) u64 msr = ucp->uc_mcontext.regs->msr;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) /* May have transactional ucontext! */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) #ifndef __powerpc64__
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) #endif
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) if (MSR_TM_ACTIVE(msr)) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) /* Yes, we crashed during a transaction. Oops. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) "crashy instruction was at 0x%llx\n",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) ucp->uc_mcontext.regs->nip,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) transactional_ucp->uc_mcontext.regs->nip);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) fix_the_problem(ucp->dar);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) When in an active transaction that takes a signal, we need to be careful with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) the stack. It's possible that the stack has moved back up after the tbegin.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) The obvious case here is when the tbegin is called inside a function that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) returns before a tend. In this case, the stack is part of the checkpointed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) transactional memory state. If we write over this non transactionally or in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) suspend, we are in trouble because if we get a tm abort, the program counter and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) stack pointer will be back at the tbegin but our in memory stack won't be valid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) anymore.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) To avoid this, when taking a signal in an active transaction, we need to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) the stack pointer from the checkpointed state, rather than the speculated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) state. This ensures that the signal context (written tm suspended) will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) written below the stack required for the rollback. The transaction is aborted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) because of the treclaim, so any memory written between the tbegin and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) signal will be rolled back anyway.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) For signals taken in non-TM or suspended mode, we use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) normal/non-checkpointed stack pointer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) Any transaction initiated inside a sighandler and suspended on return
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) from the sighandler to the kernel will get reclaimed and discarded.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) Failure cause codes used by kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) These are defined in <asm/reg.h>, and distinguish different reasons why the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) kernel aborted a transaction:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) ====================== ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) TM_CAUSE_RESCHED Thread was rescheduled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) TM_CAUSE_TLBI Software TLB invalid.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) TM_CAUSE_SYSCALL Syscall from active transaction.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) TM_CAUSE_SIGNAL Signal delivered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) TM_CAUSE_MISC Currently unused.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) TM_CAUSE_ALIGNMENT Alignment fault.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) TM_CAUSE_EMULATE Emulation that touched memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) ====================== ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) These can be checked by the user program's abort handler as TEXASR[0:7]. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) bit 7 is set, it indicates that the error is consider persistent. For example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) GDB
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) ===
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) GDB and ptrace are not currently TM-aware. If one stops during a transaction,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) it looks like the transaction has just started (the checkpointed state is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) presented). The transaction cannot then be continued and will take the failure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) handler route. Furthermore, the transactional 2nd register state will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) inaccessible. GDB can currently be used on programs using TM, but not sensibly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) in parts within transactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) POWER9
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) ======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) TM on POWER9 has issues with storing the complete register state. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) is described in this commit::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) commit 4bb3c7a0208fc13ca70598efd109901a7cd45ae7
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) Author: Paul Mackerras <paulus@ozlabs.org>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) Date: Wed Mar 21 21:32:01 2018 +1100
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) To account for this different POWER9 chips have TM enabled in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) different ways.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) On POWER9N DD2.01 and below, TM is disabled. ie
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) HWCAP2[PPC_FEATURE2_HTM] is not set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) On POWER9N DD2.1 TM is configured by firmware to always abort a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) transaction when tm suspend occurs. So tsuspend will cause a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) transaction to be aborted and rolled back. Kernel exceptions will also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) cause the transaction to be aborted and rolled back and the exception
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) will not occur. If userspace constructs a sigcontext that enables TM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) suspend, the sigcontext will be rejected by the kernel. This mode is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) advertised to users with HWCAP2[PPC_FEATURE2_HTM_NO_SUSPEND] set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) HWCAP2[PPC_FEATURE2_HTM] is not set in this mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) On POWER9N DD2.2 and above, KVM and POWERVM emulate TM for guests (as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) described in commit 4bb3c7a0208f), hence TM is enabled for guests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) ie. HWCAP2[PPC_FEATURE2_HTM] is set for guest userspace. Guests that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) makes heavy use of TM suspend (tsuspend or kernel suspend) will result
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) in traps into the hypervisor and hence will suffer a performance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) degradation. Host userspace has TM disabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) ie. HWCAP2[PPC_FEATURE2_HTM] is not set. (although we make enable it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) at some point in the future if we bring the emulation into host
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) userspace context switching).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) POWER9C DD1.2 and above are only available with POWERVM and hence
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) Linux only runs as a guest. On these systems TM is emulated like on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) POWER9N DD2.2.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) Guest migration from POWER8 to POWER9 will work with POWER9N DD2.2 and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) POWER9C DD1.2. Since earlier POWER9 processors don't support TM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) emulation, migration from POWER8 to POWER9 is not supported there.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) Kernel implementation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) h/rfid mtmsrd quirk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) As defined in the ISA, rfid has a quirk which is useful in early
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) exception handling. When in a userspace transaction and we enter the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) kernel via some exception, MSR will end up as TM=0 and TS=01 (ie. TM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) off but TM suspended). Regularly the kernel will want change bits in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) the MSR and will perform an rfid to do this. In this case rfid can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) have SRR0 TM = 0 and TS = 00 (ie. TM off and non transaction) and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) resulting MSR will retain TM = 0 and TS=01 from before (ie. stay in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) suspend). This is a quirk in the architecture as this would normally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) be a transition from TS=01 to TS=00 (ie. suspend -> non transactional)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) which is an illegal transition.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) This quirk is described the architecture in the definition of rfid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) with these lines:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) if (MSR 29:31 ¬ = 0b010 | SRR1 29:31 ¬ = 0b000) then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) MSR 29:31 <- SRR1 29:31
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) hrfid and mtmsrd have the same quirk.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) The Linux kernel uses this quirk in it's early exception handling.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags