From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: xen/arm: Domain not fully destroyed when using credit2 Date: Wed, 25 Jan 2017 12:10:10 +0100 Message-ID: <1485342610.32103.96.camel@citrix.com> References: <58871C790200007800133268@prv-mh.provo.novell.com> <1485262392.32103.52.camel@citrix.com> <1485263974.32103.61.camel@citrix.com> <1485265231.32103.65.camel@citrix.com> <1485267419.32103.71.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6979051288979105844==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWLTF-00067y-IS for xen-devel@lists.xenproject.org; Wed, 25 Jan 2017 11:10:33 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Julien Grall , Jan Beulich Cc: Stefano Stabellini , Wei Liu , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , xen-devel List-Id: xen-devel@lists.xenproject.org --===============6979051288979105844== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-dU9JkqMQKMkfvutkqqiD" --=-dU9JkqMQKMkfvutkqqiD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-01-24 at 15:06 +0000, Julien Grall wrote: > On 24/01/17 14:16, Dario Faggioli wrote: > > There, we have tracing (BTW, did that made it to ARM eventually?) > > and > > there's TRC_PM_IDLE_ENTRY/EXIT which do pretty much the same of > > your > > printk-s. >=20 > There is patch on the ML for xentrace support (see [1]) but nothing > has=C2=A0 > been upstreamed yet. Waiting for a new version from the contributor. >=20 Yep, that was I was remembering, and referring to. Thanks for the update. > > And if I look at it, I do see even totally idle (from the scheduler > > point of view) pCPUs, I indeed see them going back and forth from > > and > > to C3. >=20 > My knowledge on x86 is limited. When does a CPU decides to leave the=C2= =A0 > idle mode? >=20 I'm not an expert of that part either. Jan and Andrew for sure know best how monitor/mwait works (both in general, and our own implementation). What I know (and can quickly infer from glancing at the code), is that timers are certainly involved. In fact, we wake up when the most imminent timer would expire (see mwait_idle_with_hints()), and a timer set by the scheduler fully qualifies as being the one (if it's the most imminent). My point was that, still from scheduling perspective, neither Credit1 nor Credit2 sets a wakeup timer for idle pCPUs. Well, in Credit1, the master_ticker timer is never stopped (while, e.g., the per-pCPU tick is stopped before entering deep sleep, via=C2=A0sched_tick_suspend(), see commit=C2=A0964fae8ac), but that's only = 1 pCPU. > In the case of ARM, the wfi instruction will put the CPU in idle > mode=C2=A0 > until an interrupt is received. >=20 Just looking up references for MWAIT, I've found this: (http://x86.renejeschke.de/html/file_module_x86_id_215.html) "A store to the address range armed by the MONITOR instruction, an interrupt, an NMI or SMI, a debug exception, a machine check exception, the BINIT# signal, the INIT# signal, or the RESET# signal will exit the implementation-dependent-optimized state. Note that an interrupt will cause the processor to exit only if the state was entered with interrupts enabled." So, yeah, interrupt, as expectable, wakes x86 up. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-dU9JkqMQKMkfvutkqqiD 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 iQIcBAABCAAGBQJYiIeTAAoJEBZCeImluHPukzcQAMlL+1HRBlASgc6ijBOH6I8H FyjwdzyWG8CrC1ONPgpOnCFbwcL61gptZbKb72fBac8AaVND3u8kiLcslcA6iuAC ShHjsMAjPFpJO5tIpVSAhgSaiekYm075iT2XalUvFWm/ojSEPl2WaJqiroA9HEI/ 1X4mad9Ej3CJf01L/HAU4/cY96jrhQT4u3fJIVxO0Ov2dtDKvDpQ1zx8jR7CBV9Z B+qpP9B4KDLQMCS2nlch5CAaMAOpPm+6jW6l9N9jSkL+XI77GC0kO6wWEBqDNQGc w/MqPbhcNMIrb/TT+ATYRrkl+mavdu3U7u834P5VYevnWfa14Qgl/G7kzRHipRqV A+D3mhQAuq9SRkXbzIfgaDKWTZmHhjpvwnwS/5RBg5GpaF4DpntOHTRJBChnib0x NbuVOGdWEbEt7o35srm08tFdGq3Hlxl0tayBXxNQvqZmKv1/ZCzzHUiCXskoFwC3 Nfr9C39jZKgXvvQDNy/RyNH4kYiNAGsyRSQYcoNXI/d+InqCZhKKR/f3liR4aQDQ kk3eLJZ7gBCy523Xon9BFNxVJKjVK5fCPdUQ27CEXEa5aR+1Y06kiZFv4yPTwyrg Y+XKSoEjM03dxuB2undSvyB8eyQZiBnfY30e9c/LBqddjCkTKRjGiQdi9tMjbC1l ww1HinRfeowLXTR4qEv/ =hK+n -----END PGP SIGNATURE----- --=-dU9JkqMQKMkfvutkqqiD-- --===============6979051288979105844== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6979051288979105844==--