From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [RFC] Physical hot-add cpus and TSC Date: Fri, 28 May 2010 09:36:59 -0700 (PDT) Message-ID: <681ea80b-75c6-41cc-a13d-3c7e25721f99@default> References: <23411061-56ab-4d16-b8f1-5bba0f37c165@default C825A914.16417%keir.fraser@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: 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 , "Jiang, Yunhong" , "Xen-Devel (xen-devel@lists.xensource.com)" , Ian Pratt List-Id: xen-devel@lists.xenproject.org > Linux doesn't make strong > guarantees to applications about TSC semantics, by synthesising TSC, or > anything like that. Working on that ;-) IMHO, any non-privileged use of rdtsc, even under the control of the kernel (e.g. vsyscall) has potential issues in a virtual machine. Except a VMware VM, where the problem is completely solved. But, as you know, many Linux kernel developers aren't too interested in solving problems for Xen, so there's an uphill battle :-( > Anyhow, retreading this argument is not going to be fruitful > It's fair to > say that your definition is now also Xen's definition. Sorry, I'm not trying to beat a dead horse. I'm just playing whack-a-mole and repeating arguments for a new audience and a new corner case. If you prefer, I can take that offlist.