| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot optio
> 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
|
|
|
| |
|
Home