On Mon, Jun 13, 2016 at 08:19:30PM +0300, Roman Kagan wrote:
> While we're at this:
>
> According to the comments in the code, the purpose of the masterclock
> scheme is to prevent any vCPU from seeing an outdated hv_clock of
> another vCPU.
It prevents two vcpus from using different hv_clocks:
"
* To avoid that problem, do not allow visibility of distinct
* system_timestamp/tsc_timestamp values simultaneously: use a master
* copy of host monotonic time values. Update that master copy
* in lockstep.
"
> However I'm missing how that is achieved. AFAICS the guest entry is
> allowed as soon as all vCPUs are kicked from guest with
> KVM_REQ_CLOCK_UPDATE set; what stops one vCPU from processing it and
> entering the guest before another vCPU even started updating its
> hv_clock?
static void kvm_gen_update_masterclock(struct kvm *kvm)
{
#ifdef CONFIG_X86_64
int i;
struct kvm_vcpu *vcpu;
struct kvm_arch *ka = &kvm->arch;
spin_lock(&ka->pvclock_gtod_sync_lock);
kvm_make_mclock_inprogress_request(kvm);
/* no guest entries from this point */
pvclock_update_vm_gtod_copy(kvm);
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/* guest entries allowed */
kvm_for_each_vcpu(i, vcpu, kvm)
clear_bit(KVM_REQ_MCLOCK_INPROGRESS, &vcpu->requests);
spin_unlock(&ka->pvclock_gtod_sync_lock);
#endif
}
--
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
