Re: [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save

Paolo Bonzini
2016-11-04T22:35:25Z

> > 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
>
>