• Stefan Hajnoczi's avatar
    coroutine: use AioContext for CoQueue BH · 28f08246
    Stefan Hajnoczi authored
    CoQueue uses a BH to awake coroutines that were made ready to run again
    using qemu_co_queue_next() or qemu_co_queue_restart_all().  The BH
    currently runs in the iothread AioContext and would break coroutines
    that run in a different AioContext.
    
    This is a slightly tricky problem because the lifetime of the BH exceeds
    that of the CoQueue.  This means coroutines can be awoken after CoQueue
    itself has been freed.  Also, there is no qemu_co_queue_destroy()
    function which we could use to handle freeing resources.
    
    Introducing qemu_co_queue_destroy() has a ripple effect of requiring us
    to also add qemu_co_mutex_destroy() and qemu_co_rwlock_destroy(), as
    well as updating all callers.  Avoid doing that.
    
    We also cannot switch from BH to GIdle function because aio_poll() does
    not dispatch GIdle functions.  (GIdle functions make memory management
    slightly easier because they free themselves.)
    
    Finally, I don't want to move unlock_queue and unlock_bh into
    AioContext.  That would break encapsulation - AioContext isn't supposed
    to know about CoQueue.
    
    This patch implements a different solution: each qemu_co_queue_next() or
    qemu_co_queue_restart_all() call creates a new BH and list of coroutines
    to wake up.  Callers tend to invoke qemu_co_queue_next() and
    qemu_co_queue_restart_all() occasionally after blocking I/O, so creating
    a new BH for each call shouldn't be massively inefficient.
    
    Note that this patch does not add an interface for specifying the
    AioContext.  That is left to future patches which will convert CoQueue,
    CoMutex, and CoRwlock to expose AioContext.
    Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    28f08246
qemu-coroutine-lock.c 5.1 KB