As I look at this more, I'm convincing myself that
it may not make sense to build the guest TSC on top
of Xen system time and only the guest virtual platform
timer(s) should be built on Xen system time (and should
be monotonically non-decreasing).
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.
Unfortunately, hvm_get/set_system_time() are #defined to
be hvm_get/set_system_tsc() so the usage is pretty muddled.
I think the attached patch has teased the two apart though.
Note this is still RFC, not a finished patch.
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Dan
> Magenheimer
> Sent: Friday, May 16, 2008 11:31 AM
> To: Xen-Devel (E-mail)
> Subject: [Xen-devel] [PATCH] [RFC] Building guests on monotonic Xen
> system time
>
>
> Currently, hvm guest platform timers are built on top of the tsc.
> Even though the guest believes it is utilizing a monotonic timesource
> (such as pit, hpet, or pmtimer), all of these plumb down to an
> rdtsc instruction.
>
> Since on many SMP platforms tsc's in different processors are not
> synchronized, VMs re-scheduled from a "fast tsc" processor to
> a "slow tsc" processor may experience "time going backwards".
> This is discussed in the following thread:
>
> http://lists.xensource.com/archives/html/xen-devel/2008-04/msg
00277.html
The fix proposed by Keir is that "The logic in vpt.c should
be fixed to use Xen's concept of system time and everything,
guest TSC included, should be derived from that."
The attached patch is a first attempt to derive all
guest timers from Xen's system time... and also to ensure
that system time is non-decreasing. I don't believe the
patch is complete... and possibly not even correct.
For example, I'm concerned that Xen's system time uses
different units than a guest tsc and I don't recall if
all guest tsc accesses are trapped.
Dan
===================================
Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)
hvmstime2.patch
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home