RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

(RADclock authors cc'ed in attempt to re-merge the two threads...
Tim, if it's not too late, please reply to this email rather
than the previous one without the full cc list)

> From: Dan Magenheimer
> Sent: Friday, October 15, 2010 8:47 AM
> To: Tim Deegan
> Cc: Jeremy Fitzhardinge; Jan Beulich; Hang Du; Keir Fraser; Saipu Liu;
> Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when
> sync up time from dom0 to domU
> 
> > > Also, for those certain enterprise applications that want
> > > to sample time 10000+ samples/second/processor, and need
> > > to know "immediately" when a sample might be bad (due
> > > to, for example, live migration), I think each sample would
> > > need to check xenstore.  Is xenstore up to that kind of
> > > pounding (and is it fast enough)?
> >
> > No it's certainly not (either of those things), but:
> >  - the problem of turning a distributed wallclock into something
> > suitable
> >    for timestamping that aggressively is orthogonal to the problem of
> >    distributing that wallclock in the first place; and
> 
> Agreed that this is a better solution to a very important problem.
> I'm just trying to determine if it helps solve another time-related
> real world problem.
> 
> >  - all the user really needs is a generation counter to know that the
> >    clock correction values are stale, and the kernel can provide that
> >    alongside the stime.
> 
> Agreed that a generation counter solves this.  BUT...
> 
> (1) afaik there is no generation counter in any time-related
> kernel API; and
> 
> (2) afaict this generation counter would need to be "pushed"
> from the dom0 kernel so would either (a) require domU kernels
> to read from xenstore, or (b) require some kind of privileged
> hypercall from dom0 to the hypervisor telling the hypervisor
> to change the generation counter (and scaling values?) for all
> domUs.

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