Hello!
> the input parameter i.e. CPUARMState doesn't has the #cores-in-soc nor any
> other useful
> information. We can add this field and initialize it in virt.c
Why does it have to be a part of CPUARMState ? Isn't it a global parameter?
> on x86 APIC ID used to be derived for cpu_index as
.mayd...@linaro.org; Shlomo Pongratz
> > Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1 with mpidr
> >
> > On Wed, 6 May 2015 17:04:39 +0300
> > shlomopongr...@gmail.com wrote:
> >
> > > From: Shlomo Pongratz
> > >
> > > In order to s
emu-devel@nongnu.org;
> > peter.mayd...@linaro.org
> > Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1 with mpidr
> >
> > On Thu, 28 May 2015 07:23:55 +
> > Shlomo Pongratz wrote:
> >
> > >
> > >
> > > > -Original
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Wednesday, 27 May, 2015 7:12 PM
> To: shlomopongr...@gmail.com
> Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org; Shlomo Pongratz
> Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1
Hello!
> In helpr.c:mpidr_read we calculate aff0 & aff1 from cs->cpu_index in the
> same way but
AFAIK
> the input parameter i.e. CPUARMState doesn't has the #cores-in-soc nor any
> other useful
> information. We can add this field and initialize it in virt.c but then we
> need to touch
all o
gt; > To: shlomopongr...@gmail.com
> > > Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org; Shlomo
> Pongratz
> > > Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1 with mpidr
> > >
> > > On Wed, 6 May 2015 17:04:39 +0300
> > > shlomopongr
.mayd...@linaro.org; Shlomo Pongratz
> > Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1 with mpidr
> >
> > On Wed, 6 May 2015 17:04:39 +0300
> > shlomopongr...@gmail.com wrote:
> >
> > > From: Shlomo Pongratz
> > >
> > > In order
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Wednesday, 27 May, 2015 7:12 PM
> To: shlomopongr...@gmail.com
> Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org; Shlomo Pongratz
> Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1
Hi!
> IIUC, your implementation also uses 8 cpus per cluster which is not
> consistent with CPU spec.
Yes, i have inherited the value from Shlomo's implementation. To tell the
truth i don't
have time to read through all the docs. And i don't know in which PDF i should
look for
this info. But,
On 2015/5/28 2:03, Pavel Fedin wrote:
> Hello!
>
>> I think encoding should be CPU type specific i.e. not defined by what
>> GIC can support and once we add CPU type with 8 cores, it would provide
>> it's own version of mpidr_read since it would be defined by spec
>> how to encode aff0.
>
> I
Hello!
> I think encoding should be CPU type specific i.e. not defined by what
> GIC can support and once we add CPU type with 8 cores, it would provide
> it's own version of mpidr_read since it would be defined by spec
> how to encode aff0.
I have redone this thing from scratch:
https://lists.
On Wed, 6 May 2015 17:04:39 +0300
shlomopongr...@gmail.com wrote:
> From: Shlomo Pongratz
>
> In order to support up to 128 cores with GIC-500 (GICv3 implementation)
> affinity1 must be used. GIC-500 support up to 32 clusters with up to
> 8 cores in a cluster. So for example, if one wishes to h
On Friday, May 22, 2015, Pavel Fedin wrote:
> Hello!
>
> > The GIC-500 provides registers for managing interrupt sources, interrupt
> behavior, and interrupt
> > routing to one or more cores. It supports:
> > • Multiprocessor environments with up to 128 cores.
> > • Up to 32 affinity-level 1 clu
Hello!
> The GIC-500 provides registers for managing interrupt sources, interrupt
> behavior, and interrupt
> routing to one or more cores. It supports:
> • Multiprocessor environments with up to 128 cores.
> • Up to 32 affinity-level 1 clusters.
> • Up to eight cores for each cluster.
> I gues
On Thursday, May 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > In order to support up to 128 cores with GIC-500 (GICv3 implementation)
> > affinity1 must be used. GIC-500 support up to 32 clusters with up to
> > 8 cores in a cluster. So for example, if one wishes to have 16 cores,
> > the options
Hello!
> In order to support up to 128 cores with GIC-500 (GICv3 implementation)
> affinity1 must be used. GIC-500 support up to 32 clusters with up to
> 8 cores in 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 ea
From: Shlomo Pongratz
In order to support up to 128 cores with GIC-500 (GICv3 implementation)
affinity1 must be used. GIC-500 support up to 32 clusters with up to
8 cores in 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 c
17 matches
Mail list logo
