Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.

[Gleb Natapov <gleb@redhat.com>]

On Fri, Oct 31, 2008 at 02:17:19PM -0500, Anthony Liguori wrote:
> Gleb Natapov wrote:
>> Qemu device emulation for timers might be inaccurate and
>> causes coalescing of several IRQs into one. It happens when the
>> load on the host is high and the guest did not manage to ack the
>> previous IRQ. The problem can be reproduced by copying of a big
>> file or many small ones inside Windows guest. When you do that guest 
>> clock start to lag behind the host one.
>>
>> The first patch in the series changes qemu_irq subsystem to return
>> IRQ delivery status information. If device is notified that IRQs
>> where lost it can regenerate them as needed. The following two
>> patches add IRQ regeneration to PIC and RTC devices.
>>   
>
> I don't think any of the problems raised when this was initially posted.  
So? I raise them now. Have you tried suggested scenario and was able to
reproduce the problem?

> Further, I don't think that always playing catch-up with interrupts is 
> always the best course of action.
>
Agree. Playing catch-up with interrupts is not always the best course of
action. But sometimes there is no other choice.

> As I've said repeatedly in the past, any sort of time drift fixes needs  
> to have a lot of data posted with it that is repeatable.
>
> How much does this improve things with Windows? 
The time drift is eliminated. If there is a spike in a load time may
slow down, but after that it catches up (this happens only during very
high loads though).

>                                                  How does having a high  
> resolution timer in the host affect the problem to begin with?
My test machine has relatively recent kernel that use high resolution
timers for time keeping. Also the problem is that guest does not receive
enough time to process injected interrupt. How hr timer can help here?

>                                                                 How do  
> Linux guests behave with this?
Linux guests don't use pit or RTC for time keeping. They are completely
unaffected by those patches.

>
> Even the Windows PV spec calls out three separate approaches to dealing  
> with missed interrupts and provides an interface for the host to query  
> the guest as to which one should be used.  I don't think any solution  
> that uses a single technique is going to be correct.
>
That is what I found in Microsoft docs:

  If a virtual processor is unavailable for a sufficiently long period of
  time, a full timer period may be missed. In this case, the hypervisor
  uses one of two techniques. The first technique involves timer period
  modulation, in effect shortening the period until the timer “catches
  up”.

  If a significant number of timer signals have been missed, the
  hypervisor may be unable to compensate by using period modulation. In
  this case, some timer expiration signals may be skipped completely.
  For timers that are marked as lazy, the hypervisor uses a second
  technique for dealing with the situation in which a virtual processor is
  unavailable for a long period of time. In this case, the timer signal is
  deferred until this virtual processor is available. If it doesn’t become
  available until shortly before the next timer is due to expire, it is
  skipped entirely. 

The first techniques is what I am trying to introduce with this patch
series.

--
			Gleb.