WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Subject: RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on
> X86_FEATURE_TSC_RELIABLE
> 
> > 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?)

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.

> 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?

Thanks,
Dan


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