[PATCH 0/3] alleviate time drift with HPET periodic timers

[PATCH 0/3] alleviate time drift with HPET periodic timers

[Ulrich Obergfell]

Hi,

By the beginning of February I posted an RFC regarding an approach to
alleviate time drift with HPET periodic timers.

Ref.: http://article.gmane.org/gmane.comp.emulators.kvm.devel/67346
      http://lists.gnu.org/archive/html/qemu-devel/2011-02/msg00327.html

During the discussion it became apparent that a generic API that could
facilitate (re)injection of lost timer interrupts for any timer device
emulation would be preferred over an isolated fix for a specific device.
However, at this stage there appears to be no plan to actually implement
the generic API. Therefore, we may want to reconsider an improved version
of the code that I originally included in the RFC. This improved version
compensates the loss of timer interrupts caused by ...

-  delayed timer callback.
-  interrupt coalescing (x86 only).

Lost timer interrupts are compensated by gradually injecting additional
interrupts during the subsequent timer intervals, starting at a rate of
one additional interrupt per interval. If further interrupts are lost
while compensation is still in progress, the rate is increased. A limit
is imposed on the rate and on the 'backlog' of lost interrupts that are
to be injected. Compensation of lost timer interrupts can be enabled via
a new QEMU command line option [1].

  -hpet [device=none|present][,driftfix=none|slew]

The code is enclosed in '#ifdef CONFIG_HPET_DRIFTFIX ... #endif' and
it is configurable via a new option '--enable-hpet-driftfix' for the
'configure' script. This also makes it easy to identify and to remove
if the generic API would be implemented some day.

I've tested this code primarily by playing a list of example video files
continuously in a Windows Vista(tm) guest. In some cases I observed the
guest time fall 15+ seconds behind KVM host time in one minute without
the patch, whereas with the patch there was no visible difference between
the guest time and KVM host time after several hours of testing [2]. The
'qemu-system-x86_64' test binary image file was built from snapshot ...

http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=e700699e9f6f1e163985a8e4cd76d8568d24c152

... using only the '--prefix' and '--enable-hpet-driftfix' options of the
'configure' script (other options default). The series of patches is based
on the aforementioned snapshot and it consists of three parts.

-  Part 1 introduces the new QEMU command line option.
-  Part 2 implements the method to compensate lost timer interrupts.
-  Part 3 introduces the new option for the 'configure' script.

Please review and please comment.


Regards,

Uli Obergfell


[1] Injecting additional timer interrupts to compensate lost interrupts
    can alleviate long term time drift. However, on a short time scale,
    this method can have the side effect of making virtual machine time
    intermittently pass faster than real time (depending on the guest's
    time keeping algorithm). Compensation is disabled by default and can
    be enabled for guests where this behaviour is acceptable.

[2] Testing required a patch in tight_compress_data(), ui/vnc-enc-tight.c
    to avoid segmentation fault / core dump of qemu. However, this needs
    to be discussed in a separate post.

[Qemu-devel] [PATCH 0/3] alleviate time drift with HPET periodic timers

[Ulrich Obergfell]

Hi,

By the beginning of February I posted an RFC regarding an approach to
alleviate time drift with HPET periodic timers.

Ref.: http://article.gmane.org/gmane.comp.emulators.kvm.devel/67346
      http://lists.gnu.org/archive/html/qemu-devel/2011-02/msg00327.html

During the discussion it became apparent that a generic API that could
facilitate (re)injection of lost timer interrupts for any timer device
emulation would be preferred over an isolated fix for a specific device.
However, at this stage there appears to be no plan to actually implement
the generic API. Therefore, we may want to reconsider an improved version
of the code that I originally included in the RFC. This improved version
compensates the loss of timer interrupts caused by ...

-  delayed timer callback.
-  interrupt coalescing (x86 only).

Lost timer interrupts are compensated by gradually injecting additional
interrupts during the subsequent timer intervals, starting at a rate of
one additional interrupt per interval. If further interrupts are lost
while compensation is still in progress, the rate is increased. A limit
is imposed on the rate and on the 'backlog' of lost interrupts that are
to be injected. Compensation of lost timer interrupts can be enabled via
a new QEMU command line option [1].

  -hpet [device=none|present][,driftfix=none|slew]

The code is enclosed in '#ifdef CONFIG_HPET_DRIFTFIX ... #endif' and
it is configurable via a new option '--enable-hpet-driftfix' for the
'configure' script. This also makes it easy to identify and to remove
if the generic API would be implemented some day.

I've tested this code primarily by playing a list of example video files
continuously in a Windows Vista(tm) guest. In some cases I observed the
guest time fall 15+ seconds behind KVM host time in one minute without
the patch, whereas with the patch there was no visible difference between
the guest time and KVM host time after several hours of testing [2]. The
'qemu-system-x86_64' test binary image file was built from snapshot ...

http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=e700699e9f6f1e163985a8e4cd76d8568d24c152

... using only the '--prefix' and '--enable-hpet-driftfix' options of the
'configure' script (other options default). The series of patches is based
on the aforementioned snapshot and it consists of three parts.

-  Part 1 introduces the new QEMU command line option.
-  Part 2 implements the method to compensate lost timer interrupts.
-  Part 3 introduces the new option for the 'configure' script.

Please review and please comment.


Regards,

Uli Obergfell


[1] Injecting additional timer interrupts to compensate lost interrupts
    can alleviate long term time drift. However, on a short time scale,
    this method can have the side effect of making virtual machine time
    intermittently pass faster than real time (depending on the guest's
    time keeping algorithm). Compensation is disabled by default and can
    be enabled for guests where this behaviour is acceptable.

[2] Testing required a patch in tight_compress_data(), ui/vnc-enc-tight.c
    to avoid segmentation fault / core dump of qemu. However, this needs
    to be discussed in a separate post.

Re: [PATCH 0/3] alleviate time drift with HPET periodic timers

[Avi Kivity]

On 03/18/2011 05:54 PM, Ulrich Obergfell wrote:
> Please review and please comment.

Some procedural remarks:

- put all patches in the same thread.  'git send-email' can do that 
automatically for you.  This really helps reviewers, at least with some 
email readers
- give individual patches meaningful subjects (not 'alleviate time drift 
with HPET periodic timers' for all patches + subject letter)
- reduce the amount of ifdefs in your patches

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 0/3] alleviate time drift with HPET periodic timers

[Avi Kivity]

On 03/18/2011 05:54 PM, Ulrich Obergfell wrote:
> Please review and please comment.

Some procedural remarks:

- put all patches in the same thread.  'git send-email' can do that 
automatically for you.  This really helps reviewers, at least with some 
email readers
- give individual patches meaningful subjects (not 'alleviate time drift 
with HPET periodic timers' for all patches + subject letter)
- reduce the amount of ifdefs in your patches

-- 
error compiling committee.c: too many arguments to function