Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boot

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 03.04.11 at 15:46, Martin Wilck <mwilck@xxxxxxxx> wrote:
> processor     : 0
> vendor_id     : GenuineIntel
> cpu family    : 6
> model         : 13

Quoting SDM Vol 3a Section 16.11: "When WRMSR is used to write
the time-stamp counter on processors before family [0FH], models
[03H, 04H]: only the low-order 32-bits of the time-stamp counter
can be written (the high-order 32 bits are cleared to 0). For family
[0FH], models [03H, 04H, 06H]; for family [06H]], model [0EH,
0FH]; for family [06H]], DisplayModel [17H, 1AH, 1CH, 1DH]: all
64 bits are writable."

Quite obviously nothing good can result if we write the TSC on
a CPU that zeroes the upper 32 bits. Hopefully, none of the
affected CPUs has X86_FEATURE_CONSTANT_TSC, since
otherwise time_calibration_tsc_rendezvous() could get used,
which also uses write_tsc().

Haitao, while it is quite clear that with the current
implementation we just can't use C states above C1 on CPUs
that may halt the TSC in C2 or C3 *and* that don't allow
writing the full TSC, this family/model based determination
clearly isn't nice (and since it is a white list, it can't possibly be
complete). An alternative would seem to be to probe for how
TSC writes behave (thus at once covering eventual other
vendors' CPUs that may have similar shortcomings). That of
course would need to be done early, so that resetting the
upper bits to zero wouldn't have any adverse effect. What
do you think?

Jan


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