Il 05/12/2013 14:15, Fernando Luis Vazquez Cao ha scritto:
> /*
> * KVM is yet unable to synchronize TSC values of multiple VCPUs on
> * writeback. Until this is fixed, we only write the offset to SMP
> * guests after migration, desynchronizing the VCPUs, but avoiding
> * huge jump-backs that would occur without any writeback at all.
> */
> - if (smp_cpus == 1 || env->tsc != 0) {
> + if (smp_cpus == 1 || env->tsc != 0 || level == KVM_PUT_RESET_STATE) {
> kvm_msr_entry_set(&msrs[n++], MSR_IA32_TSC, env->tsc);
> }
This is still a bit ugly, and desynchronizes the VCPUs on reset.
The main point of my outlined solution is that you only have one value
that is tracked, not one per VCPU (which in the case of migration adds
unpredictable latencies---for example due to emptying the migration
buffers). We already save that value; all that's left is to use it
instead of env->tsc.
Though you would need one change here:
> - add a function kvm_set_ticks(int64_t ticks) to kvm-all.c and
> kvm-stub.c. For kvm-all.c it calls kvm_arch_set_ticks(CPUState *cpu,
> int64_t ticks) in target-*/kvm.c. The kvm_arch_set_tsc() function has a
> dummy implementation for all architectures except x86. For x86 it calls
> KVM_SET_MSRS passing "ticks + env->tsc_offset".
Instead you can make kvm_{,arch_}update_ticks() and pass
"cpu_get_ticks() + env->tsc_offset" to KVM_SET_MSRS (looping across all
VCPUs). Assuming the TSC is synchronized to begin with on host CPUs,
and the latency is similar for all CPUs from the invocation of the ioctl
to the time TSC_OFFSET is written, the synchronization should be decent.
Paolo
--
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
