qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QOM address space handling


From: Paolo Bonzini
Subject: Re: QOM address space handling
Date: Mon, 21 Dec 2020 20:16:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

On 21/12/20 19:54, Eduardo Habkost wrote:
On Sun, Dec 20, 2020 at 10:25:25AM +0100, Paolo Bonzini wrote:
On 18/12/20 23:32, Eduardo Habkost wrote:
Who owns the FlatView reference, exactly?

The AddressSpace.  The device creates the AddressSpace, which holds a
reference to the MemoryRegion through FlatView and AddressSpaceDispatch,
which holds a reference to the device.

By destroying the address space that it created, the device can break the
reference loop.

If the FlatView reference is owned by the MemoryRegion, we have a
reference loop: the device holds a reference to the MemoryRegion,
which owns the FlatView, which holds a reference to the device.
In this case, who owns the reference loop and is responsible for
breaking it?

The reference loop is owned by the device, which breaks it through unrealize
(called by unparent).

instance_finalize by definition cannot break reference loops, so this means
that my suggestion of using address_space_init in instance_init was wrong.

Once we fix that, I suggest we add an assertion to make it
illegal to call object_ref() on an object during instance_init.

It's not necessarily illegal. You can for example call a function that internally does

    object_ref(obj);
    oc->func(obj);
    object_unref(obj);

But perhaps we could assert that refcount == 1 on exit.

Do we know how many address_space_init() calls in instance_init
we have today?

I can see them in raven_pcihost_initfn, in sun4?_iommu.c's iommu_init and xtensa_cpu_initfn, I think that's all.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]