From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked Date: Thu, 2 Jul 2015 14:38:12 +0200 Message-ID: <1435840692.14347.9.camel@citrix.com> References: <1435123109-10481-1-git-send-email-feng.wu@intel.com> <1435123109-10481-13-git-send-email-feng.wu@intel.com> <55926B62.1000605@citrix.com> <1435757162.25170.354.camel@citrix.com> <1435825820.25170.416.camel@citrix.com> <559512BC.90303@citrix.com> <1435838657.25170.462.camel@citrix.com> <55952BA1.6050701@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6815441628904321424==" Return-path: In-Reply-To: <55952BA1.6050701@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: Andrew Cooper Cc: "Tian, Kevin" , "keir@xen.org" , "george.dunlap@eu.citrix.com" , "xen-devel@lists.xen.org" , "jbeulich@suse.com" , "Zhang, Yang Z" , "Wu, Feng" List-Id: xen-devel@lists.xenproject.org --===============6815441628904321424== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Mpi8bs822wrFflPGddhf" --=-Mpi8bs822wrFflPGddhf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-07-02 at 13:16 +0100, Andrew Cooper wrote: > On 02/07/15 13:04, Dario Faggioli wrote: > > On Thu, 2015-07-02 at 11:30 +0100, Andrew Cooper wrote: > >> I can't currently decide whether this will be quicker or slower overal= l, > >> or (most likely) it will even out to equal in the general case. > >> > > Well, given the thing works as you (two) just described, I think > > draining the list is the only thing we can do. > > > > In fact, AFAICT, since we can't know for what vcpu a particular > > notification is intended, we don't have alternatives to waking them all= , > > do we? >=20 > Perhaps you misunderstand. >=20 I'm quite sure I was. While I think now I'm getting it. > Every single vcpu has a PI descriptor which is shared memory with hardwar= e. >=20 Right. > A NV is delivered strictly when hardware atomically changes desc.on from > 0 to 1. i.e. the first time that an oustanding notification arrives.=20 > (iirc, desc.on is later cleared by hardware when the vcpu is scheduled > and the vector(s) actually injected.) >=20 > Part of the scheduling modifications alter when a vcpu is eligible to > have NV's delivered on its behalf. non-scheduled vcpus get NV's while > scheduled vcpus have direct injection instead. >=20 Blocked vcpus, AFAICT. But that's not relevant here. > Therefore, in the case that an NV arrives, we know for certain that one > of the NV-eligible vcpus has had desc.on set by hardware, and we can > uniquely identify it by searching for the vcpu for which desc.on is set. >=20 Yeah, but we ca have more than one of them. You said "I can't currently decide whether this will be quicker or slower", which I read like you were suggesting that not draining the queue was a plausible alternative, while I now think it's not. Perhaps you were not meaning anything like that, so it was not necessary for me to point this out, in which case, sorry for the noise. :-) > In the case of stacked NV's, we cannot associate which specific vcpu > caused which NV, but we know that we will get one NV per vcpu needing > kicking. >=20 Exactly, and that's what I'm talking about, and why I'm saying that waking everyone is the only solution. The bottom line being that, even in case this is deemed too slow, we don't have the option of waking only one vcpu at each NV, as we wouldn't know who to wake, and hence we'd need to make things faster in some other 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) --=-Mpi8bs822wrFflPGddhf 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 iEYEABECAAYFAlWVMM0ACgkQk4XaBE3IOsTWYgCeObZhqWBiTRAf0BA/FWuaVF7V nr4AoIfeCjLn3ZgY7/lYlgxuO2iPsC6E =hLFI -----END PGP SIGNATURE----- --=-Mpi8bs822wrFflPGddhf-- --===============6815441628904321424== 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 --===============6815441628904321424==--