qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: amit.shah@redhat.com, qemu-ppc@nongnu.org,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [Qemu-ppc] Migrating decrementer (was: Re: [PATCH 4/4] target-ppc: ensure we include the decrementer value during migration)
Date: Tue, 26 Jan 2016 16:51:20 +1100	[thread overview]
Message-ID: <20160126055120.GD16692@voom.fritz.box> (raw)
In-Reply-To: <alpine.BSF.2.20.1601251808490.88373@zero.eik.bme.hu>

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

On Mon, Jan 25, 2016 at 06:20:21PM +0100, BALATON Zoltan wrote:
> On Mon, 25 Jan 2016, David Gibson wrote:
> >Remember, we only ever compute the guest timebase value at the moment
> >the guest requests it - actually maintaining a current timebase value
> >makes sense in hardware, but would be nuts in software.
> >
> >The timebase is a function of real, wall-clock time, and the migration
> >destination has a notion of wall-clock time without reference to the
> >source.
> >
> >So what you need to transmit for migration is enough information to
> >compute the guest timebase from real-time - essentially just an offset
> >between real-time and the timebase.
> 
> I don't know anything about all this but if I understand your conversation
> correctly then you don't really need an offset between real-time and
> timebase. That would be true assuming the source and destination has the
> same real-time but that's not necessarily true.

No, it's not necessarily true, but if it's not that's not really our
problem to deal with.

We do ensure that the guest timebase doesn't go backwards in this
situation, but if the source and destination hosts don't have
synchronized time, the guest real time may jump.  But since we have no
idea whether the source or destination had a better notion of
real-time, we can't really do any better.

> What would be needed is an
> offset between source timebase and destination's real time. That is, besides
> the offset on the source you would also need to work out the difference in
> the "real-time" on the source and destination and correct the transferred
> offset with this after migration.

Yeah, that's not really possible in the current migration model.  Nor
is it something that's really qemu's job.

> Is this handled somehow in QEMU (for example by doing some message exchange
> to establish the clock difference between the source and destination during
> migration) or is it assumed that migration always needs synchronised clocks
> done by some external means?

Migration itself doesn't need synced clocks, but if the hosts'
real-time isn't well behaved, you can't really expect the guest's real
time to be well behaved.

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

  reply	other threads:[~2016-01-26  5:50 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 [this message]
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
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=20160126055120.GD16692@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=amit.shah@redhat.com \
    --cc=balaton@eik.bme.hu \
    --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).