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)
>
hvmstime5.patch
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home