Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling

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

> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@xxxxxxxxxx]
> Sent: Friday, July 10, 2015 7:06 PM
> To: Jan Beulich
> Cc: Wu, Feng; andrew.cooper3@xxxxxxxxxx; George Dunlap; Tian, Kevin; Zhang,
> Yang Z; xen-devel; keir@xxxxxxx
> Subject: Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor
> during vCPU scheduling
> 
> On Fri, 2015-07-10 at 07:22 +0100, Jan Beulich wrote:
> > >>> On 10.07.15 at 07:59, <feng.wu@xxxxxxxxx> wrote:
> > > If you agree with doing all this in a central place, maybe we can create
> > > an arch hook for 'struct scheduler' to do this and call it in all the 
> > > places
> > > vcpu_runstate_change() gets called. What is your opinion about this?
> >
> > Doing this in a central place is certainly the right approach, but
> > adding an arch hook that needs to be called everywhere
> > vcpu_runstate_change() wouldn't serve that purpose.
> >
> Indeed.
> 
> > Instead
> > we'd need to replace all current vcpu_runstate_change() calls
> > with calls to a new function calling both this and the to be added
> > arch hook.
> >
> Well, I also see the value of having this done in one place, but not to
> the point of adding something like this.
> 
> > But please wait for George's / Dario's feedback, because they
> > seem to be even less convinced than me about your model of
> > tying the updates to runstate changes.
> >
> Indeed. George stated very well the reason why vcpu_runstate_change()
> should not be used, and suggested arch hooks to be added in the relevant
> places. I particularly like this idea as, not only it would leave
> vcpu_runstate_change() alone, but it would also help disentangling this
> from runstates, which, IMO, is also important.
> 
> So, can we identify the state (runstate? :-/) transitions that needs
> intercepting, and find a suitable place where to place hooks? I mean,
> something like this:
> 
>  - running-->blocked: can be handled in the arch specific part of
>                       context switch (similarly to CMT/CAT, which
>                       already hooks into there). So, in this case, no
>                       need to add any hook, as arch specific code is
>                       called already;
> 
>  - running-->runnable: same as above;
> 
>  - running-->offline: not sure if you need to take action on this. If
>                       yes, context switch should be fine as well;
> 
>  - blocked-->runnable: I think we need this, don't we? If yes, we
>                        probably want an arch hook in vcpu_wake();
> 
>  - blocked-->offline: do you need it? Well, the hook in wake should work
>                       for this as well, if yes;
> 
>  - runnable/running-->offline: if necessary, we want an hook in
>                                vcpu_sleep_nosync().
> 
> Another way to look at this, less biased toward runstates (i.e., what
> I've been asking for since a while), would be:
> 
>  - do you need to perform an action upon context switch (on prev and/or
>    next vcpu)? If yes, there's an arch specific path in there already;
>  - do you need to perform an action when a vcpu wakes-up? If yes, we
>    need an arch hook in vcpu_wake();
>  - do you need to perform an action when a vcpu goes to sleep? If yes,
>    we need an arch hook in vcpu_sleep_nosync();
> 
> I think this makes a more than fair solution. I happen to like it even
> better than the centralized approach, actually! That is for personal
> taste, but also because I think it may be useful for others too, in
> future, to be able to execute arch specific code, e.g., upon wakes-up,
> in which case we will be able to use the hook that we're introducing
> here for PI.
> 

Hi George, any ideas about this?

Thanks,
Feng

> Thanks and 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