Low latency events across VM boundaries

Abstract

Low latency events are transmitted across virtual machine boundaries. Based on an event signaling request of a first process running at a first virtual machine, the first virtual machine updates a shared register accessible by a second virtual machine. Updating the shared register includes updating a signal stored in the shared register. The first virtual machine sends an event signal message including a register identifier to the second virtual machine through a virtualization structure. The second virtual machine receives the event signaling message and identifies the register identifier from the message. Based on the register identifier, the second virtual machine reads the shared register and identifies a value of the signal stored in the shared register. Based on at least the value of the signal including the first value, the second virtual machine notifies a second process running at the second virtual machine with a signal.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to low-latency events across virtual machine boundaries. Background Art

[0002] Virtualization technology enables a single physical computing system (often referred to as a virtualization host, or simply a host) to run multiple virtual computer systems, commonly referred to as virtual machines (VMs). During operation, each VM emulates the computing hardware that supports the operating system being executed, including the applications being executed within the operating system. Typically, a virtualization host provides a virtualization structure commonly referred to as a hypervisor, which uses physical computing resources to emulate virtual resources for each VM. One goal of virtualization is to enable the hypervisor to provide isolation between VMs. Therefore, from the perspective of any given VM, the hypervisor provides the illusion that the VM exclusively interfaces with physical resources (e.g., (multiple) processors, memory, disk storage, etc.), even if the VM only interfaces the abstraction of those physical resources. Therefore, the hypervisor can share physical resources among multiple VMs. Frequently, the hypervisor operates at least two VMs: a privileged "host" VM and one or more "guest" VMs. The host virtual machine often has direct access to the physical hardware and is typically used to manage the guest VM.

[0003] By enabling operating systems (including applications) to be executed in isolation from each other at the same computer system, virtualization technology provides many security benefits and great flexibility. Nevertheless, it may be desirable for applications at different VMs to interact with each other. When networked, VMs can interact in the same way as different physical machines can interact - for example, via network packets, such as TCP / IP packets, UDP packets, etc. In addition, some virtual machine hypervisors can enable virtual machines to interact more directly, such as by enabling two VMs to create named pipes between each other (for example, using a visualized serial port). However, network packets and named pipes include overhead that introduces latency, and are therefore often too slow for certain types of communication. For example, it may be desirable to enable a VM (for example, a guest VM) to transmit audio data to another VM (for example, a host VM that can access audio input / output hardware). However, audio playback may require a latency of approximately 500 μs, which cannot be achieved with the current level of technology (such as by using network packets and named pipes). Summary of the invention

[0004] As mentioned in the background, existing inter-VM communication technologies (e.g., such as network communications and pipes) introduce amounts of latency that may be unacceptable for certain uses (e.g., such as audio). These delays are introduced due to the inherent overhead of using these communication channels. For example, in order to transmit given data from a first user mode process at a first VM to a second user mode process at a second VM via a network structure, the first user mode process may transmit the data to a network stack at the first VM, which then divides the data into blocks of appropriate packet sizes, builds network packets around each block of data (e.g., by adding Ethernet frames, TCP / IP or UDP headers, etc.), places the network packets in a send queue, and eventually removes the packets from the send queue and sends the network packets through the network structure. After receiving the packets at the network structure, the network stack at the second VM may place the packets in a receive queue, eventually remove the packets from the receive queue, decode the packets (e.g., parse TCP / IP or UDP headers, Ethernet frames, etc.), reassemble the blocks of data, and send the data to the second user mode process. While named pipes can achieve lower overhead than network communications, they similarly require data to be chunked and queued, resulting in processing overhead at both ends of the pipe.

[0005] At least some embodiments described herein overcome these deficiencies in existing inter-VM communications by providing mechanisms for very low overhead (and therefore low latency) signaling between multiple VMs, including mechanisms for processes running at those VMs to signal each other. These low latency signaling mechanisms provide a relatively small amount of shared memory between two (or more) VMs, which is used by these VMs to store state information. These low latency signaling mechanisms also enable these VMs to send lightweight inter-VM event signal messages to each other, so that a given VM can very quickly instruct another VM to check state information. In an embodiment, the state information includes one or more signal bits and one or more wake-up cookie bits; after receiving the event signal message, the receiving VM uses these (multiple) signal bits and these (multiple) wake-up cookie bits to determine whether the local process should be signaled in response to the event signal message. Embodiments can couple these low latency signaling mechanisms with additional shared memory to transmit actual data. Thus, for example, a first VM can write data to the additional shared memory, and then use the signaling mechanism described herein to very quickly instruct a second VM to read from the shared memory (or vice versa).

[0006] In accordance with the foregoing, some embodiments include methods, systems, and computer program products for transmitting low-latency events across virtual machine boundaries. A computer system provides a virtualization structure for hosting multiple virtual machines. Based on an event signaling request made by a first process running at a first virtual machine, the first virtual machine updates a shared register accessible by a second virtual machine. Updating the shared register includes updating a signal stored in the shared register. The first virtual machine sends an event signal message to the second virtual machine through the virtualization structure. The event signal message includes a register identifier of the shared register. The second virtual machine receives the event signaling message sent by the first virtual machine and identifies the register identifier from the message. Based on the register identifier, the second virtual machine reads the shared register, including identifying the value of the signal stored in the shared register. At least based on the value of the signal including a first value, the second virtual machine signals a second process running at the second virtual machine.

[0007] This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to describe the manner in which the above and other advantages and features of the present invention can be obtained, a more particular description of the invention of the above summary will be presented by reference to specific embodiments of the invention shown in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 An example computing environment that facilitates low-latency event delivery across virtual machine boundaries is illustrated;

[0010] Figure 2 A flow chart illustrating an example method for establishing low-latency communications between VMs;

[0011] Figure 3 A flow chart illustrating an example method for communicating low-latency events across VM boundaries is illustrated;

[0012] Figure 4 illustrates examples of data that may be stored in connection with an event signaling object and in connection with a register; and

[0013] Figure 5 An example of using wait cookies while transmitting low-latency events across virtual machine boundaries is illustrated. DETAILED DESCRIPTION

[0014] At least some embodiments described herein overcome the deficiencies of existing inter-VM communications by providing mechanisms for very low overhead (and therefore low latency) signaling between multiple VMs, including mechanisms for processes running at those VMs to signal each other. These low latency signaling mechanisms provide a relatively small amount of shared memory between two (or more) VMs, which are used by these VMs to store state information. These low latency signaling mechanisms also enable these VMs to send lightweight inter-VM event signal messages to each other, so that a given VM can very quickly instruct another VM to check state information. In an embodiment, the state information includes one or more signal bits and one or more wake-up cookie bits; after receiving the event signal message, the receiving VM uses these (multiple) signal bits and these (multiple) wake-up cookie bits to determine whether the local process should be signaled in response to the event signal message. Embodiments can couple these low latency signaling mechanisms with additional shared memory to transmit actual data. Thus, for example, a first VM can write data to the additional shared memory, and then use the signaling mechanism described herein to very quickly instruct a second VM to read from the shared memory (or vice versa).

[0015] To achieve the above, Figure 1 An example computing environment 100 that facilitates the transmission of low-latency events across virtual machine boundaries is illustrated. As shown, the computing environment 100 includes computing hardware 101, including, for example, one or more processors 102, system memory 103, and any other hardware 104 suitable for the particular computing environment 100 in which the embodiments described herein are implemented (e.g., persistent storage devices, network communication hardware, user input / output hardware, audio input / output hardware, etc.).

[0016] As shown, hardware 101 is configured as a virtualization host that provides a virtualization structure in the form of a hypervisor 105. As previously discussed, a hypervisor typically uses physical computing resources to support multiple VMs. Figure 1, hypervisor 105 is shown as supporting VMs 106a-106n (generally referred to as VMs 106) by exposing portions of hardware 101 to VMs 106 as virtualized hardware resources, VMs 106 including at least VM 106a and VM 106b. In doing so, hypervisor 105 enforces isolation between VMs 106, thereby creating logical boundaries between VMs. For example, hypervisor 105 may divide resources of processor 102 among VMs 106 (e.g., with respect to allocating different processing time periods among VMs 106, allocating different individual processor cores among VMs 106, etc.), and hypervisor 105 may divide and allocate different portions of memory 103 to each VM 106 while preventing a given VM 106 from accessing memory allocated to other VMs 106.

[0017] Using virtualized hardware resources, each VM 106 can execute an operating system kernel and one or more user mode processes (e.g., operating system processes, and / or third-party processes). Figure 1 VM 106a and VM 106b are shown, each VM providing a kernel mode of operation (i.e., executing an operating system kernel and associated system processes), and a user mode of operation (i.e., executing user mode processes). In embodiments, VMs 106 may all execute the same type of operating system kernel or may execute completely different operating system kernels. Also, for completeness, Figure 1 While both user mode and kernel mode are illustrated, embodiments herein may operate entirely within kernel mode, entirely within user mode, or (as shown) in a combination of user mode and kernel mode.

[0018] exist Figure 1 , VM 106a and VM 106b are configured to transmit low latency events across a boundary 107 separating the VMs. For example, Figure 1 The memory 103 is illustrated as including a portion of the memory configured as one or more state registers 108. Following line 108a, these state registers 108 are also conceptually illustrated as state registers 108' - state registers 108' are illustrated as logically bridging the boundary 107 between VM 106a and VM 106b. Thus, state registers 108' are accessible to both VM 106a and VM 106b. In an embodiment, and as shown, state registers 108' may include a plurality of registers, each of which is capable of storing event state information for a different logical data connection (e.g., event) between VM 106a and VM 106b.

[0019] VM 106a and VM 106b are also shown to include corresponding event signaling (ES) providers 109 (i.e., ES provider 109a within VM 106a, and ES provider 109b within VM 106b), and corresponding hypervisor drivers 110 (i.e., hypervisor driver 110a within VM 106a, and hypervisor driver 110b within VM 106b). Typically, ES providers 109 are responsible for creating local event signaling objects (e.g., VM106b-Event1, VM106b-Event2, etc.) at their corresponding VMs, and for synchronizing these local ES objects with appropriate state registers 108' (e.g., as shown by arrows between ES providers 109a / 109b and state registers 108'). Typically, the hypervisor driver 110 is responsible for transmitting event signal messages between two (or more) VMs via the bus 105a provided by the hypervisor 105 (e.g., based on a request made by an ES provider 109 within the same VM as the hypervisor driver, as indicated by the arrows between the ES provider 109a and the hypervisor driver 110a and between the ES provider 109b and the hypervisor driver 110b). Figure 1 106 as separate components, but the ES provider 109 and the hypervisor driver 110 at a given VM 106 may be part of a unified component.

[0020] Although the aforementioned components (i.e., state register 108', ES provider 109, and hypervisor driver 110) provide a framework for transmitting low-latency events across boundary 107, these components generally operate to facilitate event signaling between other software components. Thus, VM 106a is shown as including one or more corresponding processes 111a, and VM 106b is shown as including one or more corresponding processes 111b. These processes 111a / 111b call ES providers 109a / 109b, respectively, to signal each other over boundary 107 (e.g., as indicated by the arrows between process 111a and ES provider 109a, and the arrows between process 111b and ES provider 109b).

[0021] Although the process 111 is shown as being in user mode, and although the state register 108', ES provider 109, and hypervisor driver 110 are shown as being in kernel mode, it is again emphasized that embodiments may operate entirely in kernel mode, entirely in user mode, or in a combination of user mode and kernel mode. As such, each of these components / data structures (i.e., the process 111, state register 108', ES provider 109, and hypervisor driver 110) may exist individually or collectively in user mode and / or kernel mode.

[0022] like Figure 1 As shown, memory 103 may also include a portion of shared memory 112 that is configured by hypervisor 105 to be accessible to both VM 106a and VM 106b. Thus, following line 112a, the shared memory 112 (if present) is also conceptually shown as shared memory 112', which also logically bridges the boundary 107 between VM 106a and VM 106b. As shown by the arrows between process 111a / 111b and shared memory 112', the shared memory 112' may be accessed (i.e., read and / or written) by process 111a / 111b.

[0023] Figure 2 A flow chart of an example method 200 for establishing low-latency communications between VMs is illustrated. Figure 1 Method 200 is described with reference to components and data structures of an example computing environment 100. Thus, embodiments of method 200 may be implemented at a computer system (e.g., hardware 101) that provides a virtualization structure (e.g., hypervisor 105) that hosts a plurality of virtual machines (e.g., VM 106), including a first virtual machine (e.g., VM 106a) and a second virtual machine (e.g., VM 106b).

[0024] exist Figure 2, method 200 includes actions / steps performed by two different VMs - VM1 in the left column and VM2 in the right column. In the following description, VM1 will be described using VM 106a, while VM2 will be described using VM 106b, but it should be understood that method 200 can operate equally well if the other way around. In an embodiment, the actions performed by VM1 can be performed by a VM with elevated privileges (such as a host VM). Therefore, in an embodiment, VM1 (i.e., VM106a) can be a host VM, while VM2 (i.e., VM 106b) is a guest VM. It can be expected that VM1 is a host VM so that it can have elevated access rights, such as privileged access to hardware (e.g., audio input / output hardware in other hardware 104). However, it is also possible that both of the VMs are host VMs, or both of the VMs are guest VMs.

[0025] like Figure 2 As shown, method 200 includes an action 201 of determining an event identifier at VM1. For example, as part of initiating a low-latency communication session (event) with VM106b, VM 106a may determine an event identifier of an event signaling object that will be used to manage the session. The event identifier may be any type of identifier as long as it uniquely identifies the session. Thus, the event identifier may include one or more globally unique identifiers (GUIDs), one or more universally unique identifiers (UUIDs), and the like. In an embodiment, the event identifier may include the identity of VM 106b (e.g., by name, by GUID, by UUID, and the like) and an identifier for a specific low-latency communication session with VM 106b. For purposes of illustration, if this is the first low-latency communication session with VM 106b, VM 106a may select an event identifier such as "VM106b-Event1". The specific components within VM 106a that determine the event identifier may vary depending on the implementation, but in an embodiment, the event identifier may be determined by process 111a as part of initiating communications with process 111b, or the event identifier may be determined by ES provider 109a based on a call from process 111a.

[0026] Based on the event identifier having been determined in action 201, method 200 includes an action 202 of creating a local event signaling object for the event identifier at VM1. For example, ES provider 109a may create a local ES object based on the event identifier. Figure 1108' as an object labeled "VM106b-Event1" within ES provider 109a. ES provider 109a can create the ES object based on, for example, an application programming interface (API) call received from process 111a. In connection with action 202, method 200 also includes action 203 of associating a state register with an event signaling object. For example, as shown in state register 108', ES provider 109a can assign a specific register to the "VM106b-Event1" event. Although action 202 and action 203 are shown as occurring serially, an implementation can perform these actions in parallel or even in reverse order.

[0027] In view of acts 202 and 203, it will be appreciated that embodiments of method 200 may include creating, at the first virtual machine, a first event signaling object corresponding to the event identifier, and associating the shared register with the first event signaling object.

[0028] Also based on the event identifier having been determined in action 201, method 200 includes an action 204 of sending the event identifier to VM2. For example, VM 106a can transmit the event identifier to VM 106b. The specific components within VM 106a that perform this communication can vary depending on the implementation, but in an embodiment, the communication can be performed by process 111a (again, as part of initiating communication with process 111b). Correspondingly, method 200 also includes an action 205 of receiving, at VM2, the event identifier from VM1. For example, VM 106b can receive the event identifier from VM 106a. Again, the specific components within VM 106b that receive this communication can vary depending on the implementation, but in an embodiment, receiving this communication can be performed by process 111b.

[0029] It is worth noting that the arrow between action 204 and action 205 is shown using a dashed line, while all other arrows are shown using a thick solid line (similar to Figure 1 105a). This is to indicate that communication of the event identifier may occur using a communication channel other than bus 105a. For example, the event identifier may be transmitted via a network communication channel established between process 111a and process 111b, transmitted via shared memory 112', etc. In an embodiment, the communication channel is a channel (e.g., such as a network channel) that may be created and maintained by the operating system itself, and may therefore be referred to as an operating system-level communication channel. In an embodiment, this is in contrast to bus 105a, which is created and maintained in contact with hypervisor 105, and may therefore be referred to as a hypervisor-level communication channel.

[0030] In view of actions 204 and 205, it will be appreciated that in an embodiment of method 200, the first communication channel may include an operating system level communication channel, and the second communication channel may include a hypervisor level communication channel. Additionally, an embodiment of method 200 may include: at the first virtual machine, transmitting an event identifier to the second virtual machine via the first communication channel; and, at the second virtual machine, receiving the event identifier from the first virtual machine via the first communication channel.

[0031] Based on VM2 having received the event identifier (act 205), method 200 includes an act 206 of creating a local event signaling object at VM2 from the received event identifier. For example, similar to act 202, ES provider 109b may create a local ES object based on the event identifier. Figure 1 106b-Event1". The ES provider 109b may create the ES object based on, for example, an API call received from the process 111b. In view of action 206, it will be appreciated that an embodiment of the method 200 may include creating a second event signaling object corresponding to the event identifier at the second virtual machine.

[0032] Method 200 also includes an action 207 of sending the received event identifier to VM1 at VM2, and a corresponding action 208 of receiving the event identifier from VM2 at VM1. It is noteworthy that the arrow connecting actions 207 and 208 uses a thick solid line, which means that this time the event identifier is sent via a hypervisor-level communication channel. Thus, for example, actions 207 and 208 may include the hypervisor driver 110b (e.g., based on a request from the ES provider 109b) sending the event identifier via bus 105a, and the hypervisor driver 110a receiving the event identifier at bus 105a. In view of actions 207 and 208, it will be understood that an embodiment of method 200 may include: at a second virtual machine, sending an event identifier to a first virtual machine via a second communication channel; and, at the first virtual machine, receiving an event identifier from a second virtual machine via a second communication channel.

[0033] Method 200 also includes an act 209 of authenticating the received event identifier at VM1. For example, ES provider 109a can verify that there is an ES object corresponding to the received event identifier (i.e., ES object "VM106b-Event1"). ES provider 109a can also verify that the ES object corresponds to the VM from which the event identifier was received.

[0034] If the authentication of action 209 is successful, method 200 also includes an action 210 of sending a status register index to VM2 at VM1, and a corresponding action 211 of receiving a status register index from VM2 at VM2. Again, the arrows connecting action 210 and action 211 use a thick solid line, meaning that the status register index is sent through a hypervisor-level communication channel. Thus, for example, actions 210 and 211 may include the hypervisor driver 110a (e.g., based on a request from the ES provider 109a) sending an index to the status register 108' corresponding to VM106b-Event1 via bus 105a, and the hypervisor driver 110b receiving the register index at bus 105a.

[0035] Method 200 also includes an action 212a at VM1 and an action 212b at VM2, which transmits (multiple) cross-domain events via associated state registers. For example, ES provider 109a and ES provider 109b may transmit event signal messages via bus 105a while transmitting actual event signals via state register 108' corresponding to VM106b-Event1. Figure 3 Method 300 of , which continues after act 211 , describes this process in more detail.

[0036] It is worth noting that actions 201-211 can be repeated to create multiple communication sessions (events). For example, Figure 1 It is shown that actions 201-211 can be repeated to create a second event for VM 106b (ie, for Figure 1 In addition, method 200 can be applied to multiple VMs in the right column. For example, Figure 1 It is shown that VM1 may also participate in method 200 with VM 106n to create a local ES object for "VM106n-Event1" and associate registers.

[0037] In view of actions 209-211, it will be understood that an embodiment of method 200 may include: at the first virtual machine, authenticating the event identifier, and sending the register identifier to the second virtual machine via the second communication channel. An embodiment of method 200 may also include: at the second virtual machine, receiving the register identifier from the first virtual machine via the second communication channel.

[0038] As will be understood by those of ordinary skill in the art, method 200 operates to cause VM1 to function to initiate and manage the creation of an event, and to cause VM2 to participate in the process. As such, VM1 can be considered a host or master, and VM2 can be considered a client or slave. For example, VM1 first establishes an event identifier, creates a local ES object for the event identifier, allocates a state register for the event identifier, and sends the event identifier to VM2. After receiving the event identifier, VM2 creates its own local ES object for the event identifier, and sends the event identifier back to VM1 via a privileged channel. VM1 then verifies the validity of the event identifier and sends a register index to VM2 via a privileged channel only if the event identifier is valid. It is noteworthy that VM2 cannot participate in an event without first receiving an event identifier from VM1. In addition, VM2 cannot cause VM1 (via an ES object or a state register) to allocate any memory by sending an invalid event identifier to VM1. As such, method 200 is resilient to a denial of service (DoS) attack against VM1 that would cause VM1 to allocate memory.

[0039] As mentioned previously, once a communication session (event) has been established between VM1 and VM2 (using actions 201-211), they can communicate (multiple) cross-domain events (i.e., actions 212a and 212b) via the associated state registers. To demonstrate this process, Figure 3 A flow chart of an example method 300 for transmitting low-latency events across VM boundaries is illustrated. Figure 1 Method 300 is described with reference to components and data structures of an example computing environment 100 of FIG. 1 , and continues after act 211 of method 200 (and thus may be viewed as an extension of method 200). Similar to method 200, embodiments of method 300 may be implemented at a computer system (e.g., hardware 101) that provides a virtualization structure (e.g., hypervisor 105) that hosts a plurality of virtual machines (e.g., VM 106), including a first virtual machine (e.g., VM 106a) and a second virtual machine (e.g., VM 106b).

[0040] Method 300 includes actions / steps performed by the signaling VM in the left column, and actions / steps performed by the receiving VM in the right column. Therefore, the identity of the VM in each column will depend on which VM initiates the transmission of a particular signal, and which VM is the recipient of the signal. In the following description, VM 106b will be described as a signaling VM, and VM 106a will be described as a receiving VM. However, an embodiment may allow both VM 106a and VM 106b to initiate method 300 as a signaling VM at almost any time. As such, method 300 can be used for both one-way signaling (e.g., from VM 106b to VM 106a) and two-way signaling (e.g., between VM 106a and VM 106b).

[0041] If there is shared memory 112 ', method 300 can start with action 301 at a signaling VM that is synchronized with the shared memory. For example, if process 111a at VM 106a and process 111b at VM 106b use shared memory 112 ' to transmit data, process 111b at VM 106b can update shared memory 112 ' with data to be read by process 111a when it is signaled. As a more specific example, assume that VM 106a is a host VM with privileged access to audio hardware (i.e., other hardware 104). In this case, process 111b at VM 106b may need to send audio data to process 111a at VM 106a in return. Like this, in action 301, process 111b can write to shared memory 112 'part of the audio data to be transmitted to process 111a. With regard to act 301 , it will be appreciated that embodiments of method 300 may include a first process running at a first virtual machine synchronized with a shared memory.

[0042] Regardless of whether action 301 is actually performed, method 300 includes action 302 of calling the event signaling provider at the signaling VM. For example, process 111b may make an API call to ES provider 109b, requesting a request for (previously used Figure 2 Event VM106b-Event1) created by actions 201-211 in the process 111b sends a signal to VM 106a. In an embodiment, one or more processes in process 111b can then block / sleep, waiting for a response signal.

[0043] Method 300 also includes the action of updating local event signaling object (action 303) and updating status register (action 304) at signaling VM. Although action 303 and action 304 are shown as occurring in parallel, it is realized that these actions can be performed serially (in any order). For example, ES provider 109b can update the ES object corresponding to VM106b-Event1 in provider 109b, and the register corresponding to VM106b-Event1 in status register 108'. This can include updating ES object and register in parallel, or updating one structure (e.g., ES object) in these structures and copying its (multiple) value to another structure (e.g., register). No matter what the exact mechanism for updating ES object and register is, the result is that both of them store the same (multiple) value. Considering action 303 and action 304, it will be understood that an embodiment of method 300 can include that the first virtual machine will synchronize the first event signaling object at the first virtual machine with a shared register.

[0044] The specific data updated in the ES object and register varies depending on the implementation. However, in an embodiment, the register (and similarly, the ES object) stores one or more bits corresponding to the signal, and one or more bits corresponding to the wakeup cookie. For example, Figure 4 An example 400 of data that can be stored in association with an ES object and a register according to one or more embodiments is illustrated. In particular, Figure 4 Including a first table 401, the first table 401 shows that the ES object can store at least an event identifier for the ES object, a register index (i.e., the index of the register associated with the ES object in action 203), a signal, and a wake-up cookie. On the other hand, table 402 shows that the register can store at least a signal and a wake-up cookie. In this example, updating the local event signaling object (action 303) and updating the status register (action 304) may include updating one or more signal bits, and updating one or more wake-up bits in the ES object and register corresponding to VM106b-Event1. In an embodiment, the signal may include a binary indication (e.g., set or clear), and the wake-up cookie may include an incremental value. Examples of the interaction of signals and wake-up cookies will be contacted later. Figure 5 and is described.

[0045] In view of action 303, it will be understood that an embodiment of method 300 may include: at the first virtual machine and based on a request made by event signaling of the first process running at the first virtual machine, updating a shared register accessible by the second virtual machine, updating the shared register includes updating a signal stored in the shared register. Embodiments of method 300 may also include updating a wakeup cookie.

[0046] Back to Figure 3 , method 300 also includes an action 305 of sending a signal to a receiving VM at a signaling VM, and a corresponding action 306 of receiving a signal from a signaling VM at a receiving VM. It is noteworthy that the arrows connecting action 305 and action 306 use a thick solid line, meaning that the event identifier is sent through a super supervisor-level communication channel (e.g., bus 105a). For example, a super supervisor driver 110b can (e.g., based on a request from an ES provider 109b) send an event signal message through bus 105a, and a super supervisor driver 110a receives an event signal message at bus 105a. It is noteworthy that the event signal message can be extremely lightweight and may only include a status register index as a payload. Considering action 305, it will be understood that an embodiment of method 300 may include sending an event signal message to a second virtual machine through a virtualization structure at a first virtual machine, the event signal message including a register identifier of a shared register. Similarly, an embodiment of method 300 may include receiving an event signaling message sent by a first virtual machine at a second virtual machine and identifying a register identifier from the message.

[0047] Method 300 also includes an action 307 of reading a state register at a receiving VM. For example, based on the event signal message received in action 306, ES provider 109a can read the appropriate register in state register 108' to obtain (multiple) values ​​placed in the state register by VM 106b in action 304-such as signal values, wake-up cookie values, etc. In an embodiment, ES provider 109a identifies the appropriate state register based on the register index included in the event signal message. However, ES provider 109a can identify the appropriate register in some other way, such as based on an event identifier (e.g., VM106b-Event1). Considering action 307, it will be understood that an embodiment of method 300 may include, at a second virtual machine, and based on a register identifier, reading a shared register, including identifying the value of a signal stored in a shared register. In addition, an embodiment of method 300 may include at a second virtual machine, and based on a register identifier, identifying the value of a wake-up cookie stored in a shared register.

[0048] Method 300 also includes an action 308 of reading and updating a local event signaling object at the receiving VM. For example, ES provider 109a may read one or more values ​​stored in an appropriate ES object (e.g., an ES object corresponding to VM106b-Event1). Then, (if the value read from the register is different from the value stored locally, then) ES provider 109a may update one or more of the values ​​stored in the ES object using the corresponding value(s) read from the status register in action 307. For example, ES provider 109a may read and update one or more values ​​of a signal value, a wake-up cookie value, etc. In view of action 308, it will be understood that an embodiment of method 300 may include a second virtual machine synchronizing a second event signaling object at the second virtual machine with a shared register.

[0049] Method 300 also includes an action 309 of determining whether a signal exists at the receiving VM. For example, the ES provider 109a may determine whether the value of the signal read from the status register in action 307 indicates that the signal should be sent to one or more processes. For illustration, if one or more signal bits store a binary value (e.g., a single bit), then: if the binary value is set (e.g., set to 1), the signal may be indicated. If the signal is indicated (e.g., if the signal bit is set to 1), following the "yes" arrow from the decision box, method 300 may include an action 311 of signaling a process at the receiving VM. For example, the ES provider 109a may send a signal to process 111a. In an embodiment, the signal wakes up at least one process in process 111a and causes the process to take some action in response to the signal. In view of actions 309 and 311, it will be understood that an embodiment of method 300 may include a second process running at the second virtual machine and at least based on the value of the signal including a first value to signal a second process running at the second virtual machine.

[0050] As shown, if shared memory 112' exists, method 300 may include an action 312 of synchronizing with the shared memory at the receiving VM. For example, process 111a may read shared memory 112' to obtain data written by process 111b in action 301. Therefore, if VM 106a is a host VM with privileged access to audio hardware (i.e., other hardware 104), process 111a may play back audio data obtained from the shared memory. Regardless of whether action 312 exists, method 300 may end at action 313. In view of action 312, it will be understood that an embodiment of method 300 may include: based on the second process having been signaled, a second process running at a second virtual machine synchronizes with the shared memory.

[0051] Returning to act 309, if the signal is not indicated (e.g., if the signal bit is set to 0), following the "no" arrow from the decision box, the method 300 may include an act 310 of determining at the receiving VM whether the wakeup cookie has changed. For example, the ES provider 109a may determine whether the value of the wakeup cookie read from the state register in act 307 is different from the value read from the local ES object in act 308. If this is the case, following the "yes" arrow from the decision box, the method 300 may continue to act 311 (and subsequent actions) of signaling the process at the receiving VM. Otherwise, if the wakeup cookie has not changed, following the "no" arrow from the decision box, the method 300 may end at act 313.

[0052] In view of actions 310 and 311, it will be understood that an embodiment of method 300 may include: at a second virtual machine, comparing a first value of the wake-up cookie with a second value of the locally stored wake-up cookie, and wherein the second virtual machine notifies a second process running at the second virtual machine with a signal only when the first value of the wake-up cookie is different from the second value of the locally stored wake-up cookie.

[0053] It is worth noting that the ES provider of the receiving VM may not wake up every time an event signal message is sent to it. For example, the receiving ES provider may not be allocated processor time when an event signal message is received, the receiving ES provider may be blocked by an interrupt when an event signal message is received, the kernel at the receiving VM may choose not to forward the event signal message to the receiving ES provider, etc. Like this, the receiving ES provider may miss an event signal message sent to it by another VM. Even if one or more event signal messages are missed, the use of the wake-up cookie in action 310 ensures the correct behavior of the receiving ES provider.

[0054] As a demonstration, Figure 5 An example 500 of using wait cookies while transmitting low-latency events across virtual machine boundaries is illustrated. In particular, example 500 includes three timing diagrams 501-503. Timing diagram 501 corresponds to a first ES object at a first VM (e.g., an ES object at ES provider 109a corresponding to event VM106b-Event1), timing diagram 502 corresponds to a state register (e.g., a state register corresponding to event VM106b-Event1), and timing diagram 503 corresponds to a second ES object at a second VM (e.g., an ES object at ES provider 109b corresponding to event VM106b-Event1).

[0055] like Figure 5As shown, at time T1, the values ​​of the signals in both the ES object and the wakeup cookie and the value of the wakeup cookie are both 0 seconds. For example, this may be the state of these data structures after initially setting up event VM106b-Event1 (e.g., after act 211 of method 200). Figure 5 In the example of , each time an ES provider signals another ES provider, it sends a pair of signaling events: a first signaling event that sets the signal bit (i.e., signals another VM to wake up the process), and another signaling event that clears the signal bit. The wakeup cookie is incremented for each signal event pair. For example, at time T2, the first ES provider at the first VM updates the signal and wakeup cookies in both its local ES object and registers to 1, and then at time T3, the ES provider updates the signal in both its local ES object and registers to 0.

[0056] As shown, if the second ES provider at the second VM wakes up at time T4, it reads the signal from the register as 0 and the wakeup cookie as 1 (and updates its local copy with these values). If method 300 lacks action 310, then at time T4, the second ES provider will see a zero value for the signal in action 309, and will not signal the process at action 311. However, since method 300 includes action 310, the second ES provider sees that the cookie value just read from the register is different from its locally stored wakeup cookie, and therefore it proceeds to signal the process at action 311. Like this, even if the second ES provider does not wake up for each update made by the first ES provider, the signal sent by the first VM is not lost.

[0057] In an embodiment, if the receiving ES provider misses multiple setup / clear cycles, it wakes up the signaled process only once. Figure 5 . Here, before the second ES provider wakes up at time T9, the first ES provider completes two setup / clear cycles (i.e., time T5-T8). However, following method 300, the second ES provider will only signal the process once when it wakes up at time T9. It is worth noting that by configuring the ES provider to use a wake-up cookie to signal the process only once each time the ES provider wakes up - even if another VM has sent multiple signals since the last ES provider woke up - method 300 provides resilience against DoS attacks because it can rate limit how often the signal process can be woken up by another virtual machine. Times T10-T12 demonstrate that signaling including the use of a wake-up cookie can also operate for signaling in the other direction.

[0058] Therefore, by providing a mechanism for very low overhead (and therefore low latency) signaling between multiple VMs, the embodiments herein overcome the deficiencies of existing inter-VM communication technologies. These low latency signaling mechanisms use shared memory (i.e., registers) between VMs to store state information, such as signals and wake-up cookies. These low latency signaling mechanisms also enable these VMs to send lightweight inter-VM event signal messages to each other, so that a given VM can very quickly instruct another VM to check the state information in the registers. After receiving the event signal message, the receiving VM uses the signal and the wake-up cookie to determine whether it should signal the local process in response to the event signal message. These low latency signaling mechanisms can be coupled with additional shared memory to transmit actual data.

[0059] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above, or the order of the acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0060] Embodiments of the present invention may include or utilize a dedicated or general-purpose computer system, which includes computer hardware, such as, for example, one or more processors and system memory, as discussed in more detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or dedicated computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media. Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct computer-readable media: computer storage media and transmission media.

[0061] Computer storage media are physical storage media that store computer-executable instructions and / or data structures. Physical storage media include computer hardware, such as RAM, ROM, EEPROM, solid-state drives ("SSD"), flash memory, phase-change memory ("PCM"), optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other (multiple) hardware storage devices that can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by general-purpose or special-purpose computer systems to implement the functionality disclosed in the present invention.

[0062] Transmission media can include networks and / or data links, which can be used to carry program codes in the form of computer executable instructions or data structures, and can be accessed by general or special computer systems."Network" is defined as one or more data links that support electronic data transmission between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system through a network or another communication connection (hardwired, wireless or or a combination of hardwired or wireless), the computer system can regard the connection as a transmission medium. The above combination should also be included in the scope of computer-readable media.

[0063] In addition, upon reaching various computer system components, program code in the form of computer executable instructions or data structures can be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., "NIC") and then ultimately transferred to computer system RAM and / or less volatile computer storage media at the computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0064] Computer executable instructions include, for example, instructions that, when executed on one or more processors, cause a general purpose computer system, a special purpose computer system, or a special purpose processing device to perform a certain function or group of functions. Computer executable instructions may be, for example, binary, intermediate format instructions (such as assembly language), or even source code.

[0065] Those skilled in the art will appreciate that the present invention can be put into practice in a network computing environment with multiple types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. The present invention can also be put into practice in a distributed system environment, in which both local and remote computer systems linked by a network (by a hardwired data link, a wireless data link, or by a combination of a hardwired and wireless data link) perform tasks. Like this, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, a program module can be located in both local and remote memory storage devices.

[0066] Those skilled in the art will also appreciate that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the following claims, "cloud computing" is defined as a model for supporting on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

[0067] The cloud computing model can consist of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured services, etc. The cloud computing model can also appear in the form of various service models, such as software as a service ("SaaS"), platform as a service ("PaaS"), and infrastructure as a service ("IaaS"). The cloud computing model can also be deployed using different deployment models, such as private cloud, community cloud, public cloud, hybrid cloud, etc.

[0068] Some embodiments, such as cloud computing environments, may include a system that includes one or more hosts, each of which is capable of running one or more virtual machines. During operation, the virtual machine emulates an operating computing system, supporting an operating system and possibly one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machine using physical resources abstracted from the virtual machine's view. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even if the virtual machine is only interfacing with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing capacity, memory, disk space, network bandwidth, media drives, and the like.

[0069] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments should be considered in all respects as merely illustrative and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes that fall within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method implemented at a computer system, the computer system comprising one or more processors, the computer system providing a virtualization structure for hosting a plurality of virtual machines, the plurality of virtual machines comprising a first virtual machine and a second virtual machine, the method for transmitting a low-latency event across a virtual machine boundary, the method comprising: At the first virtual machine: Based on an event signaling request made by a first process running at the first virtual machine, updating a shared register accessible by the second virtual machine, the updating the shared register comprising updating a signal and a first wakeup cookie stored in the shared register; as well as Sending an event signal message to the second virtual machine through the virtualization structure, the event signal message including a register identifier of the shared register; and at the second virtual machine: receiving the event signal message sent by the first virtual machine, and identifying the register identifier from the event signal message; Based on the register identifier, reading the shared register includes identifying a value of the signal stored in the shared register and identifying a first value of the first wakeup cookie stored in the shared register; comparing the first value of the first wake-up cookie with a second value of a second wake-up cookie stored at the second virtual machine; and Based at least on the value of the signal, and only if the first value of the first wake-up cookie is different from the second value of the second wake-up cookie, a second process running at the second virtual machine is signaled.

2. The method according to claim 1, further comprising: The first virtual machine synchronizes a first event signaling object at the first virtual machine with the shared register; as well as The second virtual machine synchronizes a second event signaling object at the second virtual machine with the shared register.

3. The method according to claim 1, further comprising: Before sending the event signal message, the first process running at the first virtual machine is synchronized with a shared memory; as well as Based on the second process having been signaled, the second process running at the second virtual machine synchronizes with the shared memory.

4. The method according to claim 1, further comprising: At the first virtual machine: transmitting an event identifier to the second virtual machine via the first communication channel; Creating a first event signaling object corresponding to the event identifier; associating the shared register with the first event signaling object; receiving the event identifier from the second virtual machine via a second communication channel; authenticating the event identifier; as well as After authenticating the event identifier, sending the register identifier to the second virtual machine via the second communication channel; as well as At the second virtual machine: receiving, via the first communication channel, the event identifier from the first virtual machine; Creating a second event signaling object corresponding to the event identifier; sending the event identifier to the first virtual machine through the second communication channel; as well as The register identifier is received from the first virtual machine via the second communication channel.

5. The method of claim 4, wherein the first communication channel is an operating system level communication channel, and wherein the second communication channel is a hypervisor level communication channel.

6. The method of claim 4, wherein the first process and the second process comprise user mode processes, and wherein the first event signaling object and the second event signaling object comprise kernel mode data structures.

7. A computer system comprising: one or more processors; as well as One or more computer-readable media having computer-executable instructions stored thereon, the computer-executable instructions being executable by the one or more processors to cause the computer system to provide a virtualization structure for hosting a plurality of virtual machines including a first virtual machine and a second virtual machine, and to facilitate transmission of low-latency events across virtual machine boundaries, the computer-executable instructions comprising instructions executable to cause the computer system to at least perform: At the first virtual machine: Based on an event signaling request made by a first process running at the first virtual machine, updating a shared register accessible by the second virtual machine, the updating the shared register comprising updating a signal and a first wakeup cookie stored in the shared register; as well as Sending an event signal message to the second virtual machine through the virtualization structure, wherein the event signal message includes a register identifier of the shared register; as well as At the second virtual machine: receiving the event signal message sent by the first virtual machine, and identifying the register identifier from the event signal message; Based on the register identifier, reading the shared register includes identifying a value of the signal stored in the shared register and identifying a first value of the first wakeup cookie stored in the shared register; comparing the first value of the first wake-up cookie with a second value of a second wake-up cookie stored at the second virtual machine; and Based at least on the value of the signal, and only if the first value of the first wake-up cookie is different from the second value of the second wake-up cookie, a second process running at the second virtual machine is signaled.

8. The computer system of claim 7, wherein the first virtual machine synchronizes a first event signaling object at the first virtual machine with the shared register, and the second virtual machine synchronizes a second event signaling object at the second virtual machine with the shared register.

9. A computer system according to claim 7, wherein before sending the event signal message, the first process running at the first virtual machine is synchronized with the shared memory, and based on the second process having been notified by a signal, the second process running at the second virtual machine is synchronized with the shared memory.

10. The computer system of claim 7, wherein the computer executable instructions further comprise the following instructions, wherein the instructions are executable to cause the computer system to: At the first virtual machine: transmitting an event identifier to the second virtual machine via the first communication channel; Creating a first event signaling object corresponding to the event identifier; associating the shared register with the first event signaling object; receiving the event identifier from the second virtual machine via a second communication channel; authenticating the event identifier; as well as After authenticating the event identifier, sending the register identifier to the second virtual machine via the second communication channel; as well as At the second virtual machine: receiving, via the first communication channel, the event identifier from the first virtual machine; Creating a second event signaling object corresponding to the event identifier; sending the event identifier to the first virtual machine through the second communication channel; as well as The register identifier is received from the first virtual machine via the second communication channel.

11. The computer system of claim 10, wherein the first communication channel is an operating system level communication channel, and wherein the second communication channel is a hypervisor level communication channel.

12. The computer system of claim 10, wherein the first process and the second process comprise user mode processes, and wherein the first event signaling object and the second event signaling object comprise kernel mode data structures.

13. A computer program product, comprising computer executable instructions, the computer executable instructions being executable by one or more processors to cause a computer system to provide a virtualization structure for hosting a plurality of virtual machines including a first virtual machine and a second virtual machine, and facilitating the transmission of low-latency events across virtual machine boundaries, the computer executable instructions comprising instructions, the instructions being executable to cause the computer system to at least perform: At the first virtual machine: Based on an event signaling request made by a first process running at the first virtual machine, updating a shared register accessible by the second virtual machine, the updating the shared register comprising updating a signal and a first wakeup cookie stored in the shared register; as well as Sending an event signal message to the second virtual machine through the virtualization structure, the event signal message including a register identifier of the shared register; and at the second virtual machine: receiving the event signal message sent by the first virtual machine, and identifying the register identifier from the event signal message; Based on the register identifier, reading the shared register includes identifying a value of the signal stored in the shared register and identifying a first value of the first wakeup cookie stored in the shared register; comparing the first value of the first wake-up cookie with a second value of a second wake-up cookie stored at the second virtual machine; and Based at least on the value of the signal, and only if the first value of the first wake-up cookie is different from the second value of the second wake-up cookie, a second process running at the second virtual machine is signaled.

14. The computer program product of claim 13, wherein the computer instructions further comprise instructions executable to cause the computer system to: At the first virtual machine: transmitting an event identifier to the second virtual machine via the first communication channel; Creating a first event signaling object corresponding to the event identifier; associating the shared register with the first event signaling object; receiving the event identifier from the second virtual machine via a second communication channel; authenticating the event identifier; as well as After authenticating the event identifier, sending the register identifier to the second virtual machine via the second communication channel; as well as At the second virtual machine: receiving, via the first communication channel, the event identifier from the first virtual machine; Creating a second event signaling object corresponding to the event identifier; sending the event identifier to the first virtual machine through the second communication channel; as well as The register identifier is received from the first virtual machine via the second communication channel.

15. The computer program product of claim 14, wherein the first communication channel is an operating system level communication channel, and wherein the second communication channel is a hypervisor level communication channel.

16. The computer program product of claim 14, wherein the first process and the second process comprise user mode processes, and wherein the first event signaling object and the second event signaling object comprise kernel mode data structures.

17. The computer program product of claim 13, wherein the first virtual machine synchronizes a first event signaling object at the first virtual machine with the shared register, and the second virtual machine synchronizes a second event signaling object at the second virtual machine with the shared register.

18. The computer program product of claim 13, wherein before sending the event signal message, the first process running at the first virtual machine synchronizes with a shared memory, and based on the second process having been signaled, the second process running at the second virtual machine synchronizes with the shared memory.

Images