Re: [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits

[Keir Fraser <keir.xen@gmail.com>]

On 14/04/2011 08:42, "Jan Beulich" <JBeulich@novell.com> wrote:

>>>> On 14.04.11 at 09:25, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 14/04/2011 08:18, "Jan Beulich" <JBeulich@novell.com> wrote:
>> 
>>> This means suppressing the uses in time_calibration_tsc_rendezvous(),
>>> cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot
>>> hang of Linux Dom0 when loading processor.ko on such systems that
>>> have support for C states above C1.
>> 
>> Should your new test be gated on !X86_FEATURE_TSC_RELIABLE? We already
> 
> Which test? The write-TSC-probe itself?
> 
>> *never* write the TSC when boot_cpu_has(TSC_RELIABLE) -- Dan Magenheimer
>> made that change on the assumption that TSCs were globally synced by
>> firmware in this case, and us writing one or more TSCs could only ever make
>> things worse.
> 
> That's not true - we only avoid the writing for TSC sync during boot.
> Post-boot bringup of CPUs will write the TSC no matter what, and

For physically-added CPUs only. Kind of unavoidable, that one: we can only
try to do our best in that case. And let's face it, that probably affects
exactly zero production users of Xen/x86 right now.

> cstate_restore_tsc() also has no such gating afaics.

It is gated on NONSTOP_TSC which is implied by TSC_RELIABLE.

 -- Keir

> Jan
>