From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [PATCH 0 of 5] PV on HVM Xen
Date: Tue, 16 Mar 2010 11:26:14 -0700
Message-ID: <4B9FCD46.5090705@goop.org>
References: <alpine.DEB.2.00.1003101457100.28412@kaball-desktop>
	<alpine.DEB.2.00.1003121024590.27222@kaball-desktop>
	<alpine.DEB.2.00.1003121432460.27222@kaball-desktop>
	<201003151205.29964.sheng@linux.intel.com>
	<alpine.DEB.2.00.1003151128010.28944@kaball-desktop>
	<4B9EBE03.4080105@goop.org>
	<alpine.DEB.2.00.1003161100540.23661@kaball-desktop>
	<4B9FBE94.4020303@goop.org>
	<alpine.DEB.2.00.1003161728550.23661@kaball-desktop>
	<4B9FC2B5.20103@goop.org>
	<alpine.DEB.2.00.1003161747090.23661@kaball-desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <alpine.DEB.2.00.1003161747090.23661@kaball-desktop>
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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Sheng Yang <sheng@linux.intel.com>
List-Id: xen-devel@lists.xenproject.org

On 03/16/2010 11:06 AM, Stefano Stabellini wrote:
> the following is the interesting bit of the pvclock interface:
>
> static __always_inline
> u64 pvclock_get_nsec_offset(const struct pvclock_vcpu_time_info *src)
> {
> 	u64 delta = __native_read_tsc() - src->tsc_timestamp;
> 	return scale_delta(delta, src->tsc_to_system_mul, src->tsc_shift);
> }
>
>
> xen refreshes the values in pvclock_vcpu_time_info every EPOCH (1s),
> therefore if the value returned by pvclock_get_nsec_offset is greater
> than EPOCH than the patch is not present in xen.
>
> This is a simple way of detecting if the offset is taken into account or
> not and it works because the offset is the value returned by rdtsc in
> the host when the VM was created and we can be sure it corresponds to
> more than 1 sec.
>    

That seems pretty fragile.  I don't think EPOCH is part of the ABI, and 
I don't think we should be relying on it.

     J