On 2015/3/9 22:41, shlomo.pongr...@toganetworks.com wrote: > From: Shlomo Pongratz <shlomo.pongr...@huawei.com> > > 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 <shlomo.pongr...@toganetworks.com> > --- > 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
