qemu-devel
[Top][All Lists]
Advanced

[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:34:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0


On 10 آذار, 2015 ص 03:18, Shannon Zhao wrote:
On 2015/3/9 22:41, address@hidden wrote:
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 +++++++++++++++++
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.

Hi Shannon,

Using a parameter and configuring the virtual machine makes the core
unreadable.
There are to many if then...else statements.

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]