On Tue, 2013-12-10 at 17:52 +0100, Paolo Bonzini wrote:
> Il 10/12/2013 12:23, Vadim Rozenfeld ha scritto:
> > > > +               if (kvm->arch.hv_tsc_page & 
> > > > HV_X64_MSR_TSC_REFERENCE_ENABLE) {
> > > > +                       HV_REFERENCE_TSC_PAGE* tsc_ref;
> > > > +                       u64 curr_time;
> > > > +                       tsc_ref = 
> > > > (HV_REFERENCE_TSC_PAGE*)gfn_to_hva(kvm, 
> > > > +                               kvm->arch.hv_tsc_page >> 
> > > > HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
> > > > +                       tsc_ref->tsc_sequence =
> > > > +                               boot_cpu_has(X86_FEATURE_CONSTANT_TSC) 
> > > > ? tsc_ref->tsc_sequence + 1 : 0;
> > > > +                       tsc_ref->tsc_scale = ((10000LL << 32) / 
> > > > __get_cpu_var(cpu_tsc_khz)) << 32;
> > > 
> > > Why shouldn't this be vcpu->arch.virtual_tsc_khz?
> > 
> > Yeah, I was thinking about that, but we need a vcpu instance for this.
> 
> You can perhaps store the value from vcpu->arch.virtual_tsc_khz to 
> kvm->arch when the MSR is first written?
> 
> > Do you mean between HV_X64_MSR_REFERENCE_TSC which happens during
> > partition creation time and KVM_SET_CLOCK which happens during resume 
> > after partition pause? If so - there are several differences, where
> > the offset calculation probably is the most important one.
> 
> The offset and frequence are the only differences.
> 
> +                     curr_time = (((tsc_ref->tsc_scale >> 32) * 
> native_read_tsc()) >> 32) + 
> +                             tsc_ref->tsc_offset;
> +                     tsc_ref->tsc_offset = kvm->arch.hv_ref_time - curr_time;
> 
> Why do you need kvm->arch.hv_ref_time at all?  Can you just use
> "get_kernel_ns() + kvm->arch.kvmclock_offset - kvm->arch.hv_ref_count"?
> Then the same code can set tsc_ref->tsc_offset in both cases.
> 
> In fact, it's not clear to me what hv_ref_time is for, and how it
> is different from 

OK, let me explain how it works.
Hyper-V allows guest to use invariant TSC provided by host as a time
stamp source (KeQueryPerformanceCounter). Guest is calling rdtsc and
normalizing it to 10MHz frequency, it is why we need "tsc_scale".
"tsc_offset" is needed for migration or pause/resume cycles.
When we pause a VM, we need to save the current vTSC value
("hv_ref_time"), which is rdtsc * tsc_scale + tsc_offset.
Then, during resume, we need to recalculate the new tsc_scale
as well as the new tsc_offset value. 
tsc_offset = old(saved) vTSC - new vTSC

So maybe hv_ref_time is not a good name, but we use it 
for keeping the old vTSC value, saved before stopping VM.

Vadim.

> 
> By the way, a small nit:
> 
> > 
> > +           tsc_ref.tsc_sequence =
> > +                   boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0;
> > +           tsc_ref.tsc_scale =
> > +                   ((10000LL << 32) / vcpu->arch.virtual_tsc_khz) << 32;
> > +           tsc_ref.tsc_offset = 0;
> >             if (__copy_to_user((void __user *)addr, &tsc_ref, 
> > sizeof(tsc_ref)))
> >                     return 1;
> >             mark_page_dirty(kvm, gfn);
> >             kvm->arch.hv_tsc_page = data;
> > +           kvm->arch.hv_ref_count = 0;
> >             break;
> 
> This setting of kvm->arch.hv_ref_count belongs in the previous patch.
> 
> Paolo


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to