From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dong, Eddie" Subject: RE: TSC virtualization across different host frequency platform migration Date: Wed, 22 Apr 2009 16:49:43 +0800 Message-ID: <9832F13BD22FB94A829F798DA4A8280501A7FC0827@pdsmsx503.ccr.corp.intel.com> References: <9832F13BD22FB94A829F798DA4A8280501A7D29D36@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US 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 , "xen-devel@lists.xensource.com" Cc: "Tian, Kevin" , "Dong, Eddie" , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 22/04/2009 02:32, "Dong, Eddie" wrote: >=20 >> Keir and all: >> Recently we are considering the potential issue of TSC >> virtualization across different frequency platform migration. >> Current approach will lead to synchronization issue between guest >> TSC and wall clock. Software trap and emulate can solve the problem >> with the payment of performance overhead which is not optimal. We >> want to propose smart scaling algorithm which can continuously use >> HW TSC_OFFSET and maintain long time synchronization of guest TSC.=20 >> The details are in attached document. Can you have a look and >> provide comments?=20 >=20 > The important questions are: What guests get confused by an > out-of-sync TSC? And is coarse-grained re-sync (multi-second That is what I am interested too. Is there any report from real deployment which utilize migration frequently?=20 thx, eddie