From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [Qemu-devel] [RFC PATCH 00/20] Kemari for KVM v0.1 Date: Mon, 26 Apr 2010 00:52:08 +0300 Message-ID: <4BD4B988.9020906@redhat.com> References: <1271829445-5328-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4BD00FBA.5040604@redhat.com> <4BD02684.8060202@lab.ntt.co.jp> <4BD03ED8.707@redhat.com> <4BD0B3C1.2030308@redhat.com> <4BD12D54.2020304@lab.ntt.co.jp> <4BD14E0C.9010902@oss.ntt.co.jp> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Yoshiaki Tamura , ohmura.kei@lab.ntt.co.jp, mtosatti@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, yoshikawa.takuya@oss.ntt.co.jp, aliguori@us.ibm.com, avi@redhat.com To: =?ISO-8859-1?Q?Fernando_Luis_V=E1zquez_Cao?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16431 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754009Ab0DYVut (ORCPT ); Sun, 25 Apr 2010 17:50:49 -0400 In-Reply-To: <4BD14E0C.9010902@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 04/23/2010 10:36 AM, Fernando Luis V=E1zquez Cao wrote: > On 04/23/2010 02:17 PM, Yoshiaki Tamura wrote: >> Dor Laor wrote: > [...] >>> Second, even if it wasn't the case, the tsc delta and kvmclock are >>> synchronized as part of the VM state so there is no use of trapping= it >>> in the middle. >> >> I should study the clock in KVM, but won't tsc get updated by the HW >> after migration? >> I was wondering the following case for example: >> >> 1. The application on the guest calls rdtsc on host A. >> 2. The application uses rdtsc value for something. >> 3. Failover to host B. >> 4. The application on the guest replays the rdtsc call on host B. >> 5. If the rdtsc value is different between A and B, the application = may >> get into trouble because of it. > > Regarding the TSC, we need to guarantee that the guest sees a monoton= ic > TSC after migration, which can be achieved by adjusting the TSC offse= t properly. > Besides, we also need a trapping TSC, so that we can tackle the case = where the > primary node and the standby node have different TSC frequencies. You're right but this is already taken care of by normal save/restore=20 process. Check void kvm_load_tsc(CPUState *env) function.