From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0TmC-0001VI-2Z for qemu-devel@nongnu.org; Sun, 12 Aug 2012 04:44:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0TmA-000364-SH for qemu-devel@nongnu.org; Sun, 12 Aug 2012 04:43:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0TmA-00035t-KD for qemu-devel@nongnu.org; Sun, 12 Aug 2012 04:43:58 -0400 Message-ID: <50276CC4.6040201@redhat.com> Date: Sun, 12 Aug 2012 11:43:48 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-7-git-send-email-qemulist@gmail.com> <50222F54.4080108@redhat.com> <5023771F.5030007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/15] memory: use refcnt to manage MemoryRegion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: kvm@vger.kernel.org, Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Stefan Hajnoczi , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 08/10/2012 09:44 AM, liu ping fan wrote: >>> In the previous discussion, you have suggest add dev->ref++ in >>> core_region_add. But I think, if we can move it to higher layer -- >>> memory_region_{add,del}_subregion, so we can avoid to duplicate do >>> this in other xx_region_add. >> >> Why would other memory listeners be impacted? They all operate under >> the big qemu lock. If they start using devices outside the lock, then >> they need to take a reference. >> > Yes, if unplug path in the protection of big lock. > And just one extra question, for ram-unplug scene, how do we protect from: > updater: ram-unplug -->qemu free() --> brk() invalidate this vaddr interval > reader: vhost-thread copy data from the interval > I guess something like lock/ref used by them, but can not find such > mechanism in vhost_set_memory() to protect the scene against > vhost_worker() VHOST_SET_MEM_TABLE uses synchronize_srcu() to ensure no readers are active before returning. -- error compiling committee.c: too many arguments to function