qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org,
	stefanha@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] move global bdrv_states out of block.c
Date: Wed, 18 Sep 2013 16:03:18 +0200	[thread overview]
Message-ID: <20130918140318.GE25444@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <1377589765-30215-1-git-send-email-xiawenc@linux.vnet.ibm.com>

On Tue, Aug 27, 2013 at 03:49:22PM +0800, Wenchao Xia wrote:
> In order to support multiple caller from different thread, global
> inside block layer should be carefully treated. bdrv_states represent
> a group of bds* which is now used by qemu, so it is a user concept which
> should be managed by user. This series tries to move it out, so later
> different thread can feed the API with its own bds* group.
> 
> This is a RFC series which does not completely convert the API, the missing
> part is adding parameter *l in all API which uses bdrv_states, then move
> bdrv_states to caller. About 10 functions need to be converted, so hope to
> get comments before that, to see if this is the right direction.

The global bdrv_states list needs to stay, I don't think we should try
to remove it.

The list is used to drain and flush all devices so that we can safely
shut down or live migrate.  If we give each thread their own list then
there's no way to globally drain and flush.

The invalidate function that you modified is another example: we *must*
invalidate all BDS instances across all threads.  Failure to invalidate
all instances could mean inconsistencies or data loss.

So in the end I think we need to keep bdrv_states.

Stefan

  parent reply	other threads:[~2013-09-18 14:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27  7:49 [Qemu-devel] [RFC PATCH 0/3] move global bdrv_states out of block.c Wenchao Xia
2013-08-27  7:49 ` [Qemu-devel] [RFC PATCH 1/3] block: add typedef for BlockDriverState queue Wenchao Xia
2013-08-27  7:49 ` [Qemu-devel] [RFC PATCH 2/3] block: add function qemu_get_bds_queue Wenchao Xia
2013-08-27  7:49 ` [Qemu-devel] [RFC PATCH 3/3] block: add parameter bds queue in bdrv_invalidate_cache_all() Wenchao Xia
2013-09-18 14:03 ` Stefan Hajnoczi [this message]
2013-09-20  6:24   ` [Qemu-devel] [RFC PATCH 0/3] move global bdrv_states out of block.c Wenchao Xia

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=20130918140318.GE25444@stefanha-thinkpad.redhat.com \
    --to=stefanha@gmail.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=xiawenc@linux.vnet.ibm.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).