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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

On 2011-02-04 03:06, Anthony Liguori wrote:
> 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.

But that's the only thing this patch is after: lost ticks at QEMU level.

> 
>> 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.

We don't have this issues. Relative to the host's time base, we can
actually prevent lost ticks, thus drift.

> 
> 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.

I don't disagree. The question is just how to detect guest-missed ticks.

> 
> 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.

Again, I don't disagree, but I would like to finally attack this in a
non-ad-hoc manner, specifically when going upstream.

The input & output infrastructure (aka injection feedback), and all
these calculations should be generically available so that we do not
reinvent the wheel every time we add another timer device that guests me
use for time keeping. This issue is surely not an x86-only thing. Even
on x86, we need it also for the PIT and the RTC, conceptually also for
the APIC when configured in periodic mode.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]