Retain page table root finder for in-memory snapshots - #1730
Conversation
3066727 to
369449c
Compare
369449c to
7594cc8
Compare
7594cc8 to
90f3e0d
Compare
90f3e0d to
e68e972
Compare
e68e972 to
34faa8e
Compare
5e7ba67 to
85d03c4
Compare
85d03c4 to
454ea47
Compare
454ea47 to
1a6288c
Compare
There was a problem hiding this comment.
Pull request overview
This PR fixes a correctness issue in the host snapshot/restore pipeline where restoring a snapshot into a different sandbox could accidentally keep the target sandbox’s page-table root finder (or lose the source guest’s finder), leading to later snapshots walking the wrong page-table roots. The fix applies to in-memory snapshots only (the finder remains non-serializable for on-disk snapshots).
Changes:
- Plumbs an optional runtime-only
pt_root_finderthroughSnapshotso in-memory snapshots retain it acrossfrom_snapshotandrestore. - Updates
PtRootFindertoArc<... + Send + Sync>and wires it through snapshot creation/restoration paths. - Adds tests and documentation clarifying that
PtRootFinderis not serialized for file-backed snapshots, plus a changelog entry for the breaking API change.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/hyperlight_host/src/sandbox/snapshot/mod.rs | Adds pt_root_finder to in-memory Snapshot and a crate-level accessor. |
| src/hyperlight_host/src/sandbox/snapshot/file/mod.rs | Documents that PtRootFinder is not serialized for on-disk snapshots; initializes loaded snapshots with pt_root_finder: None. |
| src/hyperlight_host/src/sandbox/snapshot/file_tests.rs | Extends snapshot round-trip tests to validate in-memory retention and on-disk non-serialization of the finder. |
| src/hyperlight_host/src/sandbox/initialized_multi_use.rs | Switches PtRootFinder to Arc + Sync, propagates it across from_snapshot/restore, and adds thread-safety tests. |
| src/hyperlight_host/src/mem/mgr.rs | Passes optional finder through to Snapshot::new. |
| CHANGELOG.md | Records the breaking change to PtRootFinder (Arc + Sync). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
1a6288c to
db8c56a
Compare
39e2ed7 to
06ba003
Compare
Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
06ba003 to
fedce3a
Compare
jprendes
left a comment
There was a problem hiding this comment.
LGTM!
What is the consequence of not setting the PtRootFinder?
If I have a sandbox, snapshot it, save to disk, then restore from disk, and don't set the PtRootFinder, what could go wrong?
| fn assert_send_sync<T: Send + Sync>() {} | ||
|
|
||
| assert_send::<MultiUseSandbox>(); | ||
| let _ = <MultiUseSandbox as AmbiguousIfSync<_>>::assert_not_sync; |
|
I'm a little bit skeptical of diverging the in-memory snapshots from the disk snapshots (at least making a release with a semantic gap there), although I agree that logically the root finder feels like a property of the guest image more than the sandbox host. Can we serialise a tag/hash/something/somehow and do validation (or lookup from a user-provided registry) on load? (Or switch to the root finder running in the guest.... but probably there are sometimes cases where the host can do better w/o needing to enter the guest? hard to say for sure.) |
restoring a snapshot into another sandbox could retain the target sandbox’s finder or lose the source guest’s finder. Later snapshots might then discover the wrong page-table roots. This pr fixes that (for in-memory snapshots only as the pt-finder cannot be serialized to disk)