RFC arm64: Scalable Vector Extension core support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 29 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 29 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
Quoted 14 lines · Florian Weimer
Quoted 13 lines · Dave Martin
The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which adds extra SIMD functionality and supports much larger vectors.
This series implements core Linux support for SVE.
Recipents not copied on the whole series can find the rest of the patches in the linux-arm-kernel archives [2].
The first 5 patches "arm64: signal: ..." factor out the allocation and placement of state information in the signal frame. The first three are prerequisites for the SVE support patches.
Quoted 9 lines
Quoted 5 lines
Patches 04-05 implement expansion of the signal frame, and may remain controversial due to ABI break issues:
* Discussion is needed on how userspace should detect/negotiate signal frame size in order for this expansion mechanism to be workable.
I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to disable really wide vector registers in case this causes problems with old binaries.
if the kernel does not increase the size and libc does not add size checks then old binaries would work with new libc just fine..
but that's non-conforming, posix requires the check.
if the kernel increases the size then it has to be changed in bionic and musl as well and old binaries may break.
Quoted 6 lines
A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to its complexity.
Quoted 3 lines
The remaining patches implement initial SVE support for Linux, with the following limitations:
Quoted 8 lines
Quoted 4 lines
* No KVM/virtualisation support for guests.
* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.
Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable functions/executors quite challenging.
i'd assume it's undefined to context switch to a different thread or to resume a function on a different thread (because the implementation can cache thread local state on the stack: e.g. errno pointer).. of course this does not stop ppl from doing it, but the practice is questionable.
Quoted 4 lines
Can you detail your plans in this area?
Thanks,
Florian