Re: [PULL 1/1] virtio-blk: avoid using ioeventfd state in irqfd conditional

[Michael Tokarev <mjt@tls.msk.ru>]

06.02.2024 18:31, Stefan Hajnoczi :
> Requests that complete in an IOThread use irqfd to notify the guest
> while requests that complete in the main loop thread use the traditional
> qdev irq code path. The reason for this conditional is that the irq code
> path requires the BQL:
> 
>    if (s->ioeventfd_started && !s->ioeventfd_disabled) {
>        virtio_notify_irqfd(vdev, req->vq);
>    } else {
>        virtio_notify(vdev, req->vq);
>    }
> 
> There is a corner case where the conditional invokes the irq code path
> instead of the irqfd code path:
> 
>    static void virtio_blk_stop_ioeventfd(VirtIODevice *vdev)
>    {
>        ...
>        /*
>         * Set ->ioeventfd_started to false before draining so that host notifiers
>         * are not detached/attached anymore.
>         */
>        s->ioeventfd_started = false;
> 
>        /* Wait for virtio_blk_dma_restart_bh() and in flight I/O to complete */
>        blk_drain(s->conf.conf.blk);
> 
> During blk_drain() the conditional produces the wrong result because
> ioeventfd_started is false.
> 
> Use qemu_in_iothread() instead of checking the ioeventfd state.
> 
> Buglink: https://issues.redhat.com/browse/RHEL-15394
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> Message-id: 20240122172625.415386-1-stefanha@redhat.com
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Cc qemu-stable?  This smells like a stable material, please let me know
if it is not.

(And yes I've seen it also included in another pullreq)

Thanks,

/mjt