Messages in this thread | | | Date | Tue, 15 Dec 2009 16:21:39 -0200 | From | Marcelo Tosatti <> | Subject | Re: [PATCH RFC: kvm tsc virtualization 15/20] Fix longstanding races |
| |
On Mon, Dec 14, 2009 at 06:08:42PM -1000, Zachary Amsden wrote:
<snip>
+ atomic_set(&per_cpu(cpu_tsc_synchronized, freq->cpu), 0); + spin_lock(&kvm_lock); + list_for_each_entry(kvm, &vm_list, vm_list) { + kvm_for_each_vcpu(i, vcpu, kvm) { + if (vcpu->cpu != freq->cpu) + continue; + if (vcpu->cpu != smp_processor_id()) + send_ipi++; + kvm_request_guest_time_update(vcpu);
There is some overlap here between KVM_REQ_KVMCLOCK_UPDATE and cpu_tsc_synchronized. Its the same information (frequency for a CPU has changed) stored in two places.
Later you do:
spin_lock(&kvm_lock); list_for_each_entry(kvm, &vm_list, vm_list) { kvm_for_each_vcpu(i, vcpu, kvm) { if (vcpu->cpu != freq->cpu) continue; if (vcpu->cpu != smp_processor_id()) send_ipi++; kvm_request_guest_time_update(vcpu); } } spin_unlock(&kvm_lock); <--- a remote CPU could have updated kvmclock information with stale cpu_tsc_khz, clearing the KVM_REQ_KVMCLOCK_UPDATE bit. smp_call_function(evict) (which sets cpu_tsc_synchronized to zero)
Maybe worthwhile to unify it. Perhaps use the per cpu tsc generation in addition to vcpu_load to update kvmclock info (on arch vcpu_load update kvmclock store generation, update again on generation change).
| |