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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

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 
'reliable': 
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. :-)

Thanks
Kevin

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