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: Wed, 06 Apr 2011 10:58:59 +0100 Message-ID: <4D9C5583020000780003A268@vpn.id2.novell.com> References: <4CAF794F.6070308@arcor.de> <4CBEAEE2020000780001E237@vpn.id2.novell.com> <4D910C24.5090908@arcor.de> <4D987A22.5050303@arcor.de> <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: <4D99A9F20200007800039CFB@vpn.id2.novell.com> 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 04.04.11 at 11: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? 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