2013-02-14 00:21:45 +08:00
|
|
|
Transactional Memory support
|
|
|
|
============================
|
|
|
|
|
|
|
|
POWER kernel support for this feature is currently limited to supporting
|
|
|
|
its use by user programs. It is not currently used by the kernel itself.
|
|
|
|
|
|
|
|
This file aims to sum up how it is supported by Linux and what behaviour you
|
|
|
|
can expect from your user programs.
|
|
|
|
|
|
|
|
|
|
|
|
Basic overview
|
|
|
|
==============
|
|
|
|
|
|
|
|
Hardware Transactional Memory is supported on POWER8 processors, and is a
|
|
|
|
feature that enables a different form of atomic memory access. Several new
|
|
|
|
instructions are presented to delimit transactions; transactions are
|
|
|
|
guaranteed to either complete atomically or roll back and undo any partial
|
|
|
|
changes.
|
|
|
|
|
|
|
|
A simple transaction looks like this:
|
|
|
|
|
|
|
|
begin_move_money:
|
|
|
|
tbegin
|
|
|
|
beq abort_handler
|
|
|
|
|
|
|
|
ld r4, SAVINGS_ACCT(r3)
|
|
|
|
ld r5, CURRENT_ACCT(r3)
|
|
|
|
subi r5, r5, 1
|
|
|
|
addi r4, r4, 1
|
|
|
|
std r4, SAVINGS_ACCT(r3)
|
|
|
|
std r5, CURRENT_ACCT(r3)
|
|
|
|
|
|
|
|
tend
|
|
|
|
|
|
|
|
b continue
|
|
|
|
|
|
|
|
abort_handler:
|
|
|
|
... test for odd failures ...
|
|
|
|
|
|
|
|
/* Retry the transaction if it failed because it conflicted with
|
|
|
|
* someone else: */
|
|
|
|
b begin_move_money
|
|
|
|
|
|
|
|
|
|
|
|
The 'tbegin' instruction denotes the start point, and 'tend' the end point.
|
|
|
|
Between these points the processor is in 'Transactional' state; any memory
|
|
|
|
references will complete in one go if there are no conflicts with other
|
|
|
|
transactional or non-transactional accesses within the system. In this
|
|
|
|
example, the transaction completes as though it were normal straight-line code
|
|
|
|
IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
|
|
|
|
atomic move of money from the current account to the savings account has been
|
|
|
|
performed. Even though the normal ld/std instructions are used (note no
|
|
|
|
lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
|
|
|
|
updated, or neither will be updated.
|
|
|
|
|
|
|
|
If, in the meantime, there is a conflict with the locations accessed by the
|
|
|
|
transaction, the transaction will be aborted by the CPU. Register and memory
|
|
|
|
state will roll back to that at the 'tbegin', and control will continue from
|
|
|
|
'tbegin+4'. The branch to abort_handler will be taken this second time; the
|
|
|
|
abort handler can check the cause of the failure, and retry.
|
|
|
|
|
|
|
|
Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
|
|
|
|
and a few other status/flag regs; see the ISA for details.
|
|
|
|
|
|
|
|
Causes of transaction aborts
|
|
|
|
============================
|
|
|
|
|
|
|
|
- Conflicts with cache lines used by other processors
|
|
|
|
- Signals
|
|
|
|
- Context switches
|
|
|
|
- See the ISA for full documentation of everything that will abort transactions.
|
|
|
|
|
|
|
|
|
|
|
|
Syscalls
|
|
|
|
========
|
|
|
|
|
2015-06-12 09:06:32 +08:00
|
|
|
Syscalls made from within an active transaction will not be performed and the
|
|
|
|
transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL
|
|
|
|
| TM_CAUSE_PERSISTENT.
|
2013-02-14 00:21:45 +08:00
|
|
|
|
2015-06-12 09:06:32 +08:00
|
|
|
Syscalls made from within a suspended transaction are performed as normal and
|
|
|
|
the transaction is not explicitly doomed by the kernel. However, what the
|
|
|
|
kernel does to perform the syscall may result in the transaction being doomed
|
|
|
|
by the hardware. The syscall is performed in suspended mode so any side
|
|
|
|
effects will be persistent, independent of transaction success or failure. No
|
|
|
|
guarantees are provided by the kernel about which syscalls will affect
|
|
|
|
transaction success.
|
2013-02-14 00:21:45 +08:00
|
|
|
|
2015-06-12 09:06:32 +08:00
|
|
|
Care must be taken when relying on syscalls to abort during active transactions
|
|
|
|
if the calls are made via a library. Libraries may cache values (which may
|
|
|
|
give the appearance of success) or perform operations that cause transaction
|
|
|
|
failure before entering the kernel (which may produce different failure codes).
|
|
|
|
Examples are glibc's getpid() and lazy symbol resolution.
|
2013-02-14 00:21:45 +08:00
|
|
|
|
|
|
|
|
|
|
|
Signals
|
|
|
|
=======
|
|
|
|
|
|
|
|
Delivery of signals (both sync and async) during transactions provides a second
|
|
|
|
thread state (ucontext/mcontext) to represent the second transactional register
|
|
|
|
state. Signal delivery 'treclaim's to capture both register states, so signals
|
|
|
|
abort transactions. The usual ucontext_t passed to the signal handler
|
|
|
|
represents the checkpointed/original register state; the signal appears to have
|
|
|
|
arisen at 'tbegin+4'.
|
|
|
|
|
|
|
|
If the sighandler ucontext has uc_link set, a second ucontext has been
|
|
|
|
delivered. For future compatibility the MSR.TS field should be checked to
|
|
|
|
determine the transactional state -- if so, the second ucontext in uc->uc_link
|
|
|
|
represents the active transactional registers at the point of the signal.
|
|
|
|
|
|
|
|
For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
|
|
|
|
field shows the transactional mode.
|
|
|
|
|
|
|
|
For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
|
|
|
|
bits are stored in the MSR of the second ucontext, i.e. in
|
|
|
|
uc->uc_link->uc_mcontext.regs->msr. The top word contains the transactional
|
|
|
|
state TS.
|
|
|
|
|
|
|
|
However, basic signal handlers don't need to be aware of transactions
|
|
|
|
and simply returning from the handler will deal with things correctly:
|
|
|
|
|
|
|
|
Transaction-aware signal handlers can read the transactional register state
|
|
|
|
from the second ucontext. This will be necessary for crash handlers to
|
|
|
|
determine, for example, the address of the instruction causing the SIGSEGV.
|
|
|
|
|
|
|
|
Example signal handler:
|
|
|
|
|
|
|
|
void crash_handler(int sig, siginfo_t *si, void *uc)
|
|
|
|
{
|
|
|
|
ucontext_t *ucp = uc;
|
|
|
|
ucontext_t *transactional_ucp = ucp->uc_link;
|
|
|
|
|
|
|
|
if (ucp_link) {
|
|
|
|
u64 msr = ucp->uc_mcontext.regs->msr;
|
|
|
|
/* May have transactional ucontext! */
|
|
|
|
#ifndef __powerpc64__
|
|
|
|
msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
|
|
|
|
#endif
|
|
|
|
if (MSR_TM_ACTIVE(msr)) {
|
|
|
|
/* Yes, we crashed during a transaction. Oops. */
|
|
|
|
fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
|
|
|
|
"crashy instruction was at 0x%llx\n",
|
|
|
|
ucp->uc_mcontext.regs->nip,
|
|
|
|
transactional_ucp->uc_mcontext.regs->nip);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fix_the_problem(ucp->dar);
|
|
|
|
}
|
|
|
|
|
2013-05-27 02:09:41 +08:00
|
|
|
When in an active transaction that takes a signal, we need to be careful with
|
|
|
|
the stack. It's possible that the stack has moved back up after the tbegin.
|
|
|
|
The obvious case here is when the tbegin is called inside a function that
|
|
|
|
returns before a tend. In this case, the stack is part of the checkpointed
|
|
|
|
transactional memory state. If we write over this non transactionally or in
|
|
|
|
suspend, we are in trouble because if we get a tm abort, the program counter and
|
|
|
|
stack pointer will be back at the tbegin but our in memory stack won't be valid
|
|
|
|
anymore.
|
|
|
|
|
|
|
|
To avoid this, when taking a signal in an active transaction, we need to use
|
|
|
|
the stack pointer from the checkpointed state, rather than the speculated
|
|
|
|
state. This ensures that the signal context (written tm suspended) will be
|
|
|
|
written below the stack required for the rollback. The transaction is aborted
|
2014-04-05 10:31:00 +08:00
|
|
|
because of the treclaim, so any memory written between the tbegin and the
|
2013-05-27 02:09:41 +08:00
|
|
|
signal will be rolled back anyway.
|
|
|
|
|
|
|
|
For signals taken in non-TM or suspended mode, we use the
|
|
|
|
normal/non-checkpointed stack pointer.
|
|
|
|
|
powerpc: signals: Discard transaction state from signal frames
Userspace can begin and suspend a transaction within the signal
handler which means they might enter sys_rt_sigreturn() with the
processor in suspended state.
sys_rt_sigreturn() wants to restore process context (which may have
been in a transaction before signal delivery). To do this it must
restore TM SPRS. To achieve this, any transaction initiated within the
signal frame must be discarded in order to be able to restore TM SPRs
as TM SPRs can only be manipulated non-transactionally..
>From the PowerPC ISA:
TM Bad Thing Exception [Category: Transactional Memory]
An attempt is made to execute a mtspr targeting a TM register in
other than Non-transactional state.
Not doing so results in a TM Bad Thing:
[12045.221359] Kernel BUG at c000000000050a40 [verbose debug info unavailable]
[12045.221470] Unexpected TM Bad Thing exception at c000000000050a40 (msr 0x201033)
[12045.221540] Oops: Unrecoverable exception, sig: 6 [#1]
[12045.221586] SMP NR_CPUS=2048 NUMA PowerNV
[12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter
ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv kvm
uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses enclosure
scsi_transport_sas bnx2x ipr mdio libcrc32c
[12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 #34
[12045.222224] task: c0000000fce38600 ti: c0000000fceb4000 task.ti: c0000000fceb4000
[12045.222293] NIP: c000000000050a40 LR: c0000000000163bc CTR: 0000000000000000
[12045.222361] REGS: c0000000fceb7ac0 TRAP: 0700 Not tainted (4.7.0)
[12045.222418] MSR: 9000000300201033 <SF,HV,ME,IR,DR,RI,LE,TM[SE]> CR: 28444280 XER: 20000000
[12045.222625] CFAR: c0000000000163b8 SOFTE: 0 PACATMSCRATCH: 900000014280f033
GPR00: 01100000b8000001 c0000000fceb7d40 c00000000139c100 c0000000fce390d0
GPR04: 900000034280f033 0000000000000000 0000000000000000 0000000000000000
GPR08: 0000000000000000 b000000000001033 0000000000000001 0000000000000000
GPR12: 0000000000000000 c000000002926400 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 00003ffff98cadd0 00003ffff98cb470 0000000000000000
GPR28: 900000034280f033 c0000000fceb7ea0 0000000000000001 c0000000fce390d0
[12045.223535] NIP [c000000000050a40] tm_restore_sprs+0xc/0x1c
[12045.223584] LR [c0000000000163bc] tm_recheckpoint+0x5c/0xa0
[12045.223630] Call Trace:
[12045.223655] [c0000000fceb7d80] [c000000000026e74] sys_rt_sigreturn+0x494/0x6c0
[12045.223738] [c0000000fceb7e30] [c0000000000092e0] system_call+0x38/0x108
[12045.223806] Instruction dump:
[12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
[12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
[12045.224074] ---[ end trace cb8002ee240bae76 ]---
It isn't clear exactly if there is really a use case for userspace
returning with a suspended transaction, however, doing so doesn't (on
its own) constitute a bad frame. As such, this patch simply discards
the transactional state of the context calling the sigreturn and
continues.
Reported-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Acked-by: Simon Guo <wei.guo.simon@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2016-08-23 08:46:17 +08:00
|
|
|
Any transaction initiated inside a sighandler and suspended on return
|
|
|
|
from the sighandler to the kernel will get reclaimed and discarded.
|
2013-02-14 00:21:45 +08:00
|
|
|
|
|
|
|
Failure cause codes used by kernel
|
|
|
|
==================================
|
|
|
|
|
|
|
|
These are defined in <asm/reg.h>, and distinguish different reasons why the
|
|
|
|
kernel aborted a transaction:
|
|
|
|
|
|
|
|
TM_CAUSE_RESCHED Thread was rescheduled.
|
2015-04-10 12:16:50 +08:00
|
|
|
TM_CAUSE_TLBI Software TLB invalid.
|
2013-02-14 00:21:45 +08:00
|
|
|
TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap.
|
2015-06-12 09:06:32 +08:00
|
|
|
TM_CAUSE_SYSCALL Syscall from active transaction.
|
2013-02-14 00:21:45 +08:00
|
|
|
TM_CAUSE_SIGNAL Signal delivered.
|
|
|
|
TM_CAUSE_MISC Currently unused.
|
2013-05-27 02:09:39 +08:00
|
|
|
TM_CAUSE_ALIGNMENT Alignment fault.
|
|
|
|
TM_CAUSE_EMULATE Emulation that touched memory.
|
2013-02-14 00:21:45 +08:00
|
|
|
|
2013-05-27 02:09:39 +08:00
|
|
|
These can be checked by the user program's abort handler as TEXASR[0:7]. If
|
|
|
|
bit 7 is set, it indicates that the error is consider persistent. For example
|
2015-04-10 12:16:50 +08:00
|
|
|
a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.
|
2013-02-14 00:21:45 +08:00
|
|
|
|
|
|
|
GDB
|
|
|
|
===
|
|
|
|
|
|
|
|
GDB and ptrace are not currently TM-aware. If one stops during a transaction,
|
|
|
|
it looks like the transaction has just started (the checkpointed state is
|
|
|
|
presented). The transaction cannot then be continued and will take the failure
|
|
|
|
handler route. Furthermore, the transactional 2nd register state will be
|
|
|
|
inaccessible. GDB can currently be used on programs using TM, but not sensibly
|
|
|
|
in parts within transactions.
|
2018-06-25 09:34:56 +08:00
|
|
|
|
|
|
|
POWER9
|
|
|
|
======
|
|
|
|
|
|
|
|
TM on POWER9 has issues with storing the complete register state. This
|
|
|
|
is described in this commit:
|
|
|
|
|
|
|
|
commit 4bb3c7a0208fc13ca70598efd109901a7cd45ae7
|
|
|
|
Author: Paul Mackerras <paulus@ozlabs.org>
|
|
|
|
Date: Wed Mar 21 21:32:01 2018 +1100
|
|
|
|
KVM: PPC: Book3S HV: Work around transactional memory bugs in POWER9
|
|
|
|
|
|
|
|
To account for this different POWER9 chips have TM enabled in
|
|
|
|
different ways.
|
|
|
|
|
|
|
|
On POWER9N DD2.01 and below, TM is disabled. ie
|
|
|
|
HWCAP2[PPC_FEATURE2_HTM] is not set.
|
|
|
|
|
|
|
|
On POWER9N DD2.1 TM is configured by firmware to always abort a
|
|
|
|
transaction when tm suspend occurs. So tsuspend will cause a
|
|
|
|
transaction to be aborted and rolled back. Kernel exceptions will also
|
|
|
|
cause the transaction to be aborted and rolled back and the exception
|
|
|
|
will not occur. If userspace constructs a sigcontext that enables TM
|
|
|
|
suspend, the sigcontext will be rejected by the kernel. This mode is
|
|
|
|
advertised to users with HWCAP2[PPC_FEATURE2_HTM_NO_SUSPEND] set.
|
|
|
|
HWCAP2[PPC_FEATURE2_HTM] is not set in this mode.
|
|
|
|
|
|
|
|
On POWER9N DD2.2 and above, KVM and POWERVM emulate TM for guests (as
|
|
|
|
described in commit 4bb3c7a0208f), hence TM is enabled for guests
|
|
|
|
ie. HWCAP2[PPC_FEATURE2_HTM] is set for guest userspace. Guests that
|
|
|
|
makes heavy use of TM suspend (tsuspend or kernel suspend) will result
|
|
|
|
in traps into the hypervisor and hence will suffer a performance
|
|
|
|
degradation. Host userspace has TM disabled
|
|
|
|
ie. HWCAP2[PPC_FEATURE2_HTM] is not set. (although we make enable it
|
|
|
|
at some point in the future if we bring the emulation into host
|
|
|
|
userspace context switching).
|
|
|
|
|
|
|
|
POWER9C DD1.2 and above are only available with POWERVM and hence
|
|
|
|
Linux only runs as a guest. On these systems TM is emulated like on
|
|
|
|
POWER9N DD2.2.
|
|
|
|
|
|
|
|
Guest migration from POWER8 to POWER9 will work with POWER9N DD2.2 and
|
|
|
|
POWER9C DD1.2. Since earlier POWER9 processors don't support TM
|
|
|
|
emulation, migration from POWER8 to POWER9 is not supported there.
|