Fast boot
摘要
說明書
When the access violation occurs, an event is triggered (in a system dependent way) to which the hyper-kernel responds. One example of how such an event can be handled is by the invocation of a panic routine. Other approaches can also be used, as applicable. As will be described in more detail below, the hyper-kernel examines the cause of the event and determines an appropriate strategy (e.g., low level transaction) for handling the event. As explained above, one way to handle the event is for one or more blocks of hyper-kernel virtualized memory to be transferred from one node's memory to another node's memory. The transfer would then be initiated, and the corresponding resource maps would be updated. A continuation would be built poised to be placed in a local table in shared memory, referred to herein as an “event table,” so that the next thing the continuation does when it is resumed would be to return control to the operating system after the transfer is completed. Alternatively, a decision could be made to move the virtual processor to the node that contains the memory being requested or to move the virtualized memory (and its virtualized memory address) from one node to another. Different decisions for how to handle the stall may be based on the characteristics or context or cause of the stalling event. In various embodiments, the hyper-kernel makes three decisions when handling an event: which (virtual) resources should move, when to move them, and to where (in terms of physical locations) they should move.
Tidal Tree
