Re: [Xen-devel] [PATCH 2/2] x86/HVM: Use fixed TSC value when saving or restoring domain

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 03/31/2014 10:34 AM, Jan Beulich wrote:
> > > > index 95b4b91..032eb23 100644
> > > > --- a/xen/include/xen/time.h
> > > > +++ b/xen/include/xen/time.h
> > > > @@ -32,7 +32,8 @@ struct vcpu;
> > > >    typedef s64 s_time_t;
> > > >    #define PRI_stime PRId64
> > > >    
> > > > -s_time_t get_s_time(void);
> > > > +s_time_t get_s_time_fixed(u64 at_tick);
> > > > +#define get_s_time() get_s_time_fixed(0)
> > > get_s_time(), through NOW(), has quite many users, so I'm not certain
> > > the code bloat resulting from this is desirable. I'd suggest the function
> > > to remain such; the compiler will be able to make it a mov+jmp.
> > Sorry, not sure I understand what you are asking for.
> >
> > There shouldn't be much of code size increase since get_s_time()
> > currently (and get_s_time_fixed() after this patch is applied) are not
> > inlines. The only increase is due to routine itself getting very
> > slightly larger.
> >
> > But I suspect you meant something else.
> All call sites have to zero %edi with the change in place, and I
> was trying to tell you that the number of call sites of this isn't
> exactly small due to the function's use via NOW(). Hence I think
> you shouldn't penalize the callers and have an explicit out of line
> wrapper.
OK, I understand the concern now but still confused about what you want ;-(

Two separate routines that only differ in how tsc is calculated (rdtscll 
vs. an 'in' parameter)?
-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel