WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot optio

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 05 Oct 2009 21:56:44 -0700
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 05 Oct 2009 21:57:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <26e6e0ca-9929-46c9-887c-5dd1cb4f68c8@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <26e6e0ca-9929-46c9-887c-5dd1cb4f68c8@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel