From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Thu, 9 Jul 2015 15:27:59 +0100 Message-ID: <559E84EF.7060507@eu.citrix.com> References: <1435123109-10481-15-git-send-email-feng.wu@intel.com> <55918214.4030102@citrix.com> <1435633087.25170.274.camel@citrix.com> <1435825253.25170.406.camel@citrix.com> <559E6EB7.3050609@eu.citrix.com> <559E96E0020000780008ED84@mail.emea.novell.com> <1436451512.22672.333.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436451512.22672.333.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Jan Beulich Cc: Kevin Tian , "keir@xen.org" , "andrew.cooper3@citrix.com" , xen-devel , Yang Z Zhang , Feng Wu List-Id: xen-devel@lists.xenproject.org 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, 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. :-) -George