Time

Drift

Time for a guest in a hypervisor system is virtualized. That is, the VM (qvm process instance) hosting the guest provides a virtual timer tick and the virtual hardware timers the guest expects to find in its environment. Thus, the hypervisor host controls the clock each of its guests sees. What the hypervisor host does with a guest's clock when a guest exits has a significant effect on the guest, in particular on the guest's time budgeting. When a guest exits, the hypervisor host can let the guest clock run or stop the guest clock. Neither of these options is ideal.

Guest clock runs during exit

If the hypervisor host allows the guest's clock to run, the guest clock remains synchronized with the host clock, separated only by the offset, the time that elapsed between when the host began counting time and when the guest began counting time (see Offset below).

Allowing the clock to run skews the guest's time accounting, however, as the period between the guest's exit and its re-entry is added to time elapsed for the guest's task that requires the exit. The task may exhaust its time budget and be pre-empted, for instance, without having actually done much except exit.

Guest clock is stopped during exit

Stopping the guest's clock when the guest exits solves the problem of exits skewing the guest's time budgeting. When the guest exits, the guest clock stops until the guest re-enters, and the guest tallies only the time it is actually running against the task's time budget. However, with the guest's clock stopped at each guest exit, this clock increasingly lags behind the host clock. This lag is called drift.

At each guest exit, drift increases. If drift is allowed to increase uncorrected, the guest soon encounters conditions that may prevent it from behaving as required: the guest may miss timer interrupts, its time of day will be increasingly inaccurate, etc.

Skipping

In order to give guests reasonable control of their time budgets, a QNX hypervisor stops the guest's clock at every guest exit, and restarts it when the guest enters (see the Lahav Line in Architecture). However, to mitigate the effects of drift and avoid the problems uncorrected drift eventually creates, a QNX hypervisor periodically causes time in the guest to skip forward; that is, it sets the guest's time forward a portion of the current drift.

The hypervisor skips forward only a portion of the lag between the guest and the host, because skipping forward time in a guest skews the guest's time accounting.

For example, consider a guest that has drifted 10 microseconds behind the host. This guest is now running foo. If the hypervisor skips the guest time forward the full 10 microseconds, these 10 microseconds (which foo didn't use) are nonetheless charged to foo, because the delta between the time when foo began and when it ended includes the 10 microseconds skipped forward. Thus, the hypervisor skips forward only a portion of a guest's time drift to more equally distribute the skips across the guest's activities.

If you have implemented any sort of time budgeting in your guest, you should consider the implications for these budgets of both drift and the corrective skips. In particular, remember that:

• Skipping is possible only when the guest has exited all its vCPUs, so skips necessarily occur at irregular intervals.
• The hypervisor host skips a guest's time forward at every opportunity it has to do so.
• The hypervisor host skips forward only a portion of the current drift.
• There is always some drift, and this drift varies through the life of the guest.

For information about how to retrieve a guest's current time drift, see Finding the current time drift in the Monitoring and Troubleshooting chapter.

Offset

A guest can start up only after the host has started, so a guest necessarily begins counting time later (as measured outside the hypervisor system) than its host. This difference is simply an offset, and is related to drift only in that it concerns time.

Wall clocks

The hypervisor provides various mechanisms you can use to keep the wall clocks in your guests and the hypervisor host aligned. These include fetching the time from an external source, and using shared memory to compare the wall clocks and trigger updates to align them if necessary (see Networking in the Using Virtual Devices, Networking, and Memory Sharing chapter for information about how to connect a guest to the outside world, and Memory sharing in the same chapter for information about how to set up memory sharing between guests and the hypervisor host).