From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] xen/arm: introduce vwfi parameter Date: Wed, 22 Feb 2017 17:40:00 +0100 Message-ID: <1487781600.6732.436.camel@citrix.com> References: <1487286292-29502-1-git-send-email-sstabellini@kernel.org> <484f2a39-1322-f40e-de01-97746e5de280@arm.com> <1487618436.6732.230.camel@citrix.com> <1845466e-c6a3-bcb9-0813-80ecdf267f03@arm.com> <1487631215.6732.266.camel@citrix.com> <06f20feb-0e9e-c757-b245-ebb55b422c67@arm.com> <1487668158.6732.310.camel@citrix.com> <14575011-0042-8940-c19f-2482136ff91c@foss.arm.com> <6a7b800a-dd6a-15a2-665d-d28352f24cd1@citrix.com> <1487689631.6732.412.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8589895127966929802==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cga1m-00056O-8h for xen-devel@lists.xenproject.org; Wed, 22 Feb 2017 16:44:30 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , Stefano Stabellini Cc: edgar.iglesias@xilinx.com, george.dunlap@eu.citrix.com, Punit Agrawal , Julien Grall , xen-devel@lists.xenproject.org, nd@arm.com List-Id: xen-devel@lists.xenproject.org --===============8589895127966929802== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-e2ig6lQzWwUuZf9IZLeo" --=-e2ig6lQzWwUuZf9IZLeo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-02-21 at 18:17 +0000, George Dunlap wrote: > On 21/02/17 17:49, Stefano Stabellini wrote: > > I don't know the inner working of the scheduler, but does it always > > send > > an interrupt to other pcpu to schedule something? >=20 > Letting a guest call WFI is as safe as letting a guest > `while(1);`.=C2=A0=C2=A0Xen > *always* has to set a timer interrupt before switching to the guest > context to make sure that it can pre-empt the vcpu -- otherwise any > vcpu > could perform a DoS by simply continually executing instructions. >=20 Yes, ensuring preemption happens is indeed Xen responsibility, and it will indeed happen, as far as interrupts are enabled, as George says. > > What if there are 2 vcpu pinned to the same pcpu? This cannot be > > fair. >=20 > From the scheduler's perspective, the WFI would be the same as the > `while(1)`.=C2=A0=C2=A0 > It is, provided you charge the vCPU for the time it spent in WFI, the same as you'd charge it for time spend in a `while(1)`. This is *probably* what happens already if we let WFI run on hardware, but I'd double check and test. > If you had two vcpus doing while(1) on the same vcpu, the > credit2 scheduler would (approximately) let one run for 2ms, then the > other for 2ms, and so on, each getting 50%.=C2=A0=C2=A0 > If you're talking about MAX_TIMER, it's 10ms these days. But yes, this still means 50% each. > If ARM had the equivalent of posted interrupts, then a pinned guest > could efficiently wait for interrupts with no additional latency from > virtualization without having to poll. >=20 > (Speaking of which -- that could be an interesting optimization even > on > x86... if a pcpu has no vcpus waiting to run, then disable HLT exit.) >=20 Sorry, this sounds interesting but I'm not sure I understand what you mean (but let's not hijack this thread, maybe, and talk about it somewhere else. :-) Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-e2ig6lQzWwUuZf9IZLeo 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 iQIcBAABCAAGBQJYrb7lAAoJEBZCeImluHPu/IsP/1M6W2R9UFlq3MOZF6a7FlOV 1k6cEZSPmtvdSIhUZDWRHm0HnGzE0tT5tzKOKpX3PP3FVC0NkTqRJWZ8lL0TZvF7 tEbMbdkpymELuGblIRORE73bViG5Cj+FTTsi9Gs8zVgwgNTghrxwjoD8ddpMuRuW cyplIwILd5XRjDmZHFj8d/DQpXIO/V7+Rv57v+tuicR8rCBmv5Q0RgGCvWZ45yB0 MPcSsLVFBzozQARd502IBZ9Ob18AjNrLsi230+8zOPv8t9AV8C/KfOjy/3ROkW/5 AJdEeTUFoExl0BhvUlhCz6UPq7p/7c4MNrd0Ed08vxG8+CPp6JZgDcPcvbVrwDN5 8nfB3M7gx7biKB4D9jxxSBzoNSX14Au63HMQOx6dH0A6rzrymwcvcwqqg5Glgfp3 HoCJ9MiC3/DyjafXhlW6M1ZSmTRItRFkrvgYygkhLwqffbG+PDeVDCKLT3DwpjE5 U3qdSCqDeA6i3MdQMrCPjrbxZ6VKIqNWRdK2tvszuXjfvxZKGfjoaYR4/RWIJvdT LShp3JqOPAOrTQc5+2JNVzzdn6+7EoB5wqbRvg0YanzZE0DP5sbdXlBmcefWXs68 l0Ct4RaskUA+JZTzsQRbC7zgDqYPgLfOPpPSFXBUjRmXoqEEIH5znxss6gUt+bn9 bdFyJJcMFfRd/cC+EZ/P =qtdX -----END PGP SIGNATURE----- --=-e2ig6lQzWwUuZf9IZLeo-- --===============8589895127966929802== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============8589895127966929802==--