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
