qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 00/20] Kemari for KVM v0.1


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
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4 ThunderBrowse/3.2.8.1

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]