From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T66K2-0006Zi-Em for qemu-devel@nongnu.org; Mon, 27 Aug 2012 16:54:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T66K1-00013h-DY for qemu-devel@nongnu.org; Mon, 27 Aug 2012 16:54:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T66Jx-00013L-W4 for qemu-devel@nongnu.org; Mon, 27 Aug 2012 16:54:09 -0400 Message-ID: <503BDE63.7090602@redhat.com> Date: Mon, 27 Aug 2012 13:53:55 -0700 From: Avi Kivity MIME-Version: 1.0 References: <1345801763-24227-1-git-send-email-qemulist@gmail.com> <1345801763-24227-11-git-send-email-qemulist@gmail.com> <503792F1.4090109@redhat.com> <503B1B4B.6050108@redhat.com> <503B260E.70607@web.de> <503BA9BC.5010207@redhat.com> <503BAAF0.2020103@siemens.com> <503BB7E7.4050709@redhat.com> <503BB9C5.3030605@siemens.com> <503BBA77.4090006@redhat.com> <503BBED4.9050705@siemens.com> <503BC1EE.4060608@redhat.com> <503BCCA1.10403@siemens.com> In-Reply-To: <503BCCA1.10403@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , Liu Ping Fan , liu ping fan , Anthony Liguori , "qemu-devel@nongnu.org" On 08/27/2012 12:38 PM, Jan Kiszka wrote: > >> Even worse, apply > >> restrictions on how the dispatched objects, the regions, have to be > >> treated because of this. > > > > Please elaborate. > > The fact that you can't manipulate a memory region object arbitrarily > after removing it from the mapping because you track the references to > the object that the region points to, not the region itself. The region > remains in use by the dispatching layer and potentially the called > device, even after deregistration. That object will be a container_of() the region, usually literally but sometimes only in spirit. Reference counting the regions means they cannot be embedded into other objects any more. We can probably figure out a way to flush out accesses. After switching to rcu, for example, all we need is synchronize_rcu() in a non-deadlocking place. But my bet is that it will not be needed. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.