Time in a guest running on a QNX Hypervisor always lags behind time in the host, but the hypervisor takes corrective action to minimize this 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 clocks its guests see. What the hypervisor host does with a guest's clocks 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 either let the guest clocks run, or stop the guest clocks. Neither of these options is ideal.
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.
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.
In order to give guests reasonable control of their time budgets, the 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, the 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:
For information about how to retrieve a guest's current time drift, see “Finding the current time drift” in the “Monitoring, Troubleshooting, and Tuning” chapter.
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.