From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: TSC virtualization across different host frequency platform migration Date: Wed, 22 Apr 2009 09:13:48 +0100 Message-ID: References: <9832F13BD22FB94A829F798DA4A8280501A7D29D36@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9832F13BD22FB94A829F798DA4A8280501A7D29D36@pdsmsx503.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: "Dong, Eddie" , "xen-devel@lists.xensource.com" Cc: "Tian, Kevin" , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org On 22/04/2009 02:32, "Dong, Eddie" wrote: > 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. The details are in attached document. Can you have a look and provide > comments? The important questions are: What guests get confused by an out-of-sync TSC? And is coarse-grained re-sync (multi-second quantum?) good enough? As a re-sync strategy well, yes, obviously it works but with some drawbacks. It would be very nice if VT could be extended to scale the host TSC as well as offset it. I would think that would be quite easy to do. -- Keir > Thanks. BTW of course PV time is another solution which is not covered in this > proposal.