From: David Gibson <david@gibson.dropbear.id.au>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: quintela@redhat.com, Alexey Kardashevskiy <aik@ozlabs.ru>,
qemu-devel@nongnu.org, agraf@suse.de, qemu-ppc@nongnu.org,
amit.shah@redhat.com
Subject: Re: [Qemu-devel] Migrating decrementer
Date: Wed, 24 Feb 2016 11:47:38 +1100 [thread overview]
Message-ID: <20160224004738.GC2808@voom.fritz.box> (raw)
In-Reply-To: <56CCCEAD.70805@ilande.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-02-24 2:47 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 18:22 [Qemu-devel] [PATCH 0/4] target-ppc: migration fixups (TCG related) Mark Cave-Ayland
2016-01-06 18:22 ` [Qemu-devel] [PATCH 1/4] target-ppc: add CPU IRQ state to PPC VMStateDescription Mark Cave-Ayland
2016-01-08 2:20 ` Alexey Kardashevskiy
2016-01-06 18:22 ` [Qemu-devel] [PATCH 2/4] target-ppc: use cpu_write_xer() helper in cpu_post_load Mark Cave-Ayland
2016-01-08 2:25 ` Alexey Kardashevskiy
2016-01-18 3:12 ` [Qemu-devel] [Qemu-ppc] " David Gibson
2016-01-18 8:31 ` Mark Cave-Ayland
2016-01-19 0:11 ` David Gibson
2016-01-06 18:22 ` [Qemu-devel] [PATCH 3/4] target-ppc: add CPU access_type into the migration stream Mark Cave-Ayland
2016-01-08 2:29 ` Alexey Kardashevskiy
2016-01-25 19:03 ` Alexander Graf
2016-01-27 1:10 ` Alexey Kardashevskiy
2016-01-06 18:22 ` [Qemu-devel] [PATCH 4/4] target-ppc: ensure we include the decrementer value during migration Mark Cave-Ayland
2016-01-08 2:47 ` Alexey Kardashevskiy
2016-01-08 14:21 ` Mark Cave-Ayland
2016-01-11 1:18 ` Alexey Kardashevskiy
2016-01-11 4:55 ` David Gibson
2016-01-11 7:43 ` Mark Cave-Ayland
2016-01-12 2:44 ` David Gibson
2016-01-15 17:46 ` Mark Cave-Ayland
2016-01-18 4:51 ` David Gibson
2016-01-25 5:48 ` [Qemu-devel] Migrating decrementer (was: Re: [PATCH 4/4] target-ppc: ensure we include the decrementer value during migration) Mark Cave-Ayland
2016-01-25 11:10 ` David Gibson
2016-01-25 17:20 ` [Qemu-devel] [Qemu-ppc] " BALATON Zoltan
2016-01-26 5:51 ` David Gibson
2016-01-26 22:31 ` [Qemu-devel] Migrating decrementer Mark Cave-Ayland
2016-01-26 23:08 ` Mark Cave-Ayland
2016-02-01 0:52 ` David Gibson
2016-02-02 23:41 ` Mark Cave-Ayland
2016-02-03 4:59 ` David Gibson
2016-02-03 5:43 ` Alexander Graf
2016-02-23 21:27 ` Mark Cave-Ayland
2016-02-24 0:47 ` David Gibson [this message]
2016-02-24 12:31 ` Juan Quintela
2016-02-25 0:19 ` David Gibson
2016-02-25 4:33 ` Mark Cave-Ayland
2016-02-25 5:00 ` [Qemu-devel] [Qemu-ppc] " Mark Cave-Ayland
2016-02-25 9:50 ` Mark Cave-Ayland
2016-02-26 4:35 ` David Gibson
2016-02-26 12:29 ` Mark Cave-Ayland
2016-02-29 3:57 ` David Gibson
2016-02-29 20:21 ` Mark Cave-Ayland
2016-03-10 4:57 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160224004738.GC2808@voom.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=amit.shah@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).