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 03:24 PM, Jan Kiszka wrote:
> On 2011-02-03 21:07, Anthony Liguori wrote:
>    
>> 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.
>>      
> Blind (/wrt the guest state) reinjection from the iothread will
> compensate for lost time of *that* thread but not of the target vcpu(s).
>    

Is the case your concern about where you try to set an interrupt from 
the I/O thread and the VCPU is not scheduled such that it doesn't 
actually get injected into KVM until after the period is over?

This should be a rare event.  If you are missing 50% of your 
notifications, not amount of gradual catchup is going to help you out.

> So, depending on your workload, you may reduce the drift more or less,
> but you won't fix it this way.
>    

There is no such thing as "fix" it.  Time drift can happen on bare metal 
too.  Interrupts can be coalesced due to crappy SMM code.  It's 
something we see quite a lot in practice.

My point is that there's really low hanging fruit and while for some 
curious reason I don't actually see this patch, I believe that a patch 
like this probably can help us quite a lot in the short term.

The think the two biggest problems we have right now are bad period 
calculations due to sloppy unit conversion (PIT/RTC) and lack of 
accounting for missed periods.

It's worth noting again that if you don't use a gradual catchup policy, 
interrupt notifiers are extremely important because you're not going to 
inject before the end of the interrupt window.   However, with a gradual 
policy, it shouldn't be a huge issue.

Regards,

Anthony Liguori

> Jan
>
>