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? > Can you clarify concretely what goes wrong here? > > (I'm also at a bit of a loss as to why this needs both system_time and > tsc_timestamp. They're redundant in the sense that you could set > tsc_timestamp to zero and subtract (tsc_timestamp * tsc_to_system_mul) >> > tsc_shift to system_time without changing the result of the > calculation.) You would have to ensure that all elements of pvti are rounded correctly whenever the base TSC is updated. Doable, but it does seem simpler to keep subtract-TSC and add-nanoseconds separate. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
