qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Rethinking missed tick catchup


From: Gleb Natapov
Subject: Re: [Qemu-devel] Rethinking missed tick catchup
Date: Thu, 13 Sep 2012 17:48:11 +0300

On Thu, Sep 13, 2012 at 09:35:18AM -0500, Anthony Liguori wrote:
> Gleb Natapov <address@hidden> writes:
> 
> > On Thu, Sep 13, 2012 at 09:06:29AM -0500, Anthony Liguori wrote:
> >> "Daniel P. Berrange" <address@hidden> 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. 

> >> 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.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]