From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCAVt-00058W-D5 for qemu-devel@nongnu.org; Thu, 13 Sep 2012 10:35:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCAVn-0002MC-Qq for qemu-devel@nongnu.org; Thu, 13 Sep 2012 10:35:29 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:52436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCAVn-0002L1-LU for qemu-devel@nongnu.org; Thu, 13 Sep 2012 10:35:23 -0400 Received: by obbta14 with SMTP id ta14so4252671obb.4 for ; Thu, 13 Sep 2012 07:35:22 -0700 (PDT) From: Anthony Liguori In-Reply-To: <20120913142228.GK20907@redhat.com> References: <87pq5r5otp.fsf@codemonkey.ws> <20120912151549.GT20907@redhat.com> <87y5kfrtne.fsf@codemonkey.ws> <20120913104940.GA20907@redhat.com> <5051DC20.4090204@redhat.com> <20120913132804.GO7767@redhat.com> <87r4q6xbiy.fsf@codemonkey.ws> <20120913142228.GK20907@redhat.com> Date: Thu, 13 Sep 2012 09:35:18 -0500 Message-ID: <87boha7zyx.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Rethinking missed tick catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, Jan Kiszka , Michael Roth , Luiz Capitulino , Avi Kivity , Paolo Bonzini , Eric Blake Gleb Natapov writes: > On Thu, Sep 13, 2012 at 09:06:29AM -0500, Anthony Liguori wrote: >> "Daniel P. Berrange" writes: >> >> I think it's better for QEMU to talk to qemu-ga. We can tell when a large >> period of time has passed in QEMU because we'll accumulate a large >> number of missed ticks. >> > With RTC configured to use vm clock we will not. Not for host suspend. For stop and live migration, we stop vm_clock. But QEMU isn't aware of host suspend so vm_clock cannot be stopped. >> This could happen because of stop, host suspend, live migration to a >> file, etc. >> >> It's much easier for us to call into qemu-ga to do the time correction >> whenever this event occurs than to try and have libvirt figure out when >> it's necessary. > And if guest does not have qemu-ga what is better inject interrupts like > crazy for next 2 minutes or leave guest with incorrect time? Yes, at least that's fixable by the end-user. QEMU consuming 100% CPU for a prolonged period of time isn't fixable. Regards, Anthony Liguori > >> >> We know exactly when it's necessary, libvirt would need to guess. >> >> Yes, we could generate a QMP event when a large skew was dedicated, but >> I think this could happen often enough that it would be problematic. >> Since QEMU is already implementing policy doing timer catchup in the >> first place, I think we probably should own time catchup policy entirely. >> >> Regards, >> >> Anthony Liguori >> >> > >> > Regards, >> > Daniel >> > -- >> > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| >> > |: http://libvirt.org -o- http://virt-manager.org :| >> > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| >> > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > -- > Gleb.