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