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
