[PATCH v2 1/2] powerpc: Runtime selection between sc and scv for syscalls

[Tulio Magno Quites Machado Filho]

Matheus Castanho via Libc-alpha <libc-alpha@sourceware.org> writes:

> Linux kernel v5.9 added support for system calls using the scv
> instruction for POWER9 and later.  The new codepath provides better
> performance (see below) if compared to using sc.  For the
> foreseeable future, both sc and scv mechanisms will co-exist, so this
> patch enables glibc to do a runtime check and use scv when it is
> available.
>
> Before issuing the system call to the kernel, we check hwcap2 in the TCB
> for PPC_FEATURE2_SCV to see if scv is supported by the kernel.  If not,
> we fallback to sc and keep the old behavior.
>
> The kernel implements a different error return convention for scv, so
> when returning from a system call we need to handle the return value
> differently depending on the instruction we used to enter the kernel.
>
> For syscalls implemented in ASM, entry and exit are implemented by
> different macros (PSEUDO and PSEUDO_RET, resp.), which may be used in
> sequence (e.g. for templated syscalls) or with other instructions in
> between (e.g. clone).  To avoid accessing the TCB a second time on
> PSEUDO_RET to check which instruction we used, the value read from
> hwcap2 is cached on a non-volatile register.
>
> This is not needed when using INTERNAL_SYSCALL macro, since entry and
> exit are bundled into the same inline asm directive.
>
> The dynamic loader may issue syscalls before the TCB has been setup
> so it always uses sc with no extra checks.  For the static case, there
> is no compile-time way to determine if we are inside startup code,
> so we also check the value of the thread pointer before effectively
> accessing the TCB.  For such situations in which the availability of
> scv cannot be determined, sc is always used.
>
> Support for scv in syscalls implemented in their own ASM file (clone and
> vfork) will be added later. For now simply use sc as before.

LGTM.

Pushed as 68ab82f56690ada86ac1e0c46bad06ba189a10ef.

Thanks!

-- 
Tulio Magno