From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US0mD-0006vX-5y for qemu-devel@nongnu.org; Tue, 16 Apr 2013 03:58:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1US0m7-0002VY-Ms for qemu-devel@nongnu.org; Tue, 16 Apr 2013 03:58:05 -0400 Received: from mail-we0-x22d.google.com ([2a00:1450:400c:c03::22d]:59657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US0m7-0002VH-Gz for qemu-devel@nongnu.org; Tue, 16 Apr 2013 03:57:59 -0400 Received: by mail-we0-f173.google.com with SMTP id t57so139917wey.18 for ; Tue, 16 Apr 2013 00:57:58 -0700 (PDT) Date: Tue, 16 Apr 2013 09:57:55 +0200 From: Stefan Hajnoczi Message-ID: <20130416075755.GB6308@stefanha-thinkpad.redhat.com> References: <1364804434-7980-1-git-send-email-qemulist@gmail.com> <1364804434-7980-5-git-send-email-qemulist@gmail.com> <20130411102032.GE9165@stefanha-thinkpad.redhat.com> <20130412084520.GE31055@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 4/5] virtio-blk: release reference to RAM's memoryRegion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Peter Maydell , Anthony Liguori , Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, Vasilis Liaskovitis , Paolo Bonzini On Fri, Apr 12, 2013 at 05:05:41PM +0800, liu ping fan wrote: > On Fri, Apr 12, 2013 at 4:45 PM, Stefan Hajnoczi wrote: > > On Fri, Apr 12, 2013 at 12:48:12PM +0800, liu ping fan wrote: > >> On Thu, Apr 11, 2013 at 6:20 PM, Stefan Hajnoczi wrote: > >> > On Mon, Apr 01, 2013 at 04:20:33PM +0800, Liu Ping Fan wrote: > >> >> From: Liu Ping Fan > >> >> > >> >> virtio-blk will reference to RAM's memoryRegion when the req has been > >> >> done. So we can avoid to call bdrv_drain_all() when RAM hot unplug. > >> > > >> > How does the hot unplug operation work without bdrv_drain_all()? In > >> > other words, how do we safely remove a MemoryRegion and wait for it to > >> > become unreferenced? > >> > > >> bdrv_drain_all() forces the end of usage of memoryRegion. But we can > >> let the req done callback ( marks this req finish the end of usage of > >> mr) to release the refcnt of memoryRegion. > > > > Yes. What I'm interested in is the wait mechanism for the QEMU thread > > to wait until the memory region(s) become unreferenced. > > > > This patch series is only one half of the memory unplug puzzle and I'd > > like to understand how the other half - the unplug operation - will be > > implemented. > > > The unplug patch is still under developed, more detail please refer to > Vasilis Liaskovitis's patches: > http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg02693.html > > > Just a summary would be interesting - especially how a QEMU thread will > > wait until memory regions have been released. The reference counter > > doesn't have any notification that would allow a blocking wait. > > > Sorry, not understand "a blocking wait". To summary, when > initializing, RamDevice's refcnt == 1, and unplug will release this > one. Meanwhile, all the MemoryListeners which are async with unplug, > will inc refcnt to against the unplug event. Okay, thanks for the summary. I don't need to see patches, I just want to understand how the changes implemented in this series will be used. > > Then you have the RCU concept. So maybe the unplug operation will not > > block but instead be called several times from the event loop until all > > references have been released? > > > As mentioned above, unplug will put its own refcnt. And unplug will not block. So it sounds like unplug will not block and there is no guarantee the memory is actually unplugged when the monitor command completes. The memory region is only released when the last reference count holder lets go. This means that pending I/O to a hung NFS mount can delay the actual unplug for unbounded time (by default the kernel NFS client keeps retrying and does not fail the I/O request). The user will be able to issue additional monitor commands and see that memory is not yet unplugged? Stefan