From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [Help] Trigger Watchdog when adding an IPI in vcpu_wake Date: Mon, 26 Sep 2016 12:18:06 +0200 Message-ID: <1474885086.23934.47.camel@citrix.com> References: <20160913085437.GA14514@linux-gk3p> <1473766217.6339.103.camel@citrix.com> <20160914104417.GA25572@linux-gk3p> <20160917033051.GA16347@vultr.guest> <1474535535.4393.339.camel@citrix.com> <20160924033925.GA31810@linux-gk3p> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1202756196115411334==" Return-path: In-Reply-To: <20160924033925.GA31810@linux-gk3p> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Yang Cc: xuquan8@huawei.com, liuxiaojian6@huawei.com, george.dunlap@eu.citrix.com, xen-devel@lists.xen.org, mengxu@cis.upenn.edu, Wei Yang List-Id: xen-devel@lists.xenproject.org --===============1202756196115411334== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-3zFT/6WdSyMdSA7VyfoI" --=-3zFT/6WdSyMdSA7VyfoI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2016-09-24 at 11:39 +0800, Wei Yang wrote: > On Thu, Sep 22, 2016 at 11:12:15AM +0200, Dario Faggioli wrote: > > _Almost_ correct. However, the problem is more that vcpu_wake() can > > happen in response to an IRQ, and when you grab a spinlock in IRQ > > context, you need to disable IRQs. > >=20 >=C2=A0 > Ok, now I have a question to this sentence. >=20 > I have checked some posts which says in the interrupt handling, irq > would be > disabled. Well, this really depends on the implementation. >=20 > This means in Xen, irq is still enabled during interrupt handling? > Because of > this, we have to disable IRQ when we need to grab the spin lock? >=20 So, I don't think I'm getting all you're saying and asking. The situation is like this: currently, vcpu_wake() can be called both from inside or outside IRQ context, and both with IRQs enabled or disabled. Given this situation, to be safe, we need to disable IRQs when taking whatever spinlock vcpu_wake() (and the functions it calls, of course) calls. Since it takes the scheduler's runq lock, this means we need to take the lock with IRQ disabled. And because of that, _everyone_ that takes the schedulr's lock must do that with IRQs disabled. If we manage to *not* take the scheduler's lock with IRQ disabled in vcpu_wake(), we then can do the same everywhere else. But we can't do that with the current structure of the code, and that's why we're thinking to defer the actual wakeup --i.e., the actual call to vcpu_wake()-- to a moment when: =C2=A0- IRQs are enabled, =C2=A0- we don't need to disable them. This is it. About the following... > Looks I almost get every thing. Let me do a summary to see whether I > have got > your words. >=20 > =C2=A0=C2=A0=C2=A0(spinlock usage convention in Xen)=C2=A0=C2=A0&=C2=A0= =C2=A0(vcpu_wake() may happen in > an IRQ) >=20 This is ok. > =3D> >=20 > =C2=A0=C2=A0=C2=A0(irq all disabled || irq all enabled) & (disable irq on= grabbing > spinlock) >=20 This, I don't get it. > =3D> >=20 > =C2=A0=C2=A0=C2=A0should grab schedule lock with IRQ disabled >=20 Yes, sounds right. Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-3zFT/6WdSyMdSA7VyfoI 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 iQIcBAABCAAGBQJX6PXfAAoJEBZCeImluHPuWg0QALLJNI/RfSQ+gvtxHVUmzOOS /MiFuUpp1k09pN8pps6cJ6iE/jFsJWEru9ISaYB0+yzFdLaZkV+Q1Xt34BHZwNGo WLLcslSz5sTlpzetQrtAKbROEbXDNu2wFzovxJ4JosDOSsQAzXQ3qnyW0kHnuUPp pGiEuFiSIIG2FAy/B0F3olBxz9bkuiwwyhLh3lZQyQgxyDQkyiIH4LsCo0ulv1tA L/09xu+Mp+u1QTbb1dfzIsUsOm/e/5Zh2Vlk3jqEliAOu1T//Z65eiYuV2bhacbL B01mAWlk98SNvSchXEBtw4Q075aPb7CFdoHBcwcNVY1xr07+446Kf8MQj+SrAO+R xkF/s+XFBvCR4TwqFI2/5ygaZFBJWc1MkbgrEnIAmUnzT5M6AxGsXZiUjtq8SRJA ig0ntT/lHu5CrL0zdW969xCoCzdE3XL/q8ONz0+dA9czdtM3t8Nqi7b+H4igtjlH uBqnFM3Kd9kN7UxgLQO2CM+6Xd+3ZWg6/wte5rTBOWRuaqj1LT71FKT4nwNCDyPt sAdoj1KKnl5MhOdELMvXAAo4GxFBALNoycp7Q58srt1ewTGjy9pVecUWhJtCZHu7 P/CaxgyzwWtcrGtSi88dIibvDO47B8k0mpDlXTihPnkWtACRRnyXfaAR1hvwU9KJ +S0NUjXH7ASH/2LzFtaI =OfzV -----END PGP SIGNATURE----- --=-3zFT/6WdSyMdSA7VyfoI-- --===============1202756196115411334== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1202756196115411334==--