Skip to content

Preserve guest floating-point and extended CPU state on Windows - #1340

Open
Weiteng Chen (CvvT) wants to merge 6 commits into
mainfrom
weiteng/windows_save_fp_state
Open

Preserve guest floating-point and extended CPU state on Windows#1340
Weiteng Chen (CvvT) wants to merge 6 commits into
mainfrom
weiteng/windows_save_fp_state

Conversation

@CvvT

Copy link
Copy Markdown
Contributor

Preserve guest floating-point and SIMD state across syscalls, exceptions, and host interrupts, while ensuring host Rust code runs with Windows ABI floating-point controls.

  • For syscall that does not update rip, save guest state with XSAVE and restore it with XRSTOR on the fast resume path.
  • For exception and interrupt, preserve extended state through Windows context capture and NtContinue.
  • For syscall that updates rip, save guest state with XSAVE but restore it with NtContinue.

@CvvT
Weiteng Chen (CvvT) marked this pull request as ready for review September 10, 2026 00:30
}
}

const XSAVE_LEGACY_SIZE: usize =

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weiteng Chen (@CvvT) This part of code is more like platform-independent but architecture-dependent. Should we consider making it sharable between linux and windows platforms?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we handle this in the Linux userland platform?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linux should be similar. I will move the common code when I add the support for Linux userland.

@wdcui

Copy link
Copy Markdown
Member

Sangho Lee (@sangho2) can you help review this PR? Thanks!

@github-actions

Copy link
Copy Markdown

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

@sangho2

Copy link
Copy Markdown
Contributor

Do we need to worry about the below? perhaps out of this PR's scope (AArch64 Linux variant somehow handles it).

@sangho2 Sangho Lee (sangho2) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, looks good to me. We might want to use XSAVEC or XAVEOPT later, but better to have a correct implementation first.

);
let features = core::arch::x86_64::__cpuid_count(0x0d, 0);
let mask = unsafe { core::arch::x86_64::_xgetbv(0) };
assert_eq!(mask & 3, 3, "x87 and SSE state must be enabled");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it mean that AVX/AVX2 are optional?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is optional. The code only assumes XSAVE_FORMAT that requires x87 and SSE state.

@CvvT

Copy link
Copy Markdown
Contributor Author

Do we need to worry about the below? perhaps out of this PR's scope (AArch64 Linux variant somehow handles it).

Yes, we should, but probably after I also fix Linux userland platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants