On 04/23/2010 10:36 AM, Fernando Luis Vázquez 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 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
