From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8ow-0006oB-8z for qemu-devel@nongnu.org; Mon, 09 Mar 2015 21:18:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YV8or-00052P-13 for qemu-devel@nongnu.org; Mon, 09 Mar 2015 21:18:54 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:6898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8oq-0004zB-5r for qemu-devel@nongnu.org; Mon, 09 Mar 2015 21:18:48 -0400 Message-ID: <54FE4667.6090901@huawei.com> Date: Tue, 10 Mar 2015 09:18:31 +0800 From: Shannon Zhao 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="ISO-8859-1" Content-Transfer-Encoding: 7bit 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, "Huangpeng (Peter)" , Shlomo Pongratz On 2015/3/9 22:41, shlomo.pongratz@toganetworks.com wrote: > 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 +++++++++++++++++ Hi, I think here you want to introduce GICv3 in this patch. So is this necessary to add a new virtv2 machine? And the codes of this machine mostly are same with virt. Maybe we can add a parameter such as -GICv3 for machine virt to choose GICv3 for it and choose GICv2 without this parameter. Then we can reuse more codes. -- Thanks, Shannon