In another embodiment, node_0 performs the conversion of GPA_34 to a dormant page. For example, node_1 sends a message back to node_0, indicating that node_0 may proceed from its stall by creating a dormant. As one example, ownership of GPA_34 is transferred to node_0. The hyper-kernel of node_0 marks GPA_34, which it now owns, as a dormant page in its internal page tables. The hyper-kernel on node_0 then sends a message to the node_1 indicating that the ownership of GPA_34 has been transferred and that the page is now dormant. Node_1 may then place the real physical page previously mapped to GPA_34 on its to be zeroed list. Further, node_1 is also instructed to unmap GPA_34 from node_1.
Thus, the distributed hyper-kernels have coordinated with each other to convert GPA_34 to dormant, which may be performed independently of where they are originally located or defined.
Moving GPA_34's dormancy to node_0 may improve locality and pre-emptively reduce future stalls, as it is likely to be accessed again by a VCPU on the node_0, from which the zeroing was requested (e.g., because node_0 is likely to write to the zeroed page next).
In the above example, GPA_27 was directly overwritten because no stall occurred since GPA_27 was mapped to a portion of physical memory local to node_0. However, there may be cases in which GPA_27 is owned by node_0 and is non-zero, but at the time of the zeroing instruction, is unmapped to real physical memory, in which case a reference to GPA_27 would stall (stalls are generated when a guest physical address is not mapped to a real physical address). There are various reasons why a guest physical address may be unmapped. For example, un-mapping could occur if the hyper-kernel is in the middle of an accounting procedure referred to herein as “sampling,” in which pages that have not been recently used are identified.