Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/03/2011 09:28 AM, Jan Kiszka wrote:
> On 2011-02-03 14:43, Ulrich Obergfell wrote:
>    
>> Hi,
>>
>> I am observing severe backward time drift in a MS Windows Vista(tm)
>> guest running on a Fedora 14 KVM host. I can reproduce the problem
>> with the following steps:
>>
>> 1. Use 'vncviewer' to connect to the guest's desktop.
>> 2. Click on the menu title bar of a window on the guest's desktop.
>> 3. Move that window around on the guest's desktop.
>>
>> While I keep on moving the window around for one minute, the guest
>> time falls up to 15 seconds behind host time.
>>
>> The problem is caused by delayed callbacks of hpet_timer(). A timer
>> interrupt is injected into the guest during each callback. However,
>> interrupts are lost if delays are greater than a comparator period.
>>
>>      
> Yes, that's a well known limitation of qemu, in fact. We are lacking a
> generic irq coalescing infrastructure. That, once designed and
> available, would also allow to fix the HPET.
>    

I don't think it requires anything that sophisticated.

It's just the period calculation of the HPET that's wrong and doesn't 
account for loss.

>    
>> This is an RFC through which I would like to get feedback on how the
>> idea of a patch to compensate those lost interrupts would be received:
>>
>> The patch determines the number of lost timer interrupts based on the
>> number of elapsed comparator periods. Lost interrupts are compensated
>>      
> That neglects coalescing of the HPET IRQs: If the timer is run regularly
> but the guest is not able to retrieve the injected IRQs, you should
> still see drifts with your patches.
>    

FWIW, this isn't the most common failure scenario.  This is only really 
prominent when you have rapid reinject like we do with the in-kernel 
PIT.  This generally shouldn't be an issue with gradual reinjection.

>> 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. The algorithm imposes a limit on
>> the rate and on the 'backlog' of lost interrupts to be injected. The
>> patch can be enabled via a qemu command line option.
>>
>>    -hpet [device=none|present][,driftfix=none|slew]
>>
>> The 'device=none' option is equivalent to the '-no-hpet' option, and
>> the 'driftfix=slew' option enables the patch (similar to RTC).
>>
>>
>> The second and third part of this series of email contain the patch:
>>
>> - Code part 1 introduces the qemu command line option.
>> - Code part 2 implements compensation of lost interrupts.
>>
>> Please review and please comment.
>>
>>      
> Generally, this issue needs to be attacked at qemu level (added to CC),
> not qemu-kvm.
>
> We had a lengthy discussion on the list last year. We (including qemu
> people) basically agreed that we needs a generic feedback infrastructure
> to track coalesced IRQs for periodic, clock providing devices to allow
> reinjection (which would include reinjection of completely missed timer
> events like in your series).
>    

This really isn't the main problem.

Regards,

Anthony Liguori

> However, there was one unsolved design issue remain IIRC:
>
> http://thread.gmane.org/gmane.comp.emulators.qemu/73181
>
> Once we have a proper answer for this, we can resume creating the
> de-coalescing framework.
>
> Jan
>
>