From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC] Physical hot-add cpus and TSC Date: Fri, 28 May 2010 06:47:32 +0100 Message-ID: References: <789F9655DD1B8F43B48D77C5D30659731E78D89D@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: <789F9655DD1B8F43B48D77C5D30659731E78D89D@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 28/05/2010 06:39, "Jiang, Yunhong" wrote: >> Hmmm... I'd be very surprised if this works ever, let alone >> always across all hardware. By "work", I mean that it will >> result in an "undetectably small difference" (less than a >> cache bounce), as defined and measured by the tsc warp test. >> Why? Because rdtsc is a long instruction (30-100 cycles) >> and I'll bet writing to the TSC is even longer. Plus, >> there's a cache bounce overhead added in due to the >> synchronization via the in-memory tsc_count variable. > > I think that depends how we define " undetectably". If the time that guest > migration among physical CPU is much higher than this difference, do we really > need care about it (of course SMI/NMI is another story)? > Or I missed anything? "Undetectable" by Dan's definition means undetectable by a multi-threaded app on a multi-vcpu guest. Any detected warp would therefore be a problem. It is impossible to meet that level of TSC consistency when doing CPU physical-add, without emulating all guest TSCs. We may need to add that as an option, at least, to keep a small class of apps that care (like Oracle's DB, we assume) happy. -- Keir