Why Relaxing Locks Is Safe Enough Here

M3U's key design question is how to reduce lock contention without weakening the address-translation relationships that keep a post-copy VM correct. The answer begins with two conditions that ordinary memory management does not always have: the VM's physical memory has already been allocated, and the guest is fully stopped during the switching window. M3U uses those conditions to change visibility instead of placement, parallelize independent regions instead of sharing one lock path, and separate page-data copying from the later consistency update.

Keep the physical memory; change its visibility

During the switching phase, M3U keeps the VM's physical memory allocated. It does not treat a page that is temporarily unavailable to the guest as a page that must be freed and later allocated again. Instead, it changes the page-table permissions or presence information that determines whether the guest can use the page. The physical placement stays stable while the guest-visible mapping records that the page must be recovered.

This is the basis of page flagging. The paper describes a 2 MB page-table entry being split into 512 4 KB entries. M3U marks those smaller entries non-present and maintains a bitmap in which each bit records the state of a 4 KB page. A later access to one of those entries can therefore identify a missing page without requiring the switching path to deallocate its physical memory. When the page is recovered, its existing placement can be made usable again rather than reconstructed through a fresh allocation. The flag is therefore a promise about access, not a statement that the host has forgotten where the page belongs. A fault on a flagged 4 KB entry identifies the unit that needs data; it does not force the system to search for a new physical home for that data.

Splitting the large entry also creates a deliberate two-level representation. The migration can reason about individual 4 KB pages while the underlying memory was previously organized in a 2 MB mapping. That is useful during the interval in which only some contents have arrived, but it creates later bookkeeping: the system must know which smaller entries are present and when the larger mapping can safely be restored. M3U accepts that bookkeeping because it is cheaper than performing full allocation and unmap work for every page during the suspended phase.

The distinction is important because allocation and visibility answer different questions. Allocation asks where the host stores the VM's physical memory. Visibility asks whether a guest or a translation structure may use that memory now. In ordinary management paths, an unmap may legitimately combine those operations: removing a mapping can release the page because the owner no longer needs it. During post-copy switching, the destination still needs the page's eventual storage; it only needs the guest to fault until the source has supplied the correct contents. M3U preserves the first fact and changes the second.

Page flagging also removes work that is redundant in this phase. The paper identifies per-unmap physical allocation and deallocation as unnecessary for post-copy. It also removes an EPT notifier callback that would erase invalidated EPT mappings even though the EPT is not fully constructed until userfault handling and VM resumption.