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

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

> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
> Sent: Thursday, July 09, 2015 10:28 PM
> To: Dario Faggioli; Jan Beulich
> Cc: Tian, Kevin; Wu, Feng; andrew.cooper3@xxxxxxxxxx; xen-devel; Zhang, Yang
> Z; keir@xxxxxxx
> Subject: Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor
> during vCPU scheduling
> 
> On 07/09/2015 03:18 PM, Dario Faggioli wrote:
> > On Thu, 2015-07-09 at 14:44 +0100, Jan Beulich wrote:
> >>>>> On 09.07.15 at 14:53, <george.dunlap@xxxxxxxxxxxxx> wrote:
> >
> >>> Consider the following scenario:
> >>> - v1 blocks on pcpu 0.
> >>>  - vcpu_runstate_change() will do everything necessary for v1 on p0.
> >>> - The scheduler does load balancing and moves v1 to p1, calling
> >>> vcpu_migrate().  Because the vcpu is still blocked,
> >>> vcpu_runstate_change() is not called.
> >>> - A device interrupt is generated.
> >>>
> >>> What happens to the interrupt?  Does everything still work properly, or
> >>> will the device wake-up interrupt go to the wrong pcpu (p0 rather than 
> >>> p1)?
> >>
> >> I think much of this was discussed before, since I also disliked the
> >> hooking into vcpu_runstate_change(). What I remember having
> >> been told is that it really only matters which pCPU's list a vCPU is
> >> on, not what v->processor says.
> >>
> > Right.
> >
> > But, as far as I could understand from the patches I've seen, a vcpu
> > ends up in a list when it blocks, and when it blocks there will be a
> > context switch, and hence we can deal with the queueing during the the
> > context switch itself (which is, in part, an arch specific operation
> > already).
> >
> > What am I missing?
> 
> I think what you're missing is that Jan is answering my question about
> migrating a blocked vcpu, not arguing that vcpu_runstate_change() is the
> right way to go.  At least that's how I understood him. :-)
> 
> But regarding context_switch: I think the reason we need more hooks than
> that is that context_switch only changes into and out of running state.
>  There are also changes that need to happen when you change from blocked
> to offline, offline to blocked, blocked to runnable, &c; these don't go
> through context_switch.  That's why I was suggesting some architectural
> equivalents to the SCHED_OP() callbacks to be added to vcpu_wake &c.
> 
> vcpu_runstate_change() is at the moment a nice quiet cul-de-sac that
> just does a little bit of accounting; I'd rather not have it suddenly
> become a major thoroughfare for runstate change hooks, if we can avoid
> it. :-)

So in my understanding, vcpu_runstate_change() is a central place to
do this, which is good. However, this function is original designed to be
served only for accounting. it is a little intrusive to make it so important
after adding the hooks in it.

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?

Thanks,
Feng

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