From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits Date: Thu, 14 Apr 2011 08:50:37 +0100 Message-ID: References: <4DA6C16F020000780003B899@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DA6C16F020000780003B899@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 Cc: Dan Magenheimer , "xen-devel@lists.xensource.com" , "winston.l.wang" List-Id: xen-devel@lists.xenproject.org On 14/04/2011 08:42, "Jan Beulich" wrote: >>>> On 14.04.11 at 09:25, Keir Fraser wrote: >> On 14/04/2011 08:18, "Jan Beulich" wrote: >> >>> This means suppressing the uses in time_calibration_tsc_rendezvous(), >>> cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot >>> hang of Linux Dom0 when loading processor.ko on such systems that >>> have support for C states above C1. >> >> Should your new test be gated on !X86_FEATURE_TSC_RELIABLE? We already > > Which test? The write-TSC-probe itself? > >> *never* write the TSC when boot_cpu_has(TSC_RELIABLE) -- Dan Magenheimer >> made that change on the assumption that TSCs were globally synced by >> firmware in this case, and us writing one or more TSCs could only ever make >> things worse. > > That's not true - we only avoid the writing for TSC sync during boot. > Post-boot bringup of CPUs will write the TSC no matter what, and For physically-added CPUs only. Kind of unavoidable, that one: we can only try to do our best in that case. And let's face it, that probably affects exactly zero production users of Xen/x86 right now. > cstate_restore_tsc() also has no such gating afaics. It is gated on NONSTOP_TSC which is implied by TSC_RELIABLE. -- Keir > Jan >