The following page explains how Rewind VM works:
...of which the following are most important:
2. Run deterministically
One vCPU on stock KVM, so code in the VM runs on the real CPU. The VM's kernel carries a small Rewind platform: interrupts arrive only when the VM hands control to Rewind, time moves only then, and the timestamp counter and hardware RNG are hidden. A step is one of those handoffs.
3. Keep keyframes
Every quarter second of wall time, Rewind snapshots the machine using KVM's dirty-page [aka Memory Pages that have been written to since the last snapshot] log. Pages go into a content-addressed store (BLAKE3, zstd), so a page shared by keyframes, runs and forks is stored once."
Now, that's some brilliant engineering right there!
While I like the product name "Rewind VM" (and yes, that's what it allows the user to do!), it could just as easily be called "Deterministic VM" and that name would have been wholly appropriate, as well!
Future OS and VM engineers should study Rewind VM. Those are some great engineering ideas there, and determinism, or at least optional determinism, should it be desired, when it is desired -- is the one thing that is completely non-existent in most OS's, most VM's, and most other program runtime environments...
Anyway, a great article on using Rewind VM (never knew about it before this article!) with Nix builds.
Are you tooting your own horn?
There could be great ideas in Rewind VM, but the page is littered with Claude-ish which is immediately off-putting.
so this is like redux but for the whole VM?