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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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



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