From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: system freeze when processor.ko is loaded during boot Date: Tue, 12 Apr 2011 14:59:46 +0100 Message-ID: References: <4D99A9F20200007800039CFB@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D99A9F20200007800039CFB@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Martin Wilck , Haitao Shan Cc: "Liu, Jinsong" , "xen-devel@lists.xensource.com" , Yunhong Jiang , Donald D Dugger , Xin Li , Gang Wei List-Id: xen-devel@lists.xenproject.org On 04/04/2011 10:22, "Jan Beulich" 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()). -- Keir