qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 00/22] block: Asynchronous request cancellati


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v5 00/22] block: Asynchronous request cancellation
Date: Wed, 10 Sep 2014 17:20:15 +0800
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, 09/10 17:09, Bin Wu wrote:
> On 2014/9/10 13:59, Fam Zheng wrote:
> >v5: Fix IDE callback. (Paolo)
> >     Fix blkdebug. (Paolo)
> >     Drop the DMA fix which is independent of this series. (Paolo)
> >     Incorperate Yuan's patch on quorum_aio_cancel. (Benoît)
> >     Commit message wording fix. (Benoît)
> >     Rename qemu_aio_release to qemu_aio_unref. (Benoît)
> >
> >v4: Drop AIOCBInfo.cancel.
> >
> >This series adds a new block layer API:
> >
> >   void bdrv_aio_cancel_async(BlockDriverAIOCB *acb);
> >
> >And use it to emulate bdrv_aio_cancel.
> >
> >The function is similar to bdrv_aio_cancel in that it cancels an AIO request,
> >but different that it doesn't block until the request is completely cancelled
> >or done.
> >
> >More importantly, the completion callback, BlockDriverAIOCB.cb, is guaranteed
> >to be called, so that the cb can take care of resource releasing and status
> >reporting to guest, etc.
> >
> >In the following work, scsi emulation code will be shifted to use the async
> >cancelling.
> >
> >One major benefit would be that when guest tries to cancel a request, where 
> >the
> >request cannot be cancelled easily, (due to throttled BlockDriverState, a 
> >lost
> >connection, or a large request queue), we don't need to block the whole vm 
> >with
> >a busy loop, which is how bdrv_aio_cancel is implemented now.
> 
> First, I think this series is really useful. However, I tested the v4 series
> and found virtio-scsi disk(scsi-hd) was still blocked when the IO could not
> come back because of virtio_scsi_do_tmf->scsi_cancel_io->bdrv_aio_cancel.
> can we just change the bdrv_aio_cancel to bdrv_aio_cancel_async to solve
> this problem?

We can't just change it yet. We need to take care of the scsi_req_unref there,
if we unref right after bdrv_aio_cancel_async, in the cb it will access
dangling pointer.

It's not trivial enough to do in this series, I will work on that on top, as
said below. For now, the user visible behavior of io cancellation is still the
same.

Thanks for testing.
Fam

> >
> >Later, we will change scsi device code to make this asynchronous, on top of
> >bdrv_aio_cancel_async.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]