RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1004275 - Qemu core dumpd, after deleting the tap in host
Summary: Qemu core dumpd, after deleting the tap in host
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: jason wang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-04 10:25 UTC by Qian Guo
Modified: 2014-10-21 11:26 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-21 11:24:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1004608 0 high CLOSED Qemu core dumpd, when delete the tap interface that is used by a vhost=on enabled guest 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1151306 0 medium CLOSED Qemu coredumpd after reboot a mq enabled but host-tap deleted guest. 2021-02-22 00:41:40 UTC

Internal Links: 1004608 1151306

Description Qian Guo 2013-09-04 10:25:58 UTC 
Description of problem:
Guest is booted w/ mq enabled and based openvswitch, when delete the tap interface in host, qemu-kvm core dumped.

Version-Release number of selected component (if applicable):
# uname -r
3.10.0-15.el7.x86_64
# rpm -q qemu-kvm
qemu-kvm-1.5.3-2.el7.x86_64

# rpm -q openvswitch
openvswitch-1.10.0-7.el7.dbmon_off.1.x86_64


How reproducible:
100%

Steps to Reproduce:
1.Boot a guest w/ openvswitch, and enabled multi-queues:
# /usr/libexec/qemu-kvm -cpu Penryn -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name rhel7base  -drive file=/mnt/rhel7cp1.qcow2_v3,if=none,id=drive-virtio-disk0,format=qcow2,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on -monitor stdio -netdev tap,id=hostnet0,ifname=guest1,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown,vhost=on,queues=4 -device virtio-net,netdev=hostnet0,mac=54:52:1b:35:3c:16,id=test,mq=on,vectors=9 -nodefaults -nodefconfig -spice port=5930,seamless-migration=on,password=redhat -vga qxl -global qxl-vga.vram_size=67108864   -device virtio-balloon-pci,id=balloon1 -qmp tcp:0:4446,server,nowait -device intel-hda,id=hda1 -device hda-duplex -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -serial unix:/tmp/qiguo,server,nowait

2.Delete tap interface "guest1" in host
# ip link delete guest1

3.

Actual results:
qemu-kvm core dumped:
(qemu) qemu-kvm: could not disable queue
qemu-kvm: /builddir/build/BUILD/qemu-1.5.3/hw/net/virtio-net.c:307: virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe9912700 (LWP 28717)]
0x00007ffff32e4999 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install alsa-lib-1.0.27.2-1.el7.x86_64 celt051-0.5.1.3-6.el7.x86_64 cyrus-sasl-lib-2.1.26-9.el7.x86_64 cyrus-sasl-md5-2.1.26-9.el7.x86_64 cyrus-sasl-plain-2.1.26-9.el7.x86_64 cyrus-sasl-scram-2.1.26-9.el7.x86_64 dbus-libs-1.6.12-4.el7.x86_64 flac-libs-1.3.0-2.el7.x86_64 glib2-2.36.3-2.el7.x86_64 glibc-2.17-21.el7.x86_64 glusterfs-3.4.0.15rhs-1.el7.x86_64 gmp-5.1.1-2.el7.x86_64 gnutls-3.1.13-1.el7.x86_64 gsm-1.0.13-9.el7.x86_64 json-c-0.11-1.el7.x86_64 keyutils-libs-1.5.5-4.el7.x86_64 krb5-libs-1.11.3-8.el7.x86_64 libICE-1.0.8-5.el7.x86_64 libSM-1.2.1-5.el7.x86_64 libX11-1.6.0-1.el7.x86_64 libXau-1.0.8-1.el7.x86_64 libXext-1.3.2-1.el7.x86_64 libXi-1.7.2-1.el7.x86_64 libXtst-1.2.2-1.el7.x86_64 libaio-0.3.109-9.el7.x86_64 libasyncns-0.8-5.el7.x86_64 libattr-2.4.46-10.el7.x86_64 libcap-2.22-6.el7.x86_64 libcom_err-1.42.8-2.el7.x86_64 libdb-5.3.21-11.el7.x86_64 libgcc-4.8.1-6.el7.x86_64 libgcrypt-1.5.3-1.el7.x86_64 libgpg-error-1.11-1.el7.x86_64 libiscsi-1.7.0-6.el7.x86_64 libjpeg-turbo-1.2.90-2.el7.x86_64 libogg-1.3.0-5.el7.x86_64 libpng-1.5.13-2.el7.x86_64 libseccomp-2.1.0-0.el7.x86_64 libselinux-2.1.13-16.el7.x86_64 libsndfile-1.0.25-7.el7.x86_64 libtasn1-3.3-1.el7.x86_64 libusbx-1.0.15-2.el7.x86_64 libuuid-2.23.2-2.el7.x86_64 libvorbis-1.3.3-4.el7.x86_64 libxcb-1.9-3.el7.x86_64 nettle-2.6-2.el7.x86_64 nspr-4.10-3.el7.x86_64 nss-3.15.1-2.el7.x86_64 nss-softokn-freebl-3.15.1-2.el7.x86_64 nss-util-3.15.1-2.el7.x86_64 openssl-libs-1.0.1e-15.el7.x86_64 p11-kit-0.18.5-1.el7.x86_64 pcre-8.32-7.el7.x86_64 pixman-0.30.0-1.el7.x86_64 pulseaudio-libs-3.0-10.el7.x86_64 spice-server-0.12.4-1.el7.x86_64 tcp_wrappers-libs-7.6-75.el7.x86_64 usbredir-0.6-3.el7.x86_64 zlib-1.2.7-10.el7.x86_64
(gdb) bt
#0  0x00007ffff32e4999 in raise () from /lib64/libc.so.6
#1  0x00007ffff32e60a8 in abort () from /lib64/libc.so.6
#2  0x00007ffff32dd906 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff32dd9b2 in __assert_fail () from /lib64/libc.so.6
#4  0x000055555577af3a in virtio_net_set_queues (n=0x555556747c58) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:307
#5  0x000055555577b173 in virtio_net_set_multiqueue (multiqueue=1, n=0x555556747c58) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:1075
#6  virtio_net_set_features (vdev=<optimized out>, features=818937827) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:367
#7  0x0000555555786c3f in virtio_set_features (vdev=0x555556747c58, val=818937827) at /usr/src/debug/qemu-1.5.3/hw/virtio/virtio.c:846
#8  0x000055555578c4c2 in access_with_adjusted_size (addr=addr@entry=4, value=value@entry=0x7fffe9911b58, size=4, access_size_min=<optimized out>, 
    access_size_max=<optimized out>, access=access@entry=0x55555578ca80 <memory_region_write_accessor>, opaque=opaque@entry=0x555556747b10)
    at /usr/src/debug/qemu-1.5.3/memory.c:364
#9  0x000055555578d997 in memory_region_iorange_write (iorange=<optimized out>, offset=4, width=4, data=818937827) at /usr/src/debug/qemu-1.5.3/memory.c:439
#10 0x000055555578b21c in kvm_handle_io (count=1, size=4, direction=1, data=<optimized out>, port=49220) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1492
#11 kvm_cpu_exec (env=env@entry=0x5555566dac00) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1638
#12 0x0000555555735e45 in qemu_kvm_cpu_thread_fn (arg=0x5555566dac00) at /usr/src/debug/qemu-1.5.3/cpus.c:793
#13 0x00007ffff625dde3 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff33a50ad in clone () from /lib64/libc.so.6


Expected results:
No core dumped

Additional info:

Test w/ bridge-utils based guest, no such issue.
Comment 2 Qian Guo 2013-09-29 09:40:53 UTC 
Test this with macvtap:
Steps:
1.Boot guest w/ macvtap and mq enabled, but use the non-exist macvtap interface:

# /usr/libexec/qemu-kvm -M q35 -cpu Penryn -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -usb -device usb-tablet,id=input0 -name rhel7 -rtc base=localtime,clock=host,driftfix=slew -device ahci,id=ahci1 -drive file=/home/rhel7cp1.qcow2_v3,if=none,id=drive-ahci,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device ide-drive,bus=ahci1.0,unit=0,drive=drive-ahci,id=sata-disk -device virtio-balloon-pci,id=balloon1 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -monitor stdio -serial unix:/tmp/ttyS0,server,nowait -qmp tcp:0:4444,server,nowait -spice disable-ticketing,port=5930,seamless-migration=on -vga std -netdev tap,id=netdev0,vhost=on,fds=10:20:30:40 10<>/dev/tap24 20<>/dev/tap24 30<>/dev/tap24 40<>/dev/tap24  -device virtio-net-pci,mq=on,vectors=9,mac=00:1b:21:7a:76:87,netdev=netdev0,id=vnic0

note: the tap24 does not exist.

then the qemu core dumped, info is same as reporter:
(gdb) bt
#0  0x00007ffff32e0999 in raise () from /lib64/libc.so.6
#1  0x00007ffff32e20a8 in abort () from /lib64/libc.so.6
#2  0x00007ffff32d9906 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff32d99b2 in __assert_fail () from /lib64/libc.so.6
#4  0x000055555577520a in virtio_net_set_queues (n=0x5555567695a8) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:307
#5  0x0000555555775443 in virtio_net_set_multiqueue (multiqueue=1, n=0x5555567695a8) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:1075
#6  virtio_net_set_features (vdev=<optimized out>, features=818872416) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:367
#7  0x000055555578056f in virtio_set_features (vdev=0x5555567695a8, val=818872416) at /usr/src/debug/qemu-1.5.3/hw/virtio/virtio.c:846
#8  0x0000555555785db2 in access_with_adjusted_size (addr=addr@entry=4, value=value@entry=0x7fffea01cb58, size=4, access_size_min=<optimized out>, 
    access_size_max=<optimized out>, access=access@entry=0x555555786370 <memory_region_write_accessor>, opaque=opaque@entry=0x555556769460)
    at /usr/src/debug/qemu-1.5.3/memory.c:364
#9  0x0000555555787287 in memory_region_iorange_write (iorange=<optimized out>, offset=4, width=4, data=818872416) at /usr/src/debug/qemu-1.5.3/memory.c:439
#10 0x0000555555784b4c in kvm_handle_io (count=1, size=4, direction=1, data=<optimized out>, port=49156) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1492
#11 kvm_cpu_exec (env=env@entry=0x5555566c16c0) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1638
#12 0x0000555555730045 in qemu_kvm_cpu_thread_fn (arg=0x5555566c16c0) at /usr/src/debug/qemu-1.5.3/cpus.c:793
#13 0x00007ffff625ade3 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff33a10dd in clone () from /lib64/libc.so.6
Comment 3 jason wang 2013-11-06 09:09:13 UTC 
(In reply to Qian Guo from comment #0)
> Description of problem:
> Guest is booted w/ mq enabled and based openvswitch, when delete the tap
> interface in host, qemu-kvm core dumped.
> 
> Version-Release number of selected component (if applicable):
> # uname -r
> 3.10.0-15.el7.x86_64
> # rpm -q qemu-kvm
> qemu-kvm-1.5.3-2.el7.x86_64
> 
> # rpm -q openvswitch
> openvswitch-1.10.0-7.el7.dbmon_off.1.x86_64
> 
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.Boot a guest w/ openvswitch, and enabled multi-queues:
> # /usr/libexec/qemu-kvm -cpu Penryn -enable-kvm -m 4096 -smp
> 4,sockets=1,cores=4,threads=1 -name rhel7base  -drive
> file=/mnt/rhel7cp1.qcow2_v3,if=none,id=drive-virtio-disk0,format=qcow2,
> werror=stop,rerror=stop,aio=native -device
> virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on
> -monitor stdio -netdev
> tap,id=hostnet0,ifname=guest1,script=/etc/ovs-ifup,downscript=/etc/ovs-
> ifdown,vhost=on,queues=4 -device
> virtio-net,netdev=hostnet0,mac=54:52:1b:35:3c:16,id=test,mq=on,vectors=9
> -nodefaults -nodefconfig -spice
> port=5930,seamless-migration=on,password=redhat -vga qxl -global
> qxl-vga.vram_size=67108864   -device virtio-balloon-pci,id=balloon1 -qmp
> tcp:0:4446,server,nowait -device intel-hda,id=hda1 -device hda-duplex
> -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -serial
> unix:/tmp/qiguo,server,nowait
> 
> 2.Delete tap interface "guest1" in host
> # ip link delete guest1
> 
> 3.
> 
> Actual results:
> qemu-kvm core dumped:
> (qemu) qemu-kvm: could not disable queue
> qemu-kvm: /builddir/build/BUILD/qemu-1.5.3/hw/net/virtio-net.c:307:
> virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffe9912700 (LWP 28717)]
> 0x00007ffff32e4999 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> alsa-lib-1.0.27.2-1.el7.x86_64 celt051-0.5.1.3-6.el7.x86_64
> cyrus-sasl-lib-2.1.26-9.el7.x86_64 cyrus-sasl-md5-2.1.26-9.el7.x86_64
> cyrus-sasl-plain-2.1.26-9.el7.x86_64 cyrus-sasl-scram-2.1.26-9.el7.x86_64
> dbus-libs-1.6.12-4.el7.x86_64 flac-libs-1.3.0-2.el7.x86_64
> glib2-2.36.3-2.el7.x86_64 glibc-2.17-21.el7.x86_64
> glusterfs-3.4.0.15rhs-1.el7.x86_64 gmp-5.1.1-2.el7.x86_64
> gnutls-3.1.13-1.el7.x86_64 gsm-1.0.13-9.el7.x86_64 json-c-0.11-1.el7.x86_64
> keyutils-libs-1.5.5-4.el7.x86_64 krb5-libs-1.11.3-8.el7.x86_64
> libICE-1.0.8-5.el7.x86_64 libSM-1.2.1-5.el7.x86_64 libX11-1.6.0-1.el7.x86_64
> libXau-1.0.8-1.el7.x86_64 libXext-1.3.2-1.el7.x86_64
> libXi-1.7.2-1.el7.x86_64 libXtst-1.2.2-1.el7.x86_64
> libaio-0.3.109-9.el7.x86_64 libasyncns-0.8-5.el7.x86_64
> libattr-2.4.46-10.el7.x86_64 libcap-2.22-6.el7.x86_64
> libcom_err-1.42.8-2.el7.x86_64 libdb-5.3.21-11.el7.x86_64
> libgcc-4.8.1-6.el7.x86_64 libgcrypt-1.5.3-1.el7.x86_64
> libgpg-error-1.11-1.el7.x86_64 libiscsi-1.7.0-6.el7.x86_64
> libjpeg-turbo-1.2.90-2.el7.x86_64 libogg-1.3.0-5.el7.x86_64
> libpng-1.5.13-2.el7.x86_64 libseccomp-2.1.0-0.el7.x86_64
> libselinux-2.1.13-16.el7.x86_64 libsndfile-1.0.25-7.el7.x86_64
> libtasn1-3.3-1.el7.x86_64 libusbx-1.0.15-2.el7.x86_64
> libuuid-2.23.2-2.el7.x86_64 libvorbis-1.3.3-4.el7.x86_64
> libxcb-1.9-3.el7.x86_64 nettle-2.6-2.el7.x86_64 nspr-4.10-3.el7.x86_64
> nss-3.15.1-2.el7.x86_64 nss-softokn-freebl-3.15.1-2.el7.x86_64
> nss-util-3.15.1-2.el7.x86_64 openssl-libs-1.0.1e-15.el7.x86_64
> p11-kit-0.18.5-1.el7.x86_64 pcre-8.32-7.el7.x86_64
> pixman-0.30.0-1.el7.x86_64 pulseaudio-libs-3.0-10.el7.x86_64
> spice-server-0.12.4-1.el7.x86_64 tcp_wrappers-libs-7.6-75.el7.x86_64
> usbredir-0.6-3.el7.x86_64 zlib-1.2.7-10.el7.x86_64
> (gdb) bt
> #0  0x00007ffff32e4999 in raise () from /lib64/libc.so.6
> #1  0x00007ffff32e60a8 in abort () from /lib64/libc.so.6
> #2  0x00007ffff32dd906 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x00007ffff32dd9b2 in __assert_fail () from /lib64/libc.so.6
> #4  0x000055555577af3a in virtio_net_set_queues (n=0x555556747c58) at
> /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:307
> #5  0x000055555577b173 in virtio_net_set_multiqueue (multiqueue=1,
> n=0x555556747c58) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:1075
> #6  virtio_net_set_features (vdev=<optimized out>, features=818937827) at
> /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:367
> #7  0x0000555555786c3f in virtio_set_features (vdev=0x555556747c58,
> val=818937827) at /usr/src/debug/qemu-1.5.3/hw/virtio/virtio.c:846
> #8  0x000055555578c4c2 in access_with_adjusted_size (addr=addr@entry=4,
> value=value@entry=0x7fffe9911b58, size=4, access_size_min=<optimized out>, 
>     access_size_max=<optimized out>, access=access@entry=0x55555578ca80
> <memory_region_write_accessor>, opaque=opaque@entry=0x555556747b10)
>     at /usr/src/debug/qemu-1.5.3/memory.c:364
> #9  0x000055555578d997 in memory_region_iorange_write (iorange=<optimized
> out>, offset=4, width=4, data=818937827) at
> /usr/src/debug/qemu-1.5.3/memory.c:439
> #10 0x000055555578b21c in kvm_handle_io (count=1, size=4, direction=1,
> data=<optimized out>, port=49220) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1492
> #11 kvm_cpu_exec (env=env@entry=0x5555566dac00) at
> /usr/src/debug/qemu-1.5.3/kvm-all.c:1638
> #12 0x0000555555735e45 in qemu_kvm_cpu_thread_fn (arg=0x5555566dac00) at
> /usr/src/debug/qemu-1.5.3/cpus.c:793
> #13 0x00007ffff625dde3 in start_thread () from /lib64/libpthread.so.0
> #14 0x00007ffff33a50ad in clone () from /lib64/libc.so.6
> 
> 
> Expected results:
> No core dumped
> 
> Additional info:
> 
> Test w/ bridge-utils based guest, no such issue.

I suspect bridge hold an extra reference count for tap. For bridge, what happens, if:

1) brctl delif
2) ip link delete guest 1

?
Comment 4 jason wang 2013-11-06 09:10:38 UTC 
(In reply to Qian Guo from comment #2)
> Test this with macvtap:
> Steps:
> 1.Boot guest w/ macvtap and mq enabled, but use the non-exist macvtap
> interface:
> 
> # /usr/libexec/qemu-kvm -M q35 -cpu Penryn -enable-kvm -m 4096 -smp
> 4,sockets=1,cores=4,threads=1 -usb -device usb-tablet,id=input0 -name rhel7
> -rtc base=localtime,clock=host,driftfix=slew -device ahci,id=ahci1 -drive
> file=/home/rhel7cp1.qcow2_v3,if=none,id=drive-ahci,format=qcow2,cache=none,
> aio=native,werror=stop,rerror=stop -device
> ide-drive,bus=ahci1.0,unit=0,drive=drive-ahci,id=sata-disk -device
> virtio-balloon-pci,id=balloon1 -global PIIX4_PM.disable_s3=0 -global
> PIIX4_PM.disable_s4=0 -monitor stdio -serial unix:/tmp/ttyS0,server,nowait
> -qmp tcp:0:4444,server,nowait -spice
> disable-ticketing,port=5930,seamless-migration=on -vga std -netdev
> tap,id=netdev0,vhost=on,fds=10:20:30:40 10<>/dev/tap24 20<>/dev/tap24
> 30<>/dev/tap24 40<>/dev/tap24  -device
> virtio-net-pci,mq=on,vectors=9,mac=00:1b:21:7a:76:87,netdev=netdev0,id=vnic0
> 
> note: the tap24 does not exist.
> 
> then the qemu core dumped, info is same as reporter:
> (gdb) bt
> #0  0x00007ffff32e0999 in raise () from /lib64/libc.so.6
> #1  0x00007ffff32e20a8 in abort () from /lib64/libc.so.6
> #2  0x00007ffff32d9906 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x00007ffff32d99b2 in __assert_fail () from /lib64/libc.so.6
> #4  0x000055555577520a in virtio_net_set_queues (n=0x5555567695a8) at
> /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:307
> #5  0x0000555555775443 in virtio_net_set_multiqueue (multiqueue=1,
> n=0x5555567695a8) at /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:1075
> #6  virtio_net_set_features (vdev=<optimized out>, features=818872416) at
> /usr/src/debug/qemu-1.5.3/hw/net/virtio-net.c:367
> #7  0x000055555578056f in virtio_set_features (vdev=0x5555567695a8,
> val=818872416) at /usr/src/debug/qemu-1.5.3/hw/virtio/virtio.c:846
> #8  0x0000555555785db2 in access_with_adjusted_size (addr=addr@entry=4,
> value=value@entry=0x7fffea01cb58, size=4, access_size_min=<optimized out>, 
>     access_size_max=<optimized out>, access=access@entry=0x555555786370
> <memory_region_write_accessor>, opaque=opaque@entry=0x555556769460)
>     at /usr/src/debug/qemu-1.5.3/memory.c:364
> #9  0x0000555555787287 in memory_region_iorange_write (iorange=<optimized
> out>, offset=4, width=4, data=818872416) at
> /usr/src/debug/qemu-1.5.3/memory.c:439
> #10 0x0000555555784b4c in kvm_handle_io (count=1, size=4, direction=1,
> data=<optimized out>, port=49156) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1492
> #11 kvm_cpu_exec (env=env@entry=0x5555566c16c0) at
> /usr/src/debug/qemu-1.5.3/kvm-all.c:1638
> #12 0x0000555555730045 in qemu_kvm_cpu_thread_fn (arg=0x5555566c16c0) at
> /usr/src/debug/qemu-1.5.3/cpus.c:793
> #13 0x00007ffff625ade3 in start_thread () from /lib64/libpthread.so.0
> #14 0x00007ffff33a10dd in clone () from /lib64/libc.so.6

This is expected because you are trying to ioctl to a non-tap device. We may need a more robust handling of detaching/attaching failure BTW.
Comment 5 jason wang 2013-11-06 09:56:30 UTC 
Ok, test with bridge with delif first. Can reproduce. I believe we could just remove the assert() and give a warning instead. Qemu could not handle the mis-configuration of host then.
Comment 8 Ronen Hod 2014-02-17 07:26:10 UTC 
Deferring to 7.1. An easy fix, but the issue has to do with an unreasonable bahavior on the host
Comment 9 Vlad Yasevich 2014-02-17 15:37:33 UTC 
There is an additional way to trigger this issue that doesn't require a shutdown of qemu.

After the tap interface is deleted on the host, if the guest changes the number queues used by the virtio device, the guest will crash.

The expected behavior here would be a failure to change the number of queues.
A possible side-effect also might be that device link is turned off.

-vlad
Comment 11 Ronen Hod 2014-07-14 06:45:04 UTC 
Deferring.
QEMU cannot recover from a non-functioning (deleted) interface. Need to think what can be done.
Note You need to log in before you can comment on or make changes to this bug.