Re: [Qemu-devel] [PATCH v2 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane

[Paolo Bonzini <pbonzini@redhat.com>]

On 29/07/2015 06:42, Fam Zheng wrote:
> v2: Switch to disable/enable model. [Paolo]
> 
> Most existing nested aio_poll()'s in block layer are inconsiderate of
> dispatching potential new r/w requests from ioeventfds and nbd exports, which
> might result in responsiveness issues (e.g. bdrv_drain_all will not return when
> new requests keep coming), or even wrong semantics (e.g. qmp_transaction cannot
> enforce atomicity due to aio_poll in bdrv_drain_all).
> 
> Previous attampts to address this issue include new op blocker[1], bdrv_lock[2]
> and nested AioContext (patches not posted to qemu-devel).
> 
> This approach is based on the idea proposed by Paolo Bonzini. The original idea
> is introducing "aio_context_disable_client / aio_context_enable_client to
> filter AioContext handlers according to the "client", e.g.
> AIO_CLIENT_DATAPLANE (ioeventfd), AIO_CLIENT_PROTOCOL, AIO_CLIENT_NBD_SERVER,
> AIO_CLIENT_CONTEXT, ... Extend aio_set_{event_notifier,fd}_handler to pass a
> client (type)." 
> 
> After this series, block layer aio_poll() will only process those "protocol"
> fds that are used in block I/O, plus the ctx->notifier for aio_notify();  other
> aio_poll()'s keep unchanged.
> 
> The biggest advantage over approaches [1] and [2] is, no change is needed in
> virtio-{blk,scsi}-dataplane code, also this doesn't depend on converting QMP to
> coroutines.
> 
> The windows implementation is not tested except for compiling.
> 
> [1]: https://lists.gnu.org/archive/html/qemu-block/2015-05/msg00800.html
> [2]: http://lists.nongnu.org/archive/html/qemu-block/2015-06/msg00027.html

For patches 1-8:

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>