[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if
From: |
Alex Williamson |
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 |
On Fri, 11 Nov 2016 21:24:33 +0100
Paolo Bonzini <address@hidden> wrote:
> On 11/11/2016 05:09, Alex Williamson wrote:
> > On Fri, 21 Oct 2016 22:48:10 +0200
> > Paolo Bonzini <address@hidden> 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 <address@hidden>
> >> Signed-off-by: Paolo Bonzini <address@hidden>
> >> ---
> >> 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
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Alex Williamson, 2016/11/10
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Paolo Bonzini, 2016/11/11
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active,
Alex Williamson <=
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Paolo Bonzini, 2016/11/14
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Alex Williamson, 2016/11/14
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Paolo Bonzini, 2016/11/14
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Alex Williamson, 2016/11/14
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Paolo Bonzini, 2016/11/14
- Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active, Alex Williamson, 2016/11/14