On Tue, Jun 23, 2020 at 10:00 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Mon, Jun 22, 2020 at 4:02 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> >
> > On 23/06/20 00:36, Jim Mattson wrote:
> > > On Mon, Jun 22, 2020 at 3:33 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> > >>
> > >> On 16/06/20 01:07, Jim Mattson wrote:
> > >>> + } else if (vcpu->arch.this_tsc_generation !=
> > >>> + kvm->arch.cur_tsc_generation) {
> > >>> u64 tsc_exp = kvm->arch.last_tsc_write +
> > >>> nsec_to_cycles(vcpu, elapsed);
> > >>> u64 tsc_hz = vcpu->arch.virtual_tsc_khz * 1000LL;
> > >>
> > >> Can this cause the same vCPU to be counted multiple times in
> > >> nr_vcpus_matched_tsc? I think you need to keep already_matched (see
> > >> also the commit message for 0d3da0d26e3c, "KVM: x86: fix TSC matching",
> > >> 2014-07-09, which introduced that variable).
> > >
> > > No. In the case where we previously might have counted the vCPU a
> > > second time, we now start a brand-new generation, and the vCPU is the
> > > first to be counted for the new generation.
> >
> > Right, because synchronizing is false. But I'm worried that a migration
> > at the wrong time would cause a wrong start of a new generation.
> >
> > start:
> > all TSCs are 0
> >
> > mid of synchronization
> > some TSCs are adjusted by a small amount, gen 1 is started
> >
> > ----------------- migration -------------
> >
> > start:
> > all TSCs are 0
> >
> > restore state
> > all TSCs are written with KVM_SET_MSR, gen 1 is started and
> > completed
> >
> > after execution restarts
> > guests finishes updating TSCs, gen 2 starts
> >
> > and now nr_vcpus_matched_tsc never reaches the maximum.
> >
> > Paolo
>
> Hmmm...
>
> Perhaps these heuristics are, in fact, irreparable. I'll ask Oliver to
> upstream our ioctls for {GET,SET}_TSC_OFFSET. These ioctls don't help
> on ancient Intel CPUs without TSC offsetting, but they do the trick on
> most CPUs.
Indeed, I'll rebase and send these out soon.
