* Nicholas Piggin: > * Proposal is for PPC_FEATURE2_SCV to indicate 'scv 0' support, all other > vectors will return -ENOSYS, and the decision for how to add support for > a new vector deferred until we see the next user.
Seems reasonable. We don't have to decide this today. > * Proposal is for scv 0 to provide the standard Linux system call ABI with > some > differences: > > - LR is volatile across scv calls. This is necessary for support because the > scv instruction clobbers LR. I think we can express this in the glibc system call assembler wrapper generators. The mcount profiling wrappers already have this property. But I don't think we are so lucky for the inline system calls. GCC recognizes an "lr" clobber with inline asm (even though it is not documented), but it generates rather strange assembler output as a result: long f (long x) { long y; asm ("#" : "=r" (y) : "r" (x) : "lr"); return y; } .abiversion 2 .section ".text" .align 2 .p2align 4,,15 .globl f .type f, @function f: .LFB0: .cfi_startproc mflr 0 .cfi_register 65, 0 #APP # 5 "t.c" 1 # # 0 "" 2 #NO_APP std 0,16(1) .cfi_offset 65, 16 ori 2,2,0 ld 0,16(1) mtlr 0 .cfi_restore 65 blr .long 0 .byte 0,0,0,1,0,0,0,0 .cfi_endproc .LFE0: .size f,.-f That's with GCC 8.3 at -O2. I don't understand what the ori is about. I don't think we can save LR in a regular register around the system call, explicitly in the inline asm statement, because we still have to generate proper unwinding information using CFI directives, something that you cannot do from within the asm statement. Supporting this in GCC should not be impossible, but someone who actually knows this stuff needs to look at it. > - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the > system call exit to avoid restoring the CR register. This sounds reasonable, but I don't know what kind of knock-on effects this has. The inline system call wrappers can handle this with minor tweaks. > - Error handling: use of CR0[SO] to indicate error requires a mtcr / mtocr > instruction on the kernel side, and it is currently not implemented well > in glibc, requiring a mfcr (mfocr should be possible and asm goto support > would allow a better implementation). Is it worth continuing this style of > error handling? Or just move to -ve return means error? Using a different > bit would allow the kernel to piggy back the CR return code setting with > a test for the error case exit. GCC does not model the condition registers, so for inline system calls, we have to produce a value anyway that the subsequence C code can check. The assembler syscall wrappers do not need to do this, of course, but I'm not sure which category of interfaces is more important. But the kernel uses the -errno convention internally, so I think it would make sense to pass this to userspace and not convert back and forth. This would align with what most of the architectures do, and also avoids the GCC oddity. > - Should this be for 64-bit only? 'scv 1' could be reserved for 32-bit > calls if there was interest in developing an ABI for 32-bit programs. > Marginal benefit in avoiding compat syscall selection. We don't have an ELFv2 ABI for 32-bit. I doubt it makes sense to provide an ELFv1 port for this given that it's POWER9-specific. >From the glibc perspective, the major question is how we handle run-time selection of the system call instruction sequence. On i386, we use a function pointer in the TCB to call an instruction sequence in the vDSO. That's problematic from a security perspective. I expect that on POWER9, using a pointer in read-only memory would be equally non-attractive due to a similar lack of PC-relative addressing. We could use the HWCAP bit in the TCB, but that would add another (easy to predict) conditional branch to every system call. I don't think it matters whether both system call variants use the same error convention because we could have different error code extraction code on the two branches. Thanks, Florian