Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Wednesday, January 20, 2016 9:31 PM
> To: Jan Beulich <JBeulich@xxxxxxxx>; Wu, Feng <feng.wu@xxxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; George Dunlap
> <george.dunlap@xxxxxxxxxxxxx>; Tian, Kevin <kevin.tian@xxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxx; Keir Fraser <keir@xxxxxxx>
> Subject: Re: [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling
> 
> On Wed, 2016-01-20 at 04:35 -0700, Jan Beulich wrote:
> > > > > On 20.01.16 at 12:20, <feng.wu@xxxxxxxxx> wrote:
> > > >
> > > > Then you didn't understand: The question isn't this path, but the
> > > > path where the hook gets called if non-NULL (and hence the
> > > > possibility to avoid such needless calls).
> > >
> > > I understand you mean the overhead happens when the hooks
> > > is called. My point is the hook is not called in a critical path,
> > > so I doubt
> > > whether it worth doing so to make the logic complex.
> >
> > Are you sure scheduling code is not a critical path?
> >
> TBH, I like Jan's point... It's always good to make all we can to avoid
> calling the hook, if unnecessary.
> 
> Does it really complicates things a lot? Feng, can you give it a try?

After more thinking about this, it seems to me avoiding the checking
of assigned devices and spinlocks in vmx_pi_switch_from() and
vmx_pi_switch_to() is more meaningful, since this two functions are
the real ones involved in scheduling than arch_vcpu_block(), should 
we also use the method Jan mentioned above to avoid the overhead
in these two function. To achieve this, we have some issues, since
these two functions are not hooks (they are called in other hooks).
vmx_pi_so_resume() has the same problem as well.

Can we do it this way?
- Define the three functions above as hooks in 'v->arch.hvm_vmx'.
- Initial them when the first device is assigned and zap them when the
last assigned device is de-assigned.

Jan and Dario, any ideas?

Thanks,
Feng

> 
> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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