feat(whp): copy-on-write file mapping for snapshot load#1391
Open
danbugs wants to merge 5 commits intohyperlight-dev:mainfrom
Open
feat(whp): copy-on-write file mapping for snapshot load#1391danbugs wants to merge 5 commits intohyperlight-dev:mainfrom
danbugs wants to merge 5 commits intohyperlight-dev:mainfrom
Conversation
danbugs
requested review from
dblnz,
devigned,
jprendes,
ludfjig,
marosset,
simongdavies and
syntactically
as code owners
Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
Save snapshots to disk via Snapshot::to_file(), load them back via Snapshot::from_file(). Create sandboxes directly from loaded snapshots via MultiUseSandbox::from_snapshot(), bypassing ELF parsing and guest init. Signed-off-by: Ludvig Liljenberg <4257730+ludfjig@users.noreply.github.com>
from_snapshot() was constructing a fresh MultiUseSandbox via from_uninit(), which assigns a new monotonically-increasing sandbox id. The loaded snapshot still carries the id of the sandbox it was originally captured from, so the very first restore() call after from_snapshot trips SnapshotSandboxMismatch and aborts before any guest code runs. Conceptually the snapshot IS this sandbox's identity when loaded from disk — the sandbox it was captured from no longer exists. Inherit the snapshot's sandbox_id and register the loaded snapshot as this sandbox's active snapshot so subsequent restores match. Signed-off-by: danbugs <danilochiarlone@gmail.com>
The Windows path in ReadonlySharedMemory::from_file_windows was
created with PAGE_READONLY + FILE_MAP_READ. That matches the name
('ReadonlySharedMemory') but not the semantics the caller needs: a
sandbox loaded from a snapshot still has to be a writable view of
the guest's memory from the host's perspective, so WHP/MSHV can
service copy-on-write faults the guest takes on first write.
A read-only mapping triggers an access violation on the host thread
the moment the guest touches any page, before the VMM can vector
the fault into the in-kernel CoW path.
Switch to PAGE_WRITECOPY + FILE_MAP_COPY — the Windows equivalent
of Linux's mmap(MAP_PRIVATE) that Linux's from_file path already
uses. Reads still come from the backing file; writes transparently
allocate private copy-on-write pages.
Follow-up to hyperlight-dev#1373; depends on that PR
landing first.
Signed-off-by: danbugs <danilochiarlone@gmail.com>
danbugs
force-pushed
the
whp-snapshot-cow
branch
from
b380323 to
daa1f7d
Compare
danbugs
added
the
kind/enhancement
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Stacked follow-up to #1373. The Windows path in
ReadonlySharedMemory::from_file_windowsis currently created withPAGE_READONLY+FILE_MAP_READ. That matches the type name (ReadonlySharedMemory) but not the semantics thefrom_snapshotcaller needs: the host-side view has to be writable so WHP (and MSHV) can service the copy-on-write faults the guest takes on first write. A read-only mapping triggers an access violation on the host thread the moment the guest touches any page.Switch to
PAGE_WRITECOPY+FILE_MAP_COPY— the Windows equivalent of Linux'smmap(MAP_PRIVATE)that the Linuxfrom_filepath already uses. Reads still come from the backing file; writes transparently allocate private copy-on-write pages.Relationship to #1373
disk_snapshot's tip, so the diff here will reduce to just the CoW change once Persist snapshot to disk #1373 is merged.shared_mem.rsdelta.Tested
On a Windows box with WHP enabled:
Snapshot::to_filethenMultiUseSandbox::from_snapshot→restore→callcompletes cleanly. Pre-fix, the same flow took an access violation on the first page fault the guest triggered after restore.Known follow-ups (not in this PR)
None for this change specifically. Separate PR will add
Registerable for MultiUseSandboxso host functions can be wired on sandboxes acquired viafrom_snapshot.