From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:59202)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZP4NM-0007Wk-1o
	for qemu-devel@nongnu.org; Tue, 11 Aug 2015 03:53:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZP4NI-0002e4-R2
	for qemu-devel@nongnu.org; Tue, 11 Aug 2015 03:53:35 -0400
Received: from mailout1.w1.samsung.com ([210.118.77.11]:33879)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZP4NI-0002dl-MD
	for qemu-devel@nongnu.org; Tue, 11 Aug 2015 03:53:32 -0400
Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244])
	by mailout1.w1.samsung.com
	(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5
	2014)) with ESMTP id <0NSW00C3DR961110@mailout1.w1.samsung.com> for
	qemu-devel@nongnu.org; Tue, 11 Aug 2015 08:53:30 +0100 (BST)
From: Pavel Fedin <p.fedin@samsung.com>
References: <cover.1439207299.git.p.fedin@samsung.com>
	<c7f3e909955e510a49728b24dfcae2f5e50566df.1439207299.git.p.fedin@samsung.com>
	<CAFEAcA-c96196NwsxLBoNSdfwQgFNm0RfX4WGJ_gkPnKSNk-0w@mail.gmail.com>
In-reply-to: <CAFEAcA-c96196NwsxLBoNSdfwQgFNm0RfX4WGJ_gkPnKSNk-0w@mail.gmail.com>
Date: Tue, 11 Aug 2015 10:53:28 +0300
Message-id: <00b401d0d40a$d0125c10$70371430$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: quoted-printable
Content-language: ru
Subject: Re: [Qemu-devel] [PATCH v8 1/5] Implement GIC-500 base class
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: 'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'Shlomo Pongratz' <shlomo.pongratz@huawei.com>, 'Shlomo Pongratz' <shlomopongratz@gmail.com>, 'QEMU Developers' <qemu-devel@nongnu.org>, 'Christoffer Dall' <christoffer.dall@linaro.org>, 'Eric Auger' <eric.auger@linaro.org>

> > +#define GICV3_NCPU 64
>=20
> What is imposing this NCPU limit?

 Currently qemu does not support Aff2 field. Can we have more than 64 =
CPUs only with Aff0 and Aff1?
 Well, if you really-really insist, i can just raise it to 128 and stop =
it finally. It's actually Shlomo's heritage, and i believe his SW =
emulation will decrease this down to 64 again. It can be changed at any =
moment, i don't see any serious obstacles for it. You ask this question =
for the 3rd time IIRC, and i answer the same thing for the 3rd time. =
Does this little #define really worth it?
 Shlomo, your word?

> > +    qemu_irq parent_irq[GICV3_NCPU];
> > +    qemu_irq parent_fiq[GICV3_NCPU];
>=20
> We should be allocating memory for the right number of irqs
> and fiqs based on the number of actual CPUs, because we don't
> really want a compile-time arbitrary limit on NCPUs.

 These arrays are just placeholders, so we reserve the maximum possible =
space for them. When we initialize the actual objects, of course we use =
only 'num_cpu' slots in each of the array.
 sizeof(qemu_irq) is rather small (IIRC it's a pointer accompanied by =
number). Does it worth g_malloc()ing them dynamically?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia