RE: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

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

> From: Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
> 
> On Mon, Apr 16, 2012 at 03:59:44PM +0100, David Vrabel wrote:
> > On 16/04/12 12:32, Jan Beulich wrote:
> > >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@citrix.com> wrote:
> > >> From: David Vrabel <david.vrabel@citrix.com>
> > >>
> > >> The sched clock was considered stable based on the capabilities of the
> > >> underlying hardware.  This does not make sense for Xen PV guests as:
> 
> In regards to PV dom0 is this still the case? Asking b/c your
> patch will make dom0 be in the same category.
> 
> > >> a) the hardware TSC is not used directly as the clock source; and b)
> > >> guests may migrate to hosts with different hardware capabilities.
> > >>
> > >> It is not clear to me whether the Xen clock source is supposed to be
> > >> stable and whether it should be stable across migration.  For a clock

Xen is -- and has always been -- responsible for emulating sufficient
clock hardware devices and presenting them to the guest AND ensuring
that this emulation works properly across migration/save/restore (which
is required because these transitions may be completely transparent
to the guest).

Prior to Xen 4.0, TSC was not considered to be a clocksource worthy
of emulating and was passed through to PV guests unchanged (and not
fully handled for HVM either IIRC).  At Xen 4.0+, it is handled properly.
 
> I thought it was dependent on XEN_DOMCTL_settscinfo:
>  - whether it gets emulated, or the guest can do rdtsc or pvrdtsc?
>
> Which I think is determined by some 'timer=X' option in the guest config?

I think you may be thinking of tsc_mode.  See docs/misc/tscmode.txt
in the Xen source.  The default should work correctly.