From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDyUa-0002Mp-4y for qemu-devel@nongnu.org; Wed, 12 Oct 2011 09:05:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDyUW-0000fU-1B for qemu-devel@nongnu.org; Wed, 12 Oct 2011 09:05:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDyUV-0000en-LN for qemu-devel@nongnu.org; Wed, 12 Oct 2011 09:04:59 -0400 Message-ID: <4E95912C.8070804@redhat.com> Date: Wed, 12 Oct 2011 15:07:56 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1317831427-477-1-git-send-email-stefanha@linux.vnet.ibm.com> <1317831427-477-5-git-send-email-stefanha@linux.vnet.ibm.com> In-Reply-To: <1317831427-477-5-git-send-email-stefanha@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/6] block: switch bdrv_aio_readv() to coroutines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , Marcelo Tosatti , qemu-devel@nongnu.org, Zhi Yong Wu , Avi Kivity , Christoph Hellwig Am 05.10.2011 18:17, schrieb Stefan Hajnoczi: > More sync, aio, and coroutine unification. Make bdrv_aio_readv() go > through coroutine request processing. > > Signed-off-by: Stefan Hajnoczi > --- > block.c | 48 +++++++++++++++++++++++++++++++++++------------- > 1 files changed, 35 insertions(+), 13 deletions(-) > > diff --git a/block.c b/block.c > index 90c29db..b83e911 100644 > --- a/block.c > +++ b/block.c > @@ -78,6 +78,15 @@ static int coroutine_fn bdrv_co_do_readv(BlockDriverState *bs, > int64_t sector_num, int nb_sectors, QEMUIOVector *qiov); > static int coroutine_fn bdrv_co_do_writev(BlockDriverState *bs, > int64_t sector_num, int nb_sectors, QEMUIOVector *qiov); > +static BlockDriverAIOCB *bdrv_co_aio_rw_vector(BlockDriverState *bs, > + int64_t sector_num, > + QEMUIOVector *qiov, > + int nb_sectors, > + BlockDriverCompletionFunc *cb, > + void *opaque, > + bool is_write, > + CoroutineEntry *entry); > +static void coroutine_fn bdrv_co_do_rw(void *opaque); > > static QTAILQ_HEAD(, BlockDriverState) bdrv_states = > QTAILQ_HEAD_INITIALIZER(bdrv_states); > @@ -2346,17 +2355,10 @@ BlockDriverAIOCB *bdrv_aio_readv(BlockDriverState *bs, int64_t sector_num, > QEMUIOVector *qiov, int nb_sectors, > BlockDriverCompletionFunc *cb, void *opaque) > { > - BlockDriver *drv = bs->drv; > - > trace_bdrv_aio_readv(bs, sector_num, nb_sectors, opaque); > > - if (!drv) > - return NULL; > - if (bdrv_check_request(bs, sector_num, nb_sectors)) > - return NULL; > - > - return drv->bdrv_aio_readv(bs, sector_num, qiov, nb_sectors, > - cb, opaque); > + return bdrv_co_aio_rw_vector(bs, sector_num, qiov, nb_sectors, > + cb, opaque, false, bdrv_co_do_rw); > } > > typedef struct BlockCompleteData { > @@ -2803,6 +2805,7 @@ static void bdrv_co_rw_bh(void *opaque) > qemu_aio_release(acb); > } > > +/* Invoke .bdrv_co_readv/.bdrv_co_writev */ > static void coroutine_fn bdrv_co_rw(void *opaque) > { > BlockDriverAIOCBCoroutine *acb = opaque; > @@ -2820,13 +2823,32 @@ static void coroutine_fn bdrv_co_rw(void *opaque) > qemu_bh_schedule(acb->bh); > } > > +/* Invoke bdrv_co_do_readv/bdrv_co_do_writev */ > +static void coroutine_fn bdrv_co_do_rw(void *opaque) > +{ > + BlockDriverAIOCBCoroutine *acb = opaque; > + BlockDriverState *bs = acb->common.bs; > + > + if (!acb->is_write) { > + acb->req.error = bdrv_co_do_readv(bs, acb->req.sector, > + acb->req.nb_sectors, acb->req.qiov); > + } else { > + acb->req.error = bdrv_co_do_writev(bs, acb->req.sector, > + acb->req.nb_sectors, acb->req.qiov); > + } > + > + acb->bh = qemu_bh_new(bdrv_co_rw_bh, acb); > + qemu_bh_schedule(acb->bh); > +} The difference between the existing bdrv_co_rw and the new bdrv_co_do_rw is that the former directly calls drv->... whereas the latter does some checks first. I think you could just switch bdrv_co_rw to do the checks. If I'm not mistaken, the other path is dead code anyway after this change. Actually, it looks like this series leaves quite a bit of dead code behind, but I need to apply all patches and check the result to be sure. Kevin