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.
