From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC 0/5] xen/arm: support big.little SoC Date: Tue, 20 Sep 2016 19:24:14 +0200 Message-ID: <1474392254.4393.220.camel@citrix.com> References: <20160919083619.GA16854@linux-7smt.suse> <5ddefbc1-3bd4-c990-b615-0039761535d8@arm.com> <97d77bdb-2f4e-e89a-95b9-8aacb56eebc0@suse.com> <1474305482.4393.42.camel@citrix.com> <1474325742.4393.78.camel@citrix.com> <1474332846.4393.153.camel@citrix.com> <20160920100331.GB8084@linux-u7w5.ap.freescale.net> <4c52141f-a6a4-a0b1-dced-f799b592481e@arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8619488626979301571==" Return-path: In-Reply-To: <4c52141f-a6a4-a0b1-dced-f799b592481e@arm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Julien Grall , George Dunlap , Peng Fan Cc: Juergen Gross , Peng Fan , Stefano Stabellini , Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============8619488626979301571== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-BKWU3Iew94lCzudbiReD" --=-BKWU3Iew94lCzudbiReD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 17:34 +0200, Julien Grall wrote: > On 20/09/2016 12:27, George Dunlap wrote: > > I think we definitely need to have Xen have some kind of idea the > > order between processors, so that the user doesn't need to figure > > out > > which class / pool is big and which pool is LITTLE.=C2=A0=C2=A0Whether = this > > sort > > of enumeration is the best way to do that I'll let Julien and > > Stefano > > give their opinion. >=20 > I don't think an hardcoded list of processor in Xen is the right=C2=A0 > solution. There are many existing processors and combinations for=C2=A0 > big.LITTLE so it will nearly be impossible to keep updated. >=20 As far as either the scheduler or cpupools go, what's necessary would be: =C2=A0- in Xen, a function (or an array acting as a map, or whatever) to=C2= =A0 =C2=A0 =C2=A0call to know whether pcpu X is big or LITTLE; =C2=A0- at toolstack level, an hypercal (or a field, bit, whatever in a =C2=A0 =C2=A0struct already returned by an existing hypercall) to know the = same=C2=A0 =C2=A0 =C2=A0thing, i.e., whether c pcpu is big or LITTLE. Once we have this, we can do everything. We will probably want to abstract things a bit, and make them as generic as practical, so that the same interface can be used not only for ARM big.LITTLE, but for whatever future heterogeneous cpu arch we'll support... but really, the actual information that we need is "just" that. I've absolutely no idea how such info could be achieved, and I have no ARM big.LITTLE hardware to test on. > I would expect the firmware table (device tree, ACPI) to provide=C2=A0 > relevant data for each processor and differentiate big from LITTLE > core. > Note that I haven't looked at it for now. A good place to start is=C2=A0 > looking at how Linux does. >=20 Makes sense. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-BKWU3Iew94lCzudbiReD 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 iQIcBAABCAAGBQJX4XC/AAoJEBZCeImluHPu+J8QAMUzzEb8bmVKWyHdalAuVB+y NMyL0wLp49PSPQ6NQ9q3h3zIQwACIzVc5ePEINK4UV3WsE4xjIBpmcZs9+ydX3KA PFTKioJ+xsmquCWBKl9sgZuZqALVF0Phpu9SzEr2xeI77v9CWOCZ2yOWClBXBfxx YZnULx1vIJvgVIQxyas59lJs0ZEwhXuTDYwtS34OeRdKBMLyDnh2BbUzxfQ9hJix VNZa+lZQIDraYneFFc1Sy1nE3+IIQPtf0+MRpozsa+Cl+hZJ4JEopJ/4J2g4Xegg nfgFs7fb/lNxzBZlm3zT+y2/6EKOWf/Jj3ilHF0fJPL20eQLw71+t3XCgwgkbx7o q4Hb8wIz/PBO4On+Zr/6i10b1urrZDzWrQT3jE3gFc6Bj2vPdML7r5H1Ez05u5PI 7kgN/iWjRs8OJOyQ+hJ375Iy5TfkHzRyTtvYIPdBkmUJ1ezrqEnHgXwbejr6coJU OPGGt8h/DJ5ldIbyRWrkSo/kontefUj9GLOsST7ZSQ9Ej4O+SwgWXwWbb3wOKsgF Fcswo4vQYWdjoNfROtU5Eu8/wjthr9gaoYZ4cuRpedrPqfGpsaa1UTK9KIyDg1uC 3gYp75x7OqCyTYF4LJJwHEqNUcjWWhQrMajSGfCSTY7QHc6MdBTqyD8go79AB4AM as4mArX1vXIL2+/+vdpk =cLB5 -----END PGP SIGNATURE----- --=-BKWU3Iew94lCzudbiReD-- --===============8619488626979301571== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============8619488626979301571==--