RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> 
> On 06/10/2009 14:49, "Dan Magenheimer" 
> <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > This was intended to record the offset across migration.
> > But a per-domain stime offset must already be recorded
> > somewhere else, or hvm fully-emulated platform timers
> > would be broken across migration.
> > 
> > Do pv guests need something similar or is it magically
> > handled someplace that I couldn't quickly find?
> 
> PV guests understand that there will be a system-time 
> discontinuity across
> save/restore. All I did was remove an unused field. You can 
> reintro it when
> you use it.

Interestingly, I find that there is a discontinuity for
HVM guests as well (with either tsc_native=0 or
tsc_native=1).  This can be demonstrated easily by
running a rdtsc loop in a user program that fails
if time goes backwards or jumps forward too far,
then doing a save/restore.

I had assumed that the VT-x tsc_offset mechanism would
handle the discontinuity but apparently it was never
implemented.  (I didn't test live migration, so maybe
the mechanism IS used if time goes backwards, but
I suspect not.)

Since TSC is used for inter-jiffie interpolation on
many Linux systems (and the system I ran the test
on reports "Using 3.5xxx MHz WALL PM GTOD PIT/TSC timer"),
I'm surprised a huge discontinuity doesn't cause at
least some interesting problem for some HVM OS's.

Oops, it does.  I see a soft lockup reported when I
save/restore an HVM domain (tested with tsc_native=1,
e.g. no tsc emulation).

Looks like another one for the "fix the tsc" list...

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel