From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [RFC 0/5] xen/arm: support big.little SoC
Date: Fri, 23 Sep 2016 15:36:57 +0200
Message-ID: <1474637817.23934.12.camel@citrix.com>
References: <alpine.DEB.2.10.1609211048310.26423@sstabellini-ThinkPad-X260>
 <1ae3ca04-2fdd-531f-7cb1-0b3ab80feccb@arm.com>
 <20160922064928.GB19448@linux-u7w5.ap.freescale.net>
 <1474534223.4393.320.camel@citrix.com>
 <20160922092744.GA22134@linux-u7w5.ap.freescale.net>
 <78b688a0-1a74-0225-2fde-a66b622a2a7e@arm.com>
 <alpine.DEB.2.10.1609221028560.26423@sstabellini-ThinkPad-X260>
 <e47afc4e-0ce1-97a9-6abc-f4d33b4d7c24@arm.com>
 <20160923021423.GC27908@linux-u7w5.ap.freescale.net>
 <98f090ef-3fff-304d-6fb7-d4f9da858a0a@arm.com>
 <20160923100523.GB5828@linux-u7w5.ap.freescale.net>
 <b034126d-fe05-d69b-b7c7-4931eb71d8fb@arm.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9160042177620402243=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <b034126d-fe05-d69b-b7c7-4931eb71d8fb@arm.com>
List-Unsubscribe: <https://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: Julien Grall <julien.grall@arm.com>, Peng Fan <van.freenix@gmail.com>
Cc: Juergen Gross <jgross@suse.com>, Peng Fan <peng.fan@nxp.com>, Stefano Stabellini <sstabellini@kernel.org>, Steve Capper <Steve.Capper@arm.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Punit Agrawal <punit.agrawal@arm.com>, George Dunlap <george.dunlap@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

--===============9160042177620402243==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="=-0bIcUa/JX6xqmT2K6JuT"

--=-0bIcUa/JX6xqmT2K6JuT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2016-09-23 at 11:15 +0100, Julien Grall wrote:
> On 23/09/16 11:05, Peng Fan wrote:
> > If cluster is not prefered, cpuclass maybe a choice, but I
> > personally perfer
> > "cluster" split for ARM.
> >=20
> > Thanks,
> > Peng.
> >=20
> > [1] https://en.wikipedia.org/wiki/ARM_big.LITTLE
>=C2=A0
> Please try to have a think on all the use case and not only yours.
>=20
This last line is absolutely true and very important!

That being said, I am a bit lost.

So, AFAICT, in order to act properly when the user asks for:

=C2=A0vcpuclass =3D ["1,2:foo", "0,3:bar"]

we need to decide what "foo" and "bar" are at the xl and libxl level,
and whether they are the same all the way down to Xen (and if not,
what's the mapping).

We also said it would be nice to support:

=C2=A0xl cpupool-split --feature=3Dfoobar

and hence we also need to decide what's foobar, whether it is in the
same namespace of foo and bar (i.e., it can be foobar=3D=3Dfoo, or
foobar=3D=3Dbar, etc), or it is something else, or both.

Can someone list what are the various alternative approaches on the
table?

Regards,
Dario
--=C2=A0
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
--=-0bIcUa/JX6xqmT2K6JuT
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

iQIcBAABCAAGBQJX5S/5AAoJEBZCeImluHPuivcQAMXN6Injf0BsNtaw944Bt6yD
UPLFyoN9h0R/QNf2HRTvL276IQwSGjlPWXu4Sn0ajY4PN6sJNwLUbDLV2vhmT4Qy
MMxe9jBsaUt3dqsnF6pYXTQPKCJAjPLU/R0E9Cl/r2LoB+/Os7vr+hulxbKrPYzU
uAPApKv5voxXuljAeRimNZm16XVkYPWXZMLssvKBbmTgmTt71xKaHY8WRdU1iZL7
2cUkgeXQ9jJqpRioUY7q9phCVlfgWF0An1mwx0seLzRjBcAsfB89LqIJ4jPbyMaU
toVoywlrt9j9tBP364BURR4MXeXcmVrDNSpSoG9M5qldr8YwonKv45U8Jp6lJ6+u
AOOwtH+bNDksWpPX9xGO4JKtUkZ0n4IsJns/OPL9T++KMCQEOY1zf4+2kEVhcFrW
wLS0aFOB33x8cwkwVDaSJvrO/r0dUOD6tOlv9Tc8eIQ9UrTsoqrYFRrusHJAmANh
6NogC8/BWGT73B+4FjpDs1uoaqfPwrbvW7Hy9+dxRjEWxiVVnWVFvZsWnlkTkSEs
LhcaK/euP1hEtSaFS6h6KXRjBRR9nyZTyod63aD8LRsLRX7rsqWDEYGXcvReWU2d
R9HBCwrySonLhwwVagb13QEuXn2wzaObalD+MFmVdBnpTInUE375+9GqT4p3JqOm
RVRLZ1+YvceOpZsYQNJX
=x8H6
-----END PGP SIGNATURE-----

--=-0bIcUa/JX6xqmT2K6JuT--


--===============9160042177620402243==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

--===============9160042177620402243==--