> > But that's why separating the two cases brings us the best of both worlds. > > If migrating a paused guest, there's no need for any adjustment, so no > > advance_clock hack. If pausing at the end of migration, there's no need > > to pause kvmclock (this patch is effectively working around 00f4d64ee76e) > > and if we don't do that we can just call KVM_GET_CLOCK at pre_save time. > > That was my internal v1. But then, the destination ignores s->clock > as follows: > > if (running) { > struct kvm_clock_data data = {}; > uint64_t time_at_migration = kvmclock_current_nsec(s); Right, but this is unnecessary in 4.9-rc, where KVM_GET_CLOCK *already* returns the same as QEMU's kvmclock_current_nsec. So this is the other half of my suggestion, where we need to check the behavior of KVM_GET_CLOCK via KVM_CHECK_EXTENSION. I think it's okay to only fix the bug with master clock enabled and for new KVM with sensible KVM_GET_CLOCK semantics. Paolo > s->clock_valid = false; > > /* We can't rely on the migrated clock value, just discard it */ > if (time_at_migration) { > s->clock = time_at_migration; > } > > data.clock = s->clock; > ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data); > > So you need to send that "ns" value (difference of two clock reads) > separately. > > > > > > Oh, and this does introduce a minor bug to this patch -- the time > > > counted by KVM_GET_CLOCK is has different frequency CLOCK_MONOTONIC. > > > Not accounting for that is bearable. > > > > Not really, I was going to point that out when I got to replying with > > a review. :) > > > > Paolo > > -- 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