On Fri, Jun 17, 2016 at 07:21:21PM -0300, Marcelo Tosatti wrote:
> 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
> }
Unless I'm missing something obvious again:
The per-vcpu hv_clock is updated when the vcpu processes
KVM_REQ_CLOCK_UPDATE request.
Once kvm_gen_update_masterclock() sets KVM_REQ_CLOCK_UPDATE and
clears KVM_REQ_MCLOCK_INPROGRESS for all vcpus, one vcpu can process the
requests, enter the guest, and read another vcpu's hv_clock, before that
other vcpu had a chance to process its KVM_REQ_CLOCK_UPDATE request.
Is there anything that prevents this?
Thanks,
Roman.
--
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
