Repository navigation
Some tweaks to the SME lazy save scheme - #325
Merged
Merged
Conversation
smithp35
reviewed
Apr 23, 2025
smithp35
left a comment
Contributor
There was a problem hiding this comment.
Spotted a typo in the change history.
rsandifo-arm
force-pushed
the
sme-lazy-save-tweaks
branch
2 times, most recently
from
April 23, 2025 18:19
078b381 to
2cf2bcc
Compare
Contributor
|
Acked-by: @yury-khrustalev |
smithp35
approved these changes
Apr 29, 2025
smithp35
left a comment
Contributor
There was a problem hiding this comment.
LGTM.
Agreed to approve with stakeholders in Arm's libraries and kernel team. Will merge at end of the UK working day.
This patch does four things: - Explicitly document that ZT0 is a temporary register. - Clarify that __arm_sme_save and __arm_sme_restore treat both ZA and ZT0 specially. - Add a general note about how platforms should handle asynchronous control flow (such as POSIX signals). The specific details are out of scope for the AAPCS64, which is why this wasn't mentioned before. However, for the sake of an example, we can at least sketch the approach that linux will use. - Change the notes around setjmp and longjmp to recommend that both routines turn ZA off. Just turning ZA off in longjmp isn't enough when jumping out of a linux-style signal handler, since longjmp would not be able to see any ZA save buffer that was in use when the signal was raised, nor the ZA contents that should be saved to it. The previous recommendation to turn ZA off only in longjmp was chosen by analogy with exception unwinding; it seemed to make sense in both cases to commit a lazy save once it was known that some frames would be unwound. However, the two cases are not analogous for asynchronous signals, since exception unwinders can examine each intermediate frame and see the point at which a signal handler was entered, whereas longjmp (in general) cannot. It may not be strictly necessary for longjmp to commit a lazy save if setjmp does; it might be enough for it to force PSTATE.ZA and TPIDR2_EL0 to zero. However, that would be a novel state transition and it would be optimising for what should be a vanishingly rare case (the one where there is an in-progress SME routine between a setjmp and a longjmp). It seems safer to use the standard transition instead.
rsandifo-arm
force-pushed
the
sme-lazy-save-tweaks
branch
from
April 30, 2025 09:01
2cf2bcc to
6e05fdd
Compare
sdesmalen-arm
approved these changes
Apr 30, 2025
sdesmalen-arm
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the rewording @rsandifo-arm. LGTM!
Contributor
|
PR has been approved. Merging into main. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch does four things:
Explicitly document that ZT0 is a temporary register.
Clarify that __arm_sme_save and __arm_sme_restore treat both ZA
and ZT0 specially.
Add a general note about how platforms should handle asynchronous control
flow (such as POSIX signals). The specific details are out of scope
for the AAPCS64, which is why this wasn't mentioned before. However,
for the sake of an example, we can at least sketch the approach that
linux will use.
Change the notes around setjmp and longjmp to recommend that both
routines turn ZA off. Just turning ZA off in longjmp isn't enough
when jumping out of a linux-style signal handler, since longjmp
would not be able to see any ZA save buffer that was in use when the
signal was raised, nor the ZA contents that should be saved to it.
The previous recommendation to turn ZA off only in longjmp was chosen
by analogy with exception unwinding; it seemed to make sense in both
cases to commit a lazy save once it was known that some frames would
be unwound. However, the two cases are not analogous for asynchronous
signals, since exception unwinders can examine each intermediate frame
and see the point at which a signal handler was entered, whereas
longjmp (in general) cannot.
It may not be strictly necessary for longjmp to commit a lazy save
if setjmp does; it might be enough for it to force PSTATE.ZA and
TPIDR2_EL0 to zero. However, that would be a novel state transition
and it would be optimising for what should be a vanishingly rare case
(the one where there is an in-progress SME routine between a setjmp
and a longjmp). It seems safer to use the standard transition instead.