This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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


Xen-devel mailing list