Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC

[Vadim Rozenfeld <vrozenfe@redhat.com>]

----- Original Message -----
From: "Gleb Natapov" <gleb@redhat.com>
To: "Marcelo Tosatti" <mtosatti@redhat.com>
Cc: "Vadim Rozenfeld" <vrozenfe@redhat.com>, kvm@vger.kernel.org, pl@dlh.net
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.