On Fri, Nov 04, 2016 at 05:29:36PM -0400, Paolo Bonzini wrote:
>
> > >> 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.
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);
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
