RE: A clocksource question

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Ian Pratt [mailto:Ian.Pratt@eu.citrix.com]
> Sent: Wednesday, March 10, 2010 5:22 PM
> To: Dan Magenheimer; Joanna Rutkowska; Jeremy Fitzhardinge
> Cc: Ian Pratt; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] A clocksource question
> 
> > The TSC delta is troubling... if you hadn't said you had turned
> > off all power management, I would have guessed a problem with
> > C-state management.  Maybe Xen is discovering some power management
> > capability not visible in BIOS settings?
> 
> Xen uses the architectural C state mechanism, bypassing ACPI.
> Use "max_cstate=0"

Yes!  The Core 2 Duo fooled me.  There are some versions
of Core 2 Duo ("Conroe") that don't support C3-state and
some ("Merom") that do support C3-state.  And the code
to "recover" from C3, which I think was added before 3.4
was released, has been observed to be very poor in its
attempt to reset TSC after C3 to a reasonable value. I
didn't think it was THAT poor though!  See:
http://lists.xensource.com/archives/html/xen-devel/2009-10/msg01414.html 

(AFAIK, this is not fixed in 4.0, though the new default
rdtsc emulation may mask the problem by ensuring TSC always
moves forward, even across different processors.)

So that may explain the TSC delta.  Since the pv clocksource
algorithm is dependent in part on the hardware TSC being
synced reasonably well by Xen, that may also explain
other clock strangeness.

P.S. Joanna -- max_cstate=0 must be specified on the
Xen boot line in grub.conf, not in the vm.cfg or grub.conf
of the guest.