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: Christian Borntraeger
Subject: Re: [Qemu-block] [PATCH 0/4] Tweaks around virtio-blk start/stop
Date: Wed, 16 Mar 2016 12:24:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/16/2016 12:09 PM, Paolo Bonzini wrote:
> 
> 
> 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! :)

So I understood your first remark (about _working_ transactional memory) but  I 
cannot parse your 2nd one. For Conny it is exactly the opposite, so I will let
Conny answer belows discussion ;-)



> 
>> #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]