On Fri, Apr 12, 2013 at 4:45 PM, Stefan Hajnoczi <stefa...@gmail.com> 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 <stefa...@gmail.com> wrote: >> > On Mon, Apr 01, 2013 at 04:20:33PM +0800, Liu Ping Fan wrote: >> >> From: Liu Ping Fan <pingf...@linux.vnet.ibm.com> >> >> >> >> 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. > 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. > Stefan
