QEMU adds fast snapshot load for near-instant VM resume
Postcopy-style lazy RAM paging from mapped snapshot files aims to cut perceived restore time for large guests.
QEMU is gaining a fast snapshot load path that can bring a saved VM back to life almost immediately, instead of waiting until every RAM page has been read from disk.
Today a snapshot restore blocks guest execution until the full RAM image and device state are in host memory. For multi-gigabyte guests that delay is often the dominant part of resume latency. The new work, posted as a fourth revision by Aadeshveer Singh, treats disk restore more like postcopy migration: only device state is required up front, then the guest starts while remaining RAM is filled in on demand.
Linux userfaultfd traps accesses to pages that are still on disk. A fault thread serves those misses by reading the corresponding offsets from a mapped-ram snapshot file. At the same time an eager background thread walks the rest of RAM so the guest does not stay dependent on fault handling forever and so idle pages are not left unloaded indefinitely. Coordination between the two threads uses a per-RAMBlock pending bitmap so the same page is not loaded twice.
The feature is exposed by enabling postcopy-ram together with mapped-ram on the load side, a combination QEMU previously rejected. Multifd, postcopy-preempt, and vhost-user remain unsupported for this mode. Documentation, capability checks, and a qtest smoke case are part of the series. Reviewers Peter Xu and Juraj Marcin have acked large portions of the preparatory cleanup, though Xu still flagged a remaining concurrency edge case when guest page size exceeds host page size.