2017-06-13 20:00+0800, Jay Zhou: > On 2017/6/13 3:52, Radim Krčmář wrote: > > If you get a timestamp from KVM_GET_CLOCK() and pass that to > > KVM_SET_CLOCK(), then kvmclock should not jump backwards anymore > > (it could before 4.9, but only if the host had stable tsc). > > If migrating from old KVMs to newer KVMs (v4.9+), the clock member > of struct KVMClockState is migrated to the destination side, but the > clock_is_reliable isn't migrated. clock_is_reliable is migrated as a subsection on newer QEMUs. > The value of clock_is_reliable is false > at the source side, and it is true at the destination side. clock_is_reliable is only set right after KVM_GET_CLOCK() and doesn't change on the destination side. > Is it possible > the clock member of struct KVMClockState migrated is smaller than the > last_value saved in the guest theoretically? KVM_GET_CLOCK() should return the kvmclock timestamp that would be seen by the guest at that time. And KVM_SET_CLOCK() would set the timestamp so that a guest reading at that time would see it. And because the guest is not running after KVM_GET_CLOCK() and before KVM_SET_CLOCK(), then it should never see a timestamp that goes backwards -- the kvmclock is going to readable until "X - epsilon" and from "X + epsilon", where X is the value QEMU got from KVM_GET_CLOCK(). > Could you explain more > why it should not jump backwards in the scenario of migrating from unstable > tsc host to stable tsc host? KVM_GET_CLOCK() returns clock based on ktime_get_boot_ns() and unstable tsc host uses that to synchronize kvmclock on every VM entry, so the last time we can read inside the guest is exteremely unlikely to be larger that the value we get get from KVM_GET_CLOCK() after all VCPUs have been paused -- the guest would have to run without a VM exit for a really long time to make a delta of several microseconds. KVM does have a KVM_SET_CLOCK() bug on a stable TSC destination that could also shift the time, but that one could only be hit if the destination was waiting for a long time and I hope it doesn't happen in the wild, because we'd also be hitting it with stable source tsc. > > Can you provide the values used for KVM_GET_CLOCK and KVM_SET_CLOCK when > > the bug occurs? > > I didn't print these values out when the bug occured, and I do not have the > physical machine with unstable tsc clocksource now. But I will try to > reproduce with the newest KVM and QEMU once I have. Great, thanks!
