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