From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxAyt-0000mH-E2 for qemu-devel@nongnu.org; Tue, 26 May 2015 05:17:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxAyk-0005Nc-BB for qemu-devel@nongnu.org; Tue, 26 May 2015 05:17:03 -0400 Message-ID: <55643A00.8080309@redhat.com> Date: Tue, 26 May 2015 11:16:48 +0200 From: Paolo Bonzini 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> <55643662.9030005@suse.de> In-Reply-To: <55643662.9030005@suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Alexander Graf , David Gibson , Alexey Kardashevskiy Cc: Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, =?windows-1252?Q?Andreas_F=E4?= =?windows-1252?Q?rber?= , Michael Roth On 26/05/2015 11:01, Alexander Graf wrote: >>> So, the sentences after that one note an exception for alias and=20 >>> >> container regions. I think iommu regions should behave similarly >>> >> - in a sense they're just a procedurally generated collection of=20 >>> >> alias regions. >> >=20 >> > The difference is that containers and aliases are resolved at the ti= me >> > the memory region tree is flattened, while IOMMU regions are resolve= d >> > at run time. > Can you please go into more detail here? What part exactly gets resolve= d > at run time? We don't flatten the memory regions for IOMMU accesses? The IOMMU is a single huge region in the FlatView, which then is forwarded to another AddressSpace. > But even if we walk the regions rather than the flattened tree, I don't > see how we could end up with races when removing a device. The problem is that there is no guarantee that the MemoryRegion dies immediately after object_unparent. In fact it will wait at least one RCU grace period, because the (RCU-protected) FlatViews hold a reference to the device via memory_region_ref. There is a very simple (in theory) solution: create the memory region via object_new instead of object_initialize, using a MemoryRegion* instead of embedding the MemoryRegion directly. But I'm not sure how to do that without duplicating the whole memory_region_init set of APIs. Perhaps Andreas has an idea of how to improve the QOM object creation API= ? Paolo