On Tue, Jun 17, 2014 at 8:12 PM, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > On Tue, Jun 17, 2014 at 6:05 PM, Paolo Bonzini <pbonz...@redhat.com> 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 >> >
