From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50503)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1VHZjc-0006gs-US
	for qemu-devel@nongnu.org; Thu, 05 Sep 2013 09:36:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1VHZjW-0005Xw-TL
	for qemu-devel@nongnu.org; Thu, 05 Sep 2013 09:36:32 -0400
Message-ID: <1378388164.4321.176.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 05 Sep 2013 23:36:04 +1000
In-Reply-To: <ED53148C-F844-4894-8F21-5CD0F072C25B@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>
	<1378381449.4321.158.camel@pasglop>
	<ED53148C-F844-4894-8F21-5CD0F072C25B@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 14:37 +0200, Alexander Graf wrote:

> Hrm, I think I'm starting to understand what this is about. So what we want is
> 
>   - timebase in guest
>   - timebase frequency in guest
>   - wall clock time in host
> 
> That way the receiving end can then take the timebase and add (new_timebase - old_timebase) * tb_freq to the guest's time base.
> 
> Which gets me to the next question. Can we modify the tb frequency in guests?

No. It's architected at 512Mhz however since P7 I think. Not sure how we
did before, it's possible that P6 was the same (at least it's sourced
from more/less the same chip TOD facility).

Cheers,
Ben.