This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir.xen@xxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on X86_FEATURE_TSC_RELIABLE
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 13 May 2011 14:01:56 +0800
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Thu, 12 May 2011 23:03:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9F2865E.1A39D%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <625BA99ED14B2D499DC4E29D8138F1505C8F0A4971@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C9F2865E.1A39D%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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