Re: [Qemu-ppc] [RFC PATCH] spapr: support time base offset migration

[Alexander Graf]

On 05.09.2013, at 13:44, Benjamin Herrenschmidt wrote:

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

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?


Alex