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

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.

Also mark tsc as reliable for X86_FEATURE_CONSTANT_TSC.

Without this fix, one of our platform hits the assertion which 
only has constant tsc feature.

Signed-off-by: Kevin Tian <kevin.tian@intel.com>

diff -r 0c446850d85e xen/arch/x86/cpu/intel.c
--- a/xen/arch/x86/cpu/intel.c	Wed May 11 12:58:04 2011 +0100
+++ b/xen/arch/x86/cpu/intel.c	Fri May 13 10:01:20 2011 +0800
@@ -221,8 +221,10 @@
 	if (c->x86 == 6) 
 		set_bit(X86_FEATURE_P3, c->x86_capability);
 	if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
-		(c->x86 == 0x6 && c->x86_model >= 0x0e))
+		(c->x86 == 0x6 && c->x86_model >= 0x0e)) {
 		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
+		set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability);
+	}
 	if (cpuid_edx(0x80000007) & (1u<<8)) {
 		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
 		set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability);
diff -r 0c446850d85e xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Wed May 11 12:58:04 2011 +0100
+++ b/xen/arch/x86/time.c	Fri May 13 10:01:20 2011 +0800
@@ -686,8 +686,6 @@
     if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
         return;
 
-    ASSERT(boot_cpu_has(X86_FEATURE_TSC_RELIABLE));
-
     write_tsc(stime2tsc(read_platform_stime()));
 }



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

On 13/05/2011 03:45, "Tian, Kevin" <kevin.tian@intel.com> 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)).
> 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.

 -- Keir
> Without this fix, one of our platform hits the assertion which
> only has constant tsc feature.
> 
> Signed-off-by: Kevin Tian <kevin.tian@intel.com>
> 
> diff -r 0c446850d85e xen/arch/x86/cpu/intel.c
> --- a/xen/arch/x86/cpu/intel.c Wed May 11 12:58:04 2011 +0100
> +++ b/xen/arch/x86/cpu/intel.c Fri May 13 10:01:20 2011 +0800
> @@ -221,8 +221,10 @@
> if (c->x86 == 6) 
> set_bit(X86_FEATURE_P3, c->x86_capability);
> if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
> -  (c->x86 == 0x6 && c->x86_model >= 0x0e))
> +  (c->x86 == 0x6 && c->x86_model >= 0x0e)) {
> set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> +  set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability);
> + }
> if (cpuid_edx(0x80000007) & (1u<<8)) {
> set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability);
> diff -r 0c446850d85e xen/arch/x86/time.c
> --- a/xen/arch/x86/time.c Wed May 11 12:58:04 2011 +0100
> +++ b/xen/arch/x86/time.c Fri May 13 10:01:20 2011 +0800
> @@ -686,8 +686,6 @@
>      if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
>          return;
>  
> -    ASSERT(boot_cpu_has(X86_FEATURE_TSC_RELIABLE));
> -
>      write_tsc(stime2tsc(read_platform_stime()));
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, May 13, 2011 1:55 PM
> 
> On 13/05/2011 03:45, "Tian, Kevin" <kevin.tian@intel.com>
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?

Thanks
Kevin

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

>>> On 13.05.11 at 07:55, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/05/2011 03:45, "Tian, Kevin" <kevin.tian@intel.com>
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)).
No, the assertion is correct imo (since tsc_check_writability() bails
immediately when boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).

But the problem Kevin reports is exactly what I expected when
we discussed the whole change. Nevertheless, simply removing the
assertion won''t be correct - instead your addition of the early
bail out on TSC_RELIABLE is what I''d now put under question (the
comment that goes with it, as we now see, isn''t correct).

Jan


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

> From: Jan Beulich [mailto:JBeulich@novell.com]
> Sent: Friday, May 13, 2011 3:14 PM
> 
> >>> On 13.05.11 at 07:55, Keir Fraser <keir.xen@gmail.com>
wrote:
> > On 13/05/2011 03:45, "Tian, Kevin"
<kevin.tian@intel.com> 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)).
> 
> No, the assertion is correct imo (since tsc_check_writability() bails
immediately
> when boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
here we may need a definition about what a reliable TSC means here. no tsc skew
among cpus, or stably incremented on the bus clock? It looks that we have some
assumption behind various TSC flags, and use them with implicit assumptions.
Here I can see that tsc_check_writability may disable deep cstate when
it''s not
writable, but it doesn''t mean that the assertion on
X86_FEATURE_TSC_RELIABLE
is correct since even when this flag is cleared the tsc could still be writable.
That
way the assertion absolutely is wrong.
> 
> But the problem Kevin reports is exactly what I expected when we discussed
> the whole change. Nevertheless, simply removing the assertion
won''t be
> correct - instead your addition of the early bail out on TSC_RELIABLE is
what I''d
> now put under question (the comment that goes with it, as we now see,
isn''t
> correct).
> 
I still don''t understand why deep cstate must be disabled when TSC is
not reliable.
Also the early bail out doesn''t impact my error, since in my case
TSC_RELIABLE is
not set but it''s simply writable.

Thanks
Kevin

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

>>> On 13.05.11 at 09:28, "Tian, Kevin"
<kevin.tian@intel.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@novell.com] 
>> Sent: Friday, May 13, 2011 3:14 PM
>> 
>> >>> On 13.05.11 at 07:55, Keir Fraser
<keir.xen@gmail.com> wrote:
>> > On 13/05/2011 03:45, "Tian, Kevin"
<kevin.tian@intel.com> 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)).
>> 
>> No, the assertion is correct imo (since tsc_check_writability() bails 
> immediately
>> when boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
> 
> here we may need a definition about what a reliable TSC means here. no tsc 
> skew
> among cpus, or stably incremented on the bus clock? It looks that we have 
> some
> assumption behind various TSC flags, and use them with implicit
assumptions.
> Here I can see that tsc_check_writability may disable deep cstate when
it''s
> not
> writable, but it doesn''t mean that the assertion on
X86_FEATURE_TSC_RELIABLE
> is correct since even when this flag is cleared the tsc could still be 
> writable. That
> way the assertion absolutely is wrong.
> 
>> 
>> But the problem Kevin reports is exactly what I expected when we
discussed
>> the whole change. Nevertheless, simply removing the assertion
won''t be
>> correct - instead your addition of the early bail out on TSC_RELIABLE
is what
> I''d
>> now put under question (the comment that goes with it, as we now see,
isn''t
>> correct).
>> 
> 
> I still don''t understand why deep cstate must be disabled when TSC
is not
> reliable.
> Also the early bail out doesn''t impact my error, since in my case 
> TSC_RELIABLE is
> not set but it''s simply writable.
My point is that for the assertion to be removed, the early bail in
tsc_check_writability() must be removed too.

Jan


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

On 13/05/2011 08:14, "Jan Beulich" <JBeulich@novell.com> wrote:
>> Looks like I just got the assertion the wrong way round, should be
>> ASSERT(!boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
> 
> No, the assertion is correct imo (since tsc_check_writability() bails
> immediately when boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
The current idea of TSC_RELIABLE is it means the platform ensures that all
TSCs are in lock step, at constant rate, never stopping even in C3. Hence we
don''t need to modify TSCs, hence we don''t need to check TSC
writability. And
also, hence we shouldn''t get to the write_tsc() in cstate_restore_tsc()
(since TSC_RELIABLE should imply NONSTOP_TSC, and hence we should bail early
from cstate_restore_tsc()).
> But the problem Kevin reports is exactly what I expected when
> we discussed the whole change.
Well I don''t understand that.

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.

As it is, I''m still of the opinion that the smallest correct fix would
be to
invert the assertion predicate.

 -- Keir
> Nevertheless, simply removing the
> assertion won''t be correct - instead your addition of the early
> bail out on TSC_RELIABLE is what I''d now put under question (the
> comment that goes with it, as we now see, isn''t correct).


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

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, May 13, 2011 4:29 PM
> 
> On 13/05/2011 08:14, "Jan Beulich" <JBeulich@novell.com>
wrote:
> 
> >> Looks like I just got the assertion the wrong way round, should be
> >> ASSERT(!boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
> >
> > No, the assertion is correct imo (since tsc_check_writability() bails
> > immediately when boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
> 
> The current idea of TSC_RELIABLE is it means the platform ensures that all
> TSCs are in lock step, at constant rate, never stopping even in C3. Hence
we
How about a system without NONSTOP_TSC, but with deep cstate disabled? This
case we could still deem it as reliable.
> don''t need to modify TSCs, hence we don''t need to check
TSC writability. And
> also, hence we shouldn''t get to the write_tsc() in
cstate_restore_tsc() (since
> TSC_RELIABLE should imply NONSTOP_TSC, and hence we should bail early
> from cstate_restore_tsc()).
Such implication simply causes confusions. If it''s really the point
that TSC_RELIABLE
implicates no any write to tsc, then we should make it consistently checked
every
where. Say in cstate_restore_tsc, we can just check TSC_RELIABLE to avoid the
assertion.
> 
> > But the problem Kevin reports is exactly what I expected when we
> > discussed the whole change.
> 
> Well I don''t understand that.
> 
> 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.
> 
> As it is, I''m still of the opinion that the smallest correct fix
would be to invert
> the assertion predicate.
> 
For now, I suggest to remove the assertion before the whole logic is cleaned up.
it''s not wise to break a working system by adding assertion on a
to-be-discussed
assumption. :-)

Thanks
Kevin

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

On 13/05/2011 09:49, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Sent: Friday, May 13, 2011 4:29 PM
>> 
>> On 13/05/2011 08:14, "Jan Beulich"
<JBeulich@novell.com> wrote:
>> 
>>>> Looks like I just got the assertion the wrong way round, should
be
>>>> ASSERT(!boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
>>> 
>>> No, the assertion is correct imo (since tsc_check_writability()
bails
>>> immediately when boot_cpu_has(X86_FEATURE_TSC_RELIABLE)).
>> 
>> The current idea of TSC_RELIABLE is it means the platform ensures that
all
>> TSCs are in lock step, at constant rate, never stopping even in C3.
Hence we
> 
> How about a system without NONSTOP_TSC, but with deep cstate disabled? This
> case we could still deem it as reliable.
Yes, I see TSC_RELIABLE as == NONSTOP_TSC && CONSTANT_TSC. If we have
deep
sleep disabled than we have simply TSC_RELIABLE == CONSTANT_TSC.
>> don''t need to modify TSCs, hence we don''t need to
check TSC writability. And
>> also, hence we shouldn''t get to the write_tsc() in
cstate_restore_tsc()
>> (since
>> TSC_RELIABLE should imply NONSTOP_TSC, and hence we should bail early
>> from cstate_restore_tsc()).
> 
> Such implication simply causes confusions. If it''s really the
point that
> TSC_RELIABLE
> implicates no any write to tsc, then we should make it consistently checked
> every
> where.
Yes I think actually we can simply put ASSERT(!TSC_RELIABLE) inside
write_tsc().
> Say in cstate_restore_tsc, we can just check TSC_RELIABLE to avoid the
> assertion.
> 
>> 
>>> But the problem Kevin reports is exactly what I expected when we
>>> discussed the whole change.
>> 
>> Well I don''t understand that.
>> 
>> 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.
> 
>> 
>> As it is, I''m still of the opinion that the smallest correct
fix would be to
>> invert
>> the assertion predicate.
>> 
> 
> For now, I suggest to remove the assertion before the whole logic is
cleaned
> up.
> it''s not wise to break a working system by adding assertion on a
> to-be-discussed 
> assumption. :-)
I''ll move the fixed assertion into write_tsc() in xen-unstable, and
remove
entirely from the stable branches.

 -- Keir
> Thanks
> Kevin


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

>>> On 13.05.11 at 11:15, Keir Fraser <keir.xen@gmail.com> wrote:
> I''ll move the fixed assertion into write_tsc() in xen-unstable,
and remove
> entirely from the stable branches.
Could you make this a one-time warning instead at least in the stable
trees, so if there are problems there would at least be a trace in the
log?

Jan


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

> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> Subject: RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on
> X86_FEATURE_TSC_RELIABLE
> 
> > From: Keir Fraser [mailto:keir.xen@gmail.com]
> >
> > 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@lists.xensource.com
http://lists.xensource.com/xen-devel

> From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> Sent: Saturday, May 14, 2011 1:17 AM
> 
> > From: Tian, Kevin [mailto:kevin.tian@intel.com]
> > Subject: RE: [Xen-devel] [PATCH] x86, cpuidle: remove assertion on
> > X86_FEATURE_TSC_RELIABLE
> >
> > > From: Keir Fraser [mailto:keir.xen@gmail.com]
> > >
> > > 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@lists.xensource.com
http://lists.xensource.com/xen-devel

> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, May 13, 2011 5:15 PM
> >>
> >> As it is, I''m still of the opinion that the smallest
correct fix
> >> would be to invert the assertion predicate.
> >>
> >
> > For now, I suggest to remove the assertion before the whole logic is
> > cleaned up.
> > it''s not wise to break a working system by adding assertion
on a
> > to-be-discussed assumption. :-)
> 
> I''ll move the fixed assertion into write_tsc() in xen-unstable,
and remove
> entirely from the stable branches.
> 
Thanks for helping that.
Kevin

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

On 17/05/2011 01:50, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>> 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. :-)
Yes, Dan is right, RELIABLE_TSC means something more than just NONSTOP_TSC
and CONSTANT_TSC. It means that:
 1. TSCs do not stop in deep sleep (NONSTOP_TSC)
 2. TSCs do not change rate with core frequency (CONSTANT_TSC)
 3. Further, that all TSCs system wide run at the same rate at all times, in
perfect sync (not represented by any other cpu feature flag).

 -- Keir



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