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. -- 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
