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

RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on X86_FEATURE_TSC_RELIABLE

  • To: Keir Fraser <keir.xen@xxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 13 May 2011 14:01:56 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Thu, 12 May 2011 23:03:48 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwRF8pkn8Z5NAyTR6K8DjXjhAYyqQAGpCgBAAAgcHA=
  • Thread-topic: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on X86_FEATURE_TSC_RELIABLE

> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Friday, May 13, 2011 1:55 PM
> On 13/05/2011 03:45, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> > x86, cpuidle: remove assertion on X86_FEATURE_TSC_RELIABLE
> >
> > 23228:1329d99b4f16 disables deep cstate to avoid restoring tsc when
> > tsc msr is not writtable on some old platform, which however also adds
> > an assertion on X86_FEATURE_TSC_RELIABLE in cstate_restore_tsc.
> > The two don't match as tsc writtable-ness has nothing to do with
> > whether it's reliable. As long as Xen can use tsc as the time source
> > and it's writable, it should be OK to continue using deep cstate with
> > tsc save/restore.
> Looks like I just got the assertion the wrong way round, should be
> ASSERT(!boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).

why? so only an unreliable tsc which is not nonstop can enter this path?

> > Also mark tsc as reliable for X86_FEATURE_CONSTANT_TSC.
> Unrelated change? Also, TSC_RELIABLE should only be asserted on
> NONSTOP_TSC platforms. I suspect this change is not correct.

not very related, but I think it does make sense? what's the implication
of reliable TSC in your mind?


Xen-devel mailing list



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