1=============================================== 2Power Architecture 64-bit Linux system call ABI 3=============================================== 4 5syscall 6======= 7 8Invocation 9---------- 10The syscall is made with the sc instruction, and returns with execution 11continuing at the instruction following the sc instruction. 12 13If PPC_FEATURE2_SCV appears in the AT_HWCAP2 ELF auxiliary vector, the 14scv 0 instruction is an alternative that may provide better performance, 15with some differences to calling sequence. 16 17syscall calling sequence\ [1]_ matches the Power Architecture 64-bit ELF ABI 18specification C function calling sequence, including register preservation 19rules, with the following differences. 20 21.. [1] Some syscalls (typically low-level management functions) may have 22 different calling sequences (e.g., rt_sigreturn). 23 24Parameters 25---------- 26The system call number is specified in r0. 27 28There is a maximum of 6 integer parameters to a syscall, passed in r3-r8. 29 30Return value 31------------ 32- For the sc instruction, both a value and an error condition are returned. 33 cr0.SO is the error condition, and r3 is the return value. When cr0.SO is 34 clear, the syscall succeeded and r3 is the return value. When cr0.SO is set, 35 the syscall failed and r3 is the error value (that normally corresponds to 36 errno). 37 38- For the scv 0 instruction, the return value indicates failure if it is 39 -4095..-1 (i.e., it is >= -MAX_ERRNO (-4095) as an unsigned comparison), 40 in which case the error value is the negated return value. 41 42Stack 43----- 44System calls do not modify the caller's stack frame. For example, the caller's 45stack frame LR and CR save fields are not used. 46 47Register preservation rules 48--------------------------- 49Register preservation rules match the ELF ABI calling sequence with the 50following differences: 51 52+------------------------------------------------------------------------+ 53| For the sc instruction, differences with the ELF ABI | 54+--------------+--------------+------------------------------------------+ 55| r0 | Volatile | (System call number.) | 56| rr3 | Volatile | (Parameter 1, and return value.) | 57| rr4-r8 | Volatile | (Parameters 2-6.) | 58| rcr0 | Volatile | (cr0.SO is the return error condition.) | 59| rcr1, cr5-7 | Nonvolatile | | 60| rlr | Nonvolatile | | 61+--------------+--------------+------------------------------------------+ 62| For the scv 0 instruction, differences with the ELF ABI | 63+--------------+--------------+------------------------------------------+ 64| r0 | Volatile | (System call number.) | 65| r3 | Volatile | (Parameter 1, and return value.) | 66| r4-r8 | Volatile | (Parameters 2-6.) | 67+--------------+--------------+------------------------------------------+ 68 69All floating point and vector data registers as well as control and status 70registers are nonvolatile. 71 72Transactional Memory 73-------------------- 74Syscall behavior can change if the processor is in transactional or suspended 75transaction state, and the syscall can affect the behavior of the transaction. 76 77If the processor is in suspended state when a syscall is made, the syscall 78will be performed as normal, and will return as normal. The syscall will be 79performed in suspended state, so its side effects will be persistent according 80to the usual transactional memory semantics. A syscall may or may not result 81in the transaction being doomed by hardware. 82 83If the processor is in transactional state when a syscall is made, then the 84behavior depends on the presence of PPC_FEATURE2_HTM_NOSC in the AT_HWCAP2 ELF 85auxiliary vector. 86 87- If present, which is the case for newer kernels, then the syscall will not 88 be performed and the transaction will be doomed by the kernel with the 89 failure code TM_CAUSE_SYSCALL | TM_CAUSE_PERSISTENT in the TEXASR SPR. 90 91- If not present (older kernels), then the kernel will suspend the 92 transactional state and the syscall will proceed as in the case of a 93 suspended state syscall, and will resume the transactional state before 94 returning to the caller. This case is not well defined or supported, so this 95 behavior should not be relied upon. 96 97scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC. 98 99ptrace 100------ 101When ptracing system calls (PTRACE_SYSCALL), the pt_regs.trap value contains 102the system call type that can be used to distinguish between sc and scv 0 103system calls, and the different register conventions can be accounted for. 104 105If the value of (pt_regs.trap & 0xfff0) is 0xc00 then the system call was 106performed with the sc instruction, if it is 0x3000 then the system call was 107performed with the scv 0 instruction. 108 109vsyscall 110======== 111 112vsyscall calling sequence matches the syscall calling sequence, with the 113following differences. Some vsyscalls may have different calling sequences. 114 115Parameters and return value 116--------------------------- 117r0 is not used as an input. The vsyscall is selected by its address. 118 119Stack 120----- 121The vsyscall may or may not use the caller's stack frame save areas. 122 123Register preservation rules 124--------------------------- 125 126=========== ======== 127r0 Volatile 128cr1, cr5-7 Volatile 129lr Volatile 130=========== ======== 131 132Invocation 133---------- 134The vsyscall is performed with a branch-with-link instruction to the vsyscall 135function address. 136 137Transactional Memory 138-------------------- 139vsyscalls will run in the same transactional state as the caller. A vsyscall 140may or may not result in the transaction being doomed by hardware. 141