[PATCH v6 06/37] kselftest/arm64: Add a test program to exercise the syscall ABI

[Catalin Marinas]

On Mon, Nov 15, 2021 at 03:28:04PM +0000, Mark Brown wrote:
> diff --git a/tools/testing/selftests/arm64/abi/syscall-abi-asm.S b/tools/testing/selftests/arm64/abi/syscall-abi-asm.S
> new file mode 100644
> index 000000000000..983467cfcee0
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/abi/syscall-abi-asm.S
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0-only

Nitpick: I think GPL-2.0 is sufficient (i.e. no '-only' suffix), though
about a quarter seem to use the -only variant.

> diff --git a/tools/testing/selftests/arm64/abi/syscall-abi.c b/tools/testing/selftests/arm64/abi/syscall-abi.c
> new file mode 100644
> index 000000000000..d103acf1ab79
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/abi/syscall-abi.c
[...]
> +static int check_z(struct syscall_cfg *cfg, int sve_vl)
> +{
> +	size_t reg_size = sve_vl;
> +	int errors = 0;
> +	int i;
> +
> +	if (!sve_vl)
> +		return 0;
> +
> +	/*
> +	 * After a syscall the low 128 bits of the Z registers should
> +	 * be preserved and the rest be zeroed.
> +	 */

That's the current behaviour I think but the sve.rst doc states the
values after syscall are 'unspecified' (same for the P regs). Should we
tighten the doc as well?

A downside with forcing zero is that it may prevent us from some
optimisations in the future. Currently we do an sve_user_discard() on
the syscall entry path and disable SVE but we could instead do this only
on context switch or when the kernel used Neon.

Of course, we also run the risk of the current behavior (zeroing)
becoming the de-facto ABI.

-- 
Catalin