From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoZN0-0007ji-2G for qemu-devel@nongnu.org; Thu, 05 Dec 2013 08:53:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoZMu-0005U3-2R for qemu-devel@nongnu.org; Thu, 05 Dec 2013 08:53:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoZMt-0005Ty-PZ for qemu-devel@nongnu.org; Thu, 05 Dec 2013 08:53:28 -0500 Message-ID: <52A08541.6090702@redhat.com> Date: Thu, 05 Dec 2013 14:53:05 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1386054500.25757.10.camel@nexus> <529D90A6.2080801@lab.ntt.co.jp> <52A0186A.2050207@lab.ntt.co.jp> <1386224104.3091.3.camel@nexus> <52A04732.4040105@redhat.com> <52A07C5A.9090105@lab.ntt.co.jp> In-Reply-To: <52A07C5A.9090105@lab.ntt.co.jp> Content-Type: text/plain; charset=Shift_JIS Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-i386: clear guest TSC on reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fernando Luis Vazquez Cao Cc: Gleb Natapov , Will Auld , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org 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