From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrWqF-000873-7O for qemu-devel@nongnu.org; Wed, 28 Oct 2015 15:57:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrWqC-0000ls-0y for qemu-devel@nongnu.org; Wed, 28 Oct 2015 15:57:03 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:48783 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrWqB-0000lY-Oc for qemu-devel@nongnu.org; Wed, 28 Oct 2015 15:56:59 -0400 Message-ID: <56312885.2000600@kamp.de> Date: Wed, 28 Oct 2015 20:56:53 +0100 From: Peter Lieven MIME-Version: 1.0 References: <1444652845-20642-1-git-send-email-pl@kamp.de> <1444652845-20642-4-git-send-email-pl@kamp.de> <20151026103949.GA20111@stefanha-x1.localdomain> <562F58EF.9050709@kamp.de> <20151028112623.GC31290@stefanha-x1.localdomain> In-Reply-To: <20151028112623.GC31290@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] ide: add support for cancelable read requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, jcody@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org Am 28.10.2015 um 12:26 schrieb Stefan Hajnoczi: > On Tue, Oct 27, 2015 at 11:58:55AM +0100, Peter Lieven wrote: >> Am 26.10.2015 um 11:39 schrieb Stefan Hajnoczi: >>> On Mon, Oct 12, 2015 at 02:27:24PM +0200, Peter Lieven wrote: >>>> +BlockAIOCB *ide_readv_cancelable(IDEState *s, int64_t sector_num, >>>> + QEMUIOVector *iov, int nb_sectors, >>>> + BlockCompletionFunc *cb, void *opaque) >>>> +{ >>>> + BlockAIOCB *aioreq; >>>> + IDECancelableRequest *req; >>>> + int c = 0; >>>> + >>>> + QLIST_FOREACH(req, &s->cancelable_requests, list) { >>>> + c++; >>>> + } >>>> + if (c > MAX_CANCELABLE_REQS) { >>>> + return NULL; >>>> + } >>> A BH is probably needed here to schedule an cb(-EIO) call since this >>> function isn't supposed to return NULL if it's a direct replacement for >>> blk_aio_readv(). >> You mean sth like: >> >> acb = qemu_aio_get(&bdrv_em_aiocb_info, bs, cb, opaque); >> acb->bh = aio_bh_new(bdrv_get_aio_context(bs), bdrv_aio_bh_cb, acb); >> acb->ret = -EIO; >> qemu_bh_schedule(acb->bh); >> >> return &acb->common; > Yes. > >> As pointed out in my comment to your requestion about write/discard I think it should >> be feasible to use buffered readv requests for all read-only IDE devices. >> Only thing I'm unsure about is reopening. A reopen seems to only flush the device not >> drain all requests. > bdrv_reopen_prepare() callers should drain requests. For example, > bdrv_reopen_multiple() (and indirectly bdrv_reopen()) call > bdrv_drain_all(). Is this what you mean? Yes, I have only found a flush in bdrv_reopen_prepare, but if you say they need to drain before I think it is safe to use the buffered_ide_readv for all read-only IDE devices not only CDROMs. Peter