Re: qemu polling KVM_IRQ_LINE_STATUS when stopped

[Paolo Bonzini <pbonzini@redhat.com>]

----- Original Message -----
> From: "Andi Kleen" <ak@linux.intel.com>
> To: "Paolo Bonzini" <pbonzini@redhat.com>
> Cc: kvm@vger.kernel.org
> Sent: Friday, October 20, 2017 10:50:26 PM
> Subject: Re: qemu polling KVM_IRQ_LINE_STATUS when stopped
> 
> On Fri, Oct 20, 2017 at 05:12:40PM +0200, Paolo Bonzini wrote:
> > On 20/10/2017 16:09, Andi Kleen wrote:
> > >> Unfortunately that's not possible in general.  Windows uses the periodic
> > >> timer to track wall time (!), so if you do that your clock is going to
> > >> be late when you resume the guest.
> > > 
> > > But when the guest cannot execute instructions
> > > it cannot see whatever the handler does.
> > > 
> > > So the handler could always catch up after stopping for longer,
> > > without making any difference.
> > 
> > You may be right... you should get the interrupt storm *after
> > continuing* the guest, but not while it's stopped.
> 
> Maybe be find to not have a storm, but only one. I belive real hardware
> cannot have a storm because only one interrupt can be pending at a time.

Real hardware also doesn't pause for an extended period of time, with
exceptions such as JTAG that aren't as prominent as pausing a virtual
machine.  This is just how Windows works: unless it's S3/S4, it updates
the time from RTC periodic timer ticks, and the frequency sometimes goes
up as much as 1024 or 2048 Hz (default being 64 Hz IIRC).

In fact, we have a lot of cruft in KVM just to track periodic timer
ticks that couldn't be delivered and retry again a little later.  Without
that, the smallest load on the host is enough for time to drift in
Windows guests.

Paolo

> The RTC driver should be able to figure it out from the actual time,
> and it already needs to handle it because this can happen for other
> reasons (e.g. a JTAG debugger)
> 
> -Andi
>