All of lore.kernel.org
 help / color / mirror / Atom feed
* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.