Abstract: Hot restart of a hypervisor by replacing a running first hypervisor by a second hypervisor with minimally perceptible downtime to guest partitions. A first hypervisor is executed on a computing system. The first hypervisor is configured to create one or more guest partitions. During the hot restart, a service partition is generated and initialized with a second hypervisor. At least a portion of runtime state of the first hypervisor is migrated and synchronized to the second hypervisor using inverse hypercalls. After the synchronization, the second hypervisor is devirtualized from the service partition to replace the first hypervisor. Devirtualizing includes transferring control of hardware resources from the first hypervisor to the second hypervisor, using the previously migrated and synchronized runtime state.

Abstract: Hot restart of a hypervisor by replacing a running first hypervisor by a second hypervisor with minimally perceptible downtime to guest partitions. A first hypervisor is executed on a computing system. The first hypervisor is configured to create one or more guest partitions. During the hot restart, a service partition is generated and initialized with a second hypervisor. At least a portion of runtime state of the first hypervisor is migrated and synchronized to the second hypervisor using inverse hypercalls. After the synchronization, the second hypervisor is devirtualized from the service partition to replace the first hypervisor. Devirtualizing includes transferring control of hardware resources from the first hypervisor to the second hypervisor, using the previously migrated and synchronized runtime state.

Abstract: Hierarchical virtualization creates a child guest partition that shares a hypervisor with a parent guest partition. A hypervisor receives a request, from a first guest partition that operates at the hypervisor, to create a second guest partition as a child of the first guest partition. The hypervisor identifies a configuration specification for the second guest partition, which includes (1) an identification of a memory portion, which is allocated to the first guest partition, that is to be mapped into the second guest partition; and (2) a configuration of a virtual processor that is to be utilized by the second guest partition. The hypervisor creates the second guest partition based on the configuration specification.

Abstract: Hot restart of a hypervisor by replacing a running first hypervisor by a second hypervisor with minimally perceptible downtime to guest partitions. A first hypervisor is executed on a computing system. The first hypervisor is configured to create one or more guest partitions. During the hot restart, a service partition is generated and initialized with a second hypervisor. At least a portion of runtime state of the first hypervisor is migrated and synchronized to the second hypervisor using inverse hypercalls. After the synchronization, the second hypervisor is devirtualized from the service partition to replace the first hypervisor. Devirtualizing includes transferring control of hardware resources from the first hypervisor to the second hypervisor, using the previously migrated and synchronized runtime state.

Abstract: Hot restart of a hypervisor by replacing a running first hypervisor by a second hypervisor with minimally perceptible downtime to guest partitions. A first hypervisor is executed on a computing system. The first hypervisor is configured to create one or more guest partitions. During the hot restart, a service partition is generated and initialized with a second hypervisor. At least a portion of runtime state of the first hypervisor is migrated and synchronized to the second hypervisor using inverse hypercalls. After the synchronization, the second hypervisor is devirtualized from the service partition to replace the first hypervisor. Devirtualizing includes transferring control of hardware resources from the first hypervisor to the second hypervisor, using the previously migrated and synchronized runtime state.

Abstract: Hot restart of a hypervisor by replacing a running first hypervisor by a second hypervisor with minimally perceptible downtime to guest partitions. A first hypervisor is executed on a computing system. The first hypervisor is configured to create one or more guest partitions. During the hot restart, a service partition is generated and initialized with a second hypervisor. At least a portion of runtime state of the first hypervisor is migrated and synchronized to the second hypervisor using inverse hypercalls. After the synchronization, the second hypervisor is devirtualized from the service partition to replace the first hypervisor. Devirtualizing includes transferring control of hardware resources from the first hypervisor to the second hypervisor, using the previously migrated and synchronized runtime state.

Abstract: Hot restart of a hypervisor by replacing a running first hypervisor by a second hypervisor with minimally perceptible downtime to guest partitions. A first hypervisor is executed on a computing system. The first hypervisor is configured to create one or more guest partitions. During the hot restart, a service partition is generated and initialized with a second hypervisor. At least a portion of runtime state of the first hypervisor is migrated and synchronized to the second hypervisor using inverse hypercalls. After the synchronization, the second hypervisor is devirtualized from the service partition to replace the first hypervisor. Devirtualizing includes transferring control of hardware resources from the first hypervisor to the second hypervisor, using the previously migrated and synchronized runtime state.

Abstract: The disclosed technology is generally directed to the patching of executing binaries. In one example of the technology, at separate times, a plurality of hot patch requests is received. Each hot patch request of the plurality of hot patch requests includes a corresponding hot patch to hot patch the executing binary. A cardinality of the plurality of hot patch requested is greater than the fixed number of logical patch slots. with the executing binary continuing to execute, each time a request to apply a hot patch to the executing binary is received, the corresponding hot patch is assigned to an inactive logical patch slot of the fixed number of logical patch slots. The corresponding hot patch is executed from the assigned logical patch slot to hot patch the executing binary based on the corresponding hot patch.

Abstract: Speculative side channels exist when memory is accessed by speculatively-executed processor instructions. Embodiments use uncacheable memory mappings to close speculative side channels that could allow an unprivileged execution context to access a privileged execution context's memory. Based on allocation of memory location(s) to the unprivileged execution context, embodiments map these memory location(s) as uncacheable within first page table(s) corresponding to the privileged execution context, but map those same memory locations as cacheable within second page table(s) corresponding to the unprivileged execution context. This prevents a processor from carrying out speculative execution of instruction(s) from the privileged execution context that access any of this memory allocated to the unprivileged execution context, due to the unprivileged execution context's memory being mapped as uncacheable for the privileged execution context.

Abstract: The disclosed technology is generally directed to the patching of executing binaries. In one example of the technology, at separate times, a plurality of hot patch requests is received. Each hot patch request of the plurality of hot patch requests includes a corresponding hot patch to hot patch the executing binary. A cardinality of the plurality of hot patch requested is greater than the fixed number of logical patch slots. with the executing binary continuing to execute, each time a request to apply a hot patch to the executing binary is received, the corresponding hot patch is assigned to an inactive logical patch slot of the fixed number of logical patch slots. The corresponding hot patch is executed from the assigned logical patch slot to hot patch the executing binary based on the corresponding hot patch.

Abstract: Speculative side channels exist when memory is accessed by speculatively-executed processor instructions. Embodiments use uncacheable memory mappings to close speculative side channels that could allow an unprivileged execution context to access a privileged execution context's memory. Based on allocation of memory location(s) to the unprivileged execution context, embodiments map these memory location(s) as uncacheable within first page table(s) corresponding to the privileged execution context, but map those same memory locations as cacheable within second page table(s) corresponding to the unprivileged execution context. This prevents a processor from carrying out speculative execution of instruction(s) from the privileged execution context that access any of this memory allocated to the unprivileged execution context, due to the unprivileged execution context's memory being mapped as uncacheable for the privileged execution context.

Abstract: In embodiments of load balanced and prioritized data connections, a first connection is established to communicate first data from a first server to a second server over a public network, where the first data is communicated from a private network to a first device or subnet that is connected to the second server. A second connection is established to communicate second data from the first server to the second server over the public network, where the second data is communicated from the private network to a second device or subnet that is connected to the second server. The second server can distinguish the first data from the second data according to an authentication certificate field that identifies one of a first communication interface of the first connection or a second communication interface of the second connection.

Abstract: In embodiments of load balanced and prioritized data connections, a first connection is established to communicate first data from a first server to a second server over a public network, where the first data is communicated from a private network to a first device or subnet that is connected to the second server. A second connection is established to communicate second data from the first server to the second server over the public network, where the second data is communicated from the private network to a second device or subnet that is connected to the second server. The second server can distinguish the first data from the second data according to an authentication certificate field that identifies one of a first communication interface of the first connection or a second communication interface of the second connection.