Re: [Qemu-devel] [PATCH memory v3 0/9] Memory Region QOMification

[Peter Maydell <peter.maydell@linaro.org>]

On 2 June 2014 05:13, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> This patch series QOMifies Memory regions. This is the Memory API
> specific subset of patches forming part of the Memory/GPIO/Sysbus
> QOMification.
>
> I think Paolo already has P1 enqeued. Including for ease of review.
> some QOM patches in P2-3 that cut down on later boilerplate. TBH I can
> live without them, if they not liked but they make life better IMO.
>
> For fuller context please see:
>
> http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03265.html

So could you sketch an example of how this would work
(for board model construction, not command line arguments)?
I'm guessing something like:
   dev = qdev_create(NULL, "my-device");
   object_property_set_something(OBJECT(dev), "container", my_memregion);
   object_property_set_uint64(OBJECT(dev), "addr", 0x40000);
   qdev_init_nofail(dev);

Code wise it looks OK but it feels oddly back-to-front to
put a subregion into a container by setting properties on
the subregion. At least personally I think of the mapping
operation as an operation on the container that says "put
this object X in at address Y", not as an operation on
the object X that says "your container is C and you're
at address Y in it". But I can see how this approach
pretty much falls out of our current MemoryRegion data
structure, so perhaps I just need to reverse the
orientation of my brain...

(Also it doesn't make sense to set only one of the
(container,address) property pair, but I guess two
properties which we can already handle makes more sense
than having one which would need a custom parser of some
kind.)

The other question is how you see this fitting into our
other use-case for passing MemoryRegions around: what
would the code for passing a container region to a
memory transaction source like a CPU object look like?

thanks
-- PMM