qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH 0/4] Tweaks around virtio-blk start/stop


From: Paolo Bonzini
Subject: Re: [Qemu-block] [PATCH 0/4] Tweaks around virtio-blk start/stop
Date: Wed, 16 Mar 2016 12:09:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0


On 16/03/2016 11:49, Christian Borntraeger wrote:
> Seems to lockup.

That's an improvement actually. :)

> Thread 3 (Thread 0x3ff888dc910 (LWP 88958)):
> #0  0x000003ff8ca90cd4 in __lll_lock_wait () at /lib64/libpthread.so.0
> #1  0x000003ff8ca93e74 in __lll_lock_elision () at /lib64/libpthread.so.0

Off-topic, I love how s390 backtraces always have a little bit of
showing off in them! :)

> #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").

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.

Paolo

> #10 0x000000008010d5aa in virtio_ccw_set_host_notifier (d=0xb9eed6a0, n=0, 
> assign=true) at /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:1211
> #11 0x00000000800b722c in virtio_blk_data_plane_start (s=0xba232d80) at 
> /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:242
> #12 0x00000000800b4ea0 in virtio_blk_handle_output (vdev=0xb9eee7e8, 
> vq=0xba305270) at /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:590
> #13 0x00000000800ef3dc in virtio_queue_notify_vq (vq=0xba305270) at 
> /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1095
> #14 0x00000000800f1c9c in virtio_queue_host_notifier_read (n=0xba3052c8) at 
> /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1785
> #15 0x00000000802f1cd4 in aio_dispatch (ctx=0xb9e81c70) at 
> /home/cborntra/REPOS/qemu/aio-posix.c:327
> #16 0x00000000802df31c in aio_ctx_dispatch (source=0xb9e81c70, callback=0x0, 
> user_data=0x0) at /home/cborntra/REPOS/qemu/async.c:232



reply via email to

[Prev in Thread] Current Thread [Next in Thread]