Thanks for the reply. Should I send patches for socs using NULL owner to qemu-triv...@nongnu.org ?
I have been reading qemu source code for soc and different device implementation for past few days to understand qemu internals. While I have a rough idea of qemu object model, I would like to have your input. If someone has to learn about qemu object model or soc implementation, what would be the correct way ? So far I have implemented a minimal platform device and experimented with it using linux driver on qemu. But I am wondering is there any other way of doing things to develop understanding. Thanks in Advance On Wed, Jan 23, 2019 at 4:23 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Wed, 23 Jan 2019 at 06:10, Thomas Huth <th...@redhat.com> 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
