qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: liu ping fan <qemulist@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org,
	Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/5] virtio-blk: release reference to RAM's memoryRegion
Date: Fri, 12 Apr 2013 10:45:20 +0200	[thread overview]
Message-ID: <20130412084520.GE31055@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <CAJnKYQ==yxc5vzaJnBoK+S4UjQvtVrvVtB8_zm_tKVXboCyxuQ@mail.gmail.com>

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 <stefanha@gmail.com> wrote:
> > On Mon, Apr 01, 2013 at 04:20:33PM +0800, Liu Ping Fan wrote:
> >> From: Liu Ping Fan <pingfank@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.

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.

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?

Stefan

  reply	other threads:[~2013-04-12  8:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01  8:20 [Qemu-devel] [PATCH 0/5] proposal to make hostmem listener RAM unplug safe Liu Ping Fan
2013-04-01  8:20 ` [Qemu-devel] [PATCH 1/5] memory: add ref/unref interface for MemroyRegionOps Liu Ping Fan
2013-04-11  9:49   ` Stefan Hajnoczi
2013-04-12  4:12     ` liu ping fan
2013-04-01  8:20 ` [Qemu-devel] [PATCH 2/5] hostmem: make hostmem global and RAM hotunplg safe Liu Ping Fan
2013-04-02  6:11   ` li guang
2013-04-11 10:09   ` Paolo Bonzini
2013-04-12  6:46     ` liu ping fan
2013-04-12  8:21       ` Stefan Hajnoczi
2013-04-11 10:11   ` Stefan Hajnoczi
2013-04-11 10:26     ` Paolo Bonzini
2013-04-12  3:55     ` liu ping fan
2013-04-12  8:38       ` Stefan Hajnoczi
2013-04-12 10:03         ` Paolo Bonzini
2013-04-15  1:42           ` liu ping fan
2013-04-15  6:38             ` Paolo Bonzini
2013-04-01  8:20 ` [Qemu-devel] [PATCH 3/5] vring: use hostmem's RAM safe api Liu Ping Fan
2013-04-11 10:15   ` Stefan Hajnoczi
2013-04-12  4:49     ` liu ping fan
2013-04-12  8:41       ` Stefan Hajnoczi
2013-04-01  8:20 ` [Qemu-devel] [PATCH 4/5] virtio-blk: release reference to RAM's memoryRegion Liu Ping Fan
2013-04-02  5:58   ` li guang
2013-04-12  4:44     ` liu ping fan
2013-04-11 10:20   ` Stefan Hajnoczi
2013-04-12  4:48     ` liu ping fan
2013-04-12  8:45       ` Stefan Hajnoczi [this message]
2013-04-12  9:05         ` liu ping fan
2013-04-16  7:57           ` Stefan Hajnoczi
2013-04-16  8:12             ` Paolo Bonzini
2013-04-01  8:20 ` [Qemu-devel] [PATCH 5/5] hostmem: init/finalize hostmem listener Liu Ping Fan
2013-04-11 10:02   ` Paolo Bonzini
2013-04-11 12:08     ` liu ping fan
2013-04-11 13:14       ` Paolo Bonzini
2013-06-13  4:38   ` [Qemu-devel] about atexit() (was: [PATCH 5/5] hostmem: init/finalize hostmem listener) Amos Kong
2013-06-13  8:51     ` liu ping fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130412084520.GE31055@stefanha-thinkpad.redhat.com \
    --to=stefanha@gmail.com \
    --cc=aliguori@us.ibm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@gmail.com \
    --cc=vasilis.liaskovitis@profitbricks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).