Re: [Qemu-devel] [RFC PATCH 0/4] aio: Don't poll ioeventfd in nested aio_poll()

[Fam Zheng]

On Wed, 05/27 11:38, Paolo Bonzini wrote:
> 
> 
> On 27/05/2015 09:19, Fam Zheng wrote:
> > This series looks at the other side of the broken "qmp transaction" problem
> > with dataplane [1] - the event loop.
> > 
> > Before, an ioeventfd of a non-dataplane device is registered via
> > qemu_set_fd_handler, which is only polled directly by main_loop_wait(), not 
> > in
> > aio_poll(); an ioeventfd of a dataplane device (virtio-blk/virtio-scsi) is
> > registered specially via aio_set_event_notifier, which is a wrapper of
> > aio_set_fd_handler, thus it WILL be polled by all aio_poll().
> > 
> > As explained in [1], and in patch 3, this is wrong. The handlers mustn't 
> > run.
> > 
> > [1] Fixes it by unregistering them temporarily around such nested poll, 
> > while
> > this series fixes it by skipping those file descriptors in all nested
> > aio_poll(), just like how iohandler behaves in the main loop.
> > 
> > On the one hand, it is simpler than [1]; on the other hand, this approach is
> > also interesting because once we remove qemu_set_fd_handler2 [2], 
> > iohandler.c
> > can be removed by converting all qemu_set_fd_handler to the new
> > aio_set_io_event_notifier introduced in this series.
> 
> I don't think this can work.
> 
> Whenever the main context is doing synchronous work for dataplane, it is
> in the outermost aio_poll.
> 

You're right. :(

The main context uses iohandler and aio_dispatch, neither calls
aio_set_dispatching(). However, if we have [2], they can be changed to
aio_poll(), then would this idea work?

Fam