On Wed, 16 Mar 2016 12:59:37 +0100 Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 16/03/2016 12:56, Cornelia Huck wrote: > > On Wed, 16 Mar 2016 12:48:22 +0100 > > Paolo Bonzini <pbonz...@redhat.com> wrote: > > > >> > >> > >> On 16/03/2016 12:32, Cornelia Huck wrote: > >>> On Wed, 16 Mar 2016 12:09:02 +0100 > >>> Paolo Bonzini <pbonz...@redhat.com> wrote: > >>> > >>>> On 16/03/2016 11:49, Christian Borntraeger wrote: > >>> > >>>>> #3 0x00000000800b713e in virtio_blk_data_plane_start (s=0xba232d80) at > >>>>> /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:224 > >>>>> #4 0x00000000800b4ea0 in virtio_blk_handle_output (vdev=0xb9eee7e8, > >>>>> vq=0xba305270) at /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:590 > >>>>> #5 0x00000000800ef3dc in virtio_queue_notify_vq (vq=0xba305270) at > >>>>> /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1095 > >>>>> #6 0x00000000800f1c9c in virtio_queue_host_notifier_read > >>>>> (n=0xba3052c8) at /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1785 > >>>>> #7 0x00000000800f1e14 in virtio_queue_set_host_notifier_fd_handler > >>>>> (vq=0xba305270, assign=false, set_handler=false) at > >>>>> /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1817 > >>>>> #8 0x0000000080109c50 in virtio_ccw_set_guest2host_notifier > >>>>> (dev=0xb9eed6a0, n=0, assign=false, set_handler=false) at > >>>>> /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:97 > >>>>> #9 0x0000000080109ef2 in virtio_ccw_stop_ioeventfd (dev=0xb9eed6a0) at > >>>>> /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:154 > >>>> > >>>> One bug is here: virtio_ccw_stop_ioeventfd, in this case, should pass > >>>> assign=true to virtio_ccw_set_guest2host_notifier. (Assuming my > >>>> understanding of assign=true is correct; I think it means "I'm going to > >>>> set up another host notifier handler"). > >>> > >>> Hm... I copied these semantics from virtio-pci, and they still seem to > >>> be the same. I wonder why we never saw this on virtio-pci? > >> > >> Just because we never ran the right tests, probably. The bug is indeed > >> in virtio-pci as well (I didn't check mmio). > > > > Somebody should probably do a writeup on the expected behaviour, as > > this always ends in mental gymnastics (at least for me :) > > Yeah, it doesn't help that the functions are underdocumented (as in the > "assign" parameter above). My understanding is: - 'assign': set up a new notifier (true) or disable it (false) - 'set_handler': use our handler (true) or have it handled elsewhere (false) > > >> > >>>> In dataplane, instead, all calls to > >>>> virtio_queue_set_host_notifier_fd_handler and > >>>> virtio_queue_aio_set_host_notifier_handler should have assign=true. The > >>>> ioeventfd is just being moved from one aiocontext to another. > >>> > >>> How can a transport know where they are called from? > >> > >> That's a bug in dataplane. The calls should be changed in > >> hw/block/dataplane/virtio-blk.c > > > > I don't think the ->set_host_notifiers() api really allows for this. > > I think it does, assign is the last argument to k->set_host_notifier(). This depends on whether we want 'assign' to clean up any old notifiers before setting up new ones. I think we want different behaviour for dataplane and vhost.