Re: [Qemu-devel] [PATCH v8 1/5] Implement GIC-500 base class

[Peter Maydell]

On 11 August 2015 at 08:53, Pavel Fedin <address@hidden> wrote:
>> > +#define GICV3_NCPU 64
>>
>> What is imposing this NCPU limit?
>
>  Currently qemu does not support Aff2 field. Can we have more
> than 64 CPUs only with Aff0 and Aff1?

The GIC code itself doesn't care, so it shouldn't be imposing
its own limit, even if other parts of the code do for now.

>  Well, if you really-really insist, i can just raise it to 128

...and where does 128 come from?

> and stop it finally. It's actually Shlomo's heritage, and i believe
> his SW emulation will decrease this down to 64 again.

No it won't, because "don't impose an arbitrary 64 bit limit"
was one of my review comments on the emulation code; that
will need to be fixed before the emulation code can be accepted.

> It can be changed at any moment, i don't see any serious obstacles
> for it. You ask this question for the 3rd time IIRC, and i answer
> the same thing for the 3rd time.

Yes, if you don't make changes that I think are needed then I'll
continue to point them out in future review rounds...

Part of the aim of the GICv3 code is to not have an arbitrary
limit on the number of vcpus we can have. In the GICv2 code
we have a #define for the maximum number of CPUs, because the
GICv2 architecture itself sets that maximum. For GICv3 I don't
want to bake an arbitrary limit into the code if it's not a
limit imposed by the GICv3 architecture.

>> > +    qemu_irq parent_irq[GICV3_NCPU];
>> > +    qemu_irq parent_fiq[GICV3_NCPU];
>>
>> We should be allocating memory for the right number of irqs
>> and fiqs based on the number of actual CPUs, because we don't
>> really want a compile-time arbitrary limit on NCPUs.
>
>  These arrays are just placeholders, so we reserve the maximum
> possible space for them. When we initialize the actual objects,
> of course we use only 'num_cpu' slots in each of the array.
>  sizeof(qemu_irq) is rather small (IIRC it's a pointer accompanied
> by number). Does it worth g_malloc()ing them dynamically?

It's not the memory usage so much as that if NCPU isn't a
compile time constant you can't have them be plain arrays.

-- PMM