From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: write_tsc in a PV domain?
Date: Wed, 26 Aug 2009 12:45:27 -0700
Message-ID: <4A9590D7.5080501@goop.org>
References: <6eb624ce-7d03-425b-afa4-2d97325b096c@default>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <6eb624ce-7d03-425b-afa4-2d97325b096c@default>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: "Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>, Keir Fraser <keir.fraser@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 08/26/09 08:42, Dan Magenheimer wrote:
> But ARCHITECTURALLY does Xen consider write_tsc to be a no-op
> for PV domains, or is this just a case that's never been
> encountered before?  In other words, if a future PV OS had a
> good reason to write_tsc, would we implement it (and make
> the necessary adjustments to Xen's usages of tsc) or just say,
> sorry, not allowed?
>   

You can think of it this way:  a Xen PV VCPU has no tsc.  There is a
register that can be read with "rdtsc", but that're purely part of Xen's
time ABI and is not independently useful.  The ABI includes no notion of
writing to that register.  Usermode code can execute "rdtsc", but
without access to the rest of the time parameters it just returns some
undefined bits with no relationship to time.

    J