From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: qemu polling KVM_IRQ_LINE_STATUS when stopped Date: Fri, 20 Oct 2017 18:51:22 -0400 (EDT) Message-ID: <1560363269.13828538.1508539882580.JavaMail.zimbra@redhat.com> References: <87a80pihlz.fsf@linux.intel.com> <20171018174946.GU5109@tassilo.jf.intel.com> <3d37ef15-932a-1492-3068-9ef0b8cd5794@redhat.com> <20171020003449.GG5109@tassilo.jf.intel.com> <22d62b58-725b-9065-1f6d-081972ca32c3@redhat.com> <20171020140917.GH5109@tassilo.jf.intel.com> <2db78631-3c63-5e93-0ce8-f52b313593e1@redhat.com> <20171020205026.GI5109@tassilo.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Andi Kleen Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40582 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752334AbdJTWvY (ORCPT ); Fri, 20 Oct 2017 18:51:24 -0400 In-Reply-To: <20171020205026.GI5109@tassilo.jf.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: ----- Original Message ----- > From: "Andi Kleen" > To: "Paolo Bonzini" > 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 >