This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Clock jumped 50 minutes in dom0 caused incorrect 2008 R2

On Tue, 2011-01-04 at 17:09 +0000, Ian Campbell wrote:
> Which ever one of you started it: Please don't top post.
> > On Sat, Oct 09, 2010 at 10:15:20AM +0800, wei song wrote:
> > >  added timer_mode =2  and tsc_mode = 1 and viridian=1 into your configure
> > > file.
> On Mon, 2010-10-11 at 11:10 +0100, Mark Adams wrote:
> > I can try this, but can you please confirm what these options do?
> viridian=1 turns off support for the Hyper-V virtualisation
                   ^^^ on ;)

> compatibility layer. Not many of these are actually supported but AFAIK
> one or two are and can affect the behaviour of Win2008 (although you
> would hope it was for the better!)
> According to xmexample.hvm: tsc_mode : TSC mode (0=default, 1=native
> TSC, 2=never emulate, 3=pvrdtscp).

>From xen/include/asm-x86/time.h:
 *  PV TSC emulation modes:
 *    0 = guest rdtsc/p executed natively when monotonicity can be guaranteed
 *         and emulated otherwise (with frequency scaled if necessary)
 *    1 = guest rdtsc/p always emulated at 1GHz (kernel and user)
 *    2 = guest rdtsc always executed natively (no monotonicity/frequency
 *         guarantees); guest rdtscp emulated at native frequency if
 *         unsupported by h/w, else executed natively
 *    3 = same as 2, except xen manages TSC_AUX register so guest can
 *         determine when a restore/migration has occurred and assumes
 *         guest obtains/uses pvclock-like mechanism to adjust for
 *         monotonicity and frequency changes

> Timer mode is apparently "0=delay virtual time when ticks are missed;
> 1=virtual time is always wallclock time".

It's all explained in xen/include/public/hvm/params.h

AIUI, timer_mode=0 means if timer ticks were missed then they all get
re-injected in to the guest when next run. IOW if 5 ticks were missed
you get 5 IRQ's in succession and the clock time is incremented stepwise
with them. I think it should never be used unless the OS simply counts
ticks to figure out the time (which they don't).

1 is default and means the same except virtual time is always up to date
when re-injecting missed ticks.

3 i'm not sure about but sounds like some variant of 4?

4 is where missed ticks delivered in one 'late tick'


Xen-devel mailing list