The aio_disable_external() API temporarily suspends file descriptor monitoring
in the event loop. The block layer uses this to prevent new I/O requests being
submitted from the guest and elsewhere between bdrv_drained_begin() and
bdrv_drained_end().
While the block layer still needs to prevent new I/O requests in drained
sections, the aio_disable_external() API can be replaced with
.drained_begin/end/poll() callbacks that have been added to BdrvChildClass and
BlockDevOps.
This newer .bdrained_begin/end/poll() approach is attractive because it works
without specifying a specific AioContext. The block layer is moving towards
multi-queue and that means multiple AioContexts may be processing I/O
simultaneously.
The aio_disable_external() was always somewhat hacky. It suspends all file
descriptors that were registered with is_external=true, even if they have
nothing to do with the BlockDriverState graph nodes that are being drained.
It's better to solve a block layer problem in the block layer than to have an
odd event loop API solution.
That covers the motivation for this change, now on to the specifics of this
series:
While it would be nice if a single conceptual approach could be applied to all
is_external=true file descriptors, I ended up looking at callers on a
case-by-case basis. There are two general ways I migrated code away from
is_external=true:
1. Block exports are typically best off unregistering fds in .drained_begin()
and registering them again in .drained_end(). The .drained_poll() function
waits for in-flight requests to finish using a reference counter.
2. Emulated storage controllers like virtio-blk and virtio-scsi are a little
simpler. They can rely on BlockBackend's request queuing during drain
feature. Guest I/O request coroutines are suspended in a drained section and
resume upon the end of the drained section.