From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [ARM] Native application design and discussion (I hope) Date: Tue, 9 May 2017 12:13:09 +0200 Message-ID: <1494324789.9501.7.camel@citrix.com> References: <1492020822.3287.33.camel@citrix.com> <29f244da-2346-70a7-13f0-e5c0cbf490d7@epam.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1642262526085819886==" 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 , Andrii Anisov Cc: Volodymyr Babchuk , Julien Grall , Artem Mygaiev , george.dunlap@citrix.com, Xen Devel List-Id: xen-devel@lists.xenproject.org --===============1642262526085819886== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-J3I431GZb8WHKzsluknK" --=-J3I431GZb8WHKzsluknK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-05-05 at 12:28 -0700, Stefano Stabellini wrote: > On Fri, 5 May 2017, Andrii Anisov wrote: > > On 24.04.17 21:08, Stefano Stabellini wrote: > > > The advantages of using EL0 apps are: > > > - scheduled deterministically > > > - faster context switch > > > - lower and deterministic latency > > > - EL0 apps execution time is accounted appropriately to the guest > > > that > > > =C2=A0=C2=A0=C2=A0they are servicing > >=20 > > Can't the EL0 app be servicing XEN itself? >=20 > Short answer: no. >=20 > Long answer follows. EL0 apps will run in a different context.=20 > I still feel like I am missing something (most likely, due to my limited knowledge of ARM arch and XenOnARM code). Can you try to clarify a bit for me what it "in a different context" in this case, and why it is important? > It was > suggested to keep track of their state in the guest vcpu struct, > which > looks like a good idea to me. If we did that, the only way to have an > EL0 app running without being bound to a specific guest, would be to > run > it on the idle vcpu, which I think is a bad idea. > Which, FTR, is what we do in Xen for a bunch of things already, i.e., softirqs and tasklets. It's actually a rather effective way of executing some piece of Xen code synchronously with some event (as softirqs are always checked 'on the way back' from the hypervisor), which I guess in your case could be the trap from the guest vCPU requesting service. And it should not be hard to give such code access to the context of the vCPU that was previously running (in x86, given we implement what we call lazy context switch, it's most likely still loaded in the pCPU!). Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-J3I431GZb8WHKzsluknK 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 iQIcBAABCAAGBQJZEZY1AAoJEBZCeImluHPu8Y0P/30mEDuJQobogpKlvbDVoupS ITaQ7rmA5LyLd6Ip24sWu8F+HxwkK/fyL7XlU76L7gViyObHfyPOUJyyqxvFWkzi mKf3EkeArT0WhREa/XNyw0yFcCfTIjFTf5b7VoKu8Bq9Q7RSFeDHdGTnW57WVwQ9 ivf9P6PVTuCql1Hmzi0LEMmUysq9PRNmsqiHxa8I2N4aMHLeLUSFieFVvCnNib33 0Y18dxbfhLbE4R78BRENw5LnoDVboaO9EaywEC8+quElEUs91qboBiKQMQwCSd9M iQ2PN894//71M5YDtRKzCn4vMJXA1n1JWfVeVKz/RDBl9XqjH54N6uMtOKUY0Fvp ABmF0ZF0dU3U5UzXlA5Kw5PO+jVtaVrTyIbX326rmR1j/NO8xq/TLFFQPUDGlLB1 sLpUydcpX+rmFE1fbKpCHlJXY8BIPc62rdxXq7LBmBbUQWTCl+F6ie961ag/KJyt N/aQt1vQTagCQNYRGwY0eJIXD4+RGcSzP1srux55fesaeqNMsl1UYA05zucX0y/W ZwB5LTfP136L4jU3jhfZZVDSxOqLWL1mJB55Q+RN8H+or1EAK0u4eFBk58NAcvWn b1jyBV3Qk8MLIZvZGEqj6RVS63HlEN6jznYQ1bk/kUQsA7m2n3tycaY0FnFTrjf7 x1lxYYfORyWrHpoRlIfi =07K4 -----END PGP SIGNATURE----- --=-J3I431GZb8WHKzsluknK-- --===============1642262526085819886== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1642262526085819886==--