From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxEuf-0008OF-8N for qemu-devel@nongnu.org; Tue, 26 May 2015 09:28:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxEua-0000eM-Hm for qemu-devel@nongnu.org; Tue, 26 May 2015 09:28:57 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:35267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxEua-0000dv-BX for qemu-devel@nongnu.org; Tue, 26 May 2015 09:28:52 -0400 Received: by pacwv17 with SMTP id wv17so92902038pac.2 for ; Tue, 26 May 2015 06:28:51 -0700 (PDT) Message-ID: <5564750C.8000100@ozlabs.ru> Date: Tue, 26 May 2015 23:28:44 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1429964684-23872-1-git-send-email-aik@ozlabs.ru> <1429964684-23872-7-git-send-email-aik@ozlabs.ru> <55633A54.8080807@ozlabs.ru> <20150526024628.GA30620@voom.redhat.com> <5564359A.2070009@redhat.com> <556447BB.9000802@ozlabs.ru> <55644819.3000003@redhat.com> <55646803.8040007@ozlabs.ru> <55646C18.4000303@redhat.com> In-Reply-To: <55646C18.4000303@redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , David Gibson Cc: Michael Roth , Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf On 05/26/2015 10:50 PM, Paolo Bonzini wrote: > > > On 26/05/2015 14:33, Alexey Kardashevskiy wrote: >> >>>>> If it's not true now that they can be unparented at any time like >>>>> alias regions, we should probably try to make it true. >>>> >>>> Unfortunately it's not so easy... >> >> >> Uff. Tricky :) >> >> memory_region_del_subregion() is not unparenting but just a wrapped >> object_unref(), right? > > Right. The problematic thing to do is explicit object_unparent followed > by one of the following: > > 1) memory_region_init for the same memory region that has been unparented > > 2) g_free of some dynamically-allocated data structure that contained > the memory region. > >> But since iommu MR are resolved dynamically, the >> whole conversation we are having here now has nothing to do with my&Mike >> concern what we can and cannot do with DMA windows here. Is this correct? > > I don't understand what you're asking here, sorry. My initial concern was if I can or cannot do: memory_region_init_iommu + memory_region_add_subregion and memory_region_del_subregion + object_unref outside of init/realize/unrealize/finalize. You said I cannot do unparenting but as I am not doing this (and I just do unref()) - I am fine. That's what I meant. -- Alexey