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: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on X86_FEATURE_TSC_RELIABLE
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 17 May 2011 08:50:20 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 16 May 2011 17:51:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <fde818ae-f251-4480-babf-7cbbb0887bc7@default>
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: <4DCCF65802000078000412A4@xxxxxxxxxxxxxxxxxx> <C9F2AA77.1A3B2%keir.xen@xxxxxxxxx 625BA99ED14B2D499DC4E29D8138F1505C8F0A4C34@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <fde818ae-f251-4480-babf-7cbbb0887bc7@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwRkZivueGLm2sbT3yA1MbSrwDN0QCmdk4A
Thread-topic: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on X86_FEATURE_TSC_RELIABLE
> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> Sent: Saturday, May 14, 2011 1:17 AM
> > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> > Subject: RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on
> >
> > > From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> > >
> > > Nevertheless, I feel I'm playing devil's advocate here and batting
> > > on
> > DanM's
> > > side for something I don't consider a major issue. If someone wants
> > to clean
> > > this up and come up with (possibly different and new) documented and
> > > consistently applied semantics for these TSC feature flags, please
> > > go
> > ahead and
> > > propose it. And we'll see who comes out to care and bat against it.
> >
> > I'll take a further look to understand it and then may send out a
> > cleanup patch later.
> Hi Kevin --
> Welcome back to xen-devel (after a two-year hiatus?)

yes, it's been a long time. :-)

> I'm not keeping up with xen-devel as frequently as I was in the past, so 
> please
> cc me directly if you propose different semantics.

no problem. I knew you guys had multiple rounds of related discussions, and 
I'll digest
them first.

> > How about a system without NONSTOP_TSC, but with deep cstate disabled?
> > This case we could still deem it as reliable.
> IIRC, this is not true on a multi-socket motherboard.  Even though each socket
> has NONSTOP_TSC, they are using different crystals, correct?

it's true that sockets may use different crystals, and NONSTOP_TSC has nothing 
to say
synchronization among sockets/cores. So it really depends on how you define a 
is it reliable enough to be a Xen time source, or reliable enough to 
passthrough to the 
guest? I'll need to check current assumption and your previous discussions 
first before 
saying anything inappropriate. :-)


Xen-devel mailing list