From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9DEh-0008IS-Kh for qemu-devel@nongnu.org; Wed, 05 Sep 2012 06:53:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9DEg-0001cB-Ko for qemu-devel@nongnu.org; Wed, 05 Sep 2012 06:53:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9DEg-0001c7-BF for qemu-devel@nongnu.org; Wed, 05 Sep 2012 06:53:30 -0400 Message-ID: <50472F23.2080702@redhat.com> Date: Wed, 05 Sep 2012 13:53:23 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1345801763-24227-1-git-send-email-qemulist@gmail.com> <503BB9C5.3030605@siemens.com> <503BBA77.4090006@redhat.com> <503BBED4.9050705@siemens.com> <503BC1EE.4060608@redhat.com> <503BCCA1.10403@siemens.com> <503C9275.5040105@siemens.com> <503E4FF4.7060506@redhat.com> <503E51BB.9070308@siemens.com> <503E5422.5050805@redhat.com> <503F1172.70103@siemens.com> <5041CB73.4050800@redhat.com> <50446FD9.3040805@redhat.com> <504720F8.9020104@redhat.com> <50472B3B.4090401@siemens.com> In-Reply-To: <50472B3B.4090401@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 09/05/2012 01:36 PM, Jan Kiszka wrote: >> >> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a >> corresponding unref), which has the following requirements: >> >> - if the refcount is nonzero, MemoryRegion::opaque is safe to use >> - if the refcount is nonzero, the MemoryRegion itself is stable. > > The second point means that the memory subsystem will cache the region > state and apply changes only after leaving a handler that performed them? No. I/O callbacks may be called after a region has been disabled. I guess we can restrict this to converted regions, so we don't introduce regressions. >> As outlined above, I now prefer MemoryRegionOps::ref/unref. >> >> Advantages compared to MemoryRegionOps::object(): >> - decoupled from the QOM framework >> >> Disadvantages: >> - more boilerplate code in converted devices >> >> Since we are likely to convert few devices to lockless dispatch, I >> believe the tradeoff is justified. But let's hear Jan and the others. > > I still need to dig into related posts of the past days, lost track, but > the above sounds much better. > > Besides the question of what to protect and how, one important thing > IMHO is that we are able to switch locking behaviour on a per region > basis. And that should also be feasible this way. It was also possible with MemoryRegionOps::object() - no one said all regions for a device have to refer to the same object (and there is a difference between locking and reference counting, each callback could take a different lock). But it is more natural with MemoryRegionOps::ref(). -- error compiling committee.c: too many arguments to function