From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Thu, 09 Jul 2015 14:44:32 +0100 Message-ID: <559E96E0020000780008ED84@mail.emea.novell.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559E6EB7.3050609@eu.citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Kevin Tian , Feng Wu , "andrew.cooper3@citrix.com" , Dario Faggioli , xen-devel , Yang Z Zhang , "keir@xen.org" List-Id: xen-devel@lists.xenproject.org >>> On 09.07.15 at 14:53, wrote: >> The migration is handled in arch_pi_desc_update() which is called >> by vcpu_runstate_change(). > > Well as far as I can tell from looking at the code, > vcpu_runstate_change() will not be called when migrating a vcpu which is > already blocked. > > 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. And I sort of accepted that moving the vCPU between lists when v->processor changes without the vCPU actually running on that pCPU is pretty pointless (and perhaps wasteful, but in any case cluttering more code than necessary). Jan