Re: [Qemu-devel] [PATCH RFC] Implement GIC-500 from GICv3 family for arm64

[michael <pxy052152@126.com>]

On 2015年03月10日 17:47, Shlomo Pongratz wrote:
>
> On 10 آذار, 2015 ص 09:06, Pei XiaoYong wrote:
>> 于 2015/3/9 22:41, shlomo.pongratz@toganetworks.com 写道:
>>> From: Shlomo Pongratz <shlomo.pongratz@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.pongratz@toganetworks.com>
>>> ---
>>>   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.
>>
> Hi Peixiaoyong,
>
> My immediate goal is running more than 8 cores, so currently "its" and
> "ipi" are not supported.
> I've used the offsets' rules from GIC-500 which is an implementation of
> GICv3.
> When and if "its" and "ipi" will be implemented then I think a new virt
> machine will need to be created
> as this is like a new HW BSP with different architecture.
>
> Best regards,


Hi :
I think we should focus on the scalable of the code . On the other hand 
, we need remove the redundant code  .