On Mon, Dec 14, 2015 at 2:00 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > On Mon, Dec 14, 2015 at 02:44:15PM +0100, Paolo Bonzini wrote: >> >> >> On 11/12/2015 22:57, Andy Lutomirski wrote: >> > I'm still not seeing the issue. >> > >> > The formula is: >> > >> > (((rdtsc - pvti->tsc_timestamp) * pvti->tsc_to_system_mul) >> >> > pvti->tsc_shift) + pvti->system_time >> > >> > Obviously, if you reset pvti->tsc_timestamp to the current tsc value >> > after suspend/resume, you would also need to update system_time. >> > >> > I don't see what this has to do with suspend/resume or with whether >> > the effective scale factor is greater than or less than one. The only >> > suspend/resume interaction I can see is that, if the host allows the >> > guest-observed TSC value to jump (which is arguably a bug, what that's >> > not important here), it needs to update pvti before resuming the >> > guest. >> >> Which is not an issue, since freezing obviously gets all CPUs out of >> guest mode. >> >> Marcelo, can you provide an example with made-up values for tsc and pvti? > > I meant "systemtime" at ^^^^^. > > guest visible clock = systemtime (updated at time 0, guest initialization) + scaled tsc reads=LARGE VALUE. > ^^^^^^^^^^ > guest reads clock to memory at location A = scaled tsc read. > -> suspend resume event > guest visible clock = systemtime (updated at time AFTER SUSPEND) + scaled tsc reads=0. > guest reads clock to memory at location B. > > So before the suspend/resume event, the clock is the RAW TSC values > (scaled by kvmclock, but the frequency of the RAW TSC). > > After suspend/resume event, the clock is updated from the host > via get_kernel_ns(), which reads the corrected NTP frequency TSC. > > So you switch the timebase, from a clock running at a given frequency, > to a clock running at another frequency (effective frequency). > > Example: > > RAW TSC NTP corrected TSC > t0 10 10 > t1 20 19.99 > t2 30 29.98 > t3 40 39.97 > t4 50 49.96 > > ... > > if you suddenly switch from RAW TSC to NTP corrected TSC, > you can see what will happen. Sure, but why would you ever switch from one to the other? I'm still not seeing the scenario under which this discontinuity is visible to anything other than the kvmclock code itself. The only things that need to be monotonic are the output from vread_pvclock and the in-kernel equivalent, I think. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
