|Publication number||US7475002 B1|
|Application number||US 10/782,092|
|Publication date||Jan 6, 2009|
|Filing date||Feb 18, 2004|
|Priority date||Feb 18, 2004|
|Publication number||10782092, 782092, US 7475002 B1, US 7475002B1, US-B1-7475002, US7475002 B1, US7475002B1|
|Inventors||Timothy P. Mann|
|Original Assignee||Vmware, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (30), Non-Patent Citations (3), Referenced by (32), Classifications (14), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
This invention relates to the field of computer virtualization, that is, to systems and methods for implementing computers as software running on an underlying host hardware platform.
2. Description of the Related Art
Virtualization has brought many advantages to the world of computers. As is well known in the art, a virtual machine (VM) is a software abstraction—a “virtualization”—of a physical computer system that runs as a “guest” on an underlying “host” hardware platform. As long as a suitable interface is provided between the VM and the host platform, one advantage is that the operating system (OS) in the guest need not be the same as the OS at the system level in the host. For example, applications that presuppose a Microsoft Windows OS can be run in the VM even though the OS used to handle actual I/O, memory management, etc., on the host might be Linux.
It usually requires less than 10% of the processing capacity of a CPU to run a typical application, although usage may peak briefly for certain operations. Virtualization can more efficiently use processing capacity by allowing more than one VM to run on a single host, effectively multiplying the number of “computers” per “box.” Depending on the implementation, the reduction in performance is negligible, or at least not enough to justify separate, dedicated hardware “boxes” for each user.
Still another advantage is that different VMs can be isolated from and completely transparent to one another. Indeed, the user of a single VM will normally be unaware that he is not using a “real” computer, that is, a system with hardware dedicated exclusively to his use. The existence of the underlying host will also be transparent to the VM software itself. The products of VMware, Inc., of Palo Alto, Calif. provide all of these advantages in that they allow multiple, isolated VMs, which may (but need not) have OSs different from each other's, to run on a common hardware platform.
Example of a Virtualized System
The system software 220 either is or at least includes an operating system (OS) 230, which has drivers 240 as needed for controlling and communicating with various devices 110, and usually with the disk 106 as well. Conventional applications 255, if included, may be installed to run on the hardware 100 via the system software 220 and any drivers needed to enable communication with devices.
As mentioned above, the virtual machine (VM) 300—also known as a “virtual computer”—is a software implementation of a complete computer system. In the VM, the physical system components of a “real” computer are emulated in software, that is, they are virtualized. Thus, the VM 300 will typically include virtualized (“guest”) system hardware 301, which in turn includes one or more virtual CPUs 302 (VCPU), virtual system memory 304 (VMEM), one or more virtual disks 306 (VDISK), and one or more virtual devices 310 (VDEVICE), all of which are implemented in software to emulate the corresponding components of an actual computer.
The VM's system software 320 includes a guest operating system 330, which may, but need not, simply be a copy of a conventional, commodity OS, as well as drivers 340 (DRVS) as needed, for example, to control the virtual device(s) 310. Of course, most computers are intended to run various applications, and a VM is usually no exception. Consequently, by way of example,
Note that although the hardware “layer” 301 will be a software abstraction of physical components, the VM's system software 320 may be the same as would be loaded into a hardware computer. The modifier “guest” is used here to indicate that the VM, although it acts as a “real” computer from the perspective of a user, is actually just computer code that is executed on the underlying “host” hardware and software platform 100, 220. Thus, for example, I/O to the virtual device 310 will actually be carried out by I/O to the hardware device 110, but in a manner transparent to the VM.
If the VM is properly designed, then the applications (or the user of the applications) will preferably not “know” that they are not running directly on “real” hardware. Of course, all of the applications and the components of the VM are instructions and data stored in memory, just as any other software. The concept, design and operation of virtual machines are well known in the field of computer science.
Some interface is usually required between the VM 300 and the underlying “host” hardware 100, which is responsible for actually executing VM-related instructions and transferring data to and from the actual, physical memory 104. One advantageous interface between the VM and the underlying host system is often referred to as a virtual machine monitor (VMM), also known as a virtual machine “manager.” Virtual machine monitors have a long history, dating back to mainframe computer systems in the 1960s. See, for example, Robert P. Goldberg, “Survey of Virtual Machine Research,” IEEE Computer, June 1974, p. 34-45.
A VMM is usually a relatively thin layer of software that runs directly on top of a host, such as the system software 220, or directly on the hardware, and virtualizes the resources of the (or some) hardware platform. The VMM will typically include at least one device emulator 410, which may also form the implementation of the virtual device 310. The interface exported to the respective VM is usually such that the guest OS 330 cannot determine the presence of the VMM. The VMM also usually tracks and either forwards (to the host OS 230) or itself schedules and handles all requests by its VM for machine resources, as well as various faults and interrupts.
In some configurations, the VMM 400 runs as a software layer between the host system software 220 and the VM 300. In other configurations, such as the one illustrated in
As used herein, the “host” OS therefore means either the native OS 230 of the underlying physical computer, or whatever system-level software handles actual I/O operations, takes faults and interrupts, etc. for the VM. The invention may be used in all the different configurations described above.
Memory Mapping and Address Terminology
In most modern computers, memory is addressed as units known as “pages,” each of which is identified by a corresponding page number. The most straightforward way for all components in a computer to uniquely identify a memory page would be for them all simply to use a common set of page numbers. This is almost never done, however, for many well-known reasons. Instead, user-level software normally refers to memory pages using one set of identifiers, which is then ultimately mapped to the set actually used by the underlying hardware memory.
When a subsystem requests access to the hardware memory 104, for example, the request is usually issued with a “virtual address,” since the memory space that the subsystem addresses is a construct adopted to allow for much greater generality and flexibility. The request must, however, ultimately be mapped to an address that is issued to the actual hardware memory. This mapping, or translation, is typically specified by the operating system (OS), which includes some form of memory management module 208 included for this purpose. The OS thus converts the “virtual” address (VA), in particular, the virtual page number (VPN) of the request, into a “physical” address (PA), in particular, a physical page number (PPN), that can be applied directly to the hardware. (The VA and PA have a common offset from a base address, so that only the VPN needs to be converted into a corresponding PPN.)
When writing a given word to a virtual address in memory, the processor breaks the virtual address into a virtual page number (higher-order address bits) plus an offset into that page (lower-order address bits). The virtual page number (VPN) is then translated using mappings established by the OS into a physical page number (PPN) based on a page table entry (PTE) for that VPN in the page table associated with the currently active address space. The page table will therefore generally include an entry for every VPN. The actual translation may be accomplished simply by replacing the VPN (the higher order bits of the virtual address) with its PPN mapping, leaving the lower order offset bits the same.
To speed up virtual-to-physical address translation, a hardware structure known as a translation look-aside buffer (TLB) is normally included, for example, as part of a hardware memory management unit (MMU) 108. The TLB contains, among other information, VPN-to-PPN mapping entries at least for VPNs that have been addressed recently or frequently. Rather than searching the entire page table, the TLB is searched first instead. If the current VPN is not found in the TLB, then a “TLB miss” occurs, and the page tables in memory are consulted to find the proper translation, and the TLB is updated to include this translation. After the TLB miss fault is handled, the same memory access is attempted again, and this time, the required VPN-to-PPN mapping is found in the TLB. The OS thus specifies the mapping, but the hardware MMU 108 usually actually performs the conversion of one type of page number to the other. Below, for the sake of simplicity, when it is stated that a software module “maps” page numbers, the existence and operation of a hardware device such as the MMU 108 may be assumed.
The concepts of VPNs and PPNs, as well as the way in which the different page numbering schemes are implemented and used, are described in many standard texts, such as “Computer Organization and Design: The Hardware/Software Interface,” by David A. Patterson and John L. Hennessy, Morgan Kaufmann Publishers, Inc., San Francisco, Calif., 1994, pp. 579-603 (chapter 7.4 “Virtual Memory”). Patterson and Hennessy analogize address translation to finding a book in a library. The VPN is the “title” of the book and the full card catalog is the page table. A catalog card is included for every book in the library and tells the searcher where the book can be found. The TLB is then the “scratch” paper on which the searcher writes down the locations of the specific books he has previously looked up.
An extra level of addressing indirection is typically implemented in virtualized systems in that a VPN issued by an application 355 in the VM 300 is remapped twice in order to determine which page of the hardware memory is intended. A mapping module 308 within the guest OS 330 translates the guest VPN (GVPN) into a corresponding guest PPN (GPPN) in the conventional manner. The guest OS therefore “believes” that it is directly addressing the actual hardware memory, but in fact it is not. Of course, a valid address to the actual hardware memory address must, however, ultimately be used.
An address mapping module 408 in the VMM 400 therefore takes the GPPN issued by the guest OS 330 and maps it to a hardware page number PPN that can be used to address the hardware memory. From the perspective of the guest OS, the GVPN and GPPN are virtual and physical page numbers just as they would be if the guest OS were the only OS in the system. From the perspective of the actual host OS, however, the GPPN is a page number in the virtual address space, that is, a VPN, which is then mapped into the physical memory space of the hardware memory as a PPN. Note that in some literature involving virtualized systems, GVPNs, GPPNs, VPNs and PPNs are sometimes referred to as “VPNs,” “PPNs,” “VPNs” and “MPNs,” respectively, where “MPN” means “machine page number,” that is, the page number used to address the hardware memory. The problem is, though, that “VPN” is then used to mean the virtual page number in both the guest and host contexts, and one must always be aware of the current context to avoid confusion. Regardless of notation, however, the intermediate GPPN→PPN mapping performed by the VMM is transparent to the guest system.
Speed is a critical issue in virtualization—a VM that perfectly emulates the functions of a given computer but that is too slow to perform needed tasks is obviously of little good to a user. Ideally, a VM should operate at the native speed of the underlying host system. In practice, even where only a single VM is installed on the host, it is impossible to run a VM at native speed, if for no other reason than that the instructions that define the VMM must also be executed. Near native speed, is possible, however, in many common applications.
The highest speed for a VM is found in the special case where every VM instruction executes directly on the hardware processor. This would in general not be a good idea, however, because the VM should not be allowed to operate at the greatest privilege level; otherwise, it might alter the instructions or data of the host OS or the VMM itself and cause unpredictable behavior. Moreover, in cross-architectural systems, one or more instructions issued by the VM may not be included in the instruction set of the host processor. Instructions that cannot (or must not) execute directly on the host are typically converted into an instruction stream that can. This conversion process is commonly known as “binary translation.”
U.S. Pat. No. 6,397,242 (Devine, et al., “Virtualization system including a virtual machine monitor for a computer with a segmented architecture”), which is incorporated herein by reference, describes a system in which the VMM includes a mechanism that allows VM instructions to execute directly on the hardware platform whenever possible, but that switches to binary translation when necessary.
A virtualization system of course involves more than executing VM instructions—the VMM itself is also a software mechanism defined by instructions and data of its own. For example, the VMM might be a program written in C, compiled to execute on the system hardware platform. At the same time, an application 355 written in a language such as Visual Basic might be running in the VM, whose guest OS may be compiled from a different language.
There must also be some way for the VM to access hardware devices, albeit in a manner transparent to the VM itself. One solution would of course be to include in the VMM all the required drivers and functionality normally found in the host OS 230 to accomplish I/O tasks. Two disadvantages of this solution are increased VMM complexity and duplicated effort—if a new device is added, then its driver would need to be loaded into both the host OS and the VMM. In systems that include a host OS (as opposed to a dedicated kernel such as shown in
In the system illustrated in
Timers in Virtual Computer Systems
A typical physical computer system contains multiple timers. Thus,
One common use for a timer is to keep track of the time of day or to keep track of how much time has elapsed since some point in time. For such a task, the timer may be set up as a periodic timer; generating timer interrupts at a constant frequency. The interrupts generated by the timer may be counted to keep track of the time with a resolution that is equal to the period of the timer. To further refine the time-keeping function, the timer may also be read from time to time. At an instant when the timer is read, the time may be determined more precisely by adding the time represented by the count of the timer to the time represented by the number of timer interrupts that have occurred. Using this technique, the resolution of the time keeping-function is limited only by the frequency at which the timer is set up to count.
A VM preferably also includes a plurality of timers. Thus,
Each virtual timer 360 within the VM 300 may be virtualized by a separate timer emulator, or a single timer emulator may virtualize multiple virtual timers 360. Thus,
In a physical computer system, the operation of the multiple timers is generally accurate and consistent, and the software executing on physical computer systems generally relies on the accuracy and consistency of these timers. In some situations, the software executing on a physical computer system may rely on the consistency of multiple timers with respect to each other, so that if the timing of one timer is not consistent with the timing of another timer, the software may not function properly. The software creates a dependency between multiple timers and the software expects this dependency to be met. As an example, a first timer may be set to generate timer events at a first frequency and a second timer may be set to generate timer events at a second frequency, with the second frequency being twice the first frequency. If the second timer does not generate timer events twice as often as the first timer, the software may not function properly; or if the timer events of the two timers are inconsistent in some other manner, the software may not function properly.
The VM 300 is preferably designed to execute much of the same software that can execute on a corresponding physical computer system. Thus, the guest software in the VM 300 may also use the virtual timers 360 in a manner that gives rise to a dependency between the multiple virtual timers 360. In this case, there must be some measure of consistency between the multiple virtual timers 360, or the guest software may not function properly. In particular, the guest software may not function in the same manner as the software would function if it were executed in a physical computer system implementing the same hardware platform. For example, if the timer events generated by the virtual timers 360 do not occur in the same relative order within the VM 300 as they would occur if the guest software were running on a physical computer system, the guest software may not run correctly in the VM 300. Also, if the relative intervals between the timer events generated by the virtual timers 360 do not approximate the relative intervals that would occur in a physical computer system, the guest software again may not run correctly.
As one particular example, suppose that the VM 300 implements a common symmetric multiprocessing (SMP) hardware platform, and that the guest OS 330 is a version of Linux that executes on a SMP computer. SMP Linux is critically dependent on a certain level of consistency between the multiple timers in a computer system. If this level of consistency is not met, then the computer system will not operate properly.
What is needed, therefore, is a method and apparatus for emulating multiple timers in a virtual computer system with sufficient consistency to enable guest software to execute properly, preferably in the same manner as the guest software would execute on a comparable physical computer system.
The invention comprises a time coordinator that provides consistent timing information for multiple virtual timers in a virtual computer system. The time coordinator preferably provides information that enables timer events from the multiple virtual timers to be generated in the same order in which they would be generated in a corresponding physical computer system. The time coordinator preferably also provides information that enables counts or time values that are read from the multiple virtual timers to be made consistent with each other and with the timer events. When a time value is read from a virtual timer, the value provided in response to the read preferably represents a time that falls between a most recent previous time incident, which may be a previous timer event or a previous reading of a virtual timer, and the time at which the next timer event is due to occur. In some embodiments of the invention, the time coordinator maintains a timer event queue, which contains information regarding timer events for the virtual timers.
In some embodiments of the invention, the time coordinator keeps track of an apparent time, which comprises all time representations provided to guest software in a virtual machine (VM), including all timer events and all time values that are read from the virtual timers. The average rate at which the apparent time runs is preferably approximately equal to the rate at which the real time of the physical computer system runs. The apparent time of the VM may at times fall behind the real time of the physical computer system because the VM may not run continuously on the physical computer system, or because a minimum processing time is provided between multiple events that occur at the VM, or for other reasons. In some embodiments of the invention, the time coordinator goes into a catch-up mode when the apparent time falls behind the real time. The time coordinator then runs the apparent time faster than the real time until the apparent time catches up with the real time. After the apparent time catches up with the real time, the time coordinator goes back into a normal mode, and runs the apparent time at approximately the same rate as the real time.
The virtual computer system may comprise one or more device emulators for emulating the virtual timers. In this case, the time coordinator provides consistent timing information to each of the device emulators, which enables the device emulators to ensure that the multiple virtual timers are consistent with each other. In some embodiments, the time coordinator notifies the device emulators when timer events should be generated for the virtual timers. Also, in some embodiments, when a time value is read from a virtual timer, the time coordinator provides a time value that may be used when responding to the reading of the virtual timer.
This invention may be advantageously implemented in any virtual computer system that includes multiple virtual timers. One such virtual computer system is described herein, by way of example. An example implementation of the invention is also described herein. Other implementations of the invention may vary substantially in a number of ways from the example implementation described herein.
As described above,
Suppose that the timer events illustrated in
If the VM 300 is the only software entity executing on the system hardware 100, besides the VMM 400 and other software routines executing in support of the VM 300, then it is generally not difficult to emulate the virtual timers 360 to approximate the functionality of hardware timers. For example, a separate hardware timer 160 may be used to provide the functionality of each of the virtual timers 360. When a virtual timer 360 is programmed by guest software to generate one or more timer events, the corresponding timer emulator 460 may program the corresponding hardware timer 160 in a corresponding manner to generate one or more timer events at substantially the same time(s) as the virtual timer 360 is to generate timer events.
For example if a virtual timer 360 is setup to implement a periodic timer having a specific frequency, the corresponding hardware timer 160 may also be setup to implement a periodic timer having the same frequency. The timer emulators 460 can then respond to timer events generated by the hardware timers 160 and generate corresponding timer events to the VM 300. Thus, if a hardware timer 160 generates a timer interrupt to mark a timer event, the corresponding timer emulator 460 may pass the interrupt on to the guest software in the VM 300 as if the timer interrupt were generated by the corresponding virtual timer 360. Similarly, when the guest software within the VM 300 attempts to read a count from a virtual timer 360, the corresponding timer emulator 460 may read a count from the corresponding hardware timer 160 and convert it into an appropriate count for the virtual timer 360 before providing it to the guest software. Using this technique, or other techniques, the virtual timers 360 can be accurately emulated to function substantially the same as a hardware timer 160, again assuming that the VM 300 and other software entities executing in support of the VM 300 are the only software entities executing on the system hardware 100.
The emulation of the virtual timers 360 becomes more difficult, however, if other software entities also execute on the system hardware 100. For example, suppose that additional VMs are also executing on the system hardware 100, supported by separate VMMs. In this case, the multiple VMs, along with their supporting VMMs, may be allowed to execute on the system hardware 100 in a time-sharing arrangement just like multiple processes in a multitasking computer system. Each of the VMs in the system that is ready to execute instructions at a given time is allowed to execute during specific time slices, but each VM is not allowed to execute during the time slices that are assigned to other VMs. Thus, the VM 300 will have some time slices in which it is allowed to execute and other time slices in which it is not allowed to execute.
These time slices in which the VM 300 is not allowed to execute may create problems for the timer emulators 460 in their emulation of the virtual timers 360. An example of this type of situation is illustrated in
During the second time slice, TIME 2, the VM 300 is not executing, so the virtual timers 360 cannot operate. Any timer events that would otherwise have occurred during the second time slice cannot occur during the second time slice in this scenario.
Now the relative timing of some of the timer events in
If the guest software in the VM 300 is dependent on the relative timing of the multiple virtual timers 360, then the guest software may execute correctly in the scenario of
This invention may be implemented in the virtual computer system 10 illustrated in
The VMM 400 also includes a time coordinator 470. The time coordinator 470 keeps track of an “apparent time.” This apparent time represents the amount of time that appears to have passed from the perspective of the guest software within the VM 300, based on timer events generated by the virtual timers 360 and based on any occasions when the guest software reads a count from one of the virtual timers 360. The apparent time is preferably kept in the same units of time as are provided to the VM 300 for the virtual timer 360 having the finest resolution. Often this virtual timer 360 represents a timestamp counter (TSC). The time coordinator 470 coordinates the activities of the timer emulators 460 to ensure that the timer events and the timer counts presented to the VM 300 by the timer emulators 460 are consistent with the apparent time and with each other. The coordination provided by the time coordinator 470 also ensures that the average running rate of each of the virtual timers 360 is approximately the same as real time. The operation of the timer emulators 460 and the time coordinator 470 are described in greater detail below with reference to
The method of
Next, at a step 706, the timer emulator 462 notifies the time coordinator 470 that the virtual timer 362 has been set to its initial state, and the timer emulator 462 provides parameters to the time coordinator 470, indicating how the virtual timer 362 has been set up. In particular, the timer emulator 462 indicates to the time coordinator 470 the apparent time at which the virtual timer 362 is to generate its next timer event, whether the virtual timer 362 has been set up as a periodic timer or as a one-shot timer, and, for a periodic timer, the period for the timer, in units of apparent time. In the preferred embodiment, the parameters that the timer emulator 462 provides to the time coordinator 470 are specified in terms of the apparent time, and not the units that are used by the virtual timer 362, although, in other embodiments, the units of the respective virtual timers 360 may be used. The timer emulators 460 may preferably determine the frequency at which the apparent time runs from the time coordinator 470, such as by calling a function of the time coordinator 470 that is provided for use by the timer emulators 460. Each timer emulator 460 may then use this frequency, along with the frequency at which its respective virtual timer 360 operates, to convert between units of apparent time and the units used by the respective virtual timer 360. Thus, for example, if the virtual timer 362 counts at a frequency that is one half as fast as the frequency of the apparent time, and the virtual timer 362 has been set up as a periodic timer having a specified period, then the timer emulator 462 informs the time coordinator 470 that the virtual timer 362 has been set up as a periodic timer, but the timer emulator 462 indicates a period for the virtual timer 362 that is twice as large as the final counter value that was specified for the timer 362 by the guest software.
After the step 706, the method of
At the step 710, in response to an attempt by the guest software to read the virtual timer 362, the timer emulator 462 retrieves a current apparent time from the time coordinator 470. Next, at a step 712, the timer emulator 462 updates the count of the virtual timer 362 based on the apparent time retrieved at the step 710. Again, the timer emulator 462 is responsible for converting the apparent time into a count value that is appropriate to the virtual timer 362. The timer emulator 462 will generally retain the apparent time from the previous time that the timer emulator 462 updated the count of the virtual timer 362 either at this step 712 or at the step 716. From a previous apparent time, as well as the frequencies at which the apparent time changes and the timer 362 counts, the timer emulator 462 can determine an appropriate count value for the timer 362. Generally, the appropriate count value is set to: Count=(fVT/fAT)*(ATC−ATR), where fVT is the frequency of operation of the virtual timer 362, fAT is the frequency at which the apparent time increases, ATC is the current apparent time retrieved at the step 710, and ATR is the apparent time that has been retained from the previous time that the timer emulator 462 updated the count of the virtual timer 362, or the apparent time from the step 702 if the timer emulator 462 has not yet updated the count of the virtual timer 362. Next, at a step 714, the timer emulator 462 provides the count value determined at the step 712 to the guest software in response to the attempted read of the virtual timer 362. After the step 714, the method of
At the optional step 716, in response to a notification from the time coordinator 470 that a timer event is due at the timer 362, the timer emulator 462 updates the timer 362. If this step is performed, the timer emulator 462 generally updates the count value of the virtual timer 362 to its final count value, to indicate that the timer 362 has finished counting up to its final value. The timer emulator 462 can determine a current apparent time at this timer event, based on the period of the timer 362 in units of apparent time and based on the apparent time of the previous timer event for the timer 362, or the apparent time when the timer 362 was started, if this is the first timer event for the timer 362. The step 716 generally does not need to be performed, however, because the guest software typically will not read the count value of the timer 362 at this point because the timer event already indicates that the final count value has been reached. Also, if the guest reads the timer 362 in response to a timer event, the timer emulator 462 will update the timer 362 at the step 712 anyway. After the optional step 716, the method of
At the step 720, in response to a change to the settings of the virtual timer 362 by the guest software, the timer emulator 462 notifies the time coordinator 470 that the settings of the virtual timer 362 have been changed, and the timer emulator 462 provides parameters to the time coordinator 470, indicating these new settings, such as the apparent time at which the next timer event is due to occur, whether or not the timer 362 is set up as a periodic timer, and, for a periodic timer, the period. This step 720 is similar to the step 706 described above, except that in this case, the timer emulator 462 only needs to provide to the time coordinator 470 any parameters that have changed. Again, the parameters that the timer emulator 462 provides to the time coordinator 470 are preferably specified in terms of the apparent time, and not the units that are used by the virtual timer 362. The timer emulator 462 may again retrieve a new current apparent time from the time coordinator 470. After the step 720, the method of
The method of
After the step 752, the method of
At the step 754, the time coordinator 470 may determine that a timer event is due to occur at one of the virtual timers 360 in a variety of ways. First, the time coordinator 470 must convert an apparent time that indicates a time at which a timer event should occur into a corresponding real time. The apparent time will be received from a timer emulator 460 during an update of the time coordinator 470, or it will be calculated from parameters received from a timer emulator 460. Then, the time coordinator 470 performs a method, which is illustrated in
In another embodiment, however, the hardware timers 160 are not used as described immediately above. This other embodiment is actually embodied in a commercial product of the assignee of this invention. In that product, the time coordinator 470 may be viewed as comprising a first software routine referred to as a TimeTracker and a second software routine referred to as a MonitorPoll. The TimeTracker keeps track of apparent time and determines when, in real time, timer events for the virtual timers should occur. The TimeTracker also uses the method of
In the preferred embodiment, the time coordinator 470 only monitors when the next virtual timer event is due to occur, such as by setting a single hardware timer 160 or by notifying the MonitorPoll or another software routine of a real time for only a single timer event. When that timer event is generated, then the time coordinator 470 moves on to monitor when the following virtual timer event is due to occur. In other embodiments, the time coordinator 470 may monitor multiple virtual timer events simultaneously, such as by setting multiple hardware timers 160 for the respective timer events or by notifying the MonitorPoll or another software routine of multiple upcoming timer events. The description below assumes the preferred technique of monitoring only a single timer event at a time, although it may be adapted by a person of skill in the art to apply to a technique in which multiple timer events are monitored simultaneously. Returning to the method of
The entries in the queue 472 are preferably maintained in the order in which the respective timer events are due to occur. Thus, as shown in
After the step 756, the method of
In the preferred embodiment, in which the time coordinator 470 only monitors a single virtual timer event at a time, the time coordinator 470 performs the step 758 only if the real time at which the next timer event is due to occur has changed as a result of the update provided by the timer emulator 460. Thus, the step 758 is performed only if the timer event represented by the first entry in the queue 472 has changed. This situation can arise (1) if the first entry in the queue 472 is modified to change the apparent time at which the corresponding timer event is due to occur, or (2) if another entry in the queue 472 is modified in a manner that makes that queue entry become the first entry. For example, if the queue 472 has the contents illustrated in
At the step 768, in response to a timer emulator 460 retrieving a current apparent time from the time coordinator 470, the time coordinator 470 again reads the first entry of the queue 472. In particular, the time coordinator 470 reads the apparent time value in the field 476A to determine the apparent time at which the next timer event is due to occur. Next, at a step 770, the time coordinator 470 determines an apparent time that can be used for this instant of time. For example, if the guest software attempted to read the virtual timer 362, the time coordinator 470 determines an apparent time that is to be presented to the guest software. The time coordinator 470 returns this apparent time to the timer emulator 462, which then provides a corresponding counter value for the timer 362 to the guest software. The time coordinator 470 determines a current apparent time that falls between (1) the latter to occur of (a) the apparent time at which the most recent previous timer event occurred and (b) the apparent time which was most recently used in response to the guest software reading a counter value from one of the virtual timers 360 and (2) the apparent time at which the next timer event is due to occur. A “time incident” is defined herein to mean any occurrence that provides timing information to the guest software running in the VM 300, such as a timer event or a reading of a virtual timer. Using this definition, the time coordinator 470 determines a current apparent time that falls between the apparent time at which the most recent previous time incident occurred and the apparent time at which the next timer event is due to occur. For example, the time coordinator 470 may determine the current apparent time according to the following equation:
AT C =AT L+((RT C −RT L))/(RT N −RT L))*(AT N −AT L),
where ATC is the current apparent time and RTC is the current real time; ATL is the latest apparent time that has been presented to the guest software either through the generation of a timer event or in response to the guest software reading a count value from a virtual timer 360; RTL is the actual real time at which the apparent time ATL was presented to the guest software; and ATN and RTN are the apparent time and the real time, respectively, at which the next timer event is due to occur. The time coordinator 470 may check a hardware timer 160 to determine the current real time, and it may keep track of all the other values required to solve the equation from prior determinations. After the step 770, the method of
As mentioned above,
The method of
At the step 784, the time coordinator 470 determines the real time at which the next timer event should occur according to the normal mode of operation. Specifically, the time coordinator 470 calculates this real time value according to the following equation: RTN=NRTP+(ATN−ATP). Thus, for example, if the real time at which the previous timer event would normally have occurred is 34, the apparent time of the next timer event is 40 and the apparent time of the previous timer event was 34, then the real time at which the next timer event should occur is 40. After the step 784, the method of
When the method of
After the step 786, the method of
During the second time slice, TIME 2, the VM 300 is not executing, so the virtual timers 360 again cannot operate. Any timer events that would otherwise have occurred during the second time slice cannot occur during the second time slice in this scenario.
As described above, the time coordinator 470 executes the method of
Next, after the step 764, the time coordinator 470 proceeds to the step 766. At this point, the time coordinator 470 performs the method of
When the VM 300 is allowed to execute again, beginning at the real time value of 113, the time coordinator 470 notices that the real time value 56 has already passed. In response, the time coordinator 470 proceeds again to the step 760 to process the next case of a timer event coming due. At the step 760, the time coordinator 470 determines that the timer event 364B is due to occur on the timer 364. At the step 762, the time coordinator 470 notifies the timer emulator 464, which generates the timer event 364B. At the step 764, the time coordinator 470 updates the queue 472. Now, the queue 472 will have the contents illustrated in
Again, at the step 766, the method of
At the real time 116, the time coordinator 470 notifies the timer emulator 466 of the timer event 366C at the step 762, and it updates the queue 472 at the step 764. This time, because the timer 366 is a one-shot timer, the first entry in the queue 472 is cleared, and the second and third entries in the queue 472 are each moved up by one entry. When the guest software sets up the timer 366 again, the queue 472 is updated to the state illustrated in
At the real time 121, the time coordinator 470 notifies the timer emulator 462 of the timer event 362C at the step 762, and it updates the queue 472 at the step 764. This time, the next timer event for the timer 362 is due to occur at the apparent time 104, which is the same apparent time as the timer event 362D represented by the second entry in the queue 472. As a result, there is no need to reorganize the entries in the queue 472, and the queue now has the state illustrated in
At the real time 137, the time coordinator 470 determines, at the step 760, that the timer 362 has the timer event 362D due and the timer 364 has the timer event 364C due, it notifies the timer emulators 462 and 464 of the respective timer events 362D and 364C at the step 762, and it updates the queue 472 at the step 764. This time, the entries for both the VTIMER1 362 and the VTIMER2 364 are updated and the queue 742 now has the state illustrated in
At the real time 147, the time coordinator 470 notifies the timer emulator 466 of the timer event 366D at the step 762, and it updates the queue 472 at the step 764. The time coordinator 470 again applies the following condition: ATN>=ARTP+(1/C)*(ATN−ATP), using the values: ATN=136, ARTP=147, C=2, and ATP=124, to determine that the method of
At the real time 153, the time coordinator 470 notifies the timer emulator 462 of the timer event 362E at the step 762, and it updates the queue 472 at the step 764. The time coordinator 470 again applies the following condition: ATN>=ARTP+(1/C)*(ATN−ATP), using the values: ATN=152, ARTP=153, C=2, and ATP=136, to determine that the method of
At the real time 161, the time coordinator 470 notifies the timer emulator 464 of the timer event 364D at the step 762, and it updates the queue 472 at the step 764. The time coordinator 470 again applies the following condition: ATN>=ARTP+(1/C)*(ATN−ATP), using the values: ATN=168, ARTP=161, C=2, and ATP=152, to determine that the method of
At the real time 169, the time coordinator 470 notifies the timer emulator 462 of the timer event 362F at the step 762, and it updates the queue 472 at the step 764. The time coordinator 470 again applies the following condition: ATN>=ARTP+(1/C)*(ATN−ATP), this time using the values: ATN=172, ARTP=169, C=2, and ATP=168. This time, however, the time coordinator 470 determines that the method of
Thus, referring again to
Now suppose that, at a real time 130 in
AT C =AT L+((RT C −RT L)/(RT N −RT L))*(AT N −AT L),
using the values: ATL=72, RTC=130, RTN=137, RTL=121, and ATN=104, to determine the current apparent time to be 90. At the step 772, the time coordinator 470 returns the apparent time of 90 to the timer emulator 462. The timer emulator 462 converts this apparent time into an appropriate counter value for the timer 362, updates the timer at the step 712 and returns the counter value to the guest software at the step 714.
In the preferred embodiment, the time coordinator 470 tries to run apparent time so that it's close to the real time. The apparent time may fall behind, however, because the VM 300 is descheduled for a period of time, as described above. The apparent time may also fall behind because the time coordinator 470 implements a minimum progress criterion for timer events. After any timer event, each virtual CPU 302 must make a certain amount of progress executing guest software before the time coordinator 470 will generate a subsequent timer event. This provision ensures that the guest software finishes processing the previous timer event and is ready for a subsequent timer event, before the subsequent timer event issues. The minimum amount of time that is provided for processing timer events may vary between the multiple virtual timers 360, and the minimum processing time that is to be provided for each virtual timer 360 may be included as an additional column in the timer event queue 472.
Also in the preferred embodiment, if apparent time falls moderately behind real time, the time coordinator 470 switches into the catch-up mode of operation, and the apparent time is run faster than real time until the apparent time catches up to real time. However, if apparent time falls behind real time by more than a threshold amount, then the time coordinator 470 may abruptly jump the apparent time forward to instantly catch up to real time, dropping any backlog of timer events.
One particular embodiment of the invention has been described above, along with some variations of the main embodiment. A wide variety of other variations may also be implemented, resulting in a wide variety of possible embodiments. For example, the functional units described above may be organized in various other ways. For example, in some embodiments, the functionality of the device emulators 460 and the time coordinator 470 may be combined into a single software unit. In other embodiments, a single device emulator 460 may virtualize all of the virtual timers 360 in the system. In other embodiments, the same time emulator 470 may be used in conjunction with a plurality of VMMs, so that consistent timing is provided across multiple VMs. For example, the time emulator 470 may be implemented in a kernel, such as the kernel 650 of
Also, in various other embodiments, the methods of
In one particular embodiment, the method of
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4812967 *||Mar 7, 1986||Mar 14, 1989||Hitachi, Ltd.||Method and apparatus for controlling interrupts in a virtual machine system|
|US4814975 *||Aug 6, 1984||Mar 21, 1989||Hitachi, Ltd.||Virtual machine system and method for controlling machines of different architectures|
|US5095427 *||Jun 14, 1989||Mar 10, 1992||Hitachi, Ltd.||Dispatch control of virtual machine|
|US5295265 *||Jun 4, 1992||Mar 15, 1994||Sextant Avionique||Device for enhancing the performance of a real time executive kernel associated with a multiprocessor structure that can include a large number of processors|
|US5488713 *||Jul 28, 1993||Jan 30, 1996||Digital Equipment Corporation||Computer simulation technique for predicting program performance|
|US5621912 *||Dec 29, 1994||Apr 15, 1997||International Business Machines Corporation||Method and apparatus for enabling monitoring of guests and native operating systems|
|US5774479 *||Mar 30, 1995||Jun 30, 1998||Motorola, Inc.||Method and system for remote procedure call via an unreliable communication channel using multiple retransmission timers|
|US5898855 *||Sep 20, 1994||Apr 27, 1999||Hitachi, Ltd.||Control method for virtual machine running time in virtual machine system|
|US6067604 *||Aug 11, 1997||May 23, 2000||Compaq Computer Corporation||Space-time memory|
|US6349388 *||May 7, 1999||Feb 19, 2002||Advanced Micro Devices, Inc.||Timer processing engine for supporting multiple virtual minimum time timers|
|US6530078 *||Mar 26, 1999||Mar 4, 2003||Alexander V. Shmid||Virtual machines in OS/390 for execution of any guest system|
|US6550015 *||Feb 10, 1999||Apr 15, 2003||Advanced Micro Devices Inc.||Scalable virtual timer architecture for efficiently implementing multiple hardware timers with minimal silicon overhead|
|US6691303 *||May 16, 2001||Feb 10, 2004||Esmertec Ag||Method and system of testing and verifying computer code in a multi-threaded environment|
|US6795966 *||Feb 4, 2000||Sep 21, 2004||Vmware, Inc.||Mechanism for restoring, porting, replicating and checkpointing computer systems using state extraction|
|US6882968 *||Oct 25, 2000||Apr 19, 2005||Sony Computer Entertainment Inc.||Method of measuring performance of an emulator and for adjusting emulator operation in response thereto|
|US7133422 *||Jan 31, 2002||Nov 7, 2006||Texas Instruments Incorporated||Implementing enhanced distributed coordinating function (EDCF) with a single hardware backoff counter|
|US7136800 *||Oct 18, 2002||Nov 14, 2006||Microsoft Corporation||Allocation of processor resources in an emulated computing environment|
|US7146305 *||Jun 19, 2001||Dec 5, 2006||Vcis, Inc.||Analytical virtual machine|
|US7155629 *||Apr 10, 2003||Dec 26, 2006||International Business Machines Corporation||Virtual real time clock maintenance in a logically partitioned computer system|
|US7219047 *||Mar 28, 2002||May 15, 2007||Opnet Technologies, Inc.||Simulation with convergence-detection skip-ahead|
|US7299468 *||Apr 29, 2003||Nov 20, 2007||International Business Machines Corporation||Management of virtual machines to utilize shared resources|
|US20030074390 *||Oct 12, 2001||Apr 17, 2003||Hudson Richard L.||Hardware to support non-blocking synchronization|
|US20030217250 *||Apr 16, 2002||Nov 20, 2003||Steve Bennett||Control register access virtualization performance improvement in the virtual-machine architecture|
|US20040148604 *||Jun 3, 2002||Jul 29, 2004||Steffens Elisabeth Francisca M||Method of and system for assessing progress of a task|
|US20050027500 *||Jul 30, 2004||Feb 3, 2005||Cornhill Dennis Thomas||Real-time software scheduler for personal computers|
|US20050071840 *||Sep 15, 2003||Mar 31, 2005||Gilbert Neiger||Use of multiple virtual machine monitors to handle privileged events|
|US20050204357 *||Mar 15, 2004||Sep 15, 2005||Ajay Garg||Mechanism to protect extensible firmware interface runtime services utilizing virtualization technology|
|US20060075402 *||Sep 30, 2004||Apr 6, 2006||Gilbert Neiger||Providing support for a timer associated with a virtual machine monitor|
|US20060130059 *||Oct 29, 2004||Jun 15, 2006||Bennett Steven M||Timer offsetting mechanism in a virtual machine environment|
|US20070033589 *||Aug 4, 2005||Feb 8, 2007||Microsoft Corporation||Controlling virtual time|
|1||*||A Virtual machine emulator for performance evaluation M. D. Canon, D. H. Fritz, J. H. Howard, T. D. Howell, M. F. Mitoma, J. Rodriquez-Rosell Feb. 1980 Communications of the ACM, vol. 23 Issue 2.|
|2||*||Virtual machine-based simulation of distributed computing and network computing Richard T. Wang, J. C. Browne Sep. 1981 ACM SIGMETRICS Performance Evaluation Review , Proceedings of the 1981 ACM SIGMETRICS conference on Measurement and modeling of computer systems SIGMETRICS '81, vol. 10 Issue 3.|
|3||*||Virtual time David R. Jefferson Jul. 1985 ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 7 Issue 3.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7770046 *||Mar 19, 2007||Aug 3, 2010||Sony Computer Entertainment Inc.||Management of time information within a plurality of execution spaces|
|US7840962 *||Sep 30, 2004||Nov 23, 2010||Intel Corporation||System and method for controlling switching between VMM and VM using enabling value of VMM timer indicator and VMM timer value having a specified time|
|US7895597 *||Oct 11, 2005||Feb 22, 2011||Nokia Corporation||Method, apparatus and computer program product enabling full pre-emptive scheduling of green threads on a virtual machine|
|US7962909 *||Feb 25, 2005||Jun 14, 2011||Globalfoundries Inc.||Limiting guest execution|
|US8099637 *||Oct 30, 2007||Jan 17, 2012||Hewlett-Packard Development Company, L.P.||Software fault detection using progress tracker|
|US8145470 *||Jun 27, 2007||Mar 27, 2012||Microsoft Corporation||Accelerated access device emulator access scheme in a hypervisor environment with child and root partitions|
|US8334640||Aug 12, 2009||Dec 18, 2012||Express Imaging Systems, Llc||Turbulent flow cooling for electronic ballast|
|US8392917 *||Mar 30, 2009||Mar 5, 2013||Microsoft Corporation||Timer access from user mode through a shared memory page|
|US8490089 *||Nov 5, 2010||Jul 16, 2013||Advanced Micro Devices, Inc.||Guest timer facility to improve management in a virtualized processing system|
|US8539010 *||Jan 4, 2011||Sep 17, 2013||Fujitsu Limited||Virtual machine, virtual machine monitor and computer control method|
|US8635057 *||Mar 30, 2009||Jan 21, 2014||Microsoft Corporation||Enlightenment for low overhead hardware access|
|US8850450||Jan 18, 2012||Sep 30, 2014||International Business Machines Corporation||Warning track interruption facility|
|US8926138 *||May 7, 2009||Jan 6, 2015||Express Imaging Systems, Llc||Gas-discharge lamp replacement|
|US8926139||Apr 29, 2010||Jan 6, 2015||Express Imaging Systems, Llc||Gas-discharge lamp replacement with passive cooling|
|US9098358||Dec 18, 2012||Aug 4, 2015||International Business Machines Corporation||Use of a warning track interruption facility by a program|
|US9098478||Jul 2, 2014||Aug 4, 2015||International Business Machines Corporation||Warning track interruption facility|
|US9104508 *||Jan 18, 2012||Aug 11, 2015||International Business Machines Corporation||Providing by one program to another program access to a warning track facility|
|US9104509 *||Dec 18, 2012||Aug 11, 2015||International Business Machines Corporation||Providing by one program to another program access to a warning track facility|
|US9110741||Dec 20, 2012||Aug 18, 2015||International Business Machines Corporation||Warning track interruption facility|
|US9110878||Jan 18, 2012||Aug 18, 2015||International Business Machines Corporation||Use of a warning track interruption facility by a program|
|US20100077394 *||Sep 19, 2008||Mar 25, 2010||Microsoft Corporation||Coalescing periodic timer expiration in guest operating systems in a virtualized environment|
|US20100251235 *||Sep 30, 2010||Microsoft Corporation||Timer access from user mode through a shared memory page|
|US20110179417 *||Jul 21, 2011||Fujitsu Limited||Virtual machine, virtual machine monitor and computer control method|
|US20120117564 *||May 10, 2012||Thomas Friebel||Guest timer facility in a virtualized processing system|
|US20130160012 *||Feb 19, 2013||Jun 20, 2013||Microsoft||Timer access from user mode through a shared memory page|
|US20130185732 *||Dec 18, 2012||Jul 18, 2013||International Business Machines Corporation||Providing by one program to another program access to a warning track facility|
|US20130185737 *||Jan 18, 2012||Jul 18, 2013||International Business Machines Corporation||Providing by one program to another program access to a warning track facility|
|EP2372542A2 *||Jan 12, 2011||Oct 5, 2011||Fujitsu Limited||Virtual machine, virtual machine monitor and computer control method|
|EP2532123A1 *||Feb 5, 2011||Dec 12, 2012||OPNET Technologies, Inc.||Correcting packet timestamps in virtualized environments|
|EP2575002A1 *||Sep 28, 2011||Apr 3, 2013||Siemens Aktiengesellschaft||Method and virtualisation software for producing independent time sources for virtual runtime environments|
|WO2012129623A1||Mar 19, 2012||Oct 4, 2012||Instituto Alberto Luiz Coimbra De Pós Graduação E Pesquisas||Strictly increasing virtual clock for high-precision timing of programs in multiprocessing systems|
|WO2015119682A1 *||Nov 7, 2014||Aug 13, 2015||The Boeing Company||Removal of idle time in virtual machine operation|
|U.S. Classification||703/23, 713/501, 703/27, 718/1, 703/21, 713/502, 703/24|
|International Classification||G06F1/00, G06F1/04, G06F9/455|
|Cooperative Classification||G06F2009/45579, G06F9/45558, G06F2009/45595|
|Feb 18, 2004||AS||Assignment|
Owner name: VMWARE, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MANN, TIMOTHY P.;REEL/FRAME:015010/0708
Effective date: 20040218
|Jun 6, 2012||FPAY||Fee payment|
Year of fee payment: 4