* [Qemu-devel] object owner argument of memory_region_init_ram @ 2019-01-23 3:07 ksourav 2019-01-23 6:10 ` Thomas Huth 0 siblings, 1 reply; 5+ messages in thread From: ksourav @ 2019-01-23 3:07 UTC (permalink / raw) To: qemu-devel Hi All, 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() ? Thanks & Regards kumar sourav ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] object owner argument of memory_region_init_ram 2019-01-23 3:07 [Qemu-devel] object owner argument of memory_region_init_ram ksourav @ 2019-01-23 6:10 ` Thomas Huth 2019-01-23 10:53 ` [Qemu-devel] [Qemu-arm] " Peter Maydell 0 siblings, 1 reply; 5+ messages in thread From: Thomas Huth @ 2019-01-23 6:10 UTC (permalink / raw) To: ksourav, qemu-devel; +Cc: qemu-arm On 2019-01-23 04:07, ksourav wrote: > Hi All, > > 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. HTH, Thomas ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [Qemu-arm] object owner argument of memory_region_init_ram 2019-01-23 6:10 ` Thomas Huth @ 2019-01-23 10:53 ` Peter Maydell 2019-01-23 15:50 ` ksourav 0 siblings, 1 reply; 5+ messages in thread From: Peter Maydell @ 2019-01-23 10:53 UTC (permalink / raw) To: Thomas Huth; +Cc: ksourav, QEMU Developers, qemu-arm On Wed, 23 Jan 2019 at 06:10, Thomas Huth <thuth@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [Qemu-arm] object owner argument of memory_region_init_ram 2019-01-23 10:53 ` [Qemu-devel] [Qemu-arm] " Peter Maydell @ 2019-01-23 15:50 ` ksourav 2019-01-25 12:40 ` Thomas Huth 0 siblings, 1 reply; 5+ messages in thread From: ksourav @ 2019-01-23 15:50 UTC (permalink / raw) To: Peter Maydell; +Cc: Thomas Huth, QEMU Developers, qemu-arm Thanks for the reply. Should I send patches for socs using NULL owner to qemu-trivial@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.maydell@linaro.org> wrote: > > On Wed, 23 Jan 2019 at 06:10, Thomas Huth <thuth@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [Qemu-arm] object owner argument of memory_region_init_ram 2019-01-23 15:50 ` ksourav @ 2019-01-25 12:40 ` Thomas Huth 0 siblings, 0 replies; 5+ messages in thread From: Thomas Huth @ 2019-01-25 12:40 UTC (permalink / raw) To: ksourav, Peter Maydell; +Cc: qemu-arm, QEMU Developers On 2019-01-23 16:50, ksourav wrote: > Thanks for the reply. > Should I send patches for socs using NULL owner to qemu-trivial@nongnu.org ? Sure, but please also CC: qemu-arm@nongnu.org for ARM-related patches. > 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 ? We certainly lack documentation here. Studying the available sources is likely the best thing you can do. There were also a couple of presentations about QOM and qdev during the various KVM Forums (see https://www.linux-kvm.org/page/KVM_Forum for example), but they are likely not quite up to date anymore. Thomas ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-01-25 12:54 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-01-23 3:07 [Qemu-devel] object owner argument of memory_region_init_ram ksourav 2019-01-23 6:10 ` Thomas Huth 2019-01-23 10:53 ` [Qemu-devel] [Qemu-arm] " Peter Maydell 2019-01-23 15:50 ` ksourav 2019-01-25 12:40 ` Thomas Huth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).