----- Original Message ----- From: "Marcelo Tosatti" <mtosatti@xxxxxxxxxx> To: "Vadim Rozenfeld" <vrozenfe@xxxxxxxxxx> Cc: kvm@xxxxxxxxxxxxxxx, gleb@xxxxxxxxxx, pl@xxxxxxx Sent: Thursday, May 23, 2013 11:47:46 PM Subject: Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC On Thu, May 23, 2013 at 08:21:29AM -0400, Vadim Rozenfeld wrote: > > > @@ -1848,6 +1847,11 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data) > > > HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT); > > > if (kvm_is_error_hva(addr)) > > > return 1; > > > + tsc_ref.TscSequence = > > > + boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0; > > > > 1) You want NONSTOP_TSC (see 40fb1715 commit) which matches INVARIANT TSC. > > [VR] > > Thank you for reviewing. Will fix it. > > 2) TscSequence should increase? > > "This field serves as a sequence number that is incremented whenever..." > > [VR] > > Yes, on every VM resume, including migration. After migration we also need > > to recalculate scale and adjust offset. > > 3) 0xFFFFFFFF is the value for invalid source of reference time? > > [VR] Yes, on boot-up. In this case guest will go with PMTimer (not sure about HPET > > but I can check). But if we set sequence to 0xFFFFFFFF after migration - it's probably will not work. > > "Reference TSC during Save and Restore and Migration > > To address migration scenarios to physical platforms that do not support > iTSC, the TscSequence field is used. In the event that a guest partition > is migrated from an iTSC capable host to a non-iTSC capable host, the > hypervisor sets TscSequence to the special value of 0xFFFFFFFF, which > directs the guest operating system to fall back to a different clock > source (for example, the virtual PM timer)." > > Why it would not/does not work after migration? > > [VR] > Because of different frequencies, I think. > Hyper-V reference counters and iTSC report > performance frequency equal to 10MHz, > which is obviously is not true for PM and HPET timers. Windows has to convert from the native hardware clock frequency to internal system frequency, so i don't believe this is a problem. > Windows calibrates timers on boot-up and you probably > have no chance to do it after or during resume. It is documented as such, it has been designed to fallback to other hardware clock devices. Is there evidence for any problem on fallback? Earlier you said: "> What if you put 0xFFFFFFFF as a sequence? Or is this another case where > the spec is wrong. > it will use PMTimer (maybe HPET if you have it) if you specify it on VM's start up. But I'm not sure if it will work if you migrate from TSC or reference counter to 0xFFFFFFFF " On startup, not after migration, when you migrate to host w/o iTSC and/or reference counters support. -- 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
