Guest Copy on Write #1200
Description
Tracking issues Guest Copy on Write.
Brief design overview
When running on a Type 1 hypervisor, servicing a Stage 2 translation
page fault is relatively quite expensive, since it requires quite a
lot of context switches. To help alleviate this, Hyperlight will use a
design in which the guest is aware of readonly snapshot from
which it is being run, and manages its own copy-on-write.
Because of this, there are two very fundamental regions of the guest
physical address space, which are always populated: one, at the very
bottom of memory, is a (hypervisor-enforced) readonly mapping of the
base snapshot from which this guest is being evolved. Another, at the
top of memory, is simply a large bag of blank pages: scratch memory
into which this VM can write.
See more in the proposal at 3d59400
TODO:
POC on older branch: main...lm/guest-cow
old PR that tracked things: #1091
- Add scratch region #1182
- Remove host function definition regions #1178
- Unify page table manipulation code between the guest and the host #1093
- Nix updates #1095
- Fix clippy #1096
- Remove the last vestiges of autodetecting heap/stack size from exes #1097
- Update snapshots #1098
- Make mem::exe::LoadInfo a struct, instead of an alias #1099
- Remove
HyperlightPEB::code_ptr#1100 - Create Sandboxes from Snapshots #1127
- Properly CoW page tables to the scratch region #1198
- Move Writable and Scratch regions
- Remove old host managed state
- Enable Snap shots and turn it on
- Docs
This is particularly improtant for Hyperlight-wasm. There are steps to leverage this there:
- update to take these changes
- more to tbd