|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs u
On 14/04/2011 08:42, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>> On 14.04.11 at 09:25, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>> On 14/04/2011 08:18, "Jan Beulich" <JBeulich@xxxxxxxxxx> 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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|