| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boo
|
To: |
"Keir Fraser" <keir@xxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boot |
|
From: |
"Jan Beulich" <JBeulich@xxxxxxxxxx> |
|
Date: |
Tue, 12 Apr 2011 15:12:54 +0100 |
|
Cc: |
Jinsong Liu <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, Donald D Dugger <donald.d.dugger@xxxxxxxxx>, Xin Li <xin.li@xxxxxxxxx>, Haitao Shan <maillists.shan@xxxxxxxxx>, Gang Wei <gang.wei@xxxxxxxxx>, Martin Wilck <mwilck@xxxxxxxx> |
|
Delivery-date: |
Tue, 12 Apr 2011 07:12:41 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C9CA1962.2C95F%keir@xxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<4D99A9F20200007800039CFB@xxxxxxxxxxxxxxxxxx> <C9CA1962.2C95F%keir@xxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
>>> On 12.04.11 at 15:59, Keir Fraser <keir@xxxxxxx> wrote:
> On 04/04/2011 10:22, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>> 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?
>
> We should do early run-time test of this from the BSP then, on failure,
> avoid all further potential uses of write_tsc() in an appropriate way (e.g.,
> bail early in cstate_restore_tsc(), synchronize_tsc_*(), and avoid use of
> time_calibration_tsc_rendezvous()).
Okay, that matches what I have so far (just need to implement
the mechanism to suppress synchronize_tsc_*() then).
Thanks, Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home