From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59187)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <shlomopongratz@gmail.com>) id 1YvTCp-0008WK-Ji
	for qemu-devel@nongnu.org; Thu, 21 May 2015 12:20:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <shlomopongratz@gmail.com>) id 1YvTCo-0004Vs-FW
	for qemu-devel@nongnu.org; Thu, 21 May 2015 12:20:23 -0400
Received: from mail-yh0-x232.google.com ([2607:f8b0:4002:c01::232]:33640)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <shlomopongratz@gmail.com>) id 1YvTCo-0004Vk-9m
	for qemu-devel@nongnu.org; Thu, 21 May 2015 12:20:22 -0400
Received: by yhcb70 with SMTP id b70so22384470yhc.0
	for <qemu-devel@nongnu.org>; Thu, 21 May 2015 09:20:21 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <000601d093de$79adf210$6d09d630$@samsung.com>
References: <1430921082-16779-1-git-send-email-shlomopongratz@gmail.com>
	<1430921082-16779-2-git-send-email-shlomopongratz@gmail.com>
	<000601d093de$79adf210$6d09d630$@samsung.com>
Date: Thu, 21 May 2015 19:20:21 +0300
Message-ID: <CAHzK-V1MW0ANyffqnHkZ=r_V2A61+Bjcya9nVXvjci=5miSQUQ@mail.gmail.com>
From: Shlomo Pongratz <shlomopongratz@gmail.com>
Content-Type: multipart/alternative; boundary=001a11330868922a10051699ebe5
Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1 with mpidr
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Ashok Kumar <ashoks@broadcom.com>, Shlomo Pongratz <shlomo.pongratz@huawei.com>

--001a11330868922a10051699ebe5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, May 21, 2015, Pavel Fedin <p.fedin@samsung.com> wrote:

>  Hello!
>
> > In order to support up to 128 cores with GIC-500 (GICv3 implementation)
> > affinity1 must be used. GIC-500 support up to 32 clusters with up to
> > 8 cores in a cluster. So for example, if one wishes to have 16 cores,
> > the options are: 2 clusters of 8 cores each, 4 clusters with 4 cores ea=
ch
>
>  I have found one more concern. Are you really sure about this scheme ? I
> am currently
> experimenting with KVM, and it seems to have 16 CPUs per cluster, at leas=
t
> on my machine.
> Actually i suggest that KVM inherits the mapping from the host. Can we do
> the same?
>  I will take a look at kvmtool, how it determines these IDs. But hardcode=
d
> scheme is
> definitely wrong.
>
>  Cc'ed Ashok because he might also be interested.
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
> Hi Pavel,

I can only quote from GIC-500 document (
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0516b/DDI0516B_gic5000_=
r0p0_trm.pdf)
which is currently the only GICv3 implementation) I'll recheck the GICv3
when I'll return to work on Monday.

>>From section 1.3 features.

The GIC-500 provides registers for managing interrupt sources, interrupt
behavior, and interrupt
routing to one or more cores. It supports:
=E2=80=A2 Multiprocessor environments with up to 128 cores.
=E2=80=A2 Up to 32 affinity-level 1 clusters.
=E2=80=A2 Up to eight cores for each cluster.

I guess your hardware uses different GIC.

Best regards,

S.P.

--001a11330868922a10051699ebe5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>On Thursday, May 21, 2015, Pavel Fedin &lt;<a href=3D"mailto:p.fedin@sa=
msung.com">p.fedin@samsung.com</a>&gt; wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">=C2=A0Hello!<br>
<br>
&gt; In order to support up to 128 cores with GIC-500 (GICv3 implementation=
)<br>
&gt; affinity1 must be used. GIC-500 support up to 32 clusters with up to<b=
r>
&gt; 8 cores in a cluster. So for example, if one wishes to have 16 cores,<=
br>
&gt; the options are: 2 clusters of 8 cores each, 4 clusters with 4 cores e=
ach<br>
<br>
=C2=A0I have found one more concern. Are you really sure about this scheme =
? I am currently<br>
experimenting with KVM, and it seems to have 16 CPUs per cluster, at least =
on my machine.<br>
Actually i suggest that KVM inherits the mapping from the host. Can we do t=
he same?<br>
=C2=A0I will take a look at kvmtool, how it determines these IDs. But hardc=
oded scheme is<br>
definitely wrong.<br>
<br>
=C2=A0Cc&#39;ed Ashok because he might also be interested.<br>
<br>
Kind regards,<br>
Pavel Fedin<br>
Expert Engineer<br>
Samsung Electronics Research center Russia<br><br></blockquote><div>Hi Pave=
l,</div><div><br></div><div>I can only quote from GIC-500 document (<a href=
=3D"http://infocenter.arm.com/help/topic/com.arm.doc.ddi0516b/DDI0516B_gic5=
000_r0p0_trm.pdf">http://infocenter.arm.com/help/topic/com.arm.doc.ddi0516b=
/DDI0516B_gic5000_r0p0_trm.pdf</a>) which is currently the only GICv3 imple=
mentation) I&#39;ll recheck the GICv3 when I&#39;ll return to work on Monda=
y.</div><div><br></div><div>From section 1.3 features.</div><div><br></div>=
<div><div>The GIC-500 provides registers for managing interrupt sources, in=
terrupt behavior, and interrupt</div><div>routing to one or more cores. It =
supports:</div><div>=E2=80=A2 Multiprocessor environments with up to 128 co=
res.</div><div>=E2=80=A2 Up to 32 affinity-level 1 clusters.</div><div>=E2=
=80=A2 Up to eight cores for each cluster.</div></div><div><br></div><div>I=
 guess your hardware uses different GIC.</div><div><br></div><div>Best rega=
rds,</div><div><br></div><div>S.P.</div>

--001a11330868922a10051699ebe5--