----- Original Message ----- > From: "Andi Kleen" <ak@xxxxxxxxxxxxxxx> > To: "Paolo Bonzini" <pbonzini@xxxxxxxxxx> > Cc: kvm@xxxxxxxxxxxxxxx > 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 >
