From: Alex Williamson <alex.williamson@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: cornelia.huck@de.ibm.com, famz@redhat.com, qemu-devel@nongnu.org,
stefanha@redhat.com, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active
Date: Fri, 11 Nov 2016 14:03:42 -0700 [thread overview]
Message-ID: <20161111140342.7825fd1b@t450s.home> (raw)
In-Reply-To: <b500f759-881d-cb62-dd66-bd81ec1aabe2@redhat.com>
On Fri, 11 Nov 2016 21:24:33 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 11/11/2016 05:09, Alex Williamson wrote:
> > On Fri, 21 Oct 2016 22:48:10 +0200
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> >> Override start_ioeventfd and stop_ioeventfd to start/stop the
> >> whole dataplane logic. This has some positive side effects:
> >>
> >> - no need anymore for virtio_add_queue_aio (i.e. a revert of
> >> commit 1c627137c10ee2dcf59e0383ade8a9abfa2d4355)
> >>
> >> - no need anymore to switch from generic ioeventfd handlers to
> >> dataplane
> >>
> >> It detects some errors better:
> >>
> >> $ qemu-system-x86_64 -object iothread,id=io \
> >> -device virtio-scsi-pci,ioeventfd=off,iothread=io
> >> qemu-system-x86_64: -device virtio-scsi-pci,ioeventfd=off,iothread=io:
> >> ioeventfd is required for iothread
> >>
> >> while previously it would have started just fine.
> >>
> >> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >> ---
> >> hw/scsi/virtio-scsi-dataplane.c | 56 +++++++++++++++++++++++++----------------
> >> hw/scsi/virtio-scsi.c | 24 ++++++++----------
> >> include/hw/virtio/virtio-scsi.h | 6 ++---
> >> 3 files changed, 48 insertions(+), 38 deletions(-)
> >
> > Looks like this added a more subtle regression with MST's previous pull
> > request, I have an OVMF/440FX/virtio-scsi/virtio-net/win8.1 VM, with
> > this patch it fails to shutdown. QEMU just spins at 400% load.
>
> I cannot reproduce this one. :( You said you get it even with vhost,
> what if you remove VFIO and add a regular VGA?
>
> If you can post a backtrace of all threads at the time of the hang, from
> origin/master (so without vhost, and not at ad07cd6) that could help.
Yes, it occurs with all of the vfio devices removed using VNC/Cirrus.
Backtrace on all threads running 6bbcb76:
Thread 7 (Thread 0x7f5734dff700 (LWP 13136)):
#0 0x00007f5748adcbd0 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x0000565105c1b5a1 in qemu_cond_wait (cond=0x565108c8f120, mutex=0x565108c8f150) at util/qemu-thread-posix.c:137
#2 0x0000565105b2219b in vnc_worker_thread_loop (queue=0x565108c8f120) at ui/vnc-jobs.c:228
#3 0x0000565105b226d1 in vnc_worker_thread (arg=0x565108c8f120) at ui/vnc-jobs.c:335
#4 0x00007f5748ad75ca in start_thread (arg=0x7f5734dff700) at pthread_create.c:333
#5 0x00007f57488110ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 6 (Thread 0x7f5736bfe700 (LWP 13133)):
#0 0x00007f5748806ce7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1 0x000056510579734e in kvm_vcpu_ioctl (cpu=0x565107b21b70, type=44672) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:2079
#2 0x0000565105796cd5 in kvm_cpu_exec (cpu=0x565107b21b70) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1929
#3 0x000056510577dc58 in qemu_kvm_cpu_thread_fn (arg=0x565107b21b70) at /net/gimli/home/alwillia/Work/qemu.git/cpus.c:998
#4 0x00007f5748ad75ca in start_thread (arg=0x7f5736bfe700) at pthread_create.c:333
#5 0x00007f57488110ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f57373ff700 (LWP 13132)):
#0 0x00007f5748806ce7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1 0x000056510579734e in kvm_vcpu_ioctl (cpu=0x565107b02350, type=44672) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:2079
#2 0x0000565105796cd5 in kvm_cpu_exec (cpu=0x565107b02350) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1929
#3 0x000056510577dc58 in qemu_kvm_cpu_thread_fn (arg=0x565107b02350) at /net/gimli/home/alwillia/Work/qemu.git/cpus.c:998
#4 0x00007f5748ad75ca in start_thread (arg=0x7f57373ff700) at pthread_create.c:333
#5 0x00007f57488110ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f5737c00700 (LWP 13131)):
#0 0x00007f5748806ce7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1 0x000056510579734e in kvm_vcpu_ioctl (cpu=0x565107ae2b20, type=44672) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:2079
#2 0x0000565105796cd5 in kvm_cpu_exec (cpu=0x565107ae2b20) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1929
#3 0x000056510577dc58 in qemu_kvm_cpu_thread_fn (arg=0x565107ae2b20) at /net/gimli/home/alwillia/Work/qemu.git/cpus.c:998
#4 0x00007f5748ad75ca in start_thread (arg=0x7f5737c00700) at pthread_create.c:333
#5 0x00007f57488110ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f5738401700 (LWP 13130)):
#0 0x00007f5748806ce7 in ioctl () at ../sysdeps/unix/syscall-template.S:84
#1 0x000056510579734e in kvm_vcpu_ioctl (cpu=0x565107a85270, type=44672) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:2079
#2 0x0000565105796cd5 in kvm_cpu_exec (cpu=0x565107a85270) at /net/gimli/home/alwillia/Work/qemu.git/kvm-all.c:1929
#3 0x000056510577dc58 in qemu_kvm_cpu_thread_fn (arg=0x565107a85270) at /net/gimli/home/alwillia/Work/qemu.git/cpus.c:998
#4 0x00007f5748ad75ca in start_thread (arg=0x7f5738401700) at pthread_create.c:333
#5 0x00007f57488110ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f573b221700 (LWP 13122)):
#0 0x00007f574880b239 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x0000565105c1b92f in futex_wait (ev=0x5651066c5624 <rcu_call_ready_event>, val=4294967295) at util/qemu-thread-posix.c:306
#2 0x0000565105c1ba32 in qemu_event_wait (ev=0x5651066c5624 <rcu_call_ready_event>) at util/qemu-thread-posix.c:422
#3 0x0000565105c31f30 in call_rcu_thread (opaque=0x0) at util/rcu.c:249
#4 0x00007f5748ad75ca in start_thread (arg=0x7f573b221700) at pthread_create.c:333
#5 0x00007f57488110ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f57638c4f80 (LWP 13114)):
#0 0x00007f5748805631 in __GI_ppoll (fds=0x565108f6e6b0, nfds=13, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:50
#1 0x0000565105b3b20b in qemu_poll_ns (fds=0x565108f6e6b0, nfds=13, timeout=2999772164) at qemu-timer.c:325
#2 0x0000565105b3a630 in os_host_main_loop_wait (timeout=2999772164) at main-loop.c:254
#3 0x0000565105b3a6f3 in main_loop_wait (nonblocking=0) at main-loop.c:508
#4 0x00005651058c9d80 in main_loop () at vl.c:1966
#5 0x00005651058d169e in main (argc=64, argv=0x7fff56193428, envp=0x7fff56193630) at vl.c:4684
next prev parent reply other threads:[~2016-11-11 21:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 20:48 [Qemu-devel] [PATCH v3 00/13] virtio: cleanup ioeventfd start/stop Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 01/13] virtio: disable ioeventfd as early as possible Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 02/13] virtio: move ioeventfd_disabled flag to VirtioBusState Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 03/13] virtio: move ioeventfd_started " Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 04/13] virtio: add start_ioeventfd and stop_ioeventfd to VirtioDeviceClass Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 05/13] virtio: introduce virtio_device_ioeventfd_enabled Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 06/13] virtio-blk: always use dataplane path if ioeventfd is active Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 07/13] virtio-scsi: " Paolo Bonzini
2016-11-11 4:09 ` Alex Williamson
2016-11-11 20:24 ` Paolo Bonzini
2016-11-11 21:03 ` Alex Williamson [this message]
2016-11-14 13:41 ` Paolo Bonzini
2016-11-14 17:09 ` Alex Williamson
2016-11-14 18:10 ` Paolo Bonzini
2016-11-14 18:49 ` Alex Williamson
2016-11-14 19:33 ` Paolo Bonzini
2016-11-14 19:48 ` Alex Williamson
2016-10-21 20:48 ` [Qemu-devel] [PATCH 08/13] Revert "virtio: Introduce virtio_add_queue_aio" Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 09/13] virtio: remove set_handler argument from set_host_notifier_internal Paolo Bonzini
2016-10-24 9:04 ` Cornelia Huck
2016-10-21 20:48 ` [Qemu-devel] [PATCH 10/13] virtio: remove ioeventfd_disabled altogether Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 11/13] virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 12/13] virtio: inline virtio_queue_set_host_notifier_fd_handler Paolo Bonzini
2016-10-21 20:48 ` [Qemu-devel] [PATCH 13/13] virtio: inline set_host_notifier_internal Paolo Bonzini
2016-10-24 13:08 ` [Qemu-devel] [14/13] fixup! virtio: remove set_handler argument from set_host_notifier_internal Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2016-10-10 11:53 [Qemu-devel] [PATCH 00/12] virtio: cleanup ioeventfd start/stop Paolo Bonzini
2016-10-10 11:53 ` [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active Paolo Bonzini
2016-10-19 10:51 ` Cornelia Huck
2016-10-19 11:34 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161111140342.7825fd1b@t450s.home \
--to=alex.williamson@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=famz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.