From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC] Physical hot-add cpus and TSC Date: Thu, 27 May 2010 07:57:45 +0100 Message-ID: References: <789F9655DD1B8F43B48D77C5D30659731E78D370@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <789F9655DD1B8F43B48D77C5D30659731E78D370@shsmsx501.ccr.corp.intel.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: "Jiang, Yunhong" , Dan Magenheimer , "Xen-Devel (xen-devel@lists.xensource.com)" , Ian Pratt List-Id: xen-devel@lists.xenproject.org On 27/05/2010 07:15, "Jiang, Yunhong" wrote: >>>> It depends how physical CPU hotplug is implemented doesn't it. I expect >>>> there's sufficient firmware involved in such an operation that TSCs >>>> could >>>> get synced up before host software gets a look in. I don't think we can >>>> comment on whether or not there is an issue here without more >>>> information. > > Yes, this is a issue. The TSC will not be synched by firmware when hot-added, > at least I didn't find any spec on this, and my experiment shows the TSC value > is very small when new CPU is brought up. We need sync it in Xen side, > > Is it possible to sync the new-added CPU with the BSP when the CPU is added > (changed from non-present to present), as Keir suggested in previous mail? I > will have a look on the related code. Is this *specifically* a problem for physical cpu hot-add, but not 'logical' cpu online (i.e, XENPF_cpu_hotadd but not XENPF_cpu_online)? We could sync an AP's TSC with the master CPU bringing it up (typically CPU0) if (a) !boot_cpu_has(RELIABLE_TSC); or (b) The slave was introduced via XENPF_cpu_hotadd and this is its first time brought online. Thoughts? I can implement this, or whatever we can (attempt to) agree on, easily enough. I expect Dan would prefer to have XENPF_cpu_hotadd disabled, or RELIABLE_TSC disabled, depending on a command-line option defaulting to the former. It seems a bit onerous to me however. -- Keir