Re: [Qemu-devel] [RFC v1 1/2] arm: Add the cortex-a9 CPU to the a9mpcore device

[Alistair Francis]

On Tue, Jun 17, 2014 at 8:12 PM, Peter Crosthwaite
<address@hidden> wrote:
> On Tue, Jun 17, 2014 at 6:05 PM, Paolo Bonzini <address@hidden> wrote:
>> Il 17/06/2014 09:16, Stefan Hajnoczi ha scritto:
>>
>>> > The bigger issue though is how do you do an N:1 mapping. The container
>>> > should only have 1 "midr" prop, but it should mirror to all contained
>>> > CPUs. Should we add multiplicity to the aliasing feature?
>>>
>>> If we'll need 1:N alias properties in other places too.
>
> Well A15 MPCore is the obvious one. Any homogeneous n-way container
> that wants to forward props could make use of this.
>
>>
>>
>> I think in the case it's the contained object that should look for a midr
>> property in the parent, and possibly create an alias to the parent's midr
>> property.
>>
>
> This sounds too difficult to me. How do you define whether a contained
> object is allowed to go looking into a parent for suitable aliasing
> oppurtunities without container level knowledge?
>
> The contained object should also be able to create it's property
> regularly in cases where the parent does not provide an aliasable
> which adds some ugly iffery to the contained's init fn.
>
> Ultimately I think the container should remain in full control and do
> the 1:N aliasing in a loop when appropriate.

I agree, the container should have the responsibility of passing
properties through.

I submitted a v2 of the RFC which does just that (the MPcore container passes
through the midr and reset-cbar properties)

>
> And some further food for thought, if we throw Andreas' heterogenous
> MPCore idea (one of the tangent topics on this thread) in the mix, a
> container will want to potentially alias the same property on two
> different children to two different props on the child. The child
> simply cannot handle this without knowing too much about it's
> container.
>
> Regards,
> Peter
>
>> Paolo
>>
>