[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd no
From: |
Halil Pasic |
Subject: |
Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify |
Date: |
Wed, 1 Mar 2017 14:22:55 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
On 03/01/2017 01:57 PM, Paolo Bonzini wrote:
>
>
> On 01/03/2017 12:50, Halil Pasic wrote:
>> The commits 03de2f527 "virtio-blk: do not use vring in dataplane" and
>> 9ffe337c08 "virtio-blk: always use dataplane path if ioeventfd is active"
>> changed how notifications are done for virtio-blk substantially. Due to a
>> race condition interrupts are lost when irqfd is torn down after
>> notify_guest_bh was scheduled but before it actually runs.
>
> I don't think the non-irqfd notification mechanism is thread safe, and
> that would be a problem for this patch.
Sorry, haven't looked into that thoroughly (and speculated people with
more understanding will jump in).
>
> What is the path that causes the irqfd to be torn down? Only something
Here a trace:
address@hidden:virtio_blk_req_complete req 0x2aa6b117e10 status 0
address@hidden:virtio_notify_irqfd vdev 0x2aa6b0e19d8 vq 0x2aa6b4c0870
address@hidden:virtio_blk_req_complete req 0x2aa6b118980 status 0
address@hidden:virtio_blk_req_complete req 0x2aa6b119260 status 0
address@hidden:virtio_notify_irqfd vdev 0x2aa6b0e19d8 vq 0x2aa6b4c0870
address@hidden:virtio_blk_req_complete req 0x2aa6b118980 status 0
address@hidden:virtio_notify_irqfd vdev 0x2aa6b0e19d8 vq 0x2aa6b4c0870
address@hidden:virtio_guest_notifier_read vdev 0x2aa6b0e61c8 vq 0x2aa6b4de880
address@hidden:virtio_guest_notifier_read vdev 0x2aa6b0e61c8 vq 0x2aa6b4de8f8
address@hidden:virtio_blk_data_plane_stop dataplane 0x2aa6b0e5540
^== DATAPLANE STOP
address@hidden:virtio_blk_req_complete req 0x2aa6b117e10 status 0
address@hidden:virtio_guest_notifier_read vdev 0x2aa6b0e19d8 vq 0x2aa6b4c0870
^== comes from k->set_guest_notifiers(qbus->parent,
nvqs, false);
in virtio_blk_data_plane_stop and done immediately
after
irqfd is cleaned up by the transport
address@hidden:virtio_notify_irqfd vdev 0x2aa6b0e19d8 vq 0x2aa6b4c0870
halil: error in event_notifier_set: Bad file descriptor
^== here we have the problem
If you want a stacktrace that can be arranged to.
> like a reset should cause it (the only call in virtio-blk is from
> virtio_blk_data_plane_stop), and then the guest doesn't care anymore
> about interrupts.
I do not understand this with 'doesn't care anymore about interrupts'.
I was debugging a virtio-blk device being stuck waiting for a host
notification (interrupt) after migration.
>
> That path also does a qemu_bh_delete, so the notify_guest_bh should not
> be invoked at all.
>
That's only for destroy. I'm migrating.
Seems I tried to fix this is the wrong way. Was not too confident about it
in the first place. Suggestions welcome!
Cheers,
Halil
- [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Halil Pasic, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Michael S. Tsirkin, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Paolo Bonzini, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify,
Halil Pasic <=
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Paolo Bonzini, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Halil Pasic, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Michael S. Tsirkin, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Paolo Bonzini, 2017/03/01
- Re: [Qemu-devel] [PATCH 1/1] virtio: fallback from irqfd to non-irqfd notify, Halil Pasic, 2017/03/02