> > @@ -2106,6 +2120,25 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> > kvm_migrate_timers(vcpu);
> > vcpu->cpu = cpu;
> > }
> > +
> > + if (vcpu->arch.this_time_out) {
> > + u64 to = (get_kernel_ns() - vcpu->arch.this_time_out);
> > + /*
> > + * using nanoseconds introduces noise, which accumulates easily
> > + * leading to big steal time values. We want, however, to keep the
> > + * interface nanosecond-based for future-proofness.
> > + */
> > + to /= NSEC_PER_USEC;
> > + to *= NSEC_PER_USEC;
>
> Seems there is a real problem and that this is just papering it over.
> I'd like to understand the root cause.
Okay, my self-explanation seemed reasonable to me, but since both you
and Peter dislike it, I think it is important enough to get a more
thorough investigation before a second round.
But in this case,
I keep that using nanoseconds may then not be the best approach here. We
also have to keep in mind that the host and guest clocks may be running
at different resolutions.
> > + vcpu->arch.sversion += 2;
>
> Doesn't survive live migration. You need to use the version from the
> guest area.
Why not? Who said versions need to always increase? If current version
is 102324, and we live migrate and it becomes 0, what is the problem?