[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH][v4] PV extension of HVM(hybrid) support in Xen



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.