On 02/01/2011 05:48 PM, Glauber Costa wrote:
> > @@ -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.
Yes please.
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.
We need to choose a resolution for the clock (or negotiate one), an
nanoseconds seems as good as any from a range and precision
considerations, and is convenient for the host and Linux guests. So why
not pick it?
> > + 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?
Guest reads version (result: 2)
Guest starts reading data
Live migration; vcpu->arch.sversion is zeroed
Steal time update; vcpu->arch.sversion += 2; write to guest
Guest continues reading data
Guest reads version (result: 2)
So the guest is unaware that an update has occurred while it was reading
the data.
--
error compiling committee.c: too many arguments to function
--
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
