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/
Home Products Support Community News


Re: [Xen-devel] write_tsc in a PV domain?

To: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] write_tsc in a PV domain?
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 27 Aug 2009 12:10:45 -0700
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 27 Aug 2009 12:11:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090827094817.0b398bbe@xxxxxxxxxxxxxxxxxxx>
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: <e519f01b-b609-42a2-8636-45eee4fad8a7@default> <4A95B789.6020604@xxxxxxxx> <20090827094817.0b398bbe@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 08/27/09 01:48, Alan Cox wrote:
>> as part of its ABI.  It is not a general tsc.  You can't meaningfully
>> execute "rdtsc" without also being (indirectly) aware of what pcpu its
>> running on and applying the appropriate corrections to turn it into
>> system monotonic time.  Executing rdtsc willy-nilly gets you useless
>> results; fortunately no PV Xen kernel does that.
> Actually for user space this isn't at all true. You can use rdtsc
> directly and sample the data for things like profiling then correct for
> things like spikes and skews from processor switches by filtering.

If an app is sophisticated to do this correctly then it doesn't need any
special assistance from a hypervisor to make the tsc well-behaved.  It
should continue to work even in a Xen guest where both the process can
skip between VCPUs and the VCPUs can skip between PCPUs.

>> No, write_tsc is meaningless, and anyone trying to execute it is not
>> even wrong.
> Writing to the tsc is perfectly reasonable providing the tsc is an
> advertised feature. Being able to use the tsc becomes much more relevant
> with newer processors which have sane tsc implementations in the
> architecture however.

Apparently on some large servers the tsc is only synced and sane within
a NUMA node, and not globally across all processors, so any app which
assumed sane tsc behaviour would break when the hardware gets scaled up.

But in this case I'm talking specifically about a Xen PV guest, where
the tsc is claimed for use by the Xen clocksource ABI.

> Unfortunately if you hide the tsc and hide the tsc flag in the cpu info
> lots of stuff doesn't run due to crap coding 8(

And you can't actually hide the TSC flag in cpuid without virtualization


Xen-devel mailing list