On 04/23/2010 10:36 AM, Fernando Luis Vázquez Cao wrote:
quoted text
> 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 monotonic
> TSC after migration, which can be achieved by adjusting the TSC offset 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 
process. Check void kvm_load_tsc(CPUState *env) function.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html