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

[Anthony Liguori <anthony@codemonkey.ws>]

Hi Ulrich,

Mike Roth just posted a mechanism to implement per-device unit tests.  I 
think this is a great example to use for what type of testing we should 
be doing in QEMU.

Please take a look at Mike's series and see if you can do something 
similar for HPET as he's doing for the RTC.

Regards,

Anthony Liguori

On 02/03/2011 02:07 PM, 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.
>
>>> 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
>>
>