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

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

Next version of guest-virtual-platform-time-on-xen-system-time
attached.  This version seems to work but could use more
testing.

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Dan
> Magenheimer
> Sent: Monday, May 19, 2008 12:27 PM
> To: Xen-Devel (E-mail)
> Subject: RE: [Xen-devel] [PATCH] [RFC] Building guests on 
> monotonic Xen
> system time
> 
> 
> 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)
>

Attachment: hvmstime5.patch
Description: Binary data

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