[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: michael
Subject: Re: [Qemu-devel] [PATCH RFC] Implement GIC-500 from GICv3 family for arm64
Date: Tue, 10 Mar 2015 23:01:54 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015年03月10日 17:47, Shlomo Pongratz wrote:

On 10 آذار, 2015 ص 09:06, Pei XiaoYong wrote:
于 2015/3/9 22:41, address@hidden 写道:
From: Shlomo Pongratz <address@hidden>

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 <address@hidden>
  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
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 .

reply via email to

[Prev in Thread] Current Thread [Next in Thread]