Now that aio_poll() users check their termination condition themselves,
it is no longer necessary to call .io_flush() handlers.
The behavior of aio_poll() changes as follows:
1. .io_flush() is no longer invoked and file descriptors are *always*
monitored. Previously returning 0 from .io_flush() would skip this file
descriptor.
Due to this change it is essential to check that requests are pending
before calling qemu_aio_wait(). Failure to do so means we block, for
example, waiting for an idle iSCSI socket to become readable when there
are no requests. Currently all qemu_aio_wait()/aio_poll() callers check
before calling.
2. aio_poll() now returns true if progress was made (BH or fd handlers
executed) and false otherwise. Previously it would return true whenever
'busy', which means that .io_flush() returned true. The 'busy' concept
no longer exists so just progress is returned.
Due to this change we need to update tests/test-aio.c which asserts
aio_poll() return values. Note that QEMU doesn't actually rely on these
return values so only tests/test-aio.c cares.
Note that ctx->notifier, the EventNotifier fd used for aio_notify(), is
now handled as a special case. This is a little ugly but maintains
aio_poll() semantics, i.e. aio_notify() does not count as 'progress' and
aio_poll() avoids blocking when the user has not set any fd handlers yet.
Patches after this remove .io_flush() handler code until we can finally
drop the io_flush arguments to aio_set_fd_handler() and friends.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
164a101f28