arm64: Initial SVE support

[andrew]

Summary

Add initial kernel support for SVE. This detects if SVE is present on
all CPUs, and if so allows for the use of SVE in the future.

As the SVE registers are a superset of the VFP registers we don't need
to restore the VFP registers when SVE is enabled.

Ths interface to enable SVE is provided, but not used until SVE is
supported in signals and with ptrace.

Sponsored by: Arm Ltd

[imp]

This one seems reasonable, but it would be best to get others to say so too.

sys/arm64/arm64/vfp.c

111

Do you want to leave this in?

661

should you free the svesaved memory instead?

[andrew]

Rework to not guarentee the SVE registers are saved over a syscall other than sigreturn.
The ABI doesn't require SVE registers to be saved on a function call so extend this to a system call.
As dropping the SVE state on all system calls could get expensive only do it on context switch when in one.

[kib]

In D43306#1021418, @andrew wrote:

Rework to not guarentee the SVE registers are saved over a syscall other than sigreturn.
The ABI doesn't require SVE registers to be saved on a function call so extend this to a system call.
As dropping the SVE state on all system calls could get expensive only do it on context switch when in one.

I read this as disallowing use of rtld for any custom ABI. Imagine that rtld bind is called to resolve a symbol which use custom calling conventions (namely, preserving SVE state). Then, if rtld ever needed to issue a syscall while working, it corrupts the SVE state of the caller.

[andrew]

Functions that take an SVE register as an argument, or use one for the return value are marked with STO_AARCH64_VARIANT_PCS [1]. In glibc it looks like they avoid lazy resolution for all variant pcs functions. As there are more reasons than just SVE for a function to be marked as a variant, and more reasons could be added in the future I think it's the only safe option.

[1] https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#st_other-values