From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part) Date: Mon, 05 Oct 2009 21:56:44 -0700 Message-ID: <4ACACE0C.5030706@goop.org> References: <26e6e0ca-9929-46c9-887c-5dd1cb4f68c8@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <26e6e0ca-9929-46c9-887c-5dd1cb4f68c8@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: "Xen-Devel (E-mail)" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 10/05/09 18:43, Dan Magenheimer wrote: > Perhaps a better choice would be for emulated tsc > to return Xen system time in both kernel and user > mode (which is what it does for HVM domains) and, > when a domain has tsc_native==0, > Xen sets its pvclock parameters so that no scaling > occurs? This results in the guest reporting that > it has a 1GHz clock, but may be more consistent. > Yes, as I said: > But aside from that, all I'm asking for is a way for a domain to > explicitly request that its tsc not be synthesized (or failing that, > something that looks exactly like an unsynthesized tsc), so that > usermode pvclock can work without needing edits to the config file. > Having a consistent tsc between usermode and kernel will solve the significant functional breakage that currently exists with tsc synthesis enabled, making it just a question of performance (and resolution). I still think tsc_native=1 is the correct setting for the vast majority of PV guest domains, and enabling it by default is a bad idea. J