From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling Date: Wed, 28 Oct 2015 17:36:46 +0100 Message-ID: <1446050206.28782.14.camel@citrix.com> References: <1444640103-4685-1-git-send-email-feng.wu@intel.com> <1444640103-4685-16-git-send-email-feng.wu@intel.com> <1445870370.2717.103.camel@citrix.com> <562F574A02000078000AEFC7@prv-mh.provo.novell.com> <56309D6A02000078000AF728@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6256853670286453308==" Return-path: In-Reply-To: <56309D6A02000078000AF728@prv-mh.provo.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 , Feng Wu Cc: GeorgeDunlap , Andrew Cooper , Kevin Tian , Keir Fraser , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============6256853670286453308== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UN1we+jh53a0ji+PyI7W" --=-UN1we+jh53a0ji+PyI7W Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-10-28 at 03:03 -0600, Jan Beulich wrote: > > > > On 28.10.15 at 03:58, wrote: > > We still call arch_vcpu_block() in vcpu_block(), but we don't need > > to > > call arch_vcpu_block_cancel(v) when local_events_need_delivery() > > returns true. Then before VM-Entry, we can check if 'NV' field is > > ' pi_wakeup_vector', if it is, we change the PI status and remove > > it from the blocking list. > >=20 > > Jan, if #2 is what you mean, I think it worth a try. If I don't > > understand > > your comments correctly, could you please elaborate it more? Thanks > > a lot! >=20 > Ideally we'd avoid both arch_vcpu_*() calls by doing what is needed > in arch code (e.g. the VM entry path).=20 > +1 > If only avoiding the cancel > hook is reasonably possible this way, then so be it - still better to > have just one hook here than having two. >=20 +1 again As an aside, I've spoked with some ARM people, the context being that they will get to implement a similar feature in the nearish future. They said that, although they can't be sure, they don't think they'll be interested in arch hooks in the scheduling code and that, actually, having them risk being more harmful than helpful. Of course, that does not mean that we shouldn't add them for the sake of this patch, if we can't avoid doing that. But if we can avoid them, that is perhaps one more reason for doing things that way. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-UN1we+jh53a0ji+PyI7W 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 v1 iEYEABECAAYFAlYw+Z4ACgkQk4XaBE3IOsSyOACghsMYeeaS8RRlOT+jvKeoDvXH Ax8Ani5RNTNtzL7ehnUo7naUW+USsSUF =P696 -----END PGP SIGNATURE----- --=-UN1we+jh53a0ji+PyI7W-- --===============6256853670286453308== 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 --===============6256853670286453308==--