[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: Shlomo Pongratz
Subject: Re: [Qemu-devel] [PATCH RFC] Implement GIC-500 from GICv3 family for arm64
Date: Tue, 10 Mar 2015 11:47:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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,

This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.

reply via email to

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