Consider interaction of SME with POSIX APIs

[smithp35]

This has been raised from the discussion #289 . Which I've quoted below

The base ABI does not cover platform specific functions, it leaves the platform ABI to define these. It does not say anything about POSIX [0] functions like siglongjmp that may need to interact with SME state.

The one document in the ABI where this could be mentioned is the sysvabi64 https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst

My preference is that the sysvabi64.rst record the result of community consensus rather than be the driving force in defining it.

Quote from discussion

POSIX allows software to exit a signal handler by calling siglongjmp, bypassing the more common signal return [1].

When a signal is delivered, and execution is transferred to its handler, it is expected that ZA will be in the off state and all SME state to be persisted in the signal frame [2]. Signals can be delivered when SME is in any state, including the dormant state. Delivering a Signal will not commit the lazy state.

Since siglongjmp will truncate and discard the signal frame, it is not possible to delay the committal of lazy state to siglongjmp instead of making it upfront on sigsetjmp without risking the loss of ZA state, as it is recommended for setjmp/longjmp [3].
[0]
https://austingroupbugs.net/view_all_bug_page.php?page_number=1
[1]
https://www.man7.org/linux/man-pages/man3/siglongjmp.3p.html
[2]
https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/sme.rst#5--signal-handling
[3]
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#setjmp-and-longjmp

[mrutland-arm]

For the sake of posterity, I believe we addressed the specific issues raised by @pmsjt in discussion #289 as a result of commit 3952cfb ("Some tweaks to the SME lazy save scheme").