From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass Date: Wed, 6 Sep 2017 12:27:29 +0200 Message-ID: <1504693649.30217.10.camel@citrix.com> References: <2017e7bc-aec8-ec04-89b7-46e59020ce16@citrix.com> <7e3c4fda-eb04-2595-bed7-9a459ba1d6e7@citrix.com> <1504626653.338.4.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9003951575368535172==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Stefano Stabellini Cc: xen-devel@lists.xensource.com, George Dunlap , Andrew Cooper , George Dunlap , osstest service owner , Julien Grall , Julien Grall , andre.przywara@arm.com List-Id: xen-devel@lists.xenproject.org --===============9003951575368535172== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-h+srqKWvg3k819/v2KBu" --=-h+srqKWvg3k819/v2KBu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-09-05 at 15:06 -0700, Stefano Stabellini wrote: > On Tue, 5 Sep 2017, Dario Faggioli wrote: > >=20 > > Re-checking things now, I actually do see that context_switch() on > > ARM > > is not 'terminal'. It call schedule_tail(), which on x86 does not > > return, while in ARM, it does. I must have confused these two... > > Sorry. > >=20 > > Also, mostly out of curiosity, still looking at ARM code, I'm not > > getting at all how continue_new_vcpu() works (e.g., when/how is it > > invoked?). >=20 > On ARM, context_switch() returns, unless it's the first time a new > vcpu > is run. In that case pc is set to continue_new_vcpu. __context_switch > restores pc to continue_new_vcpu, returning to it. > Ah, yes, that's what I was missing! The fact that PC is assigned the adress of continue_new_vcpu().. that's how it run. Only the first time, as you're explaining. Thanks! :-) > From the second time onward a vcpu is run, > context_switch returns normally. >=20 Right. And you (or someone else) can also confirm that the stack is per-vCPU? Or, in general, make sense out of the fact that the stack pointer register changes in such a way that, when we get back in do_softirq(), what's in the stack in the place where there was the 'cpu' local variable has (at least in some circumstances) changed? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-h+srqKWvg3k819/v2KBu 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 iQIcBAABCAAGBQJZr82SAAoJEBZCeImluHPu39sQAK290qpqlQU4dD/hNuLhr6RK gkIznLHYfB8QPsvpCKFXy033TXhGXGuO8iiHPQLzs8WNuVcPQ+vDWjWzufmgSJ6l Ii3LUbZd83Dgm+I6662jAc/1xaswtn0c3W8x9z/FrUVxtTYDPz910aXLHMFuJV3o tGQY2cgp92I8tZ+DBuVqaa2718Xz8sWZ3LCUUZ98wbCuRZ9kLcVVvY6F0pbezA9v Rppsj5cpQkjqpoaKgT8AeW3hHMA5bBCdHbQArfGbwxM72FVv2DqqP9xDTefFF1vN A72ot1Jpeom3kLV6hmsGZ3RMK5X93FjFxxP9AgZfzSWnsAZB+himh/WbywrA+orY fpJAsRRiBEBDjfDf/ajcRghSOmi3Gb9Cwkemm9CV6Wkj+vIDkKffZyBaaIjYqtby Kx9Hd8pyy5uxyqW9iMn6Zy0knHehnYp77CCQIlSG/OKn8Bpl1SLBawsrkI1V+Yjo NTqzotopuvGfcnOijoAC028e2x0vpK65z6DXk+HioGa1TTKzC788L+f5qHSE5jG6 EsAyixwUJZnJADVYVcqOqRnn0KKowwllTObw39nyNh+WVuisRGcbCVQGmpfRFdBM 3lcwcVXlWkmaZrLT8sjz24xhXx5hy1VZfpPjhPYzOLmrjdbGWTLXdgBtN8u1IWj5 mdMMlFMea1YpEyaqR3Zd =8fzZ -----END PGP SIGNATURE----- --=-h+srqKWvg3k819/v2KBu-- --===============9003951575368535172== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============9003951575368535172==--