Guest Copy on Write #1200

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
• Allow the guest to manage its own stack #1205
• Enable CoW #1229
• Docs
• Mmap tests fail with GuestAborted(15, "Exception: PageFault" ) #1249

This is particularly improtant for Hyperlight-wasm. There are steps to leverage this there:

• update to take these changes
• more to tbd