| |
|
 |
|
 |
|
|
|
| |
|
|
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: |
Wed, 06 Apr 2011 10:58:59 +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: |
Wed, 06 Apr 2011 02:59:50 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4D99A9F20200007800039CFB@xxxxxxxxxxxxxxxxxx> |
|
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: |
<4CAF794F.6070308@xxxxxxxx> <4CBEAEE2020000780001E237@xxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E1E7146599A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D910C24.5090908@xxxxxxxx> <AANLkTimmXHe2W00++wCmQRTRmOd37MvsPqqQ0191wCc7@xxxxxxxxxxxxxx> <4D987A22.5050303@xxxxxxxx> <4D99A9F20200007800039CFB@xxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
>>> On 04.04.11 at 11: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?
The probing itself seems to work fine. I'm confused by something
else though: synchronize_tsc_{master,slave}() execute their
loops (at boot or during hotplug) on any CPU that doesn't have
X86_FEATURE_TSC_RELIABLE, including such where TSC writes
don't really work (luckily I still haven't thrown out one that is
affected by this). What is the point of doing this synchronization
if we can happily live with it actually not working (Xen runs fine
on that box afaict)? c/s 21468:26c2922da53c is also not very
verbose about why this got (re-)added... Should the body
perhaps really only be run for X86_FEATURE_CONSTANT_TSC but
!X86_FEATURE_NONSTOP_TSC CPUs?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home