From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVEG0-0007p8-Re for qemu-devel@nongnu.org; Tue, 10 Mar 2015 03:07:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVEFu-0005nS-Uo for qemu-devel@nongnu.org; Tue, 10 Mar 2015 03:07:12 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:7870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVEFu-0005ja-5p for qemu-devel@nongnu.org; Tue, 10 Mar 2015 03:07:06 -0400 Message-ID: <54FE97E0.6020906@huawei.com> Date: Tue, 10 Mar 2015 15:06:08 +0800 From: Pei XiaoYong MIME-Version: 1.0 References: <1425912119-15681-1-git-send-email-shlomo.pongratz@toganetworks.com> In-Reply-To: <1425912119-15681-1-git-send-email-shlomo.pongratz@toganetworks.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH RFC] Implement GIC-500 from GICv3 family for arm64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: shlomo.pongratz@toganetworks.com, qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, claudio.fontana@huawei.com, Shlomo Pongratz ÓÚ 2015/3/9 22:41, shlomo.pongratz@toganetworks.com дµÀ: > From: Shlomo Pongratz > > This patch is a first step toward 128 cores support for arm64. > > At first only 64 cores are supported for two reasons: > First the largest integer type has the size of 64 bits and modifying > essential data structures in order to support 128 cores will require > the usage of bitops. > Second currently the Linux (kernel) can be configured to support > up to 64 cores thus there is no urgency with 128 cores support. > > Things left to do: > > Currently the booting Linux may got stuck. The probability of getting stuck > increases with the number of cores. I'll appreciate core review. > > There is a need to support flexible clusters size. The GIC-500 can support > up to 128 cores, up to 32 clusters and up to 8 cores is 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 each > Currently only the first option is supported. > There is an issue of passing clock affinity to via the dtb. In the dtb > > interrupt section there are only 24 bit left to affinity since the > variable is a 32 bit entity and 8 bits are reserved for flags. > See Documentation/devicetree/bindings/arm/arch_timer.txt. > Note that this issue is not seems to be critical as when checking > /proc/irq/3/smp_affinity with 32 cores all 32 bits are one. > > The last issue is to add support for 128 cores. This requires the usage > of bitops and currently can be tested up to 64 cores. > > Signed-off-by: Shlomo Pongratz > --- > hw/arm/Makefile.objs | 2 +- > hw/arm/virtv2.c | 774 +++++++++++++++++ > hw/intc/Makefile.objs | 2 + > hw/intc/arm_gic_common.c | 2 + > hw/intc/arm_gicv3.c | 1596 ++++++++++++++++++++++++++++++++++++ > hw/intc/arm_gicv3_common.c | 188 +++++ > hw/intc/gicv3_internal.h | 153 ++++ > include/hw/intc/arm_gicv3.h | 44 + > include/hw/intc/arm_gicv3_common.h | 136 +++ > target-arm/cpu.c | 1 + > target-arm/cpu.h | 6 + > target-arm/cpu64.c | 92 +++ > target-arm/helper.c | 12 +- > target-arm/psci.c | 18 +- > target-arm/translate-a64.c | 14 + > 15 files changed, 3034 insertions(+), 6 deletions(-) > create mode 100644 hw/arm/virtv2.c > create mode 100644 hw/intc/arm_gicv3.c > create mode 100644 hw/intc/arm_gicv3_common.c > create mode 100644 hw/intc/gicv3_internal.h > create mode 100644 include/hw/intc/arm_gicv3.h > create mode 100644 include/hw/intc/arm_gicv3_common.h > > > ------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > as far as we know , there are many components in gic-v3 implementation , like distributor , redistributor , its , lpi . Offsets of them is not defined in the gic-v3 specification , i think wo should implement these components independently , not like v2&v1 implementation in qemu.