From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Fwd: [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked Date: Tue, 30 Jun 2015 11:46:43 +0200 Message-ID: <1435657603.25170.286.camel@citrix.com> References: <1435123109-10481-13-git-send-email-feng.wu@intel.com> <559181F9.6020106@citrix.com> <1435632691.25170.268.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5229471274006855162==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" Cc: "Tian, Kevin" , "keir@xen.org" , "george.dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , xen-devel , "jbeulich@suse.com" , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org --===============5229471274006855162== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aYaXsC66+9k29UrYdUGu" --=-aYaXsC66+9k29UrYdUGu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-06-30 at 02:59 +0000, Wu, Feng wrote: > > Quoting the design document in patch 1: > >=20 > > +Here is the scenario for the usage of the new global vector: > > + > > +1. vCPU0 is running on pCPU0 > > +2. vCPU0 is blocked and vCPU1 is currently running on pCPU0 > > +3. An external interrupt from an assigned device occurs for vCPU0, if = we > > +still use 'posted_intr_vector' as the notification vector for vCPU0, t= he > > +notification event for vCPU0 (the event will go to pCPU1) will be cons= umed > > +by vCPU1 incorrectly (remember this is a special vector to CPU). The w= orst > > +case is that vCPU0 will never be woken up again since the wakeup event > > +for it is always consumed by other vCPUs incorrectly. So we need intro= duce > > +another global vector, naming 'pi_wakeup_vector' to wake up the blocke= d > > vCPU. > > + > > +After using 'pi_wakeup_vector' for vCPU0, VT-d engine will issue notif= ication > > +event using this new vector. Since this new vector is not a SPECIAL on= e to > > CPU, > > +it is just a normal vector. To cpu, it just receives an normal externa= l > > interrupt, > > +then we can get control in the handler of this new vector. In this cas= e, > > hypervisor > > +can do something in it, such as wakeup the blocked vCPU. > >=20 > > Let's assume that there are two vCPUs blocked, waiting for a (posted) > > interrupt, on pCPU0, and that they are vCPU2 and vCPU4, while vCPU12 is > > running there. > >=20 > > AFAIU the code above, when an interrupt arrives on pCPU0, you scan the > > list, find both vCPU2 and vCPU4, which both have pi_desc.on set to true= , > > and hence you kick (via the tasklet) both of them? >=20 > Yes, that is the case. Do you have any questions about it? >=20 The question is if that is how things should work as, by reading the design document, my understanding was that you wanted a certain interrupt to wake-up a specific vCPU. But perhaps I'm failing to understand what really happens, and how the 'special vector' vs. 'normal vector' thing work (due to lack of my lack of confidence in this area). Am I actually talking nonsense? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-aYaXsC66+9k29UrYdUGu 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 iEYEABECAAYFAlWSZYMACgkQk4XaBE3IOsQ4mQCdFAxNJhpcMlXa06R+EluEH7vR w84AoIR6oezhtieqEF/XHtjyt7aVoYW1 =NZ9d -----END PGP SIGNATURE----- --=-aYaXsC66+9k29UrYdUGu-- --===============5229471274006855162== 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 --===============5229471274006855162==--