Re: [Xen-devel] Re: system freeze when processor.ko is loaded

["Wang, Winston L" <winston.l.wang@xxxxxxxxx>]

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
> !X86_FEATURE_NONSTOP_TSC CPUs?
> 
> 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?

Winston,

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel