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: 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