[release/9.0-preview7] Improve the handling of SVE state as part of threadsuspend #105291
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.
Backport of #105059 to release/9.0-preview7
/cc @tannergooding
Customer Impact
.NET 9 has introduced experimental support for the SVE instruction set for the Arm64 platform. While this feature work is considered experimental and some functionality is expected to be incomplete, it is still important that key scenarios function so that developers can successfully use the functionality in non-production scenarios.
The support for saving/restoring SVE state as part of thread suspension had been added for Unix platforms, but had not yet been added for Windows. As such, developers utilizing the SVE APIs on Windows could see corruption of state if a GC were to occur and cause the underlying thread to be suspended.
Regression
This is not a regression, it is impacting a new feature that was developed as part of .NET 9
Testing
As we do not currently have SVE capable machines in our CI pool, manual validation was done on the internal SVE capable machines we have in our hardware lab.
This manual validation included using SVE instructions, forcing a GC suspension to occur, and observing that the state was no longer trashed after the GC completed and the managed code was allowed to continue executing.
Risk
Low. This is ensuring that the general thread suspension support saves/restores state that is unique to experimental SVE feature.
It is worth noting, however, that the thread suspension logic is centralized and needs to work without context as to whether any SVE is actually in use. This means that all context save/restore queries made to the OS are now requesting that SVE state be preserved even if the process does not otherwise use the feature. On OS versions or hardware that does not support SVE, this additional
XSTATE_MASK_ARM64_SVEflag is ignored (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setxstatefeaturesmask#remarks) and we correctly check for such support before attempting to access SVE related data from the returnedCONTEXT. This will not impact non SVE related state and is completely transparent to the user, but is still worth calling out given that it isn't strictly isolated to only contexts where the user has opted to use SVE related APIs.