[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200611081203.995112-1-npiggin@gmail.com>
Date: Thu, 11 Jun 2020 18:12:01 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: linuxppc-dev@...ts.ozlabs.org
Cc: Nicholas Piggin <npiggin@...il.com>,
musl@...ts.openwall.com,
libc-dev@...ts.llvm.org,
linux-api@...r.kernel.org
Subject: Linux powerpc new system call instruction and ABI
Thanks to everyone who has given feedback on the proposed new system
call instruction and ABI, I think it has reached agreement and the
implementation can be merged into Linux.
I have a hacked glibc implementation (that doesn't do all the right
HWCAP detection and misses a few things) that I've tested several things
including some kernel selftests (involving signals and syscalls) with.
System Call Vectored (scv) ABI
==============================
The scv instruction is introduced with POWER9 / ISA3, it comes with an
rfscv counter-part. The benefit of these instructions is performance
(trading slower SRR0/1 with faster LR/CTR registers, and entering the
kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
updates. The scv instruction has 128 levels (not enough to cover the Linux
system call space).
Assignment and advertisement
----------------------------
The proposal is to assign scv levels conservatively, and advertise them
with HWCAP feature bits as we add support for more.
Linux has not enabled FSCR[SCV] yet, so executing the scv instruction will
cause the kernel to log a "SCV facility unavilable" message, and deliver a
SIGILL with ILL_ILLOPC to the process. Linux has defined a HWCAP2 bit
PPC_FEATURE2_SCV for SCV support, but does not set it.
This change allocates the zero level ('scv 0'), advertised with
PPC_FEATURE2_SCV, which will be used to provide normal Linux system
calls (equivalent to 'sc').
Attempting to execute scv with other levels will cause a SIGILL to be
delivered the same as before, but will not log a "SCV facility unavailable"
message (because the processor facility is enabled).
Calling convention
------------------
The proposal is for scv 0 to provide the standard Linux system call ABI
with the following differences from sc convention[1]:
- lr is to be volatile across scv calls. This is necessary because the
scv instruction clobbers lr. From previous discussion, this should be
possible to deal with in GCC clobbers and CFI.
- cr1 and cr5-cr7 are volatile. This matches the C ABI and would allow the
kernel system call exit to avoid restoring the volatile cr registers
(although we probably still would anyway to avoid information leaks).
- Error handling: The consensus among kernel, glibc, and musl is to move to
using negative return values in r3 rather than CR0[SO]=1 to indicate error,
which matches most other architectures, and is closer to a function call.
Notes
-----
- r0,r4-r8 are documented as volatile in the ABI, but the kernel patch as
submitted currently preserves them. This is to leave room for deciding
which way to go with these. Some small benefit was found by preserving
them[1] but I'm not convinced it's worth deviating from the C function
call ABI just for this. Release code should follow the ABI.
Previous discussions:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208691.html
https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/209268.html
[1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/209263.html
The following patches to add scv support to Linux are posted to
https://lists.ozlabs.org/pipermail/linuxppc-dev/
Nicholas Piggin (2):
powerpc/64s/exception: treat NIA below __end_interrupts as soft-masked
powerpc/64s: system call support for scv/rfscv instructions
Thanks,
Nick
--
2.23.0
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
