From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9ADO-0000UK-QE for qemu-devel@nongnu.org; Wed, 05 Sep 2012 03:40:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9ADE-0005fl-Rw for qemu-devel@nongnu.org; Wed, 05 Sep 2012 03:39:58 -0400 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:48142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9ADE-0005fX-4A for qemu-devel@nongnu.org; Wed, 05 Sep 2012 03:39:48 -0400 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 5 Sep 2012 17:38:02 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q857UK8d27459642 for ; Wed, 5 Sep 2012 17:30:20 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q857dIUw015691 for ; Wed, 5 Sep 2012 17:39:19 +1000 Date: Wed, 5 Sep 2012 13:11:06 +0530 From: Bharata B Rao Message-ID: <20120905074106.GA28080@in.ibm.com> References: <20120809130010.GA7960@in.ibm.com> <20120809130216.GC7960@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120809130216.GC7960@in.ibm.com> Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini , Kevin Wolf Cc: Blue Swirl , Anand Avati , Amar Tumballi , Stefan Hajnoczi , Vijay Bellur On Thu, Aug 09, 2012 at 06:32:16PM +0530, Bharata B Rao wrote: > +static void qemu_gluster_complete_aio(GlusterAIOCB *acb) > +{ > + int ret; > + > + if (acb->canceled) { > + qemu_aio_release(acb); > + return; > + } > + > + if (acb->ret == acb->size) { > + ret = 0; /* Success */ > + } else if (acb->ret < 0) { > + ret = acb->ret; /* Read/Write failed */ > + } else { > + ret = -EIO; /* Partial read/write - fail it */ > + } > + acb->common.cb(acb->common.opaque, ret); The .cb() here is bdrv_co_io_em_complete(). It does qemu_coroutine_enter(), handles the return value and comes back here. But if the bdrv_read or bdrv_write or bdrv_flush was called from a coroutine context (as against they themselves creating a new coroutine), the above .cb() call above doesn't return to this point. Hence I won't be able to release the acb and decrement the qemu_aio_count. What could be the issue here ? In general, how do I ensure that my aio calls get completed correctly in such scenarios where bdrv_read etc are called from coroutine context rather than from main thread context ? Creating qcow2 image would lead to this scenario where ->bdrv_create (=qcow2_create) will create a coroutine and subsequently read and write are called within qcow2_create in coroutine context itself. > + qemu_aio_release(acb); > +} > + > +static void qemu_gluster_aio_event_reader(void *opaque) > +{ > + BDRVGlusterState *s = opaque; > + GlusterAIOCB *event_acb; > + int event_reader_pos = 0; > + ssize_t ret; > + > + do { > + char *p = (char *)&event_acb; > + > + ret = read(s->fds[GLUSTER_FD_READ], p + event_reader_pos, > + sizeof(event_acb) - event_reader_pos); > + if (ret > 0) { > + event_reader_pos += ret; > + if (event_reader_pos == sizeof(event_acb)) { > + event_reader_pos = 0; > + qemu_gluster_complete_aio(event_acb); > + s->qemu_aio_count--; > + } > + } > + } while (ret < 0 && errno == EINTR); > +} > +