On Mon, Dec 21, 2020 at 08:16:00PM +0100, Paolo Bonzini wrote: > 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);
Oh, right. > > But perhaps we could assert that refcount == 1 on exit. That would be more difficult to debug, but would work. > > > 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. There's usb_ehci_init() too. -- Eduardo
