Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[2.1 backport] Avoid save/restoring AMX registers to avoid a SPR erratum #15969

Merged
merged 1 commit into from
Apr 3, 2024
Merged

[2.1 backport] Avoid save/restoring AMX registers to avoid a SPR erratum #15969

merged 1 commit into from
Apr 3, 2024

Conversation

rincebrain
Copy link
Contributor

Motivation and Context

Someone hit #14989 on 2.1.x, and I noticed this hadn't ever ended up there.

I don't know if we're cutting a 2.1.16, but I figured I'd push it out in case someone needed it.

Description

See #15168

How Has This Been Tested?

Isn't that what CI is for?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

Checklist:

@rincebrain
Avoid save/restoring AMX registers to avoid a SPR erratum
5b521c9 
Intel SPR erratum SPR4 says that if you trip into a vmexit while
doing FPU save/restore, your AMX register state might misbehave...
and by misbehave, I mean save all zeroes incorrectly, leading to
explosions if you restore it.

Since we're not using AMX for anything, the simple way to avoid
this is to just not save/restore those when we do anything, since
we're killing preemption of any sort across our save/restores.

If we ever decide to use AMX, it's not clear that we have any
way to mitigate this, on Linux...but I am not an expert.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Rich Ercolani <[email protected]>
Closes openzfs#14989
Closes openzfs#15168

Signed-off-by: Rich Ercolani <[email protected]>
@rincebrain rincebrain changed the base branch from master to zfs-2.1.16-staging March 6, 2024 02:38
@behlendorf behlendorf added the Status: Accepted Ready to integrate (reviewed, tested) label Apr 3, 2024
@behlendorf behlendorf merged commit f288fdb into openzfs:zfs-2.1.16-staging Apr 3, 2024
5 of 7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@behlendorf behlendorf behlendorf approved these changes

Assignees
No one assigned
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@rincebrain @behlendorf