From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36904)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1VHYs3-00045L-Vd
	for qemu-devel@nongnu.org; Thu, 05 Sep 2013 08:41:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1VHYrw-0004oV-Es
	for qemu-devel@nongnu.org; Thu, 05 Sep 2013 08:41:11 -0400
Message-ID: <1378381449.4321.158.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 05 Sep 2013 21:44:09 +1000
In-Reply-To: <F5F06793-4E50-4B4C-96DC-535009BB7DF3@suse.de>
References: <1378193502-4968-1-git-send-email-aik@ozlabs.ru>
	<20130905043059.GC10158@voom.redhat.com> <52280E96.1030402@ozlabs.ru>
	<350E3728-BF3A-4B43-8E43-2622033970D0@suse.de>
	<52285369.1040907@ozlabs.ru>
	<F5F06793-4E50-4B4C-96DC-535009BB7DF3@suse.de>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH] spapr: support time base offset
	migration
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>, Andreas =?ISO-8859-1?Q?F=E4rber?= <afaerber@suse.de>, Paul Mackerras <paulus@samba.org>, David Gibson <david@gibson.dropbear.id.au>

On Thu, 2013-09-05 at 11:58 +0200, Alexander Graf wrote:

> > Yes. I do not really understand the problem here (and I am not
> playing
> > dump). Do you suggest sending just the guest timebase and do not
> send the
> > host timebase and the offset (one number instead of two)? I can do
> that,
> > makes sense, no problem, thanks for the idea.
> 
> Yup, pretty much :). The receiving end should have no business in
> knowing how far off the guest and the host timebase were skewed on the
> sending end :).

Well, yes and no ... we'd like to account for the migration latency on
the timebase or the guest view of real time will get skewed since it
uses the TB to maintain it's clock.

So assuming both hosts are reasonably synchronized with NTP, we want a
correlation guest TB / TOD in order to properly make the adjustment on
the target.

This may not be what Alexey implemented but I think that's what Paulus
and I asked for :-)

Cheers,
Ben.