From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling Date: Thu, 9 Jul 2015 16:18:32 +0200 Message-ID: <1436451512.22672.333.camel@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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0248285938246399269==" Return-path: In-Reply-To: <559E96E0020000780008ED84@mail.emea.novell.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: Jan Beulich Cc: Kevin Tian , Feng Wu , George Dunlap , "andrew.cooper3@citrix.com" , xen-devel , Yang Z Zhang , "keir@xen.org" List-Id: xen-devel@lists.xenproject.org --===============0248285938246399269== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QvzaapAQ1MVwasp8NOIZ" --=-QvzaapAQ1MVwasp8NOIZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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)? >=20 > 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.=20 > 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? Maybe (looking at vmx_pi_desc_update() in patch 14), something that is right now dealt with by means of RUNSTATE_offline? What (if yes)? Can (if yes) it be explained in some "non rusntate"-based way, so we can judge whether that could also be achieved differently than by actually hooking in vcpu_runstate_change()? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-QvzaapAQ1MVwasp8NOIZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlWegsEACgkQk4XaBE3IOsRQ9QCfYiR9Ub3qwYCEAWAaRQW6Beye 6sEAnjWG0JKeCzAHDvW0k+JkRKJm9kcq =SLQ1 -----END PGP SIGNATURE----- --=-QvzaapAQ1MVwasp8NOIZ-- --===============0248285938246399269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0248285938246399269==--