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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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.

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)

Attachment: signature.asc
Description: This is a digitally signed message part

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