Reset more vcpu state on snapshot::restore

[ludfjig]

MSRs will be added in another PR.

• Removed padding fields from fpu register to simplify comparisons. Not sure why I added them to begin with, we don't need C repr on these. It could possibly allow more efficient into() implementation for kvm/mshv due to single memcyp, but that seems like premature optimization to me
• Reset vcpu state on snapshot::restore
• Added bunch of tests
• MSRs are not included in this PR. Will add MSRs in future PR

Addresses #791 partially

------ After rebase ------

• Added field onto Snapshot which is SpecialRegisters. These are saved on snapshot() and restored when calling restore(). This is since we can no longer just reset them to default since the guest initializes them

[syntactically]

This looks pretty good to me! It's probably a good bit of extra overhead, but perhaps that's unavoidable.

One alternate option would be to require every guest to have some code somewhere that does some/all of this reset work inside the VM, validating that the correct code is in the correct place whenever we make a snapshot. We have talked about doing something similar for TLB flushes as well. That would let you batch most of this into a single hypercall, although the hypercall itself would be a bit more expensive. Do you have any sense of whether that would make sense to investigate?

[syntactically]

Sorry, missed one other comment.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 15 changed files in this pull request and generated 2 comments.

[Copilot]

reset_vcpu() ignores the provided cr3/sregs when init-paging is disabled and unconditionally sets real-mode defaults (with an explicit TODO saying it's probably incorrect). This is a functional regression for non-init-paging builds: restoring a snapshot would reset the vCPU into a mode/state that may not match how the VM is actually configured. Consider either implementing the correct restore logic for the non-init-paging configuration (using the passed-in sregs/cr3), or gating the new reset behavior behind init-paging so behavior doesn’t silently change in that build mode.

Suggested change

	let _ = (cr3, sregs); // suppress unused warnings
	// TODO: This is probably not correct.
	// Let's deal with it when we clean up the init-paging feature
	self.vm
	.set_sregs(&CommonSpecialRegisters::standard_real_mode_defaults())?;
	// In non-init-paging builds, rely on the caller-provided snapshot
	// state (including CR3) rather than forcing real-mode defaults.
	self.vm.set_sregs(sregs)?;

[Copilot]

The restore path returns HyperlightError::Error("snapshot from running sandbox should have sregs"...) when snapshot.sregs() is None. Using the generic stringly-typed error makes it hard for callers/tests to match on the failure mode and isn’t very actionable. Consider introducing a dedicated error variant (e.g. SnapshotMissingSregs) or reusing an existing structured error so this case can be handled explicitly.

Suggested change

	let sregs = snapshot.sregs().ok_or_else(|| {
	HyperlightError::Error("snapshot from running sandbox should have sregs".to_string())
	})?;
	let sregs = snapshot
	.sregs()
	.ok_or(HyperlightError::SnapshotMissingSregs)?;