Patent Application
20090006690
The invention relates to Input/Output (I/O) virtualization performed on computer platforms. More specifically, the invention relates to merging the Universal Serial Bus (USB) data transfer schedules of multiple virtual machines running on a single computer platform before the schedules are consumed by a physical USB host controller.
Virtualized computer platforms are becoming popular for security purposes as well as for efficiency purposes. In a virtualized environment with multiple virtual machines (VMs) running on top of a virtual machine manager (VMM), the VMs need to share the input/output (I/O) devices connected to the computer platform.
The Universal Serial Bus (USB Specification Revision 2.0 (Apr. 27, 2000) has become an extremely popular I/O bus for today's computer platforms. Its plug-and-play versatility and fast transfer speeds offer a great deal of flexibility and thus, it is commonplace on most of today's computer platforms. A USB host controller hub, serves as the controller that controls one or more USB devices plugged into a computer platform. Each USB host controller typically supports up to 6 USB ports. Because of the need to support greater than the number of USB ports supported by one USB host controller and many I/O devices are USB devices, it is also common to have more than one USB host controller located in the platform. Each USB host controller may control typically six high speed USB devices. Thus, two or more USB host controller devices are located in the system to control the entire set of USB devices in the system. The USB host controller may control low speed or full speed USB devices compliant with USB 1.1 specification as well as high speed devices compliant with the USB 2.0 specification.
The present invention is illustrated by way of example and is not limited by the figures of the accompanying drawings, in which like references indicate similar elements, and in which:
Embodiments of an apparatus, system, and method to merge multiple universal serial bus device data transfer schedules in a virtualized environment are described. In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known elements, specifications, and protocols have not been discussed in detail in order to avoid obscuring the present invention.
The memory controller 104 is coupled to the interconnect 102. The interconnect 102 may be any type of interconnect that can send data from one device to another. In some embodiments, the inter-connect includes data, address, clock, and control lines used to transmit data (these lines are not shown). In some embodiments, the memory controller 104 is part of the chipset. In other embodiments, the memory controller is integrated into the processor 100. The memory controller controls system memory access. An additional interconnect 106 is coupled to the memory controller 104 as well as system memory 108. In some embodiments, interconnect 106 may utilize the same protocol as interconnect 102 as well as having the same data, address, clock, and control lines used to transmit data. In some embodiments, System memory 108 may be comprised of specific types of dynamic random access memory (DRAM), such as, for example, double data rate (DDR) synchronous DRAM. In some other embodiment the System memory 108 may be comprised of other memory type devices.
The memory controller 104 is coupled to an interconnect 112. An IO Controller 110 is also coupled to the interconnect 112. In some embodiments the IO controller may be part of the chipset. In other embodiments the IO controller may be integrated with the CPU or the memory controller or both. In different embodiments, the interconnect 112 may be any type of interconnect that can send data from one device to another. Again, in some embodiments, the interconnect 112 includes data, address, clock, and control lines used to transmit data (these lines are not shown). The IO Controller 112 controls the transfer of data between the processor 100, system memory 108 and any input/output (I/O) devices coupled to the IO Controller 112. In many embodiments, the IO Controller 110 is coupled to multiple I/O interconnects. In many embodiments, one of these interconnects is a universal serial bus (USB) interconnect. 132.
A USB host controller controls multiple USB devices coupled to the USB interconnect 132. With the proliferation of USB devices, it has become necessary to add multiple USB host controllers to be able to service a large number of USB devices coupled to a single system in a timely manner. Thus, in many embodiments, multiple USB host controller are integrated into the IO Controller 110, such as USB host controller A 114 and USB host controller B 116. In this example, USB host controller A 114 controls USB devices 1 and 2 (118 and 120) and USB host controller B 116 controls USB devices 3 and 4 (122 and 124).
In some embodiments the IO Controller 110 also has a virtualization engine 126. The virtualization engine allows the separation of the I/O system into multiple virtual I/O systems. where each system provides its own software interface to the operating system that controls it. The processor can switch execution between these multiple virtual systems. The virtualization engine 126 includes logic to effectively allow the rest of the computer system (including the I/O devices) to support multiple virtual systems.
In some embodiments, USB host controller A 206 is coupled to USB Dev1218 and USB Dev2220 through the USB interconnect and USB host controller B 208 is coupled to USB Dev3222 and USB Dev4224 through the USB interconnect. In many embodiments, for each VM residing in the system, a virtual USB host controller is created in system memory for each physical USB host controller residing in the system. Thus, since there are two physical USB host controllers in the system in
Additionally, for each virtual USB host controller, a virtual data transfer schedule is stored in system memory. In many embodiments, this virtual data transfer schedule includes a virtual frame list that schedules isochronous traffic and a linked list of transfer descriptors that schedules asynchronous traffic. Within each frame of the virtual frame list a linked list of isochronous traffic transfer descriptors may also be present. This allows each physical USB host controller to transact with each VM. For example, if VM1200 controls USB Dev1 and USB Dev3 (118 and 122 in
Each physical USB host controller (either USB host controller A 206 or USB host controller B 208 in
Additionally, after the isochronous transfer descriptor linked lists (pointed to by a single frame in each frame list) are merged, the lower priority asynchronous data transfer schedule linked lists may also be merged. Asynchronous traffic does not require as high of priority, thus, in many embodiments, asynchronous transfer descriptors from multiple virtual USB host controllers may be given a small percentage of the total frame time (e.g. 10% of the frame time versus the isochronous traffic receiving 90%). In other embodiments, the asynchronous traffic may be required to wait altogether from having any time for a given frame, and receive a portion of a frame's time from a subsequent frame. Thus, in some embodiments, isochronous traffic from the merged frame lists are linked together and the asynchronous transfer descriptors are then linked into the merged list of transfer descriptors after all linked isochronous transfers.
Returning to
In many embodiments, the two frame lists (the USB host controller A frame list 300 and the USB host controller B frame list 302) are synchronized in time, so frame list pointers 304 and 306 point to the same frame in their respective frame lists. Thus, in this example, frame list pointers 304 and 306 point to frame 3 in each respective frame list. Frame 3 in the frame list for USB host controller A points to a transfer descriptor schedule (linked list 308) that is three transfer descriptors long (TD1A, TD2A, and TD3A) followed by a null pointer. Frame 3 in the frame list for USB host controller B points to a transfer descriptor schedule (linked list 310) that is one transfer descriptor long (TD1B) followed by a null pointer. In some embodiments the two frame lists are not synchronized. In these embodiments, the frame list pointer 304 may point to frame 3 in virtual USB host controller A frame list 300, while frame list pointer 306 may point to frame 0 in virtual USB host controller A frame list 302.
In many embodiments, when the virtualization engine (126 in
Thus, as the virtualization engine traverses the first linked list 308, it checks the terminate bit at each transfer descriptor to find the last transfer descriptor. Once the virtualization engine finds the last transfer descriptor (TD3A) in the first linked list 308, it clears the terminate bit (in TD3A) and inputs the address of the first transfer descriptor in the transfer descriptor linked list for USB host controller B (TD1B). Thus, the address in TD3A points to TD1B. TD1B still points to null pointer it originally pointed to. After this modification, the virtualization engine has created a new frame 3 in a merged frame list 312. Merged frame list pointer 314 points to the new merged frame 3. And the new merged frame 3 points to the merged transfer descriptor schedule 316. The merged transfer descriptor schedule 316 is sent by the virtualization engine to physical USB host controller A to be operated on. The merging can be performed in a just-in-time manner (on the fly) by the virtualization engine. When the merging is performed on the fly, the virtualization does not create a merged physical list, rather it just sends the newly merged data transfer schedules directly to the physical USB host controller per frame.
In some embodiments, VM1 and VM2 may use different USB addresses to access the physical USB devices. In such embodiments, a translation table is maintained per VM to store the corresponding virtual USB address for a given physical USB address. Each transfer descriptor has at least a USB address, a termination bit, and a pointer to a next transfer descriptor (if one exists—otherwise it has a null pointer). The specific details of a transfer descriptor are shown in
In many embodiments, the transfer descriptor schedules are sent on a frame by frame basis to a target USB host controller. In these frame by frame embodiments, the virtualization engine merges the linked lists in a just-in-time manner. In other words, the virtualization engine is creating each merged linked list only one, two, or three frames in advance—right before they will be operated on by the physical USB host controller.
Specifically turning to
Frame list pointer 402 points to a transfer descriptor schedule (a linked list of transfer descriptors) 408 that includes only TD1A. Frame list pointer 402 points to a transfer descriptor schedule 410 that include TD1B and TD2B. In this example, the virtualization engine determines that frame 2 in both frame lists has a transfer descriptor linked list. Once the virtualization engine makes this determination, then it checks the next position in each frame list past the current frame list pointers (402 and 406), namely frame 3 in each frame list. At this point the virtualization engine checks to see if linked lists exist in either frame 3. When it determines that both frame 3's are empty, the virtualization engine then sends linked list 408 from frame 2 in virtual USB host controller A frame list during the time that the physical USB host controller assumes it is receiving the linked list from all frame 2's. After the physical USB host controller operates on linked list 408 during the frame 2 time period, then the frame list pointers increment and the virtualization engine sends linked list 410 to the physical USB host controller during the frame 3 time period. The new virtual USB host controller merged frame list 412 is shown after the merge operation takes place.
If two or more consecutive frames for both frame lists have linked lists, then, in some embodiments, the virtualization engine would be required to push back the linked lists associated with the second consecutive frame to the third frame and so on to maintain the correct order of operations.
In many embodiments, upon system initialization, the virtualization engine will map each device coupled to a physical USB host controller to a particular virtual USB host controller. In the embodiment described above in reference to
Thus, embodiments of an apparatus, system, and method to merge multiple universal serial bus device virtual frame list schedules in a virtualized environment are described. These embodiments have been described with reference to specific exemplary embodiments thereof. It will be evident to persons having the benefit of this disclosure that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments described herein. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
