> >> No, the one that forced Marcelo to add the 10 minute limit to the
> >> advance_clock. We wouldn't need this advance_clock hack if we could
> >> just call KVM_GET_CLOCK like we did before 00f4d64ee76e ("kvmclock:
> >> clock should count only if vm is running").
> >
> > There are two cases:
> >
> > - migrating a paused guest
> >
> > - pausing at the end of migration
> >
> > In the first case, kvmclock_vm_state_change's !running branch will see
> > state == RUN_STATE_FINISH_MIGRATE && s->clock_valid. In the second
> > case, it will see state == RUN_STATE_FINISH_MIGRATE && !s->clock_valid.
>
> I lift my case, marcelo's said that stopping the time is a feature ...
> (*kittens die*)
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.
> 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
