From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCEaF-0008IO-Mw for qemu-devel@nongnu.org; Thu, 13 Sep 2012 14:56:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCEaE-0000nj-FK for qemu-devel@nongnu.org; Thu, 13 Sep 2012 14:56:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCEaE-0000mb-4R for qemu-devel@nongnu.org; Thu, 13 Sep 2012 14:56:14 -0400 Date: Thu, 13 Sep 2012 21:56:00 +0300 From: Gleb Natapov Message-ID: <20120913185600.GG25041@redhat.com> References: <20120913104940.GA20907@redhat.com> <5051DC20.4090204@redhat.com> <20120913132804.GO7767@redhat.com> <87r4q6xbiy.fsf@codemonkey.ws> <20120913142228.GK20907@redhat.com> <87boha7zyx.fsf@codemonkey.ws> <20120913144811.GL20907@redhat.com> <87ehm5or07.fsf@codemonkey.ws> <20120913160613.GF25041@redhat.com> <87392l7oxw.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87392l7oxw.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] Rethinking missed tick catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Jan Kiszka , Michael Roth , Luiz Capitulino , Avi Kivity , Paolo Bonzini , Eric Blake On Thu, Sep 13, 2012 at 01:33:31PM -0500, Anthony Liguori wrote: > Gleb Natapov writes: > > > On Thu, Sep 13, 2012 at 10:56:56AM -0500, Anthony Liguori wrote: > >> Gleb Natapov writes: > >> > >> > On Thu, Sep 13, 2012 at 09:35:18AM -0500, Anthony Liguori wrote: > >> >> 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. > >> >> > >> > Hmm, true. What about hooking into suspend and doing vmstop during > >> > suspend. > >> > >> Is suspend the only foreseeable way for this problem to happen? I don't > >> think it is which is what concerns me about any approach that relies on > >> "hooking suspend". > >> > > With RTC using real time clock setting host time far ahead of what is it > > will trigger same behaviour I think. > > > >> Also, I don't think there is a generic way to "hook suspend". > >> > >> >> >> 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. > >> >> > >> > You mean yes to "leave guest with incorrect time"? QEMU will still > >> > consume 100% of cpu for some time calling qemu_timer callback millions > >> > times. timedrift code is not the right level to fix that. > >> > >> Not if we put a cap on how many interrupts we'll try to catch up. > >> > > Interrupts ctachup happens at another level. If guest was stopped for > > 24 hours while RTC was configured to 1kHz qemu_timer will fire callback > > 88473600 times. Each invocation will try to inject interrupt and fail > > incrementing coalesced_irq instead. You can cap coalesced_irq but > > callback will still fire 88473600 times. > > That's a bug. > > The next period calculation should not be based on the last period + > length of period but rather on the current time + delta to next period > boundary. > I disagree that this is a bug. This is by design to account for timer signals that was delivered to late. > IOW, if we shouldn't arm timers to expire backwards in time from when > the event occurred. That should be accounted as a missed tick. > Not all users of qemu_timer have their own missed tick accounting so qemu_timer provides general one. We can create another time source for qemu_timer without this behaviour and use it in RTC. -- Gleb.