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

[Anthony Liguori]

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