RE: [Xen-devel] [PATCH] [RFC] Building guests on monotonic Xen system time

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

OK, I think this version is ready for prime-time.

Keir, please check-in to unstable.

[PATCH] Build hvm guest platform timers on monotonic Xen system time

This patch moves hvm platform timers from underlying physical CPU TSC
to Xen system time and ensures monotonicity.  TSC on many systems may
skew between processors, thus hvm platform timer reads were not
monotonic which led to "Time going backwards" problems.

Signed-off-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Tuesday, May 20, 2008 1:37 AM
> To: dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
> Subject: Re: [Xen-devel] [PATCH] [RFC] Building guests on 
> monotonic Xen
> system time
> 
> 
> On 19/5/08 19:27, "Dan Magenheimer" 
> <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > Why? Scaling and adjusting of xen-time-based-tsc will
> > be very difficult to coordinate with processor-based-tsc.
> > We need to always ensure that A < B < C for a guest
> > executing:
> >
> > rdtsc(A) /* untrapped */
> > emulated_rdtsc(B)
> > rdtsc(C) /* untrapped */
> >
> > Further, OS's use TSC as a highest-resolution time source
> > with knowledge that TSCs on different processors may
> > not be synchronized, whereas they assume that a platform
> > timer is one-per-system and monotonically increasing.
> >
> > Keir, if you disagree and see guest-TSC-on-Xen-system-time
> > as an absolute must, please let me know.
> 
> I am inclined to say we should have a 
> guest-TSC-on-system-time mode where
> *all* RDTSC executions get trapped. This would at least be useful as a
> baseline for tracking down guest time problems, and also provide a
> guaranteed stable TSC timesource for those who care about 
> that more than
> pure performance.
> 
> *However* I would agree that, with TSC virtualisation as it 
> currently is,
> there actually isn't really a way to build guest TSC on Xen 
> system time
> without periodically warping the TSC back or forth. The guest 
> TSC runs at
> the host TSC rate and that is that!
> 
> I think my original point was that at least we should not 
> build all our
> other virtual time sources on this dodgy 'guest TSC'. :-)
> 
>  -- Keir
> 
> 
>

hvmstime7.patch
Description: Binary data

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