----- Original Message ----- From: "Gleb Natapov" <gleb@xxxxxxxxxx> To: "Marcelo Tosatti" <mtosatti@xxxxxxxxxx> Cc: "Vadim Rozenfeld" <vrozenfe@xxxxxxxxxx>, kvm@xxxxxxxxxxxxxxx, pl@xxxxxxx Sent: Friday, May 24, 2013 1:31:10 AM Subject: Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC On Thu, May 23, 2013 at 10:53:38AM -0300, Marcelo Tosatti wrote: > On Thu, May 23, 2013 at 12:12:29PM +0300, Gleb Natapov wrote: > > > 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? > > > > > Please read the whole discussion, we talked about it already. We > > definitely do not want to fall back to PM timer either, we want to use > > reference counter instead. > > Case 1) On migration of TSC page enabled Windows guest, from invariant TSC host, > to non-invariant TSC host, Windows guests fallback to PMTimer > and not to reference timer via MSR. > > This is suboptimal because pmtimer emulation is excessively slow. > > Is there a better option? > If setting TscSequence to zero makes Windows fall back to the MSR this is a better option. +1 This is why MS has two different mechanisms: iTSC as a primary, reference counters as a fall-back. > Case 2) > Reference timer (via MSR) support is interesting for the case of non invariant TSC > host. -- Gleb. -- 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
