qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Migrating decrementer


From: David Gibson
Subject: Re: [Qemu-devel] Migrating decrementer
Date: Wed, 24 Feb 2016 11:47:38 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Feb 23, 2016 at 09:27:09PM +0000, Mark Cave-Ayland wrote:
> On 03/02/16 04:59, David Gibson wrote:
> 
> >> Going back to your earlier email you suggested that the host timebase is
> >> always continuously running, even when the guest is paused. But then
> >> resuming the guest then the timebase must jump in the guest regardless?
> >>
> >> If this is the case then this is the big difference between TCG and KVM
> >> guests: TCG timebase is derived from the virtual clock which solves the
> >> problem of paused guests during migration. For example with the existing
> >> migration code, what would happen if you did a migration with the guest
> >> paused on KVM? The offset would surely be wrong as it was calculated at
> >> the end of migration.
> > 
> > So there are two different cases to consider here.  Once is when the
> > guest is paused incidentally, such as during migration, the other is
> > when the guest is explicitly paused.
> > 
> > In the first case the timebase absolutely should keep running (or
> > appear to do so), since it's the primary source of real time for the
> > guest.
> 
> I'm not sure I understand this, since if the guest is paused either
> deliberately or incidentally during migration then isn't the timebase
> also frozen? Or is it external to the CPU?

I don't really understand the question.  Migration has no equivalent
in real hardware, so there's no "real" behaviour to mimic.  If we
freeze the TB during migration, then the guest's clock will get out of
sync with wall clock time, and in a production environment that's
really bad.  So no, we absolutely must not freeze the TB during
migration.

When the guest has been explicitly paused, there's a case to be made
either way.

> > In the second case, it's a bit unclear what the right thing to do is.
> > Keeping the tb running means accurate realtime, but stopping it is
> > often better for debugging, which is one of the main reasons to
> > explicitly pause.
> > 
> > I believe spapr on KVM HV will keep the TB going, but the TSC on x86
> > will be stopped.
> 
> Is this from a guest-centric view, i.e. if I pause a VM and wait 20 mins
> then when the guest resumes the timebase will jump forward by 20 mins
> worth of ticks?

Yes, that's correct.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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