Re: [Qemu-devel] [Qemu-arm] object owner argument of memory_region_init_ram

[Peter Maydell]

On Wed, 23 Jan 2019 at 06:10, Thomas Huth <address@hidden> wrote:
> On 2019-01-23 04:07, ksourav wrote:
> > I am trying to learn how qemu implements different soc.
> > While reading the source code, I found that in some socs, object owner
> > is passed as NULL to the routine memory_region_init_ram() (for example
> > in nrf51 soc) and in some socs(for example in Allwinner A10) an
> > object(non NULL) is passed to memory_region_initi_ram().
> > When I checked docs/devel/memory.txt, I found below lines.
> > "For regions that "have no owner" (NULL is passed at creation time), the
> > machine object is actually used as the owner."
> > Is the machine object refers to the actual board instance that will
> > use the soc? For example microbit in case of nrf51 soc ?
> > Is there any reason of not passing object as owner or in other words,
> > when do we pass NULL or an object to memory_region_initi_ram() ?
>
> I'm not an expert here, but when you look at the description of
> memory_region_init_ram() in include/exec/memory.h:
>
>  * @owner: the object that tracks the region's reference count (must be
>  *         TYPE_DEVICE or a subclass of TYPE_DEVICE, or NULL)
>
> So if you're calling memory_region_init_ram() from a device's
> instance_init() or realize() function, you should use the current device
> state as owner. But if you want to call the function from a
> MachineClass->init function instead already, you don't have a
> DeviceState* yet, so you have to use NULL there.

Yes. Also old-style boards which don't use MachineState directly
will pass a NULL owner, as will very old non-QOM devices, and
probably one or two devices with bugs. Don't copy those examples :-)
(the nrf51_soc you mention above is an example of a bug.)

The reason the owner matters here is so we clean things up correctly
when the device goes away. So for a machine model it doesn't matter
because the machine is never destroyed. For an SoC, that is also
typically never destroyed and so bugs where the owner was not set
easily go unnoticed. But there is a corner case where the user can
introspect an object, which causes a temporary copy to go through
instance_init, which can result in leaks if ownership is wrong.

We really need to make sure we have a good grasp of this kind of
thing and write it up somewhere (in particular the object life cycle,
what can or should be done in instance_init, how things need to
be parented to ensure there are no leaks, etc.)

thanks
-- PMM