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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded
From: "Wang, Winston L" <winston.l.wang@xxxxxxxxx>
Date: Mon, 11 Apr 2011 15:35:13 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <keir@xxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, Keir
Delivery-date: Mon, 11 Apr 2011 15:36:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <d6cfc1ce-e4b3-47dc-ae83-8d0c341988b3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <d6cfc1ce-e4b3-47dc-ae83-8d0c341988b3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acv0QiSpeFblUzkuQKubjOfuuFt+cQEVKxIQ
Thread-topic: [Xen-devel] Re: system freeze when processor.ko is loaded
Hi Jan,

> Date: Wed, 06 Apr 2011 10:58:59 +0100
> From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
> Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded
>       during boot
> To: "Keir Fraser" <keir@xxxxxxx>
> 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>
> Message-ID: <4D9C5583020000780003A268@xxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=US-ASCII
> >>> 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
> Jan
Thanks for the great effort for root cause the issue!
I think restore only the lower 32bit TSC is good enough, why do we need to 
touch upper 32 bit TSC?
1. I would not think if any processor's deep c-state wakeup from idle can more 
than 100 ms.
2. For 3GHZ processor lower 32bit TSC wrapper around time is ~2.83 Sec.
3. The platform timer (22bit ACPI timer) wrapper around is 2.34 sec (this is 
used for counting the delta before enter deep_cstate and before wakeup)
Just need to change cstate_restore_tsc() and only patch back the delta time to 
the lower 32 bit TSC to make that simple?


Xen-devel mailing list