Skip to content

docs: native snapshot-fork feasibility (GO — extend our libkrun fork)#27

Merged
ZhiXiao-Lin merged 1 commit into
mainfrom
docs/native-snapshot-fork
Jun 12, 2026
Merged

docs: native snapshot-fork feasibility (GO — extend our libkrun fork)#27
ZhiXiao-Lin merged 1 commit into
mainfrom
docs/native-snapshot-fork

Conversation

@ZhiXiao-Lin

Copy link
Copy Markdown
Contributor

Resolves the backend-selection question from #17: go native in A3S-Lab/libkrun (vendored checkout) instead of adding a Firecracker/CH second VMM.

Survey findings: vCPU/VM save+restore already exists (dead code, vstate.rs); pause/resume half-wired; TEE guest_memfd is in-tree precedent for file-backed RAM; virtio device serialization is missing — but snapshotting an IDLE deferred-main template (P2) collapses the device problem to queue registration + the virtio-fs inode map.

4-phase plan, ~4–6 weeks total; Phase A (memfd RAM + krun_snapshot/krun_restore with MAP_PRIVATE CoW on a quiesced idle VM) gives a measurable go/no-go in ~2 weeks.

Code survey of A3S-Lab/libkrun (vendored checkout): vCPU/VM state save+restore
already exists as dead code; pause/resume half-wired; TEE guest_memfd is an
in-tree precedent for non-anonymous RAM; device serialization missing — but our
use case snapshots an IDLE deferred-main template (quiesced queues), shrinking
device state to queue registration + the virtio-fs inode map (the one hard
item). Native path chosen over a Firecracker/CH second backend (no virtio-fs in
FC; no adapter layer; single VMM). 4-phase plan, Phase A = RAM+CPU
snapshot/restore with MAP_PRIVATE CoW, go/no-go in ~2 weeks.
@ZhiXiao-Lin ZhiXiao-Lin merged commit 71e2e40 into main Jun 12, 2026
7 checks passed
@ZhiXiao-Lin ZhiXiao-Lin deleted the docs/native-snapshot-fork branch June 12, 2026 07:23
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.

1 participant