[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-ia64-devel] SMP-guest status



Le Jeudi 20 Avril 2006 17:11, Alex Williamson a écrit :
> On Thu, 2006-04-20 at 15:22 +0200, Tristan Gingold wrote:
> > Le Jeudi 20 Avril 2006 05:47, Alex Williamson a écrit :
> > >    Is the jitter protection in the time interpolator sufficient for
> > > ignoring this?  Drift is really meant to indicate the ITCs are driven
> > > from different time sources so may run at slightly different clock
> > > frequencies.  Seems we should only need to provide that flag to the
> > > guest if the platform firmware set it.  As long as the ITCs are nearly
> > > synchronized, the jitter protection in the ITC interpolator will
> > > prevent time from going backwards.  This would then get rid of the
> > > change in time.c.  Thanks,
> >
> > The change in time.c is just to work around a kernel bug.  Linux kernel
> > requires at least an interpolator. [Hence I think there is no platform
> > without ITC drift].
>
>    I'm not sure I'd call it a bug. 
Here are the facts:  if you boot linux 2.6.16 with ITC_DRIFT bit set, kernel 
crashes.  That's a bug to me.

> The kernel requires some kind of
> timesource for an interpolator.  AFAIK, SGI systems are the only ones
> that report ITC drift and they have a platform timesource to compensate.
                 ^^^ no ITC drift
Thank you for the info.

> HPET support is another, more generic, way to do this.
Sure.

>  If this is a
> temporary workaround, I think it would be more clear to use
> running_on_xen as a flag to indicate ITCs are pre-synchronized and not
> report platform ITC drift via the features table. 
Ok for this approach.
I will revisite the issue.

Tristan.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.