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 0 of 5] PV on HVM Xen

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Wed, 17 Mar 2010 17:18:37 +0800
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 17 Mar 2010 02:19:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201003171651.05220.sheng@xxxxxxxxxxxxxxx>
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>
Organization: Intel Opensource Technology Center
References: <alpine.DEB.2.00.1003101457100.28412@kaball-desktop> <alpine.DEB.2.00.1003161834570.23661@kaball-desktop> <201003171651.05220.sheng@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
On Wednesday 17 March 2010 16:51:05 Sheng Yang wrote:
> On Wednesday 17 March 2010 02:37:51 Stefano Stabellini wrote:
> > On Tue, 16 Mar 2010, Jeremy Fitzhardinge wrote:
> > > 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.
> >
> > EPOCH is certainly not part of the ABI :)
> > That said the difference between a correct delta and a wrong delta is so
> > big that we cannot really be mistaken.
> >
> > In any case I wouldn't mind a feature flag just to stay on the safe
> > side, so I'll leave this decision to you and Keir (that this week is on
> > vacation).
> 
> I am quite happy with a feature flag. Depends on the return of hypercall to
> determine if the feature is there seems tricky to me...
> 
> Sure, I am fine with a set/remove tsc offset.

Seem not get enough update...

OK, a new flag, adjustment in Xen. Right?

-- 
regards
Yang, Sheng

> And a side effort would be we
> need more code to do it explicitly for SMP guest's vcpu in the guest kernel
> code... But it's fine if they are elegant enough(I think
>  setup_percpu_clockev should be fit for it).
> 

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