On Tue, Jan 14, 2020 at 12:30:02AM +0100, Rafael J. Wysocki wrote:

On Mon, Jan 13, 2020 at 10:50 PM Rafael J. Wysocki [off-list ref] wrote:

quoted

On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra [off-list ref] wrote:

quoted

On Mon, Jan 13, 2020 at 11:43:18AM +0000, Singh, Balbir wrote:

quoted

For your original comment, just wanted to clarify the following:

1. After hibernation, the machine can be resumed on a different but compatible
host (these are VM images hibernated)
2. This means the clock between host1 and host2 can/will be different

In your comments are you making the assumption that the host(s) is/are the
same? Just checking the assumptions being made and being on the same page with
them.

I would expect this to be the same problem we have as regular suspend,
after power off the TSC will have been reset, so resume will have to
somehow bridge that gap. I've no idea if/how it does that.

In general, this is done by timekeeping_resume() and the only special
thing done for the TSC appears to be the tsc_verify_tsc_adjust(true)
call in tsc_resume().

And I forgot about tsc_restore_sched_clock_state() that gets called
via restore_processor_state() on x86, before calling
timekeeping_resume().

In this case tsc_verify_tsc_adjust(true) this does nothing as
feature bit X86_FEATURE_TSC_ADJUST is not available to guest. 
I am no expert in this area, but could this be messing things up?

Thanks,
Anchal