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] Re: [PATCH][v4] PV extension of HVM(hybrid) support in

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH][v4] PV extension of HVM(hybrid) support in Xen
From: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Date: Tue, 2 Mar 2010 11:36:02 +0800
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 01 Mar 2010 19:35:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B8C6EC3.2020307@xxxxxxxx>
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: <201003011743.41341.sheng@xxxxxxxxxxxxxxx> <201003011940.50685.sheng@xxxxxxxxxxxxxxx> <4B8C6EC3.2020307@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; )
On Tuesday 02 March 2010 09:49:55 Jeremy Fitzhardinge wrote:
> On 03/01/2010 03:40 AM, Sheng Yang wrote:
> > The issue is pv timer. It assumed the tsc start from 0, which is
> > different from HVM. So I'd like to give it a explicit call here.
> > Otherwise it can be hooked in evtchn binding, but I don't think that's
> > clear...
> 
> [...]
> 
> >> Only vcpu 0?  Doesn't this do horrible things to timekeeping in the
> >> guest?
> >
> > The other vcpus are initialized when it is brought up. TSC started from 0
> > is a fundamental assumption for pv clock in Linux...
> 
> Could you expand on this?  Do you mean in the pvops Xen time code?  What
> do you mean?
> 

The function pvclock_get_nsec_offset() in Linux kernel have this:

>static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time *shadow)
>{
>        u64 delta = native_read_tsc() - shadow->tsc_timestamp;
>        return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow-
>tsc_shift);
>}

tsc_timestamp take the vcpu beginning at 0, so that's the assumption. So I 
adjusted guest TSC(the return value of native_read_tsc()) to satisfy this 
assumption. 

-- 
regards
Yang, Sheng

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