From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMAo5-0006Qm-VC for qemu-devel@nongnu.org; Tue, 26 Aug 2014 03:04:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMAnv-0002L8-Te for qemu-devel@nongnu.org; Tue, 26 Aug 2014 03:04:41 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:35567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMAnv-0002Kx-Np for qemu-devel@nongnu.org; Tue, 26 Aug 2014 03:04:31 -0400 Received: by mail-pa0-f42.google.com with SMTP id lf10so22781636pab.15 for ; Tue, 26 Aug 2014 00:04:31 -0700 (PDT) Message-ID: <53FC3179.6040200@ozlabs.ru> Date: Tue, 26 Aug 2014 17:04:25 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1408097555-28126-1-git-send-email-aik@ozlabs.ru> <1408097555-28126-7-git-send-email-aik@ozlabs.ru> <20140826061656.GT9923@voom.redhat.com> In-Reply-To: <20140826061656.GT9923@voom.redhat.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 06/13] spapr_iommu: Implement free_table() helper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Gavin Shan , Alexander Graf On 08/26/2014 04:16 PM, David Gibson wrote: > On Fri, Aug 15, 2014 at 08:12:28PM +1000, Alexey Kardashevskiy wrote: >> Every sPAPRTCETable object holds an IOMMU memory region which holds >> a referenced to the sPAPRTCETable instance. So if we want to free >> an sPAPRTCETable instance, calling object_unref() will not be enough >> as embedded memory region will hold the reference and we need to break >> the loop. >> >> This adds a spapr_tce_free_table() helper which destroys the embedded >> memory region and then calls object_unref() on the sPAPRTCETable instance >> which will succeed now. The helper adds a new child under unique name >> derived from LIOBN. >> >> As we are here, fix spapr_tce_new_table() callers. >> At the moment spapr_tce_new_table() references sPAPRTCETable twice - >> once in object_new() and second time in object_property_add_child(). >> The callers of spapr_tce_new_table() should take care of correct >> referencing. > > So I've been trying to determine if there's any way to avoid this by > not constructing the reference loop in the first place, but all the > qom is breaking my brain. Well. I could have added an additional object to sPAPRTCETable (just a pointer in the struct but not a QOM-child!) and use it as an owner for MemoryRegion. It would not hold reference to the table. But since I do not grasp the idea of having an owner for a MemoryRegion, this can break something which I cannot even imagine :) -- Alexey